什么是Web应用架构？剖解网络应用程序

世界已经转移到互联网上，网络应用已经成为新的工作场所和商业商店。为了适应现代网络应用的各种目的，每一个网络应用都需要被设计成高性能和可定制的。

网络应用架构解决了这个问题。

网络应用程序架构定义了基于网络的应用程序的各个组成部分是如何结构化的。这种架构对于网络应用的性质和目的来说是非常具体的。为你的网络应用程序选择错误的架构会对你的业务造成严重的破坏。

在本指南中，我们将分解网络应用程序架构的概念，并了解它如何影响你的应用程序的最终用户体验。最后，我们还将看看你可以实施的一些最佳实践，以获得你的网络应用的最大收益。

1. 什么是网络应用程序架构？
2. 为什么网络应用程序架构很重要？
3. 网络应用程序架构是如何工作的？
4. 网络应用程序架构的类型
5. 网络应用程序架构的层级
6. 网络应用程序组件
7. 网络应用程序架构的最佳实践

什么是网络应用程序架构？

为了拉开讨论的序幕，让我们从网络应用架构的定义开始。

简单地说，网络应用程序架构是你的网络应用程序的各种组件如何相互作用的一个大纲。

它可以简单到定义客户端和服务器之间的关系。它也可以是复杂的，如定义容器化后端服务器群、负载均衡器、API网关和面向用户的单页前端之间的相互关系。

这就是说，很少有人会选择用哪种编程语言来写代码。

你如何设计你的网络应用程序对其可用性和成本优化都起着关键作用。下面是一个网络应用程序架构样本的纸面情况。

一个推荐应用程序的架构图（图片来源：维基百科）

为什么网络应用程序架构很重要？

毫无疑问，网络应用程序架构是你的网络应用程序中最重要的部分之一。如果你选择以特定的架构来开发你的网络应用，那么在维护和发展你的应用时，你肯定会收到许多好处。

然而，选择正确的架构可以进一步放大这些好处。

以下是你应该认真考虑采用网络应用程序架构的一些首要原因。

轻松适应业务需求

你的应用程序是你业务的一个关键门户，而业务需求随着市场的变化而变化。为了与时俱进，你会希望你的应用程序足够灵活，以适应你不断变化的业务需求。如果你在建立一个应用程序时没有考虑到内置的灵活性，你必然会花费越来越多的时间和精力来对你的应用程序进行微小的调整。

正确的网络应用程序架构已经考虑到了你的业务在未来可能需要的一些变化。例如，如果你知道你正在建立一个电子商务应用程序，该应用程序将在某一天扩展并满足大量客户的广泛服务，那么选择一个微服务架构而不是单体架构将为你提供更多的灵活性。

另一方面，如果你正在为公司建立一个只有一两个固定需求的内部应用，你可以选择一个更简单的单片机，以加快开发速度并保持代码库的清洁。

有组织的发展

正如我们前面提到的，正确的网络应用程序架构为你提供了一个更方便的开发路线图。架构在你的系统中提供了足够的模块化，以便在必要时隔离组件，你可以根据需要为每个模块和组件自由选择合适的项目结构。

如果你在没有考虑到架构的情况下潜入应用开发，你就有可能浪费时间和金钱来重新组织你的组件和制定新的规则，以帮助促进团队成员之间的协作–这些时间和金钱本来可以用在其他地方。

更好的代码库管理

除了编写你的应用程序的代码，你还会花相当多的时间来管理它。组织你的项目文件，将你的应用程序分解成模块，并设置自定义管道，这些只是需要积极维护以确保顺利开发的少数任务。

正确的网络应用程序架构使你很容易做出改变。你可以实施特定组件的最佳实践，将你的应用程序的痛点彼此分开，并保持每个功能的独立和松散耦合。这并不是说没有架构就不能做这些
事情，只是正确的架构让所有这些事情变得更加简单。

遵循预先定义的架构也使你很容易更快地开发你的应用程序。正确的架构与完善的版本控制策略相结合，可以使你的开发人员相互平行工作，更快地构建功能。

