应用的架构组件可以归类为前端或后端。在某些情况下，可以托管这些组件，以便在不同的计算环境中运行。作为分层混合架构模式的一部分，计算环境位于本地私有计算环境和 Google Cloud 中。
前端应用组件直接对最终用户或设备公开。因此，这些应用通常对性能要求较高。为了开发新功能和改进现有功能，软件更新可能会频繁进行。由于前端应用通常依赖后端应用来存储和管理数据（以及可能的业务逻辑和���户输入处理），因此它们通常是无状态的，或者仅管理有限数量的数据。
为了确保可访问性和可用性，您可以使用各种框架和技术构建前端应用。应用前端成功的关键因素包括应用性能、响应速度和浏览器兼容性。
后端应用组件通常专注于存储和管理数据。在某些架构中，业务逻辑可能会包含在后端组件中。后端应用新版本的推出往往不如前端应用频繁。后端应用需要管理以下挑战：
- 处理大量请求
- 处理大量数据
- 保护数据
- 在所有系统副本中维护最新数据
三层式应用架构是构建企业 Web 应用（例如包含不同应用组件的电子商务网站）的最常用实现之一。此架构包含以下层。每个层级均独立运行，但它们紧密关联且全都协同工作。
- Web 前端和呈现层
- 应用层级
- 数据访问或后端层
将这些层放入容器中可以分离其技术需求（例如扩缩要求），并有助于分阶段进行迁移。此外，它还让您可以将其部署到与平台无关的云服务上，这些服务可以跨环境移植、使用自动化管理，并使用 Cloud Run 或 Google Kubernetes Engine (GKE) Enterprise 版等云托管式平台进行扩缩。此外，Google Cloud 管理的数据库（如 Cloud SQL）有助于提供后端作为数据库层。
分层混合架构模式侧重于将现有前端应用组件部署到公有云。在此模式中，您会将所有现有的后端应用组件保留在其私有计算环境中。根据应用的规模和具体设计，您可以逐个迁移前端应用组件。如需了解详情，请参阅迁移到 Google Cloud。
如果您的现有应用具有托管在本地环境中的后端和前端组件，请考虑当前架构的限制。例如，随着应用的扩展以及对其性能和可靠性的要求的提高，您������开������估是否应重构应用的某些部分或将其迁移到更优化的架构。分层混合架构模式使您可以在完成完全转换之前将一些应用工作负载和组件迁移到云端。此外，请务必考虑此类迁移所涉及的费用、时间和风险。
下图展示了典型的分层混合架构模式。
在上图中，客户端请求会发送到托管在 Google Cloud 中的应用前端。反过来，应用前端会将数据发送回托管应用后端的本地环境（最好通过 API 网关）。
通过分层混合架构模式，您可以利用 Google Cloud 基础架构和全球服务，如下图中的示例架构所示。可以通过 Google Cloud 访问应用前端。它还可以通过自动扩缩来增加前端的弹性，以便动态且高效地响应扩缩需求，而无需过度预配基础架构。您可以使用不同的架构在 Google Cloud 上构建和运行可扩缩的 Web 应用。每种架构都有其优缺点，可满足不同的要求。
如需了解详情，请观看 YouTube 上的在 Google Cloud 上运行可扩缩的 Web 应用的三种方法。如需详细了解在 Google Cloud 上对电子商务平台进行现代化改造的不同方法，请参阅如何在 Google Cloud 上构建数字商务平台。
在上图中，应用前端托管在 Google Cloud 上，以提供多区域和全球优化的用户体验，该体验通过 Google Cloud Armor 使用全球负载均衡功能、自动扩缩功能和 DDoS 攻击保护功能。
随着时间的推移，您部署到公有云的应用数量可能会增加，增加到您可能会考虑将后端应用组件迁移到公有云的程度。如果您预计流量会很大，选择云端管理服务可能会帮助您在管理自己的基础架构时节省工程工作量。除非限制条件或其他因素要求在本地托管后端应用组件，否则请考虑使用此选项。例如，如果您的后端数据受到监管限制，您可能需要将该数据保留在本地。不过，在适用且合规的情况下，使用去标识化技术等敏感数据保护功能可以帮助您迁移这些数据。
在分层混合架构模式中，您还可以在某些情况下使用 Google Distributed Cloud。借助分布式云，您可以在由 Google 提供和维护并独立于 Google Cloud 数据中心的专用硬件上运行 Google Kubernetes Engine 集群。为了确保 Distributed Cloud 满足您当前和未来的需求，请了解 Distributed Cloud 与传统的基于云的 GKE 可用区相比的局限性。
优点
首先专注于前端应用具有许多优势，包括：
- 前端组件依赖于后端资源，偶尔依赖于其他前端组件。
- 后端组件不依赖于前端组件。因此，隔离和迁移前端应用往往没有迁移后端应用那样复杂。
- 由于前端应用通常是无状态的，或者不自行管理数据，因此迁移的难度比后端要小。
- 前端组件可以在迁移过程中进行优化，以使用无状态架构。如需了解详情，请观看 YouTube 上的如何将有状态 Web 应用移植到 Cloud Run。
将现有或新开发的前端应用部署到公有云具有多项优势：
- 许多前端应用可能会频繁更改。在公有云中运行这些应用可以简化持续集成/持续部署 (CI/CD) 流程的设置。您可以使用 CI/CD 以高效自动的方式发送更新。如需了解详情，请参阅 Google Cloud 上的 CI/CD。
- 对性能要求较高且流量负载不定的前端可以从云部署实现的负载均衡、多区域部署、Cloud CDN 缓存、无服务器和自动扩缩功能中大大受益（最好采用无状态架构）。
通过使用带有容器且使用云端代管式平台（如 GKE）的微服务，您可以使用微前端等现代架构，将微服务扩展到前端组件。
扩展微服务通常用于涉及多个团队协作处理同一应用的前端。这种团队结构需要迭代方法和持续维护。使用微前端的一些优点如下：
- 它可以构建为独立的微服务模块，用于开发、测试和部署。
- 它提供了隔离功能，让各个开发团队可以选择自己喜欢的技术和代码。
- 它可以加快开发和部署周期，而不会影响可能由其他��队管理的其余部分的前端组件。
无论是实现界面或 API，还是处理物联网 (IoT) 数据注入，前端应用都可以受益于 Firebase、Pub/Sub、Apigee、Cloud CDN、App Engine 或 Cloud Run 等云服务的功能。
-
- 将面向应用的 API 与后端服务（例如微服务）分离。
- 保护应用免受后端代码更改的影响。
- 支持现有的 API 驱动型前端架构，例如前端后端 (BFF)、微前端等。
- 通过在 Apigee 上实现 API 代理，在 Google Cloud 或其他环境中公开您的 API。
您还可以反向应用分层混合模式，方法是在云端部署后端，同时将前端保留在私有计算环境中。虽然这种方法不太常见，但如果您处理重量级、单体式前端，此方法非常适用。在这种情况下，以迭代方式提取后端功能，以及在云中部署这些新后端可能更轻松。
本系列的第 3 部分将讨论可能的网络模式，以实现此类架构。Apigee Hybrid 有助于作为在混合部署模型中构建和管理 API 代理的平台。如需了解详情，请参阅松散耦合的架构，包括分层单体式应用和微服务架构。
最佳实践
在规划分层混合架构时，请使用本部分中的信息。
简化复杂性的最佳实践
在应用分层混合架构模式时，请考虑采用以下最佳实践，以帮助降低其整体部署和操作复杂性：
- 根据对所标识应用的通信模型的评估，为这些应用选择最有效的通信解决方案。
由于大多数用户互动都涉及在多个计算环境之间进行连接的系统，因此在这些系统之间实现快速低延迟连接非常重要。要满足可用性和性能预期，您应该针对高可用性、低延迟和适当的吞吐量水平进行设计。从安全角度来看，通信需要进行精细控制。理想情况下，您应使用安全 API 公开应用组件。如需了解详情，请参阅封闭出站流量。
- 如需最大限度地降低各环境之间的通信延迟，请选择地理位置靠近您的应用后端组件托管的私有计算环境的 Google Cloud 区域。如需了解详情，请参阅 Compute Engine 区域选择最佳实践。
- 最大限度减少在不同环境中运行的系统之间的依赖项，尤其是在同步处理通信时。这些依赖项会降低性能、降低整体可用性，并可能产生额外的出站数据传输费用。
- 在分层混合架构模式中，从本地环境进入 Google Cloud 的入站流量量可能大于从 Google Cloud 发出的出站流量。不过，您应该了解从 Google Cloud 传出的预期出站数据传输量。如果您计划长期使用此架构且出站数据传输量较大，请考虑使用 Cloud Interconnect。Cloud Interconnect 有助于优化连接性能，并可能降低满足特定条件的流量的出站数据传输费用。如需了解详情，请参阅 Cloud Interconnect 价格。
- 为了保护敏感信息，我们建议加密传输中的所有通信。如果连接层需要加密，您可以使用 VPN 隧道、通过 Cloud Interconnect 实现的高可用性 VPN 和 MACsec for Cloud Interconnect。
为了解决不同后端的协议、API 和身份验证机制不一致的问题，我们建议在适用的情况下将 API 网关或代理部署为统一的门面。此网关或代理充当集中式控制点并实施以下措施：
- 实施额外的安全措施。
- 保护客户端应用和其他服务免受后端代码更改的影响。
- 帮助为所有跨环境应用及其解耦组件之间的通信提供审核跟踪记录。
- 充当旧版服务和经过现代化改造的服务之间的中间通信层。
- 借助 Apigee 和 Apigee Hybrid，您可以跨本地环境、边缘、其他云和 Google Cloud 环境托管和管理企业级和混合网关。
为了更轻松地建立混合设置，请使用具有混合连接的 Cloud Load Balancing。这意味着您可以将 Cloud Load Balancing 的优势扩展到本地计算环境中托管的服务。这种方法可以将工作负载分阶段迁移到 Google Cloud，同时将服务中断降至最低或不发生，从而确保分布式服务顺利过渡。如需了解详情，请参阅混合连接网络端点组概览。
有时，将 API 网关或代理和应用负载均衡器一起使用，可以提供更强大的解决方案，以便大规模管理、保护和分发 API 流量。将 Cloud Load Balancing 与 API 网关搭配使用，您可以实现以下目标：
- 通过 Apigee 和 Cloud CDN 提供高性能 API，以缩短延迟时间、在全球范围内托管 API，以及提高流量高峰时段的可用性。如需了解详情，请观看 YouTube 上的借助 Apigee 和 Cloud CDN 提供高性能 API。
- 实现高级流量管理。
- 使用 Google Cloud Armor 作为 DDoS 防护和网络安全服务来保护您的 API。
- 跨多个区域中的网关管理高效负载均衡。如需了解详情，请观看 YouTube 上的使用 Private Service Connect 和 Apigee 保护 API 并实现多区域故障切换。
使用 API 管理和服务网格通过微服务架构保护和控制服务通信和公开。
- 使用 Cloud Service Mesh 可实现服务到服务的通信，从而在由分布式服务组成的系统中维持服务质量，您可以在其中管理身份验证服务之间的授权和加密。
- 使用 Apigee 等 API 管理平台，您的组织和外部实体可以通过将这些服务作为 API 公开来使用这些服务。
在环境之间建立通用标识，以便系统能够跨环境边界安全地进行身份验证。
在公有云中部署 CI/CD 和配置管理系统。 如需了解详情，请参阅镜像网络架构模式。
为帮助提高运营效率，请跨环境使用一致的工具和 CI/CD 流水线。
单个工作负载和应用架构的最佳实践
- 虽然此模式侧重于前端应用，但请注意后端应用现代化的需求。如果后端应用的开发速度远远低于前端应用的开发速度，这种差异可能会额外增加复杂性。
- 将 API 视为后端接口可简化集成、前端开发、服务交互，并隐藏后端系统的复杂性。为了应对这些挑战，Apigee 为混合云和多云部署提供了 API 网关/代理开发和管理功能。
- 根据内容（静态或动态）、搜索引擎优化性能以及对网页加载速度的预期，为您的前端 Web 应用选择呈现方法。
- 为内容驱动的 Web 应用选择架构时，您可以使用各种选项，包括单体式应用架构、无服务器架构、基于事件的架构和微服务架构。如需选择最合适的架构，请根据您当前和未来的应用要求全面评估这些选项。如需帮助您做出符合业务和技术目标的架构决策，请参阅内容驱动型 Web 应用后端的不同架构比较和Web 后端的关键注意事项。
借助微服务架构，您可以使用容器化应用，并将 Kubernetes 用作通用运行时层。使用分层混合架构模式，您可以在以下任一场景中运行它：
跨这两个环境（Google Cloud 和本地环境）。
- 在各个环境中使用容器和 Kubernetes 时，您可以灵活地对工作负载进行现代化改造，然后在不同时间迁移到 Google Cloud。当工作负载严重依赖于另一个工作负载且无法单独迁移时，或者使用混合工作负载可移植性来利用每个环境中可用的最佳资源时，这会有所帮助。在所有情况下，GKE Enterprise 都可以成为关键的支持技术。如需了解详情，请参阅 GKE Enterprise 混合环境。
在 Google Cloud 环境中，用于迁移和改进的应用组件。
- 如果您的本地旧版后端缺少容器化支持，或者需要大量时间和资源在短期内进行现代化改造，请使用此方法。
如需详细了解如何设计和重构单体式应用以采用微服务架构，从而使您的 Web 应用架构现代化，请参阅微服务简介。
您可以根据 Web 应用的需求组合使用数据存储技术。使用 Cloud SQL 存储结构化数据，使用 Cloud Storage 存储媒体文件，这是满足各种数据存储需求的常见方法。不过，选择哪种方式在很大程度上取决于您的用例。如需详细了解内容驱动的应用后端的数据存储方案和有效模式，请参阅内容驱动的 Web 应用的数据存储方案。此外，请参阅 Google Cloud 数据库选项说明