Google Cloud混合和多云架构模式

https://cloud.google.com/architecture/hybrid-multicloud-patterns-and-practices/one-page-view

整理 by https://zhengkai.blog.csdn.net/

本文档是该系列三篇文档中的第二篇。它讨论了常见的混合云和多云架构模式。它还描述了这些模式最适合的场景。最后，它提供了在 Google Cloud 中部署此类架构时可以使用的最佳实践。

混合和多云架构模式的文档集由以下部分组成：

• 构建混合和多云架构：讨论使用 Google Cloud 构建混合和多云设置的架构策略。
• 混合和多云架构模式：讨论作为混合和多云策略的一部分采用的常见架构模式（本文档）。
• 混合和多云安全网络架构模式：从网络角度讨论混合和多云网络架构模式。

每个企业都有独特的应用程序工作负载组合，这些工作负载对混合云或多云设置的架构提出了要求和限制。虽然您必须设计和定制架构以满足这些限制和要求，但您可以依靠一些常见模式来定义基础架构。

架构模式是一种可重复的方式，用于构建技术解决方案、应用程序或服务的多个功能组件，以创建可重复使用的解决方案，满足某些要求或用例。基于云的技术解决方案通常由几个不同的分布式云服务组成。这些服务协作提供所需的功能。在这种情况下，每个服务都被视为技术解决方案的功能组件。同样，应用程序可以由多个功能层、模块或服务组成，每个都可以代表应用程序架构的功能组件。这种架构可以标准化以解决特定的业务用例，并作为基础的可重复使用模式。

要为应用程序或解决方案定义架构模式，请识别并定义以下内容：

• 解决方案或应用程序的组件。
• 每个组件的预期功能 — 例如，提供图形用户界面的前端功能或提供数据访问的后端功能。
• 组件如何相互通信以及与外部系统或用户通信。在现代应用程序中，这些组件通过定义明确的接口或 API 进行交互。通信模型多种多样，例如异步和同步、请求-响应或基于队列。

以下是混合和多云架构模式的两大类别：

• 分布式架构模式：这些模式依赖于工作负载或应用程序组件的分布式部署。这意味着它们在最适合该模式的计算环境中运行应用程序（或该应用程序的特定组件）。这样做可以让模式利用分布式和互连计算环境的不同属性和特征。
• 冗余架构模式：这些模式基于工作负载的冗余部署。在这些模式中，您将相同的应用程序及其组件部署在多个计算环境中。目标是提高应用程序的性能或弹性，或复制现有环境以进行开发和测试。

实施所选架构模式时，您必须使用合适的部署原型。部署原型包括区域、区域、多区域或全球。此选择构成了构建特定于应用程序的部署架构的基础。每个部署原型都定义了应用程序可以在其中运行的故障域组合。这些故障域可以包含一个或多个Google Cloud 区域或地区，并且可以扩展到包括您的本地数据中心或其他云提供商的故障域。

本系列包含以下页面：

• 分布式架构模式

  • 分层混合模式

  • 分区多云模式

  • 分析混合和多云模式

  • 边缘混合模式

• 冗余架构模式

  • 环境混合模式
  • 业务连续性混合和多云模式
  • 云爆发模式

贡献者

作者：马尔万·阿尔·沙维|合作伙伴客户工程师

其他贡献者：

• Saud Albazei | 应用程序现代化客户工程师
• 安娜·贝伦伯格| 工程研究员
• Marco Ferrari | 云解决方案架构师
• Victor Moreno | 云网络产品经理
• Johannes Passing | 云解决方案架构师
• Mark Schlagenhauf | 网络技术作家
• Daniel Strebel | 欧洲、中东和非洲 (EMEA) 解决方案主管、应用程序现代化
• Ammett Williams | 开发者关系工程师

分布式架构模式

从非混合或非多云计算环境迁移到混合或多云架构时，首先要考虑现有应用程序的限制以及这些限制可能导致应用程序故障的原因。当您的应用程序或应用程序组件以分布式方式跨不同环境运行时，这种考虑就变得更加重要。考虑完限制后，制定计划来避免或克服这些限制。确保考虑分布式架构中每个计算环境的独特功能。

注意：您可以根据不同应用的用例和要求，将不同的架构模式应用于不同的应用。这意味着您可能同时运行多个采用不同混合和多云架构模式的应用。

设计注意事项

以下设计注意事项适用于分布式部署模式。根据目标解决方案和业务目标，每个注意事项的优先级和效果可能会有所不同。

延迟

在任何将应用组件（前端、后端或微服务）分布在不同计算环境中的架构模式中，都可能出现通信延迟。此延迟受混合网络连接（Cloud VPN 和 Cloud Interconnect）以及本地站点与云区域之间或多云设置中云区域之间的地理距离的影响。因此，评估应用的延迟要求及其对网络延迟的敏感度至关重要。能够容忍延迟的应用更适合在混合或多云环境中进行初始分布式部署。

临时架构与最终架构

要指定预期以及对成本、规模和性能的任何潜在影响，在规划阶段分析您需要的架构类型和预期持续时间非常重要。例如，如果您计划长期或永久使用混合或多云架构，则可能需要考虑使用Cloud Interconnect 。为了降低出站数据传输成本并优化混合连接网络性能，Cloud Interconnect 会对符合折扣数据传输费率条件的出站数据传输费用进行折扣。

可靠性

可靠性是构建 IT 系统时的主要考虑因素。正常运行时间可用性是系统可靠性的一个重要方面。在 Google Cloud 中，您可以通过在单个区域的多个区域或多个区域部署该应用程序的冗余组件并具有切换功能来提高应用程序的弹性。冗余是提高应用程序整体可用性的关键要素之一。对于在混合和多云环境中具有分布式设置的应用程序，保持一致的可用性水平非常重要。

为了增强本地环境或其他云环境中系统的可用性，请考虑应用程序及其组件需要哪些硬件或软件冗余（以及故障转移机制）。理想情况下，您应该考虑服务或应用程序在所有环境中的各个组件和支持基础架构（包括混合连接可用性）中的可用性。此概念也称为应用程序或服务的复合可用性。

根据组件或服务之间的依赖关系，应用程序的综合可用性可能高于或低于单个服务或组件。有关更多信息，请参阅综合可用性：计算云基础设施的整体可用性。

为了达到您想要的系统可靠性水平，请定义明确的可靠性指标，并设计应用程序以在不同环境中有效地自我修复和承受中断。为了帮助您定义衡量服务客户体验的适当方法，请参阅定义您的可靠性目标。

混合和多云连接

分布式应用程序组件之间的通信要求应该会影响您对混合网络连接选项的选择。每种连接选项都有其优点和缺点，以及需要考虑的特定驱动因素，例如成本、流量、安全性等。有关更多信息，请参阅连接设计注意事项部分。

可管理性

一致且统一的管理和监控工具对于成功的混合云和多云设置（无论是否具有工作负载可移植性）至关重要。从短期来看，这些工具会增加开发、测试和运营成本。从技术上讲，您使用的云提供商越多，管理环境就越复杂。大多数公共云供应商不仅具有不同的功能，而且还具有用于管理云服务的不同工具、SLA 和 API。因此，请权衡所选架构的战略优势与潜在的短期复杂性和长期利益。

成本

多云环境中的每个云服务提供商都有自己的计费指标和工具。为了提供更好的可见性和统一的仪表板，请考虑使用多云成本管理和优化工具。例如，在跨多个云环境构建云优先解决方案时，每个提供商的产品、定价、折扣和管理工具都可能导致这些环境之间的成本不一致。