一个网络应用程序架构还能使你的应用程序面向未来。一旦你围绕如何组织你的应用程序的组件定义了一个坚实的战略，你可以很容易地将这些组件逐一迁移到较新的技术，而不必重新做你的整个应用程序。

增强安全性

大多数网络应用程序架构在构建组件时都考虑了安全因素。开发人员可以提前计划实施的措施和做法，以便在向用户推出之前提高应用程序的安全性。

例如，使用微服务构建一个同时提供付费和免费内容的OTT视频流应用更有意义，因为微服务架构使你能够将你的应用分割成业务友好的组件，如用户认证和免费或付费内容流。如果你的用户认证模块出现故障，你可以很容易地配置你的应用程序，限制对付费内容模块的访问，直到认证恢复，而免费内容模块仍然可以为你的用户提供。

在另一种情况下，同样的应用程序被设计成紧密耦合的单体，认证服务瘫痪将意味着应用程序瘫痪或付费内容被免费提供–你会想不惜一切代价避免这种结果。

网络应用程序架构是如何工作的？

在我们谈论网络应用程序架构如何工作之前，重要的是要了解一个简单的网站如何工作：

1. 用户在浏览器的地址栏中输入你的应用程序的URL或点击一个链接。
2. 浏览器在DNS服务器中查找该URL，并确定你的应用程序的IP地址。
3. 浏览器向你的应用程序发送一个HTTP请求。
4. 你的应用程序以正确的内容（通常是一个网页）作出反应。
5. 浏览器将网页呈现在屏幕上。

如果你再深入一点，以下是一个网络应用如何处理一个请求：

1. 用户通过你的前端用户界面向你的应用程序发送一个请求。
2. 如果你设置了相关的缓存，应用程序会首先检查它是否有一个有效的记录，可以直接发回给客户端。如果有，缓存的内容就会被送回来，而请求将被标记为完成。
3. 如果没有缓存，请求将被转发到负载平衡器。
4. 负载平衡器确定一个可以处理请求的服务器实例，并将其转发。
5. 服务器实例处理请求并在需要时调用任何外部API。
6. 一旦在一个地方收集到结果，服务器就会将响应发回给负载均衡器。负载均衡器将响应返回给API网关，而API网关又将其下发到前端客户端的用户手中。然后，该请求被标记为完成。

网络应用程序架构的类型

现在你对什么是网络应用程序架构有了一个基本的概念，让我们详细了解一下整个网络应用程序架构的一些流行类型。

单页结构

单页应用程序（SPA）的架构和它的名字一样简单：整个应用程序基于一个单页。一旦用户拉起你的应用程序，他们不需要导航到任何其他网页。该应用被做成动态的，足以在用户浏览应用本身时获取和呈现符合用户要求的屏幕。

当涉及到为终端用户或消费者提供快速和无缝的体验时，SPA是很好的。然而，它们缺乏传统网站的触感，而且它们可能难以为搜索引擎优化。

SPA架构的优点

SPA架构的一些优点包括：

• 你可以建立高度互动的网络应用。
• SPA很容易扩展。
• 优化SPA的性能并不需要太多的努力。

SPA架构的缺点

SPA架构的几个缺点是：

• SPA限制了超链接和SEO的灵活性。
• 最初的渲染通常很慢。
• 通过该应用程序的导航可能是不直观的。

渐进式网络应用程序架构

渐进式网络应用程序（PWA）架构建立在单页架构之上，为您的网络应用程序提供离线功能。Capacitor和Ionic等技术被用来构建PWA，可以为用户提供跨平台的统一体验。

与SPA类似，PWA是平滑和无缝的。由于增加了安装在用户设备上的能力（通过服务工作者），你的用户在你的应用程序上得到了更统一的体验。

同时，为搜索引擎优化这类应用程序可能很困难，而且已安装的应用程序的更新也很难推动。

PWA架构的优点

PWA架构有许多好处，包括：

• 应用程序运行非常流畅，并提供跨平台的兼容性。
• 可扩展性很简单。
• 开发人员可以访问离线访问和设备原生API，如后台工作者和推送通知。

