分层混合模式

应用的架构组件可以归为前端或后端。在某些情况下，这些组件可以托管在不同的计算环境中运行。作为分层混合架构模式的一部分，计算环境位于本地私有计算环境中和 Google Cloud中。

前端应用组件直接对最终用户或设备公开。因此，这些应用通常对性能要求较高。为了开发新功能和改进功能，软件更新可能会很频繁。由于前端应用通常依赖后端应用来存储和管理数据（可能还包括业务逻辑和用户输入处理），因此前端应用通常是无状态的，或者仅管理有限的数据量。

为了确保前端应用易于访问和使用，您可以使用各种框架和技术来构建前端应用。成功的前端应用的一些关键因素包括应用性能、响应速度和浏览器兼容性。

后端应用组件通常专注于存储和管理数据。在某些架构中，业务逻辑可能包含在后端组件中。后端应用新版本的推出往往不如前端应用频繁。后端应用在管理方面面临以下挑战：

  • 处理大量请求
  • 处理大量数据
  • 保护数据
  • 在所有系统副本中维护最新数据

三层式 Web 应用解决方案是构建商务 Web 应用（例如包含不同应用组件的电子商务网站）时最常用的实现之一。此架构包含以下层级。每个层级都独立运作，但它们紧密相连，共同发挥作用。

  • Web 前端和演示层级
  • 应用层级
  • 数据访问或后端层

将这些层放入容器中可分离它们的技术需求（例如伸缩要求），并有助于以分阶段的方式迁移它们。此外，它还让您可以将其部署到与平台无关的云服务上，这些服务可以跨环境移植、使用自动化管理，并使用 Cloud Run 或 Google Kubernetes Engine (GKE) Enterprise 版等云托管式平台进行扩缩。此外，Google Cloud-托管式数据库（如 Cloud SQL）有助于将后端作为数据库层提供。

分层混合架构模式侧重于将现有前端应用组件部署到公有云。在此模式中，您会将所有现有后端应用组件保留在其私有计算环境中。您可以根据应用规模和具体设计，逐个迁移前端应用组件。如需了解详情，请参阅迁移到 Google Cloud。

如果您现有的应用具有在本地环境中托管的后端和前端组件，请考虑当前架构的限制。例如，随着应用规模的扩大，对应用性能和可靠性的要求也会随之提高，此时您应开始评估是否应重构应用的部分内容，或将其迁移到更优化的架构。借助分层混合架构模式，您可以在完全过渡之前将部分应用工作负载和组件转移到云端。此外，还必须考虑此类迁移所涉及的费用、时间和风险。

下图展示了典型的分层混合架构模式。

数据从本地应用前端流向 Google Cloud中的应用前端。然后，数据会流回本地环境。

在上图中，客户端请求会发送到托管在 Google Cloud中的应用前端。反过来，应用前端会将数据发送回托管应用后端的本地环境（最好是通过 API 网关）。

借助分层混合架构模式，您可以充分利用Google Cloud 基础架构和全球服务，如下图中的示例架构所示。应用前端可通过 Google Cloud访问。它还可以通过使用自动伸缩功能为前端添加弹性，从而动态高效地响应伸缩需求，而无需过度预配基础架构。您可以使用不同的架构在 Google Cloud上构建和运行可伸缩的 Web 应用。每种架构都有各自的优缺点，可满足不同的需求。

如需了解详情，请在 YouTube 上观看在 Google Cloud上运行可伸缩的 Web 应用的 3 种方式。 如需详细了解如何在Google Cloud上以各种方式实现电子商务平台现代化，请参阅如何在 Google Cloud上构建数字商务平台。

数据通过 Cloud Load Balancing 和 Compute Engine 从用户流向本地数据库服务器。

在上图中，应用前端托管在Google Cloud 上，以提供多区域和全球优化的用户体验，该体验通过 Google Cloud Armor 使用全球负载均衡功能、自动扩缩功能和 DDoS 攻击保护功能。