我们建议采用一种单一、定义明确的方法来计算云资源的全部成本，并提供成本可见性。成本可见性对于成本优化至关重要。例如，通过结合您使用的云提供商的账单数据并使用 Google Cloud Looker Cloud Cost Management Block，您可以创建多云成本的集中视图。此视图可帮助提供跨多个云的支出的综合报告视图。有关更多信息，请参阅有效优化云账单成本管理的策略。

我们还建议使用 FinOps 实践来使成本可见。作为强大的 FinOps 实践的一部分，中央团队可以将资源优化的决策委托给参与项目的任何其他团队，以鼓励个人责任。在此模型中，中央团队应标准化成本优化的流程、报告和工具。有关您应考虑的不同成本优化方面和建议的更多信息，请参阅Google Cloud 架构框架：成本优化。

数据移动

数据移动是混合云和多云战略及架构规划的重要考虑因素，尤其是对于分布式系统而言。企业需要确定其不同的业务用例、为其提供支持的数据以及数据的分类方式（针对受监管行业）。他们还应考虑跨环境的分布式系统的数据存储、共享和访问可能会如何影响应用程序性能和数据一致性。这些因素可能会影响应用程序和数据管道架构。Google Cloud 全面的数据移动选项使企业能够满足其特定需求并采用混合云和多云架构，而不会影响简单性、效率或性能。

安全

将应用程序迁移到云时，重要的是要考虑云优先的安全功能，例如一致性、可观察性和统一的安全可见性。每个公共云提供商都有自己的安全方法、最佳实践和功能。分析和协调这些功能以构建标准、功能齐全的安全架构非常重要。强大的 IAM 控制、数据加密、漏洞扫描和遵守行业法规也是云安全的重要方面。

在规划迁移策略时，我们建议您分析前面提到的注意事项。它们可以帮助您在应用程序或流量增长时将引入架构复杂性的可能性降至最低。此外，设计和构建着陆区几乎始终是在云环境中部署企业工作负载的先决条件。着陆区可帮助您的企业在多个区域更安全地部署、使用和扩展云服务，并包含不同的元素，例如身份、资源管理、安全性和网络。有关更多信息，请参阅Google Cloud 中的着陆区设计。

本系列中的以下文档描述了其他分布式架构模式：

• 分层混合模式
• 分区多云模式
• 分析混合和多云模式
• 边缘混合模式

分层混合模式

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

前端应用程序组件直接面向最终用户或设备。因此，这些应用程序通常对性能非常敏感。为了开发新功能和改进，软件更新可能非常频繁。由于前端应用程序通常依赖后端应用程序来存储和管理数据（可能还有业务逻辑和用户输入处理），因此它们通常是无状态的或仅管理有限量的数据。

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

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

• 处理大量请求
• 处理大量数据
• 保护数据
• 在所有系统副本中维护当前和更新的数据

三层应用程序架构是构建商业 Web 应用程序（如包含不同应用程序组件的电子商务网站）的最流行实现之一。此架构包含以下层。每层都独立运行，但它们紧密相连且共同发挥作用。

• Web 前端和表示层
• 应用程序层
• 数据访问或后端层

将这些层放入容器中可以区分它们的技术需求（例如扩展要求），并有助于分阶段迁移它们。此外，它还允许您将它们部署在与平台无关的云服务上，这些服务可以跨环境移植、使用自动化管理，并使用云托管平台（如 Cloud Run 或 Google Kubernetes Engine (GKE) 企业版）进行扩展。此外，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 分布式云。分布式云可让您在由 Google 提供和维护的专用硬件上运行 Google Kubernetes Engine 集群，该硬件与 Google Cloud 数据中心是分开的。为了确保分布式云满足您当前和未来的需求，请了解分布式云与传统基于云的 GKE 区域相比的局限性。

优点

首先关注前端应用程序有几个优点，包括：

• 前端组件依赖于后端资源，有时也依赖于其他前端组件。
• 后端组件不依赖于前端组件。因此，隔离和迁移前端应用程序往往比迁移后端应用程序更简单。
• 由于前端应用程序通常是无状态的或不能自行管理数据，因此它们的迁移难度往往比后端要小。
  • 可以在迁移过程中优化前端组件以使用无状态架构。如需了解更多信息，请观看YouTube 上的“如何将有状态 Web 应用移植到 Cloud Run”。

将现有或新开发的前端应用程序部署到公共云有几个优点：

• 许多前端应用程序经常发生变化。在公共云中运行这些应用程序可简化持续集成/持续部署 (CI/CD) 流程的设置。您可以使用 CI/CD 以高效且自动化的方式发送更新。有关更多信息，请参阅Google Cloud 上的 CI/CD。
• 具有不同流量负载的性能敏感型前端可以从基于云的部署所支持的负载平衡、多区域部署、云 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 上的 HA VPN和Cloud Interconnect 的 MACsec。

• 为了克服不同后端之间协议、API 和身份验证机制的不一致问题，我们建议在适用的情况下部署 API 网关或代理作为统一的外观。此网关或代理充当集中控制点并执行以下措施：

  • 实施额外的安全措施。
  • 保护客户端应用程序和其他服务免受后端代码更改的影响。
  • 促进所有跨环境应用程序及其解耦组件之间的通信的审计跟踪。
  • 充当传统服务和现代化服务之间的中间通信层。
    • 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” 。
  • 实施先进的交通管理。
  • 使用 Google Cloud Armor 作为 DDoS 防护和网络安全服务来保护您的 API。
  • 管理跨多个区域网关的有效负载平衡。如需了解更多信息，请观看YouTube 上的“保护 API”和“使用 Private Service Connect 和 Apigee 实现多区域故障转移” 。

• 使用API 管理和服务网格来保护和控制与微服务架构的服务通信和暴露。

  • 使用云服务网格允许服务到服务的通信，从而在由分布式服务组成的系统中维护服务质量，您可以在其中管理服务之间的身份验证、授权和加密。
  • 使用 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 数据库选项说明

分区多云模式

分区多云架构模式结合了由不同云服务提供商运营的多个公共云环境。此架构提供了在最佳计算环境中部署应用程序的灵活性，该环境考虑了本系列第一部分中讨论的多云驱动因素和注意事项。

下图展示了分区多云架构模式。

这种架构模式可以通过两种不同的方式构建。第一种方法是基于在不同的公共云环境中部署应用程序组件。这种方法也称为复合架构，与分层混合架构模式相同。但它不是使用带有公共云的本地环境，而是使用至少两个云环境。在复合架构中，单个工作负载或应用程序使用来自多个云的组件。第二种方法在不同的公共云环境中部署不同的应用程序。以下非详尽列表描述了第二种方法的一些业务驱动因素：

• 在两家企业合并收购期间，完全集成托管在不同云环境中的应用程序。
• 提高灵活性并满足组织内不同的云偏好。采用这种方法可鼓励组织单位选择最适合其特定需求和偏好的云提供商。
• 在多区域或全球云部署中运营。如果企业需要遵守特定区域或国家的数据驻留法规，那么如果他们的主要云提供商在当地没有云区域，他们就需要从当地可用的云提供商中进行选择。

使用分区多云架构模式，您可以选择根据需要将工作负载从一个公共云环境转移到另一个公共云环境。在这种情况下，工作负载的可移植性成为一项关键要求。当您将工作负载部署到多个计算环境，并希望保持在环境之间移动工作负载的能力时，您必须抽象出环境之间的差异。通过使用 GKE Enterprise，您可以设计和构建一个解决方案，以一致的治理、运营和安全态势来解决多云复杂性。有关更多信息，请参阅GKE 多云。