PWA架构的缺点

PWA架构的一些缺点可能包括。

• 对链接管理和SEO的支持有限。
• 向离线的PWA推送更新比本地应用程序更复杂。
• 各个网络浏览器和操作系统对PWA的支持都很有限。

服务器端渲染的架构

在服务器端渲染（SSR）中，前端的网页在被用户请求后在后端服务器上进行渲染。这有助于减少客户端设备的负载，因为它收到的是静态HTML、CSS和JS网页。

SSR应用程序在博客和电子商务网站中非常流行。这是因为它们使链接管理和SEO变得相当简单。此外，SSR应用程序的首次渲染是相当快的，因为客户端不需要处理任何JS代码来渲染屏幕。

SSR架构的优点

下面列出了SSR架构的一些优点：

• 这些应用程序对于SEO重的网站来说是非常好的。
• 在大多数情况下，第一页的加载几乎是即时的。
• 你可以将它与缓存服务配对，以进一步提高你的应用程序的性能。

SSR架构的缺点

使用SSR架构的几个缺点包括：

• 对于复杂或繁重的网页，不建议使用这种方法，因为服务器可能需要时间来完全生成页面，导致首次渲染延迟。
• 它主要被推荐给那些不太关注用户界面，只想提高可扩展性或安全性的应用程序。

预先渲染的应用程序架构

预先渲染的应用程序架构也被称为静态网站生成架构。在这种架构中，应用程序的前端网页是预先生成的，并作为普通的HTML、CSS和JS文件存储在服务器上。一旦用户请求一个页面，它就
被直接获取并显示给他们。这使得网络应用非常快，任何类型的加载时间都最小。

然而，这种架构增加了应用程序的构建时间，因为网页是在构建过程中渲染的。当你想生成静态内容，如博客或不经常变化的产品细节时，预渲染的网页应用程序是很好的选择。你还可以利用模板来简化你的网页设计。然而，使用这种架构几乎不可能建立动态的网络应用。如果你想建立一个以查询为路径的搜索页面（类似 https://myapp.com/search/foo+bar），你就找错地方了。

由于应用程序的每条可能的路线都是在构建过程中预先渲染的，所以不可能有上述的动态路线，因为有无限的可能性，在构建过程中无法预先渲染（而且这样做也没有意义）。

预渲染架构的优点

预渲染应用程序架构的几大好处是：

• 网页是用纯HTML、CSS和JS生成的；因此其性能与使用vanilla JS构建的应用程序相似。
• 如果你知道你的应用程序的所有可能的路线，SEO就会变得超级容易。

预渲染架构的缺点

与任何建筑模型一样，预渲染也有其缺点：

• 动态内容不能通过这些应用程序提供。
• 对网络应用的任何改变都意味着完全重建并从头部署该应用。

同构的应用架构

同构应用程序是那些混合了服务器端渲染的应用程序和SPA的应用程序。这意味着这类应用首先在服务器上被渲染成普通的服务器端渲染的应用。一旦被客户端接收，该应用就会将自己水化，并附加上虚拟DOM，以便更快、更有效地进行客户端处理。这实质上将应用程序变成了一个单页应用程序。

Isomorphic将两个世界的优点结合起来。由于SPA的存在，你可以在客户端获得超快的处理和用户界面。由于服务器端的渲染，你还可以得到快速的初始渲染和成熟的SEO和链接支持。

同构式架构的优点

以下是使用同构式应用架构的一些好处：

• Isomorphic应用程序具有超快的初始渲染和对SEO的全面支持。
• 这些应用程序在客户端也表现良好，因为它们在加载后变成了SPA。

同构式架构的缺点

同构应用架构的一些缺点可以是：

• 设置这样的应用程序需要熟练的人才。
• 当涉及到设计一个同构的应用程序时，技术栈的选择是有限的。你只能从少数几个（大部分）基于JS的库和框架中选择。

面向服务的架构

