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