后端架构是指 Web 应用后端的结构。后端架构确定应用的各个部分如何相互通信，以处理传入请求并创建响应。构建 Web 应用时，请根据您的具体要求和因素选择后端架构，这些因素包括持续费用和大规模成本、应用的复杂性、扩缩目标，以及团队的专业知识。
特别是对于内容驱动的 Web 应用（例如电子商务、报纸或博客），关键要求包括数据和性能的一致性，尤其是当您的应用发展到全球规模和可能更加分散时。对于内容驱动的 Web 应用，应用使用的数据存储也至关重要，数据存储指南中对此进行了详细介绍。在优化应用性能时，不再局限于典型的应用架构，托管您的内容并使其可供访问至关重要。如需详细了解如何选择合适的托管策略和优化您的应用，请参阅托管指南。
如果您已经有一个 Web 应用后端，请考虑当前架构的限制。例如，随着应用的扩容以及性能和可靠性的提高需求，应考虑应重构应用的某些部分，或将应用的某些部分移至更适合您扩大规模的其他架构。例如，混合（或多云）架构允许您在完成完全转换之前将一些工作负载迁移到云端。考虑此类迁移所需的费用、时间和风险也很重要。
单体式架构
单体式架构具有统一的结构，应用的所有组件紧密集成到单个代码库中。整个应用作为一个独立的单元进行构建。单体式架构是多层式架构，其中不同的应用层需要完成特定任务。
结构层
- 界面 (UI) 包含用于呈现应用功能的组件，通常是与用户互动的 Web 应用或桌面应用。
- 应用逻辑是核心功能所在。代码库的这一部分包含定义应用如何工作的规则、计算和操作。
- 数据访问层包含用于读取和写入数据，以及在应用的数据结构和数据库架构之间进行转换的函数。该层负责与应用的数据库或数据存储交互。
- 数据库是应用存储其数据的位置。应用的所有数据（包括用户数据、配置和其他信息）通常只有一个数据库。
- 中间件组件可处理身份验证、请求路由和数据验证等任务。这些组件有助于管理数据流和请求。
- 某些单体式应用具有与外部服务或 API 的集成点。这些点允许应用与第三方服务、数据源或其他系统进行交互。
结构层通常是单个代码库的一部分。此代码库包含整个应用，通常分为目录、模块和类。开发者负责代码库的各个部分来构建和维护应用。但是，整个应用通常作为一个单元进行部署。当进行更新或更改时，整个应用都会重新部署。
潜在挑战
- 随着单体式应用的增长，代码库往往变得越来越复杂且难以维护。这可能会导致较长的开发周期，并且难以理解整个代码库。
- 将更改部署到单体式应用可能存在风险，因为对代码的某一部分所做的更改可能会无意中影响应用的其他部分。这可能会创建冗长且容易出错的部署过程。
- 单体式应用可能难以扩缩，因为它们作为一个单元进行部署。即使只有一个组件需要增加需求，也必须扩缩整个应用。
- 单体式应用通常依赖于单一技术栈或编程语言，因此，在应用中针对特定任务使用最佳工具的能力可能会受到限制。
- 即使在需求较低时，单体式应用也需要大量资源才能运行。随着应用的老化，维护费用也会增加，因为更新和修补应用而不会导致回归变得愈发困难。
- 开发单体式应用的开发团队通常围绕整个应用进行组织，这会导致团队规模较大，团队成员之间的协调也变得更加复杂。
建议用法
单体式架构适用于应用要求适度且开发团队规模较小的情况。随着应用的复杂性和规模提高，或者应用的不同部分需要不同的技术或部署策略，单体式架构的灵活性可能会降低，维护难度也会增加。
您可以创建和管理可在 Compute Engine 上运行单体式应用的虚拟机。您可以完全控制这些虚拟机的操作系统、软件和管理，以便运行单体式应用。
通过 App Engine 等平台即服务服务，您可以构建应用并在可随请求自动扩缩的全代管式基础架构上运行应用。
如果您的单体式应用已容器化，您可以使用 Google Kubernetes Engine (GKE) 或 Cloud Run 运行该应用。Cloud SQL 或 Cloud Spanner 等服务可用于存储单体式应用的数据。请考虑根据应用的具体要求来组合使用各种服务和系统。
无服务器架构
利用无服务器架构，您可以在不管理物理或虚拟服务器的情况下构建和运行应用。该云提供商会自动管理基础架构、扩缩和资源分配，以便开发者专注于编写其应用的代码。无服务器架构无需维护服务器，即可简化开发、减少运营开销并优化费用。它们非常适合微服务、实时数据处理、具有可变工作负载的 Web 应用和事件处理。
基于事件的无服务器架构
基于事件的无服务器架构是特定类型的无服务器计算架构，它依赖事件或触发器来启动函数或微服务的执行。系统组件通过事件进行通信，并调用函数来响应这些事件。它们通常依赖于异步通信，因为函数由事件触发，然后独立处理它们，并且可能会生成随后触发后续操作的事件。这种类型的无服务器架构非常适合用于构建可扩缩、响应迅速且松散耦合的系统。
借助 Google Cloud Functions 和 Cloud Functions for Firebase，您可以在全代管式无服务器环境中构建和部署事件驱动型函数。利用它，您可以运行代码来响应各种事件和触发器（包括 HTTP 请求、Cloud Pub/Sub 消息、Google Cloud Storage 更改、Firebase Realtime Database 更新），而无需管理基础架构。主要特性包括：多种语言支持、可伸缩性、精细的结算、第三方集成、强大的日志记录和监控功能，以及与其他 Google 和 Firebase 服务的集成。
无服务器架构在许多使用场景中都经济实惠，尤其是对于工作负载不断变化、开发需求快速和流量不可预测的应用。可靠性取决于云服务商，他们实施了服务等级协议 (SLA) 来确保实现特定的性能和可靠性目标。您必须评估自己的特定用例和要求，以确定无服务器架构是否是最佳选择。
容器化
容器化允许将应用及其依赖项打包到轻量级可移植容器中。它们提供一致的应用环境，支持跨不同系统和平台的开发和部署。某些无服务器平台能够运行容器化工作负载。当您具有无法以基本函数表示的复杂或有状态工作负载时，在无服务器环境中运行容器会很有帮助。它在语言支持和运行时环境方面提供了灵活性。
Cloud Run 是一个无服务器计算平台，可让开发者在全托管式环境中部署和运行容器化应用。它提供了一种简单明了的方法，可让您构建、部署和扩缩应用，而无需管理底层基础架构。它适用于各种 Web 应用和微服务应用，尤其是工作负载不断变化的应用，以及容器化在应用打包和一致性方面具有优势的方面。
微服务架构
应用被分解为多个松散耦合的小部分，并实现不同的特性或功能。这些服务可以通过异步消息、基于事件的通道来通信，也可以通过公开接口直接通信。每项服务都是在其容器中独立开发、测试和扩缩的，容器通常通过编排服务（如 Kubernetes）进行管理，或者使用代管式平台（如 Cloud Run）进行部署。
微服务部署通常也可以不依赖于集中式服务器，从而利用无服务器应用模式。
将应用分离为自主服务可以简化复杂的系统。明确界定的界限和目标可以加快开发速度并改善维护效果。每个微服务都可以使用最有效的框架或工具独立开发。服务之间的通信通常使用事件、发布-订阅通信、消息流水线或远程过程调用（例如 gRPC）来处理。
对于微服务架构中的任务编排，请考虑使用符合以下条件的框架：支持您的目标平台、要编排的任务和工作流类型有足够的深度，以及错误处理和遥测来调试问题。常见的选项包括 Conductor 或云提供商的产品（例如 Google Workflows）。
基于微服务的应用由于其分布式性质且需要服务内通信，因此开发和维护起来可能比较复杂。因此，管理部署、监控和日志记录比其他架构选项更复杂。由于可靠性取决于各项服务的架构，因此分布式性质可以提供额外的弹性，特别是在需要部署并启用监控和遥测的情况下。
内容驱动型 Web 应用后端的不同架构比较
下表将架构与内容驱动型 Web 应用后端的关键要求进行了比较。
| 单体式架构 | 基于事件的无服务器架构 | 无服务器的微服务架构 | |
|---|---|---|---|
| 复杂性和维护 |
|
|
|
| 可伸缩性和性能 |
|
|
|
| 弹性和回退策略 |
|
|
|
| 开发体验 |
|
|
|
| 费用 |
|
|
|
详细了解内容驱动 Web 应用的后端架构
您可以通过以下资源详细了解内容驱动型 Web 应用的架构，包括如何将应用迁移到其他架构：
- 详细了解松散耦合的 Web 应用后端架构，包括分层单体式应用和无服务器 Web 应用。