面向服务的架构是最受欢迎的替代传统的单片机构建应用程序的方式之一。在这种架构中，网络应用被分解为代表每个业务功能单元的服务。这些服务被松散地耦合在一起，并通过消息传递的媒介相互作用。

面向服务的架构为你的应用技术栈增加了稳定性和可扩展性。然而，SOA中的服务规模没有明确的定义，通常与业务组件而不是技术组件相联系；因此，维护有时会成为一个问题。

面向服务的架构的优点

面向服务的架构的主要好处包括：

• 这种架构有助于建立高度可扩展和可靠的应用程序。
• 组件是可重复使用的，并被共享以加强开发和维护工作。

面向服务的架构的缺点

这里列出了使用面向服务架构的潜在缺点：

• SOA应用程序仍然不是100%的灵活，因为每个服务的规模和范围都不固定。可能会有企业应用程序大小的服务难以维护。
• 组件共享引入了服务之间的依赖性。

微服务架构

微服务架构的设计是为了解决面向服务架构的问题。微服务是更加模块化的组件，它们配合在一起构建一个网络应用。然而，微服务专注于保持每个组件的小型化和有边界的上下文。有界限的上下文本质上意味着每个微服务的代码和数据都耦合在一起，对其他微服务的依赖性最小。

微服务架构可能是构建旨在有朝一日扩展到数千乃至数百万用户的应用程序的最佳架构。每个组件都是有弹性的，可扩展的，并且易于维护。然而，维护基于微服务的应用程序的DevOps生命周期需要额外的努力，因此它可能不适合较小的用例。

微服务架构的优点

微服务架构的一些优点包括：

• 与面向服务架构的组件相比，应用程序组件具有高度的模块化、独立性，并且可以在更大程度上被重复使用。
• 每个组件都可以独立扩展，以满足不同的用户流量。
• 基于微服务的应用程序具有高度的容错性。

微服务架构的缺点

微服务架构的一个缺点可能是：

• 对于较小的项目，微服务架构可能需要太多的精力来维护。

无服务器架构

无服务器架构是网络应用程序架构世界中的另一个热门加入者。这种架构的重点是将你的应用分解为它应该执行的功能。然后，这些功能被托管在FaaS（Function-as-a-Service，功能即服务）平台上，当有请求时被调用。

与本列表中的大多数其他架构不同，使用无服务器架构构建的应用程序不会一直保持运行。它们的行为就像函数一样–等待被调用，并在被调用后，运行所定义的流程并返回结果。由于这种性质，它们减少了维护成本，并且不费吹灰之力就能高度扩展。然而，使用这种组件很难执行长期运行的任务。

无服务器架构的优点

以下是无服务器架构的主要好处：

• 无服务器应用程序具有高度和轻松的可扩展性。它们甚至可以实时适应进入的流量，以减少基础设施的负载。
• 这类应用程序可以利用无服务器平台的按使用量付费的定价模式来降低基础设施成本。
• 无服务器应用程序的构建和部署相当容易，因为你所要做的就是编写一个函数并将其托管在Firebase函数、AWS Lambda等平台上。

无服务器架构的缺点

以下是无服务器架构的一些弊端：

• 在这样的架构上，长期运行的任务可能成本很高。
• 当一个函数在很长时间后收到一个请求时，它被称为冷启动。冷启动很慢，会给你的终端用户带来不好的体验

网络应用程序架构的层级

虽然你在上面看到的网络应用程序架构可能看起来都很不一样，但它们的组件可以逻辑地组合成明确的层，帮助实现业务目标。

表示层

表示层指的是网络应用中暴露给最终用户的一切。主要来说，表示层是由前端客户端组成的。然而，它也包含了你在后端编写的任何逻辑，以使你的前端动态化。这为你提供了空间，使你可以根据用户的情况和要求定制UI，为用户提供服务。

三个基本技术被用来建立这个层。HTML、CSS和JavaScript。HTML描述了你的前端，CSS为它设计了样式，而JS则为它注入了活力（即，当用户与它互动时控制它的行为）。在这三种技术之上，你可以使用任何一种框架来帮助你的开发变得简单。一些常见的前端框架包括Laravel、React、NextJS、Vue、GatsbyJS等。