如前所述，在某些情况下，出于业务和技术原因，可能需要将 Google Cloud 与其他云提供商相结合，并在这些云环境中划分工作负载。多云解决方案可让您灵活地在多云环境中迁移、构建和优化应用程序的可移植性，同时最大限度地减少锁定并帮助您满足监管要求。例如，您可以将 Google Cloud 与 Oracle Cloud Infrastructure (OCI) 连接起来，以构建一个多云解决方案，该解决方案使用私有云互连将 OCI 中运行的组件与 Google Cloud 上运行的资源相结合，从而充分利用每个平台的功能。有关更多信息，请参阅Google Cloud 和 Oracle Cloud Infrastructure — 充分利用多云。此外，跨云互连促进了 Google Cloud 与其他受支持的云服务提供商之间的高带宽专用连接，使您能够设计和构建多云解决方案来处理高云间流量。

优点

虽然使用多云架构可以带来多种业务和技术优势（如驱动因素、注意事项、策略和方法中所述），但对每项潜在优势进行详细的可行性评估至关重要。您的评估应仔细考虑任何相关的直接或间接挑战或潜在障碍，以及您有效应对这些挑战或障碍的能力。此外，请考虑应用程序或服务的长期增长可能会带来超过最初优势的复杂性。

以下是分区多云架构模式的一些主要优点：

• 在您可能需要尽量减少对单个云提供商的承诺的情况下，您可以将应用程序分发到多个云提供商。因此，您可以相对减少供应商锁定，并能够在云提供商之间（在一定程度上）更改计划。Open Cloud有助于将 Google Cloud 功能（如 GKE Enterprise）带到不同的物理位置。通过在本地、多个公共云和边缘扩展 Google Cloud 功能，它提供了灵活性、敏捷性并推动了转型。

• 出于监管原因，您可以从 Google Cloud 没有云区域的国家/地区为特定部分用户群和数据提供服务。

• 在主云提供商没有云区域或接入点的位置，分区多云架构模式可以帮助减少延迟并提高用户体验的整体质量。当使用高容量和低延迟的多云连接时，此模式特别有用，例如跨云互连和与分布式 CDN 的CDN 互连。

• 您可以跨多个云提供商部署应用程序，以便从其他云提供商提供的最佳服务中进行选择。

• 分区多云架构模式可以帮助促进和加速并购场景，其中两个企业的应用程序和服务可能托管在不同的公共云环境中。

最佳实践

• 首先部署非关键任务工作负载。在辅助云中的初始部署可以作为未来部署或迁移的模式。但是，这种方法可能不适用于法律或监管要求特定工作负载驻留在特定云区域，而主要云提供商在所需地区没有区域的情况。
• 尽量减少在不同公共云环境中运行的系统之间的依赖关系，尤其是在同步处理通信时。这些依赖关系可能会降低性能、降低整体可用性，并可能产生额外的出站数据传输费用。
• 为了消除环境之间的差异，请考虑在应用程序支持且可行的情况下使用容器和 Kubernetes。
• 确保用于部署和监控的 CI/CD 管道和工具在云环境中保持一致。
• 选择最佳网络架构模式，为您所使用的应用程序提供最高效的通信解决方案。
  • 通信必须细粒度且可控。使用安全的 API 来公开应用程序组件。
  • 根据您的特定业务和技术要求，考虑使用网状架构模式或门控网络模式之一。
• 为了满足您的可用性和性能期望，请设计端到端高可用性 (HA)、低延迟和适当的吞吐量级别。

• 为了保护敏感信息，我们建议对传输中的所有通信进行加密。

  • 如果连接层需要加密，则根据所选的混合连接解决方​​案，有多种选项可供选择。这些选项包括 VPN 隧道、基于 Cloud Interconnect 的 HA VPN 以及用于跨云互连的 MACsec。

• 如果您将多个 CDN 作为多云分区架构模式的一部分，并使用来自 Google Cloud 的大型数据文件填充其他 CDN，请考虑在 Google Cloud 和受支持的提供商之间使用CDN 互连链接来优化此流量并可能降低其成本。

• 在环境之间扩展您的身份管理解决方案，以便系统可以跨环境边界安全地进行身份验证。

• 为了有效地平衡 Google Cloud 和其他云平台之间的请求，您可以使用 Cloud Load Balancing。有关详细信息，请参阅将流量路由到本地位置或其他云。

  • 如果从 Google Cloud 到其他环境的出站数据传输量很大，请考虑使用跨云互连。

• 为了克服不同后端之间协议、API 和身份验证机制的不一致问题，我们建议在适用的情况下部署 API 网关或代理作为统一的外观。此网关或代理充当集中控制点并执行以下措施：

  • 实施额外的安全措施。
  • 保护客户端应用程序和其他服务免受后端代码更改的影响。
  • 促进所有跨环境应用程序及其解耦组件之间的通信的审计跟踪。
  • 充当传统服务和现代化服务之间的中间通信层。
    • Apigee 和Apigee Hybrid可让您在本地环境、边缘、其他云和 Google Cloud 环境中托管和管理企业级和混合网关。

• 在以下某些情况下，将Cloud Load Balancing 与 API 网关结合使用可以提供强大而安全的解决方案，用于跨多个区域大规模管理、保护和分发 API 流量：

  • 为不同区域的 Apigee API 运行时部署多区域故障转移。

  • 使用 Cloud CDN提高性能。

  • 通过 Google Cloud Armor 提供 WAF 和 DDoS 保护。

• 尽可能使用一致的工具跨云环境进行日志记录和监控。您可以考虑使用开源监控系统。有关更多信息，请参阅混合和多云监控和日志记录模式。

• 如果您以分布式方式部署应用程序组件，即单个应用程序的组件部署在多个云环境中，请参阅分层混合架构模式的最佳实践。

分析混合和多云模式

本文档讨论了分析混合和多云模式的目标是利用事务和分析工作负载之间的分割。

在企业系统中，大多数工作负载属于以下类别：

• 交易工作负载包括销售、财务处理、企业资源规划或通信等交互式应用程序。
• 分析工作负载包括转换、分析、改进或可视化数据以协助决策过程的应用程序。

分析系统通过查询 API 或访问数据库从事务系统获取数据。在大多数企业中，分析系统和事务系统往往是分开的，并且松散耦合。分析混合和多云模式的目标是通过在两个不同的计算环境中运行事务和分析工作负载来利用这种预先存在的分离。首先从在私有计算环境中运行的工作负载中提取原始数据，然后将其加载到 Google Cloud 中，在那里用于分析处理。然后可能会将部分结果反馈给事务系统。

下图通过展示潜在的数据管道，从概念上说明了可能的架构。每条路径/箭头代表一种可能的数据移动和转换管道选项，可以基于ETL或 ELT，具体取决于可用的数据质量和目标用例。

要将数据移动到 Google Cloud 并从中释放价值，请使用数据移动服务（一整套数据提取、集成和复制服务）。

如上图所示，将 Google Cloud 与本地环境和其他云环境连接起来可以实现各种数据分析用例，例如数据流和数据库备份。为了支持需要大量数据传输的混合和多云分析模式的基础传输，Cloud Interconnect 和Cross-Cloud Interconnect为本地和其他云提供商提供了专用连接。

优点

在云中运行分析工作负载有几个主要优势：

• 入站流量（将数据从您的私有计算环境或其他云移动到 Google Cloud）可能是免费的。
• 分析工作负载通常需要处理大量数据，并且可能会突发，因此特别适合部署在公共云环境中。通过动态扩展计算资源，您可以快速处理大型数据集，同时避免前期投资或过度配置计算设备。
• Google Cloud 提供了丰富的服务来管理数据的整个生命周期，从最初的获取到处理和分析，再到最终的可视化。
  • Google Cloud 上的数据移动服务提供了一整套产品，可以以不同的方式无缝地移动、集成和转换数据。
  • 云存储非常适合构建数据湖。