随着时间的推移，您部署到公有云的应用数量可能会增加，增加到一定量后，您可能会考虑将后端应用组件转移到公有云。如果您预计会处理大量流量，那么选择云端托管服务可能有助于您在管理自己的基础架构时节省工程工作量。除非限制条件或其他因素要求在本地托管后端应用组件，否则请考虑使用此选项。例如，如果您的后端数据受到监管限制，您可能需要将这些数据保留在本地。不过，在适用且合规的情况下，使用去标识化技术等敏感数据保护功能可以帮助您迁移这些数据。

在分层混合架构模式中，您还可以在某些场景中使用 Google Distributed Cloud。借助分布式云，您可以在由 Google 提供和维护并独立于 Google Cloud 数据中心的专用硬件上运行 Google Kubernetes Engine 集群。为了确保 Distributed Cloud 满足您当前和未来的需求，请了解 Distributed Cloud 与传统的基于云的 GKE 可用区相比的局限性。

优点

首先专注于前端应用具有许多优势，包括：

  • 前端组件依赖于后端资源，偶尔也依赖于其他前端组件。
  • 后端组件不依赖于前端组件。因此，隔离和迁移前端应用往往没有迁移后端应用那样复杂。
  • 由于前端应用通常是无状态的，或者不自行管理数据，因此迁移的难度往往比后端小。

将现有或新开发的前端应用部署到公有云具有多项优势：

  • 许多前端应用可能会频繁更改。在公有云中运行这些应用可以简化持续集成/持续部署 (CI/CD) 流程的设置。您可以使用 CI/CD 以高效自动的方式发送更新。如需了解详情，请参阅 Google Cloud上的 CI/CD。
  • 对于流量负载各异且对性能要求较高的前端，云部署实现的负载均衡、多区域部署、Cloud CDN 缓存、无服务器和自动扩缩功能可带来显著优势（最好采用无状态架构）。

  • 采用基于容器的微服务并使用 GKE 等云托管平台，可让您使用 microfrontend 等现代架构，将微服务扩展到前端组件。

    扩展微服务通常用于涉及多个团队协作开发同一应用的前端。这种团队结构需要采用迭代方法并持续维护。使用微前端的一些优势如下：

    • 它可以成为独立的微服务模块，用于开发、测试和部署。
    • 它提供了分离功能，让各个开发团队可以选择自己偏好的技术和代码。
    • 它有助于快速完成开发和部署周期，而不会影响可能由其他团队管理的其他前端组件。

  • 无论是实现界面或 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 和 MACsec for Cloud Interconnect。

  • 为了解决各种各样的后端之间协议、API 和身份验证机制的不一致，我们建议在适用的情况下，将 API 网关或代理部署为统一的外观 (facade)。此网关或代理充当集中式控制点并实施以下措施：

    • 实施额外的安全措施。
    • 保护客户端应用和其他服务免受后端代码更改的影响。
    • 帮助为所有跨环境应用及其解耦组件之间的通信提供审核跟踪记录。
    • 充当旧版服务和经过现代化改造的服务之间的中间通信层。
      • 借助 Apigee 和 Apigee Hybrid，您可以跨本地环境、边缘、其他云和Google Cloud 环境托管和管理企业级混合网关。

  • 为了便于建立混合设置，请将 Cloud Load Balancing 与混合连接搭配使用。这意味着，您可以将 Cloud 负载均衡的优势扩展到本地计算环境中托管的服务。这种方法可实现分阶段将工作负载迁移到 Google Cloud ，且服务中断时间极短或根本不会中断，从而确保分布式服务顺利过渡。如需了解详情，请参阅混合连接性网络端点组概览。

  • 有时，将 API 网关或代理和应用负载均衡器一起使用，可以提供更强大的解决方案，以便大规模管理、保护和分发 API 流量。将 Cloud Load Balancing 与 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 数据库选项说明。

上一页
分布式架构模式
下一页
分区多云模式