业务层

业务层负责持有和管理你的应用程序的工作逻辑。它通常是一个后端服务，接受来自客户端的请求并处理它们。它控制用户可以访问的内容，并决定如何利用基础设施来服务于用户请求。在酒店预订应用程序的情况下，你的客户端应用程序作为一个门户，供用户输入酒店名称和其他相关数据。

然而，一旦用户点击搜索按钮，业务层就会收到请求并启动逻辑，寻找符合你要求的可用酒店房间。然后，客户只是收到一个酒店房间的列表，而不知道这个列表是如何生成的，甚至不知道为什么列表中的项目会以它们被发送的方式排列。

这样一个层的存在确保了你的业务逻辑不会暴露给你的客户，最终也不会暴露给用户。隔离业务逻辑对处理支付或管理健康记录等敏感业务有极大的帮助。

持久层

持久层负责控制对你的数据存储的访问。它在你的数据存储和你的业务层之间充当了一个额外的抽象层。它从业务层接收所有与数据相关的调用，并通过与数据库的安全连接来处理它们。

这一层通常由一个数据库服务器组成。你可以通过在你的内部基础设施中配置一个数据库和一个数据库服务器来自己设置这一层，或者选择一个由领先的云基础设施供应商如AWS、GCP和Microsoft Azure等提供的远程/管理的解决方案。

网络应用程序组件

现在你已经了解了网络应用程序架构的内容，让我们来详细了解一下构成网络应用程序的每个组件。我们将讨论分为两个大标题–服务器端组件和客户端组件，或后端和前端组件。

服务器端组件

服务器端组件是那些驻扎在你的Web应用后台的组件。这些组件并不直接暴露在用户面前，而是为你的网络应用保存最重要的业务逻辑和资源。

DNS & Routing

DNS负责控制你的应用程序是如何暴露在网络上的。DNS记录被HTTP客户端（也可以是浏览器）用来寻找和发送请求到你的应用程序的组件。DNS也被你的前端客户在内部使用，以解决你的网络服务器和API端点的位置，以发送请求和处理用户操作。

负载平衡是网络应用架构的另一个流行的组成部分。负载平衡器被用来在多个相同的网络服务器之间分配HTTP请求。拥有多个网络服务器背后的意图是保持冗余，这有助于提高容错能力，以及分配流量以保持高性能。

API端点是用来向前端应用程序暴露后端服务的。这些有助于促进客户端和服务器之间的通信，有时甚至是多个服务器之间的通信。

数据存储

数据存储是大多数现代应用程序的关键部分，因为总有一些应用程序的数据需要跨用户会话持续存在。数据存储有两种类型。

• 数据库：数据库是用来存储数据以实现快速访问的。通常情况下，它们支持存储少量的、被你的应用程序定期访问的数据
• 数据仓库：数据仓库是用来保存历史数据的。这些数据在应用程序中通常不是经常需要的，但会定期处理以产生业务洞察力。

缓存

缓存是一种可选的功能，通常在网络应用程序架构中实现，以更快地向用户提供内容。很大一部分应用程序的内容通常在一定时间内是重复的，即使不是一直如此。与其从数据存储中访问它并在将其送回给用户之前对其进行处理，不如将其缓存起来。下面是在整个网络应用中使用的两种最流行的缓存类型：

• 数据缓存：数据缓存为你的应用程序提供了一种方法，可以轻松快速地访问经常使用的、不经常变化的数据。诸如Redis和Memcache等技术可以实现数据缓存，以节省昂贵的数据库查询，而这些查询只是为了重复检索相同的数据。
• 网页缓存：CDN（内容交付网络）缓存网页的方式与Redis缓存数据的方式相同。类似于
  只有不经常变化的数据才会被缓存，通常只有静态网页才被建议缓存。对于服务器端渲
  染的网络应用，缓存的作用不大，因为其内容应该是高度动态的。

工作和服务

除了向用户暴露界面（前端）和处理他们的请求（后端）之外，还有另一类稍不流行的Web应用组件。工作通常是后台服务，旨在完成不具时间敏感性或同步性的任务。