• Google Cloud 可帮助您实现数据平台的现代化和优化，从而打破数据孤岛。使用数据湖库有助于实现不同存储格式之间的标准化。它还可以提供所需的灵活性、可扩展性和敏捷性，以帮助确保您的数据为您的业务创造价值，而不是效率低下。如需了解更多信息，请参阅BigLake。

• BigQuery Omni提供在 AWS 或 Azure 上的存储本地运行的计算能力。它还可以帮助您查询存储在 Amazon Simple Storage Service (Amazon S3) 或 Azure Blob Storage 中的您自己的数据。这种多云分析功能可让数据团队打破数据孤岛。有关查询存储在 BigQuery 之外的数据的更多信息，请参阅外部数据源简介。

最佳实践

要实现分析混合和多云架构模式，请考虑以下常规最佳实践：

• 使用切换网络模式来实现数据提取。如果需要将分析结果反馈给交易系统，则可以结合使用切换和门控出口模式。
• 使用Pub/Sub队列或Cloud Storage 存储桶将数据从您私有计算环境中运行的事务系统移交给 Google Cloud。然后，这些队列或存储桶可以作为数据处理管道和工作负载的来源。
• 要部署 ETL 和 ELT 数据管道，请考虑使用Cloud Data Fusion或Dataflow，具体取决于您的具体用例要求。两者都是完全托管的云优先数据处理服务，用于构建和管理数据管道。
• 要发现、分类和保护您宝贵的数据资产，请考虑使用 Google Cloud敏感数据保护功能，例如去标识化技术。这些技术可让您使用随机生成或预先确定的密钥（如果适用且合规）屏蔽、加密和替换敏感数据（例如个人身份信息 (PII)）。
• 如果您有现有的 Hadoop 或 Spark 工作负载，请考虑将作业迁移到 Dataproc并将现有的 HDFS 数据迁移到 Cloud Storage。

• 当您从私有计算环境向 Google Cloud 执行初始数据传输时，请选择最适合您的数据集大小和可用带宽的传输方法。有关详细信息，请参阅迁移到 Google Cloud：传输大型数据集。

• 如果需要长期在 Google Cloud 与其他云之间进行高流量的数据传输或交换，您应该评估使用 Google Cloud Cross-Cloud Interconnect来帮助您在 Google Cloud 与其他云服务提供商（在某些位置可用）之间建立高带宽的专用连接。

• 如果连接层需要加密，则根据所选的混合连接解决方​​案，有多种选项可供选择。这些选项包括 VPN 隧道、基于 Cloud Interconnect 的 HA VPN 以及用于跨云互连的 MACsec。

• 跨环境使用一致的工具和流程。在分析混合场景中，这种做法可以帮助提高运营效率，尽管这不是先决条件。

边缘混合模式

在云中运行工作负载需要客户端在某些情况下具有快速可靠的互联网连接。考虑到当今的网络，这一要求很少对云采用构成挑战。但是，在某些情况下，您不能依赖持续的连接，例如：

• 远洋船舶和其他交通工具可能仅能间歇性地连接网络或只能访问高延迟卫星链路。
• 工厂或发电厂可能会连接到互联网。这些设施的可靠性要求可能超出其互联网提供商的可用性要求。
• 零售商店和超市可能仅偶尔联网，或者使用无法提供处理关键业务交易所需可靠性或吞吐量的链接。

边缘混合架构模式通过在网络边缘本地运行时间关键型和业务关键型工作负载，同时使用云来处理所有其他类型的工作负载，从而解决了这些挑战。在边缘混合架构中，互联网链路是一个非关键组件，用于管理目的以及同步或上传数据（通常是异步的），但不参与时间关键型或业务关键型事务。

优点

在边缘运行某些工作负载并在云中运行其他工作负载有几个优点：

• 入站流量（将数据从边缘移动到 Google Cloud）可能是免费的。
• 在边缘运行业务和时间关键型工作负载有助于确保低延迟和自给自足。如果互联网连接失败或暂时不可用，您仍然可以运行所有重要交易。同时，您可以将大部分总体工作负载使用云来处理，从而受益匪浅。
• 您可以重复使用对计算和存储设备的现有投资。
• 随着时间的推移，您可以通过重新设计某些应用程序或为某些边缘位置配备更可靠的互联网链接，逐步减少在边缘运行的工作负载并将其转移到云中。
• 通过在本地执行数据计算，物联网 (IoT) 相关项目可以变得更具成本效益。这使企业能够在更靠近数据源的边缘本地运行和处理某些服务。它还允许企业有选择地将数据发送到云端，这有助于降低物联网解决方案的容量、数据传输、处理和总体成本。
• 边缘计算可以充当传统服务和现代化服务之间的中间通信层。例如，可能运行容器化 API 网关（如 Apigee Hybrid）的服务。这使传统应用程序和系统能够与现代化服务（如物联网解决方案）集成。

最佳实践

在实施边缘混合架构模式时，请考虑以下建议：

• 如果通信是单向的，请使用门控入口模式。
• 如果通信是双向的，请考虑门控出口和门控入口模式。
• 如果解决方案包含许多通过公共互联网连接到 Google Cloud 的边缘远程站点，则可以使用软件定义的 WAN (SD-WAN) 解决方案。您还可以将Network Connectivity Center与Google Cloud 合作伙伴支持的第三方 SD-WAN 路由器结合使用，以简化大规模安全连接的配置和管理。
• 尽量减少在边缘运行的系统与在云环境中运行的系统之间的依赖关系。每种依赖关系都可能削弱边缘混合设置的可靠性和延迟优势。
• 为了有效地管理和运营多个边缘位置，您应该在云中拥有一个集中的管理平面和监控解决方案。
• 确保 CI/CD 管道以及用于部署和监控的工具在云和边缘环境中保持一致。
• 在适用且可行的情况下，请考虑使用容器和 Kubernetes，以消除各个边缘位置之间以及边缘位置和云之间的差异。由于 Kubernetes 提供了一个通用的运行时层，因此您可以在计算环境中一致地开发、运行和操作工作负载。您还可以在边缘和云之间移动工作负载。
  • 为了简化混合设置和操作，您可以将GKE Enterprise用于此架构（如果跨环境使用容器）。考虑将本地或边缘环境中运行的 GKE Enterprise 集群连接到 Google Cloud 所需的可能的连接选项。
• 作为此模式的一部分，尽管某些 GKE Enterprise 组件可能会在与 Google Cloud 的连接暂时中断期间持续运行，但请勿在与 Google Cloud 断开连接时将 GKE Enterprises 用作正常工作模式。如需了解详情，请参阅与 Google Cloud 暂时断开连接的影响。
• 为了克服不同后端和边缘服务之间的协议、API 和身份验证机制不一致的问题，我们建议在适用的情况下部署 API 网关或代理作为统一的外观。此网关或代理充当集中控制点并执行以下措施：
  • 实施额外的安全措施。
  • 保护客户端应用程序和其他服务免受后端代码更改的影响。
  • 促进所有跨环境应用程序及其解耦组件之间的通信的审计跟踪。
  • 充当传统服务和现代化服务之间的中间通信层。
    • Apigee 和Apigee Hybrid让您可以跨本地环境、边缘、其他云和 Google Cloud 环境托管和管理企业级和混合网关。
• 在环境之间建立共同的身份，以便系统可以跨环境边界安全地进行身份验证。
• 由于环境之间交换的数据可能是敏感的，请确保使用 VPN 隧道、TLS或两者对传输中的所有通信进行加密。

环境混合模式

使用环境混合架构模式，您可以将工作负载的生产环境保留在现有数据中心中。然后，您可以将公共云用于开发和测试环境或其他环境。此模式依赖于跨多个计算环境对相同应用程序进行冗余部署。部署的目标是帮助提高容量、敏捷性和弹性。

在评估要迁移哪些工作负载时，您可能会注意到在公共云中运行特定应用程序会带来挑战的情况：

• 司法管辖权或监管限制可能要求您将数据保存在特定国家/地区。
• 第三方许可条款可能会阻止您在云环境中操作某些软件。
• 应用程序可能需要访问仅本地可用的硬件设备。

在这种情况下，不仅要考虑生产环境，还要考虑应用程序生命周期中涉及的所有环境，包括开发、测试和登台系统。这些限制通常适用于生产环境及其数据。它们可能不适用于不使用实际数据的其他环境。请咨询您组织的合规部门或同等团队。

下图展示了典型的环境混合架构模式：

在与生产系统不同的环境中运行开发和测试系统似乎存在风险，并且可能会偏离您现有的最佳实践或您为尽量减少环境之间的差异所做的努力。虽然这种担忧是有道理的，但如果您区分开发和测试过程的各个阶段，这些担忧就不适用了：

尽管每个应用程序的开发、测试和部署过程各不相同，但它们通常涉及以下阶段的变化：

• 开发：创建候选发布版本。
• 功能测试或用户验收测试：验证候选版本是否满足功能要求。
• 性能和可靠性测试：验证候选版本是否满足非功能性要求。这也称为负载测试。
• 暂存或部署测试：验证部署过程是否有效。
• 生产：发布新的或更新的应用程序。

在单一环境中执行多个阶段很少可行，因此每个阶段通常需要一个或多个专用环境。

注意：术语“暂存环境”经常与测试环境混淆。

测试环境的主要目的是运行功能测试。暂存环境的主要目的是测试您的应用程序部署过程是否按预期工作。当版本到达暂存环境时，您的功能测试应该已经完成​​。暂存是将软件部署到生产部署之前的最后一步。

为了确保测试结果有意义并且适用于生产部署，在应用程序的整个生命周期中使用的环境集必须尽可能满足以下规则：

• 所有环境在功能上都是等效的。也就是说，操作系统和库的架构、API 和版本都是等效的，并且系统在各个环境中的行为相同。这种等效性可以避免应用程序在一个环境中运行但在另一个环境中失败的情况，或者缺陷无法重现的情况。
• 用于性能和可靠性测试、准备和生产的环境在功能上是非等同的。也就是说，它们的性能、规模和配置以及操作和维护方式要么相同，要么只有微不足道的差异。否则，性能和准备测试就毫无意义。

一般来说，如果用于开发和功能测试的环境与其他环境在非功能上有所不同，那就没问题。

如下图所示，测试和开发环境均在 Google Cloud 上构建。托管数据库（如 Cloud SQL）可用作 Google Cloud 中的开发和测试选项。开发和测试可以在本地环境中使用相同的数据库引擎和版本、功能等效的数据库引擎和版本，或者在测试阶段后推广到生产环境的新版本。但是，由于两个环境的底层基础架构并不相同，因此这种性能负载测试方法无效。

以下场景可以很好地适应环境混合模式：

• 在适用且可行的情况下，通过依赖 Kubernetes 作为通用运行时层，在所有环境中实现功能等效性。Google Kubernetes Engine (GKE) 企业版可以成为此方法的关键支持技术。
  • 确保工作负载的可移植性并抽象计算环境之间的差异。使用零信任服务网格，您可以控制和维护不同环境之间所需的通信分离。
• 在公共云中运行开发和功能测试环境。这些环境在功能上可能与其余环境相同，但在性能等非功能方面可能有所不同。上图说明了此概念。
• 在私有计算环境中运行生产、登台、性能（负载测试）和可靠性测试的环境，确保功能和非功能等效性。

设计考虑

• 业务需求：每种应用程序部署和发布策略都有各自的优点和缺点。为确保您选择的方法符合您的特定要求，请根据对业务需求和限制的全面评估进行选择。
• 环境差异：作为此模式的一部分，使用此云环境的主要目的是进行开发和测试。最终状态是在私有本地环境（生产）中托管经过测试的应用程序。为了避免开发和测试在云环境中可能按预期运行但在生产环境（本地）中失败的功能，技术团队必须了解并理解这两种环境的架构和功能。这包括对其他应用程序和硬件基础架构的依赖关系 — 例如，执行流量检查的安全系统。
• 治理：要控制贵公司可以在云中开发哪些内容以及可以使用哪些数据进行测试，请使用审批和治理流程。此流程还可以帮助您的公司确保不会在开发和测试环境中使用本地生产环境中不存在的任何云功能。
• 成功标准：必须有明确、预定义且可衡量的测试成功标准，这些标准必须符合您组织的软件质量保证标准。将这些标准应用于您开发和测试的任何应用程序。
• 冗余：尽管开发和测试环境可能不需要像生产环境那样高的可靠性，但它们仍然需要冗余功能和测试不同故障场景的能力。您的故障场景要求可能会促使设计将冗余作为开发和测试环境的一部分。

优点

在公共云中运行开发和功能测试工作负载有几个优点：

• 您可以根据需要自动启动和停止环境。例如，您可以为每个提交或拉取请求配置整个环境，允许测试运行，然后再次关闭它。这种方法还具有以下优势：
  • 您可以通过在虚拟机 (VM) 实例处于非活动状态时停止它们或仅按需配置环境来降低成本。
  • 您可以通过为每个拉取请求启动临时环境来加快开发和测试速度。这样做还可以减少维护开销并减少构建环境中的不一致。
• 在公有云中运行这些环境有助于熟悉和信任云和相关工具，这可能有助于迁移其他工作负载。如果您决定使用容器和 Kubernetes 探索工作负载可移植性（例如，跨环境使用GKE Enterprise） ，这种方法尤其有用。

最佳实践

为了成功实现环境混合架构模式，请考虑以下建议：

• 定义您的应用程序通信需求，包括最佳网络和安全设计。然后，使用镜像网络模式来帮助您设计网络架构，以防止来自不同环境的系统之间直接通信。如果需要跨环境通信，则必须以受控的方式进行。

• 您选择的应用程序部署和测试策略应与您的业务目标和要求保持一致。这可能涉及在不停机的情况下推出更改，或在更广泛发布之前逐步向特定环境或用户组实施功能。

• 为了使工作负载可移植并消除环境之间的差异，您可以将容器与 Kubernetes 结合使用。有关详细信息，请参阅GKE Enterprise 混合环境参考架构。

• 建立跨计算环境的通用工具链，用于部署、配置和操作工作负载。使用 Kubernetes 可为您提供这种一致性。

• 确保 CI/CD 管道在计算环境中保持一致，并且在这些环境中部署完全相同的二进制文件、包或容器。

• 使用 Kubernetes 时，使用Tekton等 CI 系统来实现部署到集群并跨环境工作的部署流水线。如需了解更多信息，请参阅Google Cloud 上的 DevOps 解决方案。

• 为了帮助您持续发布安全可靠的应用程序，请将安全性作为 DevOps 流程 (DevSecOps) 不可或缺的一部分。有关更多信息，请参阅使用 Dev(Sec)Ops Toolkit 在不到一小时内交付并保护面向互联网的应用程序。

• 使用相同的工具在 Google Cloud 和现有云环境中进行日志记录和监控。考虑使用开源监控系统。有关详细信息，请参阅混合和多云监控和日志记录模式。