CRON作业是那些在固定时间段内反复运行的作业。这些工作是在后台安排的，在设定的时间自动运行维护程序。一些常见的例子包括从数据库中删除重复的/旧的记录，向客户发送提醒邮件，等等。

客户端组件

客户端组件是那些直接或间接暴露给用户的组件。这个类别中主要有两种类型的组件。

前端用户界面

用户界面是你的应用程序的视觉方面。它是你的用户为了访问你的服务而看到的和与之互动的东西。

前台界面主要是建立在三种流行的技术上。HTML、CSS和JavaScript。前端用户界面本身可以是一个应用程序，有自己的软件开发生命周期。

这些用户界面并不容纳你的很多业务逻辑，因为它们直接暴露在你的用户面前。如果一个恶意的用户试图对你的前端应用程序进行逆向工程，他们可以获得关于你的业务如何运作的信息，并进行品牌冒充和数据盗窃等非法活动。

另外，由于前端的用户界面直接暴露在用户面前，你要对其进行优化，以达到最小的加载时间和响应能力。有时这可以帮助你为用户提供更好的体验，从而提高你的业务增长。

客户端业务逻辑

有时你可能需要在你的客户端存储一些业务逻辑，以便快速执行更简单的操作。通常驻留在你的前端应用程序内的客户端逻辑可以帮助你跳过前往服务器的旅程，为你的用户提供更快的体验。

这是客户端组件的一个可选的功能。在某些情况下，应用程序的业务逻辑完全存储在客户端（特别是在没有传统后台服务器的情况下构建）。诸如BaaS这样的现代解决方案可以帮助你在前端应用中随时访问常见的操作，如认证、数据存储、文件存储等。

在向用户推广之前，有一些方法可以混淆或简化这些代码，以减少反向工程的机会。

网络应用程序组件的模式

网络应用程序架构有多种模式，每种模式都是基于网络服务器如何连接到其数据存储。

一个服务器，一个数据库

最简单的模型是一个网络服务器连接到一个数据库实例。这样的模型很容易实现和维护，而且在生产中使用它也是相当容易的。

由于其简单性，这种模式适用于学习和不会暴露于高流量的小型实验性应用。新手开发者可以轻松地设置和修补这些应用程序，以学习网络应用程序开发的基本原理。

然而，这种模式不应该在生产中使用，因为它是非常不可靠的。服务器或数据库的问题都可能导致停机和业务损失。

多个服务器，一个数据库

这种模式通过设置多个服务器的冗余和一个共同的数据库实例，将应用提高了一个档次。

由于多个网络服务器同时访问数据库，可能会出现不一致的问题。为了避免这种情况，网络服务器被设计为无状态。这意味着服务器不保留跨会话的数据；它们只是处理数据并将其存储在数据库中。

使用这种模式制作的应用程序当然比以前的模式更可靠，因为多个Web服务器的存在增加了Web应用程序的容错性。然而，由于数据库仍然是一个共同的实例，它是架构中最薄弱的环节，可能成为故障的来源。

多个服务器，多个数据库

这种模式是最常见的、传统的设计网络应用的模式之一。

在这种情况下，将你的应用逻辑部署为多个相同的Web服务器实例，并在负载平衡器后面将其聚集在一起。你的数据存储也在多个数据库实例中维护，以增加容错。

你也可以选择在可用的实例中拆分你的数据库以提高性能，或者维护整个数据存储的副本以实现冗余。在任何一种情况下，你的数据库的任何一个实例的故障都不会导致应用程序的完全中断。

这种模式因其可靠性和可扩展性而受到高度赞赏。然而，使用这种模式开发和维护应用程序是相对复杂的，需要昂贵的、经验丰富的开发人员。因此，这种模式只建议在你大规模建设时使用。

应用服务

虽然上面提到的三种模式很适合单体应用，但还有一种模式适合模块化应用。

应用服务模型根据业务功能将一个应用程序分解成更小的模块。这些模块可以小到一个功能，大到一个服务。

这里的想法是使每个业务功能独立和可扩展。这些模块中的每一个都可以独立连接到数据库。你甚至可以有专门的数据库实例来配合你的模块的可扩展性需求。

在非单片机应用中，这种模式相当流行。传统的单片机经常被迁移到这种模式，以利用其可扩展性和模块化的优势。然而，管理建立在这种模式上的应用程序往往需要经验丰富的开发人员，特别是在DevOps和CI/CD方面的经验。

网络应用程序架构的最佳实践

这里有一些最佳实践，你可以在你的网络应用程序项目中实施，以获得你所选择的网络应用程序架构的最大收益。

1. 使你的前台具有响应性

这一点怎么强调都不为过。始终以响应式前端为目标。无论你的网络应用内部有多庞大和复杂，它都是通过前端的网页、应用和屏幕暴露在你的用户面前。

如果你的用户发现这些屏幕是不直观的或缓慢的，他们就不会停留足够长的时间来查看和欣赏你的网络应用的工程奇迹。

因此，设计可访问的、易于使用的、轻量级的前台是非常重要的。

网络上有大量的UI/UX最佳实践，可以帮助你了解什么对你的用户最有效。你可以找到擅长制作用户友好型设计和架构的专业人士，他们可以使你的用户从你的应用程序中获得最大的收益。

我们建议在向用户推出你的产品之前，认真考虑你的前端的响应性。

2. .监控加载时间

除了易于理解之外，你的前台还需要快速加载。

根据Portent，最高的电子商务转换率发生在加载时间在0-2秒之间的页面上，根据Unbounce，大约70%的消费者承认，页面加载时间是他们选择从网上卖家购买的一个重要因素。

在设计移动原生应用程序时，你通常无法确定你的用户的设备规格。任何不符合你的应用程序要求的设备通常被宣布为不支持该应用程序。

然而，这与网络是完全不同的。

当涉及到网络应用时，你的用户可能使用任何东西，从最新的苹果Macbook M1 Pros到老式的黑莓和诺基亚手机来查看你的应用。为如此广泛的用户优化你的前端体验，有时会很困难。

谈到前端性能时，人们会想到LightHouse和Google PageSpeed等服务。在将你的前端应用部署到生产中之前，你应该使用这样的工具来对其进行基准测试。大多数这样的工具为你提供了一个可操作的提示列表，以帮助尽可能地提高你的应用程序的性能。

应用的最后5-10%的性能通常是针对你的用例的，只能由熟悉你的应用及其技术的人解决。对网络性能进行投资永远不会有坏处!

3. 在可能的情况下首选PWA

如前所述，PWA是未来的设计。它们可以很好地适应大多数的使用情况，而且它们在主要的平台上提供最统一的体验。

你应该尽可能多地考虑为你的应用程序使用PWA。跨越网络和移动的原生体验对你的用户有巨大的影响，同时也可以减少你自己的很多工作量。

PWA的加载速度也很快，易于优化，而且构建迅速。选择使用PWA可以帮助你在早期将大量的注意力从开发转移到业务上。

4. 保持你的代码库简洁明了

一个干净的代码库可以帮助你在造成损害之前发现并解决大多数问题。下面是一些你可以遵循的提示，以确保你的代码库不会给你带来任何不必要的麻烦。

• 专注于代码重用。在整个代码库中维护相同代码的副本不仅是多余的，而且还可能导致差异的出现，使你的代码库难以维护。始终专注于尽可能地重复使用代码。
• 规划你的项目结构。软件项目会随着时间的推移而变得非常庞大。如果你开始时没有计划好代码组织和资源的结构，你最终可能会花更多的时间去寻找文件而不是写有用的代码。
• 编写单元测试。每一块代码都有可能被破坏。手动测试所有的代码是不可行的，所以你需要一个固定的策略来对你的代码库进行自动测试。测试运行器和代码覆盖率工具可以帮助你确定你的单元测试工作是否产生了预期的结果。
• 高度模块化。在编写代码时，要始终关注模块化。编写与其他代码紧密耦合的代码会使其
  难以测试、重复使用和在需要时进行修改。