• 如果不同的团队管理测试和生产工作负载，使用单独的工具可能是可以接受的。但是，使用具有不同查看权限的相同工具可以帮助减少培训工作量和复杂性。

• 当您选择数据库、存储和消息传递服务进行功能测试时，请使用在 Google Cloud 上具有托管等效产品的产品。依赖托管服务有助于减少维护开发和测试环境的管理工作量。

• 为了保护敏感信息，我们建议对所有传输中的通信进行加密。如果连接层需要加密，则有多种选项可供选择，具体取决于所选的混合连接解决方​​案。这些选项包括 VPN 隧道、Cloud Interconnect 上的 HA VPN 和 Cloud Interconnect 的 MACsec。

下表显示了哪些 Google Cloud 产品与常见的 OSS 产品兼容。

OSS 产品	与 Google Cloud 产品兼容
Apache HBase	Bigtable
阿帕奇梁	数据流
慢性非霍奇金淋巴瘤	云数据融合
Apache Hadoop	数据处理
MySQL、PostgreSQL	云端 SQL
Redis 集群、Redis、Memcached	记忆商店
网络文件系统 (NFS)	文件存储
JMS，卡夫卡	发布/订阅
Kubernetes	GKE 企业版

业务连续性混合和多云模式

考虑关键任务系统业务连续性的主要驱动力是帮助组织保持弹性并在故障事件期间和之后继续其业务运营。通过在多个地理区域复制系统和数据并避免单点故障，您可以最大限度地降低影响本地基础设施的自然灾害的风险。其他故障情况包括严重的系统故障、网络安全攻击，甚至系统配置错误。

优化系统以抵御故障对于建立有效的业务连续性至关重要。系统可靠性可能受多种因素影响，包括但不限于性能、弹性、正常运行时间可用性、安全性和用户体验。如需详细了解如何在 Google Cloud 上设计和运行可靠的服务，请参阅Google Cloud架构框架的可靠性支柱和Google Cloud 中的可靠性构建块。

这种架构模式依赖于跨多个计算环境的冗余应用程序部署。在此模式中，您将相同的应用程序部署在多个计算环境中，以提高可靠性。业务连续性可以定义为组织在发生中断事件后以预定义的可接受水平继续其关键业务功能或服务的能力。

灾难恢复 (DR)被视为业务连续性的一个子集，明确侧重于确保支持关键业务功能的 IT 系统在发生中断后尽快恢复运行。一般而言，灾难恢复策略和计划通常有助于制定更广泛的业务连续性策略。从技术角度来看，当您开始制定灾难恢复策略时，您的业务影响分析应定义两个关键指标：恢复点目标 (RPO)和恢复时间目标 (RTO)。有关使用 Google Cloud 解决灾难恢复问题的更多指导，请参阅灾难恢复规划指南。

RPO 和 RTO 目标值越小，服务从中断中恢复的速度就越快，数据丢失也越少。但是，这意味着更高的成本，因为这意味着要构建冗余系统。能够执行近乎实时的数据复制并在发生故障后以相同规模运行的冗余系统会增加复杂性、管理开销和成本。

选择DR 策略或模式的决定应由业务影响分析决定。例如，对于金融服务组织来说，即使几分钟的停机时间造成的财务损失也可能远远超过实施 DR 系统的成本。然而，其他行业的企业可能会承受数小时的停机时间而不会对业务产生重大影响。

当您在本地数据中心运行任务关键型系统时，一种 DR 方法是在不同区域的第二个数据中心维护备用系统。然而，更具成本效益的方法是使用基于公共云的计算环境进行故障转移。这种方法是业务连续性混合模式的主要驱动力。从成本角度来看，云尤其有吸引力，因为它允许您在不使用时关闭部分 DR 基础设施。为了实现更低成本的 DR 解决方案，云解决方案允许企业接受 RPO 和 RTO 值的潜在增加。

上图说明了如何使用云作为本地环境的故障转移或灾难恢复环境。

此模式的一个不太常见（且很少需要）的变体是业务连续性多云模式。在该模式中，生产环境使用一个云提供商，而 DR 环境使用另一个云提供商。通过跨多个云提供商部署工作负载副本，您可能会提高可用性，而多区域部署则无法提供这种可用性。

评估跨多个云平台的 DR 与使用一个云提供商的不同区域的 DR 需要彻底分析几个考虑因素，包括以下内容：

• 可管理性
• 安全
• 总体可行性。
• 成本
  • 如果持续进行云间通信，来自多个云提供商的潜在出站数据传输费用可能会很高。
  • 复制数据库时可能会产生大量流量。
  • TCO 和管理云间网络基础设施的成本。

注意：有关跨云互连如何帮助您降低 TCO 和减少复杂性的更多信息，请参阅宣布跨云互连：与所有云的无缝连接。

如果您的数据需要留在您所在的国家/地区以满足监管要求，则可以使用同样位于您所在国家/地区的第二个云提供商作为 DR。使用第二个云提供商的前提是无法使用本地环境构建混合设置。为了避免重新构建您的云解决方案，理想情况下，您的第二个云提供商应提供您在区域内所需的所有必需功能和服务。

设计注意事项

• DR 预期：您的企业想要实现的 RPO 和 RTO 目标应该推动您的 DR 架构和构建规划。
• 解决方案架构：使用此模式，您需要复制本地环境的现有功能和能力以满足您的 DR 期望。因此，您需要评估重新托管、重构或重新架构应用程序的可行性和可行性，以便在云环境中提供相同（或更优化）的功能和性能。
• 设计和构建：构建着陆区几乎始终是部署云环境中企业工作负载的先决条件。有关详细信息，请参阅Google Cloud 中的着陆区设计。

• DR 调用：对于您的 DR 设计和流程来说，考虑以下问题非常重要：

  • 什么会触发 DR 场景？例如，主站点中的特定功能或系统发生故障可能会触发 DR。
  • 如何调用故障转移到 DR 环境？这是一个手动批准流程，还是可以自动化以实现低 RTO 目标？
  • 应如何设计系统故障检测和通知机制，以便根据预期的 RTO 调用故障转移？
  • 检测到故障后，流量如何重新路由到 DR 环境？

  通过测试验证这些问题的答案。

• 测试：彻底测试和评估 DR 故障转移。确保它符合您的 RPO 和 RTO 预期。这样做可以让您更有信心在需要时调用 DR。每当对流程或技术解决方案进行新的更改或更新时，请再次进行测试。

• 团队技能：一个或多个技术团队必须具备在云环境中构建、操作和排除生产工作负载故障的技能和专业知识，除非您的环境由第三方管理。

优点

使用 Google Cloud 实现业务连续性具有以下几个优势：

• 由于 Google Cloud 在全球拥有多个区域可供选择，因此您可以使用它将数据备份或复制到同一大洲内的其他站点。您还可以将数据备份或复制到不同大洲的站点。
• Google Cloud 提供了将数据存储在双区域或多区域存储桶中的 Cloud Storage 功能。数据以冗余方式存储在至少两个独立的地理区域中。存储在双区域和多区域存储桶中的数据使用默认复制功能跨地理区域进行复制。
  • 双区域存储桶提供地理冗余，以支持业务连续性和灾难恢复计划。此外，为了以更低的 RPO更快地进行复制，存储在双区域中的对象可以选择在这些区域之间使用Turbo 复制。
  • 类似地，多区域复制通过将数据存储在多区域的地理边界内，提供了跨多个区域的冗余。
• 提供以下一个或多个选项，以减少构建 DR 的资本支出和运营费用：
  • 停止的 VM 实例仅会产生存储成本，比正在运行的 VM 实例便宜得多。这意味着您可以最大限度地降低维护冷备用系统的成本。
  • Google Cloud 的按使用付费模式意味着您只需为实际使用的存储和计算容量付费。
  • 自动扩展等弹性功能可让您根据需要自动扩展或缩小 DR 环境。

例如，下图显示了在本地环境（生产）中运行的应用，该应用使用 Google Cloud 上的恢复组件以及 Compute Engine、Cloud SQL 和 Cloud Load Balancing。在此场景中，数据库使用基于虚拟机的数据库或使用 Google Cloud 托管数据库（如 Cloud SQL）进行预配置，以便通过持续数据复制实现更快的恢复。您可以从预先创建的快照启动 Compute Engine VM，以降低正常操作期间的成本。使用此设置，在发生故障事件后，DNS 需要指向 Cloud Load Balancing 外部 IP 地址。

要使应用程序在云中运行，您需要配置 Web 和应用程序虚拟机。根据目标 RTO 级别和公司政策，调用 DR、在云中配置工作负载和重新路由流量的整个过程可以手动或自动完成。

为了加快和自动化基础设施的配置，请考虑将基础设施作为代码进行管理。您可以使用 Cloud Build（一种持续集成服务）自动将 Terraform 清单应用于您的环境。有关更多信息，请参阅使用 Terraform、Cloud Build 和 GitOps 将基础设施作为代码进行管理。

最佳实践

使用业务连续性模式时，请考虑以下最佳做法：

• 创建一个灾难恢复计划，记录您的基础设施以及故障转移和恢复程序。
• 根据您的业务影响分析和确定的所需 RPO 和 RTO 目标，考虑采取以下措施：
  • 确定将数据备份到 Google Cloud 是否足够，或者是否需要考虑其他 DR 策略（冷、温或热备用系统）。
  • 定义可用作DR 计划构建模块的服务和产品。
  • 将适用于您的应用程序和数据的 DR 场景作为您选择的 DR 策略的一部分。
• 当您仅备份数据时，请考虑使用切换模式。否则，网状模式可能是复制现有环境网络架构的不错选择。
• 尽量减少在不同环境中运行的系统之间的依赖关系，尤其是在同步处理通信时。这些依赖关系可能会降低性能并降低整体可用性。

• 避免裂脑问题。如果您在环境之间双向复制数据，则可能会遇到裂脑问题。当两个双向复制数据的环境彼此失去通信时，就会发生裂脑问题。这种分裂可能会导致两个环境中的系统得出另一个环境不可用且它们对数据具有独占访问权限的结论。这可能会导致数据修改冲突。有两种常用方法可以避免裂脑问题：

  • 使用第三个计算环境。此环境允许系统在修改数据之前检查法定人数。

  • 允许在连接恢复后协调冲突的数据修改。

    使用 SQL 数据库，您可以在客户端开始使用新的主实例之前使原始主实例无法访问，从而避免裂脑问题。有关详细信息，请参阅Cloud SQL 数据库灾难恢复。

• 确保 CI/CD 系统和工件存储库不会成为单点故障。当一个环境不可用时，您仍然必须能够部署新版本或应用配置更改。

• 使用备用系统时，确保所有工作负载都可移植。所有工作负载都应可移植（在应用程序支持且可行的情况下），以便系统在不同环境中保持一致。您可以通过考虑容器和 Kubernetes 来实现此方法。通过使用 Google Kubernetes Engine (GKE) 企业版，您可以简化构建和操作。

• 将备用系统的部署集成到您的 CI/CD 管道中。此集成有助于确保应用程序版本和配置在各个环境中保持一致。

• 通过将 DNS 配置为合理较短的生存时间值来确保 DNS 更改能够快速传播，以便在发生灾难时可以将用户重新路由到备用系统。

• 选择与您的架构和解决方案行为相符的DNS 策略和路由策略。此外，您可以将多个区域负载均衡器与 DNS 路由策略相结合，以针对不同用例（包括混合设置）创建全局负载均衡架构。

• 使用多个 DNS 提供商。使用多个 DNS 提供商时，您可以：

  • 提高应用程序和服务的可用性和弹性。

  • 通过多提供商 DNS 配置简化跨本地和云环境依赖的混合应用程序的部署或迁移。

    Google Cloud 提供基于 octoDNS 的开源解决方案，帮助您设置和运行具有多个 DNS 提供商的环境。如需了解详情，请参阅使用 Cloud DNS 的多提供商公共 DNS。

• 使用备用系统创建自动故障转移时，请使用负载平衡器。请记住，负载平衡器硬件可能会发生故障。

• 使用Cloud Load Balancing代替硬件负载均衡器来支持使用此架构模式时出现的某些场景。内部客户端请求或外部客户端请求可以根据不同的指标（例如基于权重的流量拆分）重定向到主环境或 DR 环境。有关更多信息，请参阅全局外部应用程序负载均衡器的流量管理概述。

• 如果从 Google Cloud 到其他环境的出站数据传输量很大，请考虑使用 Cloud Interconnect 或 Cross-Cloud Interconnect。Cloud Interconnect 可以帮助优化连接性能，并可能降低满足特定条件的流量的出站数据传输费用。有关更多信息，请参阅Cloud Interconnect 定价。

• 考虑在Google Cloud Marketplace上使用您首选的合作伙伴解决方案来帮助促进数据备份、复制和其他满足您的要求的任务，包括您的 RPO 和 RTO 目标。

• 测试并评估 DR 调用场景，以了解与目标 RTO 值相比，应用程序从灾难事件中恢复的速度有多快。

• 加密传输中的通信。为了保护敏感信息，我们建议加密传输中的所有通信。如果连接层需要加密，则根据所选的混合连接解决方​​案，有多种选项可供选择。这些选项包括 VPN 隧道、Cloud Interconnect 上的高可用性 VPN 和 Cloud Interconnect 的 MACsec。

云爆发模式

互联网应用程序的使用情况可能会出现极大的波动。虽然大多数企业应用程序不会面临这一挑战，但许多企业必须处理不同类型的突发工作负载：批处理或 CI/CD 作业。

此架构模式依赖于跨多个计算环境的应用程序冗余部署。目标是提高容量、弹性或两者兼而有之。

虽然您可以通过过度配置资源来适应数据中心计算环境中的突发工作负载，但这种方法可能并不经济高效。对于批处理作业，您可以通过延长执行时间来实现优化，但如果作业对时间敏感，则延迟执行作业并不实际。

云爆发模式的理念是使用私有计算环境作为基线负载，并在需要额外容量时暂时爆发到云端。

在上图中，当本地私有环境中的数据容量达到极限时，系统可以在需要时从 Google Cloud 环境获取额外的容量。

这种模式的关键驱动因素是节省资金并减少响应规模需求变化所需的时间和精力。通过这种方法，您只需为处理额外负载时使用的资源付费。这意味着您无需过度配置基础设施。相反，您可以利用按需云资源并根据需求和任何预定义指标进行扩展。因此，您的公司可能会避免在高峰需求时段出现服务中断。

云爆发场景的一个潜在要求是工作负载可移植性。当您允许将工作负载部署到多个环境时，必须抽象出环境之间的差异。例如，Kubernetes 使您能够在使用不同基础架构的不同环境中实现工作负载级别的一致性。有关更多信息，请参阅GKE Enterprise 混合环境参考架构。

设计注意事项

云爆发模式适用于交互式和批处理工作负载。但是，在处理交互式工作负载时，您必须确定如何在环境中分配请求：