5. 自动化你的CI/CD流程

CI/CD是持续集成/持续部署的意思。CI/CD流程对你的应用程序的开发至关重要，因为它们可以帮助你轻松地构建、测试和部署你的项目。

然而，你不希望每次都要手动运行它们。相反，你应该建立管道，根据你的项目活动自动触发。例如，你可以建立一个管道，在你提交代码到版本控制系统时自动运行你的测试。也有很多更复杂的用例，比如每当创建一个版本时，从你的代码库中生成跨平台的人工制品。

可能性是无穷无尽的，所以要看你如何能使你的CI/CD管道发挥最大作用。

6. 纳入安全功能

大多数现代应用程序是由多个组件组成的。以下面这个应用程序为例：

无服务器网络应用架构的例子

客户端请求是通过API网关转到应用程序的。虽然这个网关目前只允许直接请求到应用程序的主模块，但在未来，它可以允许访问更多的组件，而不需要通过主模块。

接下来，主页模块在允许访问之前检查外部认证BaaS。一旦通过认证，客户可以访问 “更新资料 “或 “查看资料 “页面。这两个页面都与处理档案数据的通用管理数据库解决方案互动

正如你所看到的，该应用程序似乎是一个非常基本和最小版本的在线人物目录。你可以添加/更新你自己的个人资料或查看其他可用的个人资料。

这里有一个关于架构中各个组成部分的快速图例：

• Blue boxes: 应用模块，可能作为微服务或无服务器功能托管。
• Red boxes: 提供认证和数据库的外部BaaS组件。
• Green box: 路由组件，对来自客户端的传入请求进行调节。
• Black box: 你的客户端应用程序暴露在用户面前。

上述每种颜色的组件都容易受到各种安全威胁。这里有一些安全结构，你可以把你的风险降到最低：

• 应用程序模块（蓝色）: 由于这些是无服务器的功能，这里有一些加强其安全性的提示:
  • 隔离应用程序的秘密，并独立于你的源代码进行管理
  • 通过IAM服务维持访问控制
    改进你的测试工作，通过SAST等技术寻找安全威胁。
• 外部服务（红色）:
  • 通过其IAM模块设置访问控制，以规范访问
  • 选择API速率限制
    对于数据库等服务，要设置更精细的控制权限，比如谁可以访问配置文件的数据，谁可以查看用户的数据，等等。许多服务，如Firebase，提供了一套详细的此类规则。
• 路由组件（绿色）:
  • 像所有其他组件一样，实施访问控制
  • 设置授权
    仔细检查标准的最佳做法，如CORS
• 客户:
  • 确保你的客户无法获得任何应用程序的机密信息
    混淆你的客户端代码，以减少逆向工程的机会

虽然这些只是一些建议，但它们说明了一个问题，即应用安全是复杂的，你有责任确保不给攻击者留下任何漏洞。你不能依靠一个中央安全组件来保护你的业务；应用程序的安全是分布在你的应用程序架构中。

7. 收集用户反馈

用户反馈是了解你的应用程序在业务和技术性能方面表现如何的重要工具。你可以建立世界上最轻、最流畅的应用程序，但如果它不能让你的用户做他们期望的事情，那么你所有的努力就会付诸东流。

有多种方法来收集用户反馈。虽然快速和匿名的调查是传统的方法，但你也可以选择更复杂的解决方案，如用户活动的热图。

选择收集反馈的方法不如对收集到的反馈采取行动重要。客户喜欢那些倾听他们问题的企业。像麦当劳和特斯拉这样的巨头都是这样做的，这也是他们在市场上持续成功的原因之一。

小结

网络是一个巨大的游乐场，里面有各种各样的应用程序，每一个都以自己独特的方式设计。多种类型的架构为网络应用的多样化、蓬勃发展和为全球用户提供服务创造了条件。

在本指南中，我们分解了网络应用程序架构的不同模式，并向你展示了它们对一个应用程序的发展有多么关键。

原文地址：https://www.wbolt.com/web-application-architecture.html