• 您可以将传入的用户请求路由到在现有数据中心运行的负载均衡器，然后让负载均衡器在本地和云资源之间分配请求。

  这种方法要求现有数据中心中运行的负载均衡器或其他系统也跟踪云中分配的资源。负载均衡器或其他系统还必须启动资源的自动扩展或缩减。使用这种方法，您可以在活动较少时停用所有云资源。但是，实施跟踪资源的机制可能会超出负载均衡器解决方案的能力，因此会增加整体复杂性。

• 您可以将 Cloud Load Balancing 与混合连接网络端点组 (NEG)后端结合使用，而无需实施资源跟踪机制。您可以使用此负载均衡器将内部客户端请求或外部客户端请求路由到位于本地和 Google Cloud 中的后端，这些后端基于不同的指标，例如基于权重的流量拆分。您还可以根据Google Cloud 中工作负载的负载平衡服务容量来扩展后端。有关更多信息，请参阅全局外部应用程序负载均衡器的流量管理概览。

  这种方法还有其他一些好处，例如利用 Google Cloud Armor DDoS 防护功能、WAF 以及使用Cloud CDN在云边缘缓存内容。但是，您需要调整混合网络连接的大小以处理额外的流量。

• 正如在工作负载可移植性中强调的那样，应用程序可能只需进行少量更改即可移植到不同的环境以实现工作负载一致性，但这并不意味着应用程序在两种环境中的性能相同。底层计算、基础设施安全功能或网络基础设施的差异以及与依赖服务的接近程度通常决定了性能。通过测试，您可以获得更准确的可见性并了解性能预期。

• 您可以使用云基础架构服务构建一个环境来托管不具备可移植性的应用程序。在高峰需求时段重定向流量时，请使用以下方法来处理客户端请求：

  • 使用一致的工具来监控和管理这两个环境。
  • 确保工作负载版本一致且数据源是最新的。
  • 当需求增加并且云工作负载预计会接受客户端对您的应用程序的请求时，您可能需要添加自动化功能来配置云环境并重新路由流量。

• 如果您打算在需求低迷时关闭所有 Google Cloud 资源，则主要使用 DNS 路由策略进行流量负载平衡可能并非始终是最佳选择。这主要是因为：

  • 资源可能需要一些时间进行初始化才能为用户提供服务。
  • DNS 更新往往会在互联网上传播得很慢。

  因此：

  • 即使没有可用资源来处理用户的请求，用户也可能会被路由到云环境。
  • 当 DNS 更新在互联网上传播时，用户可能会暂时被路由到本地环境。

使用 Cloud DNS，您可以选择与您的解决方案架构和行为相符的DNS 策略和路由策略，例如地理位置 DNS 路由策略。Cloud DNS 还支持内部直通网络负载均衡器和内部应用程序负载均衡器的健康检查。在这种情况下，您可以将其与基于此模式的整体混合 DNS 设置相结合。

在某些情况下，您可以使用 Cloud DNS 在 Google Cloud 上分发带有健康检查的客户端请求，例如使用内部应用程序负载均衡器或跨区域内部应用程序负载均衡器时。在这种情况下，Cloud DNS 检查内部应用程序负载均衡器的整体运行状况，而内部应用程序负载均衡器本身会检查后端实例的运行状况。有关更多信息，请参阅管理 DNS 路由策略和健康检查。

您还可以使用Cloud DNS 水平分割。Cloud DNS 水平分割是一种针对同一域名设置 DNS 响应或记录到 DNS 查询发起者的特定位置或网络的方法。此方法通常用于满足应用程序旨在提供私人和公共体验的需求，每种体验都具有独特的功能。该方法还有助于跨环境分配流量负载。

考虑到这些因素，云爆发通常更适合批处理工作负载而不是交互式工作负载。

优点

云爆发架构模式的主要优势包括：

• 云爆发让您可以重复利用数据中心和私有计算环境中的现有投资。这种重复利用可以是永久性的，也可以一直有效，直到现有设备需要更换，此时您可以考虑进行全面迁移。
• 由于您不再需要维持过剩容量来满足峰值需求，因此您可能能够提高私有计算环境的利用率和成本效益。
• 云爆发让您可以及时运行批处理作业，而无需过度配置计算资源。

最佳实践

实施云爆发时，请考虑以下最佳实践：

• 为了确保在云中运行的工作负载能够以与在本地环境中运行的工作负载相同的方式访问资源，请使用具有最小特权安全访问原则的网状模式。如果工作负载设计允许，您可以只允许从云访问本地计算环境，而不允许反过来。
• 为了最大限度地减少环境之间的通信延迟，请选择地理位置靠近您的私有计算环境的Google Cloud 区域。有关详细信息，请参阅Compute Engine 区域选择最佳实践。
• 当仅将云爆发用于批处理工作负载时，请将所有 Google Cloud 资源设为私密，以减少安全攻击面。禁止从互联网直接访问这些资源，即使您使用 Google Cloud 外部负载平衡来提供工作负载的入口点。

• 选择与您的架构模式和目标解决方案行为相符的DNS 策略和路由策略。

  • 作为此模式的一部分，您可以永久应用 DNS 策略的设计，或者在高峰需求时段使用其他环境来获取额外容量。
  • 您可以使用地理位置 DNS 路由策略为您的区域负载均衡器设置全局 DNS 端点。此策略有许多使用地理位置 DNS 路由策略的用例，包括使用 Google Cloud 的混合应用以及存在 Google Cloud 区域的本地部署。

  • 如果您需要为相同的 DNS 查询提供不同的记录，则可以使用分割水平 DNS - 例如来自内部和外部客户端的查询。

    有关详细信息，请参阅混合 DNS 的参考体系结构For more information, see reference architectures for hybrid DNS

• 为了确保 DNS 更改能够快速传播，请为 DNS 配置一个合理较短的生存时间值，以便在需要使用云环境的额外容量时可以将用户重新路由到备用系统。

• 对于时间要求不高且不在本地存储数据的作业，请考虑使用Spot VM 实例，这比常规 VM 实例便宜得多。但前提条件是，如果 VM 作业被抢占，系统必须能够自动重新启动该作业。

• 在适用的情况下使用容器实现工作负载可移植性。此外，GKE Enterprise 可以成为该设计的关键支持技术。有关更多信息，请参阅GKE Enterprise 混合环境参考架构。

• 监控从 Google Cloud 发送到其他计算环境的任何流量。此流量需缴纳出站数据传输费。

• 如果您计划长期使用此架构并处理大量出站数据传输，请考虑使用 Cloud Interconnect。Cloud Interconnect 可以帮助优化连接性能，并可能降低满足特定条件的流量的出站数据传输费用。有关更多信息，请参阅Cloud Interconnect 定价。

• 使用 Cloud Load Balancing 时，您应在适用的情况下使用其应用程序容量优化功能。这样做可以帮助您解决全球分布式应用程序中可能出现的一些容量挑战。

• 通过在环境之间建立共同的身份来对使用系统的人员进行身份验证，以便系统可以跨环境边界安全地进行身份验证。

• 为了保护敏感信息，强烈建议对传输中的所有通信进行加密。如果连接层需要加密，则根据所选的混合连接解决方​​案，有多种选项可供选择。这些选项包括 VPN 隧道、Cloud Interconnect 上的 HA VPN 和 Cloud Interconnect 的 MACsec。

混合云和多云架构模式：下一步是什么

• 了解如何实现混合和多云架构以及如何选择合适的工作负载。
• 了解适合所选混合和多云架构模式的网络架构模式的更多信息。
• 了解有关云应用程序部署原型的更多信息。
• 了解如何使用不同的架构设计和部署电子商务 Web 应用程序，包括使用 GKE 的基于微服务的电子商务 Web 应用程序，以及基于无服务器 API的动态 Web 应用程序。