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

混合云和多云架构模式的文档集包含以下部分：

• 构建混合云和多云架构：讨论如何规划使用 Google Cloud设计混合云和多云设置架构的策略。
• 混合云和多云架构模式：讨论在混合云和多云策略中采用的常见架构模式（本文档）。
• 混合云和多云安全网络架构模式：从网络角度讨论混合云和多云网络架构模式。

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

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

如需大致定义应用或解决方案的架构模式，请确定并定义以下内容：

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

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

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

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

本系列包含以下页面：

• 分布式架构模式

  • 分层混合模式

  • 分区多云模式

  • 分析混合云和多云端模式

  • 边缘混合模式

• 冗余架构模式

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

贡献者

作者：Marwan Al Shawi | 合作伙伴客户工程师

其他贡献者：

• Saud Albazei | 客户工程师，应用现代化改造
• Anna Berenberg | 工程研究员
• Marco Ferrari | 云解决方案架构师
• Victor Morno | Cloud 网络产品经理
• ohannes Passing | 云解决方案架构师
• Mark Schlagenhauf | 网络技术文档工程师
• Daniel Strebel | 欧洲、中东和非洲地区应用现代化改造解决方案负责人
• 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 Well-Architected Framework：费用优化。

数据移动

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

安全

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

在规划迁移策略时，我们建议您分析上述注意事项。它们可以帮助您最大限度地降低应用或流量规模扩大时架构复杂化的可能性。此外，设计和构建着陆区几乎总是在云环境中部署企业工作负载的前提条件。着陆区可帮助您的企业更安全地部署、使用和扩缩云服务，它跨多个区域，涉及身份、资源管理、安全性和网络等不同元素。如需了解详情，请参阅 Google Cloud中的着陆区设计。

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

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

分层混合模式

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

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

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

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

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

三层式 Web 应用解决方案是构建商务 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 应用的 3 种方式。 如需详细了解如何在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 等云托管平台，可让您使用 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 网关搭配使用可实现以下目标：

  • 借助 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 Enterprise 都可以成为关键的赋能技术。如需了解详情，请参阅 GKE Enterprise 混合环境。

  • 在 Google Cloud 迁移和现代化应用组件的环境中。

    • 如果您的本地旧版后端不支持容器化，或者需要在短期内投入大量时间和资源才能实现现代化，请使用此方法。

    如需详细了解如何设计单体式应用并将其重构为微服务架构，以实现 Web 应用架构的现代化，请参阅微服务简介。

• 您可以根据 Web 应用的需求组合使用各种数据存储技术。使用 Cloud SQL 存储结构化数据，使用 Cloud Storage 存储媒体文件，是一种常见的做法，可满足多样化的数据存储需求。不过，具体选择哪种方式在很大程度上取决于您的使用情形。如需详细了解内容驱动型应用后端的数据存储选项和有效模式，请参阅内容驱动型 Web 应用的数据存储选项。 另请参阅 Google Cloud 数据库选项说明。

分区多云模式

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

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

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

• 在两家企业合并和收购的场景中，全面集成托管在不同云环境中的应用。
• 提升灵活性并满足组织内的各种云偏好。采用这种方法可鼓励组织部门选择最符合其特定需求和偏好的云服务提供商。
• 在多区域或全球云部署中运营。如果企业需要遵守特定地区或国家的数据驻留法规，但其主要云服务提供商在该地区或国家没有云区域，那么企业就需要从该位置的可用云服务提供商中进行选择。

采用分区多云架构模式时，您可以选择保留根据需要将工作负载从一个公有云环境迁移到另一个公有云环境的能力。在这种情况下，工作负载的可移植性就成为关键要求。如果您将工作负载部署到多个计算环境，并希望保留在环境之间移动工作负载的功能，则必须将环境之间的差异抽象化。借助 GKE Enterprise，您可以设计和构建解决方案，通过一致的治理、运营和安全状况来解决多云复杂性。如需了解详情，请参阅 GKE Multi-cloud。

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

优点

如推动因素、注意事项、策略和模式中所述，使用多云架构有许多业务和技术优势，而对每项潜在优势进行详细的可行性评估也非常重要。您的评估应仔细考虑任何相关的直接或间接挑战或潜在障碍，以及您有效应对这些挑战和障碍的能力。此外，请注意，应用或服务的长期增长可能会引入复杂性，从而使劣势大于最初的优势。

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

• 如果您需要尽可能减少对单个云服务提供商的承诺，您可以在多个云服务提供商之间分布应用。这样，您可以相对地减少供应商锁定，并能够（在某种程度上）跨云服务提供商调整计划。开放式云平台可将 Google Cloud 功能（例如 GKE Enterprise）带到不同的物理位置。通过在本地、多个公有云和边缘扩展 Google Cloud 功能，它可提供灵活性、敏捷性并推动转型。

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

• 分区多云架构模式有助于在主要云服务提供商尚未推出云区域或入网点的位置降低延迟时间并提升用户体验的整体质量。当使用高容量和低延迟的多云连接（例如 Cross-Cloud Interconnect 和使用分布式 CDN 的 CDN 互连）时，此模式尤为有用。

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

• 分区多云架构模式可促进和加速合并和收购场景，在此场景中，两个企业的应用和服务可能托管在不同的公有云环境中。

最佳做法

• 首先部署非任务关键型工作负载。然后，这种在次要云中的初始部署可用作未来部署或迁移的模式。但是，如果法律或法规要求特定工作负载位于特定云区域，而主要云服务提供商在所要求的地区未推出云区域，则此方法可能不适用。
• 最大限度减少在不同公有云环境中运行的系统之间的依赖项，尤其是在同步处理通信时。这些依赖项会降低性能和整体可用性，并可能产生额外的出站数据传输费用。
• 如需将环境之间的差异抽象化，请考虑在应用支持且可行的情况下使用容器和 Kubernetes。
• 确保 CI/CD 流水线和用于部署和监控的工具在云环境之间保持一致。
• 选择可为您使用的应用提供最高效和最有效的通信解决方案的最优网络架构模式。
  • 必须对通信进行精细控制。使用安全的 API 来公开应用组件。
  • 根据您的特定业务和技术要求，考虑使用网状架构模式或某一种封闭网络模式。
• 为了满足您的可用性和性能预期，请针对端到端高可用性 (HA)、低延迟和适当的吞吐量级别进行设计。

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

  • 如果需要在连接层进行加密，根据所选的混合连接解决方案，有多种选项可供选择。这些选项包括 VPN 隧道、通过 Cloud Interconnect 实现的高可用性 VPN 和 MACsec for Cross-Cloud Interconnect。

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

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

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

  • 如果从 Google Cloud到其他环境的出站数据传输量较高，请考虑使用 Cross-Cloud Interconnect。

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

  • 实施额外的安全措施。
  • 保护客户端应用和其他服务免受后端代码更改的影响。
  • 帮助为所有跨环境应用及其解耦组件之间的通信提供审核跟踪记录。
  • 充当旧版服务和经过现代化改造的服务之间的中间通信层。
    • 借助 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 上的数据移动服务提供了一套完整的产品，可让您以各种方式无缝移动、集成和转换数据。
  • Cloud Storage 非常适合构建数据湖。

• 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) 等敏感数据，前提是符合适用法规和合规要求。

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

• 如果需要长期在 Google Cloud 与其他云之间传输或交换大量数据，您应考虑使用 Google Cloud Cross-Cloud Interconnect，以便在Google Cloud 与其他云服务提供商之间建立高带宽专用连接（在某些位置提供）。

• 如果需要在连接层进行加密，根据所选的混合连接解决方案，有多种选项可供选择。这些选项包括 VPN 隧道、通过 Cloud Interconnect 实现的高可用性 VPN 和 MACsec for Cross-Cloud Interconnect。

• 在环境之间使用一致的工具和流程。在分析混合场景中，此做法有助于提高运营效率，但这并非先决条件。

边缘混合模式

在云中运行工作负载需要某些场景中的客户端具有快速可靠的互联网连接。考虑到今天的网络，这一要求几乎不会对云采用造成障碍。但在某些情况下，持续连接无法得到保证，例如：

• 远洋船舶和其他交通工具可能只能间歇性连接，或者只能接入高延迟的卫星链路。
• 工厂或发电厂可能连接到互联网，这些设施的可靠性要求可能高于其互联网提供商的可用性声明。
• 零售店和超市可能仅需要偶尔连接，或者使用的链接不支持处理业务关键型事务所需的可靠性或吞吐量。

边缘混合架构模式解决了这些难题，方法是在网络边缘本地运行时间关键型和业务关键型工作负载，同时将云用于所有其他类型的工作负载。在边缘混合架构中，互联网链接是非关键组件，用于管理用途以及同步或上传数据（通常以异步方式），但不参与时间关键型或业务关键型事务。

优点

在边缘运行某些工作负载并在云中运行其他工作负载具有多项优势：

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

最佳做法

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

• 对于单向通信，使用封闭入站流量模式。
• 对于双向通信，请考虑使用封闭出站流量和封闭入站流量模式。
• 如果解决方案由许多通过公共互联网连接到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临时断开连接期间仍然可用，但请不要在 GKE Enterprise 与 Google Cloud 断开连接时将其用作标称工作模式。如需了解详情，请参阅与 Google Cloud临时断开连接的影响。
• 为了解决各种各样的后端和边缘服务之间协议、API 和身份验证机制的不一致，我们建议在适用的情况下，将 API 网关或代理部署为统一的外观 (facade)。此网关或代理充当集中式控制点并实施以下措施：
  • 实施额外的安全措施。
  • 保护客户端应用和其他服务免受后端代码更改的影响。
  • 帮助为所有跨环境应用及其解耦组件之间的通信提供审核跟踪记录。
  • 充当旧版服务和经过现代化改造的服务之间的中间通信层。
    • 借助 Apigee 和 Apigee Hybrid，您可以跨本地环境、边缘、其他云和Google Cloud 环境托管和管理企业级混合网关。
• 在环境之间建立通用标识，以便系统能够跨环境边界安全地进行身份验证。
• 由于环境之间交换的数据可能是敏感数据，因此请确保使用 VPN 隧道和/或 TLS 加密所有传输中的通信。

环境混合模式

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

在评估要迁移的工作负载时，您可能会注意到，在公有云中运行特定应用存在一些难题：

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

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

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

在生产系统之外的其他环境中运行开发和测试系统似乎具有风险，并且可能会与现有的最佳实践或为最大限度减少环境之间的差异而进行的尝试背道而驰。虽然这些顾虑是有理由的，但如果您区分开发和测试过程的各个阶段，就会发现这些顾虑是不必要的：

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

• 开发：创建候选版本。
• 功能测试或用户验收测试：验证候选版本是否符合功能要求。
• 性能和可靠性测试：验证候选版本是否符合非功能性要求。也称为负载测试。
• 模拟环境或部署测试：验证部署过程是否有效。
• 生产：发布新应用或更新应用。

在单个环境中执行上述多个阶段不太现实，因此每个阶段通常需要一个或多个专用环境。

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

为确保测试结果有意义且适用于生产部署，您在整个应用生命周期中使用的一组环境必须尽可能符合以下规则：

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

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

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

以下场景非常适合环境混合模式：

• 在适用且可行的情况下，通过依赖 Kubernetes 作为通用运行时层，实现所有环境中的功能等效。Google Kubernetes Engine (GKE) Enterprise 版可以成为实现此方法的关键技术。
  • 确保工作负载可移植性并忽略计算环境之间的差异。借助零信任服务网格，您可以控制并保持不同环境之间所需的通信隔离。
• 在公有云中运行开发和功能测试环境。这些环境在功能上等效于其他环境，但在性能等非功能性方面可能有所不同。上图展示了这一概念。
• 在私有计算环境中运行用于生产、预演环境以及性能（负载测试）和可靠性测试的环境，确保功能和非功能等效性。

设计考虑事项

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

优点

在公有云中运行开发和功能测试工作负载具有多项优势：

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

最佳做法

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

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

• 您选择的应用部署和测试策略应与您的业务目标和要求保持一致。这可能涉及在没有停机时间的情况下发布更改，或者在更广泛地发布之前，先逐步向特定环境或用户群组实现功能。

• 如需使工作负载具有可移植性并忽略环境之间的差异，您可以使用容器和 Kubernetes。如需了解详情，请参阅 GKE Enterprise 混合环境参考架构。

• 建立可跨计算环境的常见工具链，用于部署、配置和操作工作负载。使用 Kubernetes 可让您保持这种一致性。

• 确保 CI/CD 流水线在计算环境之间保持一致，并确保将一组完全相同的二进制文件、软件包或容器部署到这些环境中。

• 使用 Kubernetes 时，使用 Tekton 等持续集成系统实施部署流水线，该流水线可部署到集群并跨环境工作。如需了解详情，请参阅 Google Cloud上的 DevOps 解决方案。

• 为了帮助您持续发布安全可靠的应用，请将安全性纳入 DevOps 流程 (DevSecOps) 中，作为其不可或缺的一部分。如需了解详情，请参阅使用 Dev(Sec)Ops 工具包在不到一小时内交付并保护面向互联网的应用。

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

• 如果由不同团队管理测试和生产工作负载，则使用各自的工具或许可以接受。不过，使用具有不同查看权限的相同工具可以帮助您减少培训工作量和复杂性。

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

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

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

OSS 产品	与 Google Cloud 产品兼容
Apache HBase	Bigtable
Apache Beam	Dataflow
CDAP	Cloud Data Fusion
Apache Hadoop	Dataproc
MySQL、PostgreSQL	Cloud SQL
Redis 集群、Redis、Memcached	Memorystore
Network File System (NFS)	Filestore
JMS、Kafka	Pub/Sub
Kubernetes	GKE Enterprise

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

考虑为关键任务系统提供业务连续性的主要目的是帮助组织在发生故障事件期间和之后保持弹性并继续开展业务运营。通过复制多个地理区域的系统和数据并避免单点故障，您可以将影响本地基础架构的自然灾害风险降至最低。其他故障场景包括严重的系统故障、网络安全攻击，甚至是系统配置错误。

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

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

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

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

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

当您在本地数据中心运行任务关键型系统时，灾难恢复的方法之一，是在位于另一区域的另一个数据中心维护备用系统。不过，更经济实惠的方法是使用基于公有云的计算环境进行故障切换。此方法是业务连续性混合模式的主要驱动因素。从成本角度来看，云平台尤其具有吸引力，因为您可以关闭部分不使用的灾难恢复基础设施。为了实现低成本的灾难恢复解决方案，企业可以接受云解决方案带来的 RPO 和 RTO 值潜在增加。

上图展示了如何将云用作本地环境的故障切换或灾难恢复环境。

此模式有一个不太常见（且很少被需要）的变体，即业务连续性多云端模式。在此模式下，生产环境使用一个云提供商，灾难恢复环境使用另一个云提供商。通过跨多个云提供商部署工作负载副本，您可以获得超过多区域部署所提供的可用性。

评估跨多个云的 DR 与使用具有不同区域的单个云提供商的 DR 需要对多种考虑因素进行全面分析，包括：

• 易管理性
• 安全
• 总体可行性。
• 费用
  • 如果持续进行云间通信，则向多个云提供商支付的出站数据传输费用可能会非常高昂。
  • 复制数据库时，可能会产生大量流量。
  • 总体拥有成本和管理云间网络基础设施的成本。

如果您的数据需要保留在您的国家/地区，以满足监管要求，那么使用也位于您国家/地区的第二家云服务提供商作为灾难恢复解决方案可能是一个不错的选择。使用第二个云服务提供商的前提是，无法使用本地环境来构建混合设置。为避免重新设计云解决方案，理想情况下，您的第二个云提供商应在区域内提供您所需的所有功能和服务。

设计考虑事项

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

• 灾难恢复调用：在设计灾难恢复方案和流程时，请务必考虑以下问题：

  • 什么会触发灾难恢复场景？例如，如果主站点中的特定功能或系统发生故障，可能会触发灾难恢复。
  • 如何调用到灾难恢复环境的故障切换？是手动审批流程，还是可以自动执行以实现较低的 RTO 目标？
  • 系统故障检测和通知机制应如何设计，才能在符合预期 RTO 的情况下调用故障切换？
  • 检测到故障后，流量如何重新路由到 DR 环境？

  通过测试验证您对这些问题的回答。

• 测试：全面测试和评估向 DR 的故障切换。确保其符合您的 RPO 和 RTO 预期。这样做可以帮助您在需要时更有信心调用 DR。每当流程或技术解决方案发生新的变化或更新时，请再次进行测试。

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

优点

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

• 由于 Google Cloud 在全球范围内有许多区域可供选择，因此您可以使用它将数据备份或复制到同一大洲内的其他位置。您还可以将数据备份或复制到其他大洲的位置。
• Google Cloud 支持将数据存储在 Cloud Storage 的双区域或多区域存储桶中。数据以冗余方式存储在至少两个不同的地理区域。存储在双区域和多区域存储分区中的数据会使用默认复制跨地理区域进行复制。
  • 双区域存储分区提供地理位置冗余，以支持业务连续性和灾难恢复 (DR) 计划。此外，为了更快地复制（降低 RPO），存储在双区域中的对象可以选择使用增强型复制功能跨这些区域进行复制。
  • 同样，多区域复制通过将数据存储在多区域的地理边界内，在多个区域之间提供冗余。
• 提供以下一个或多个选项，以减少资本支出和运营支出，从而构建灾难恢复解决方案：
  • 已停止的虚拟机实例仅产生存储费用，比正在运行的虚拟机实例便宜很多。这意味着您可以最大限度地降低维护冷备用系统的费用。
  • Google Cloud 的按用量计费模式意味着您只需为实际使用的存储和计算容量付费。
  • 借助自动扩缩等弹性功能，您可以根据需要自动扩缩灾难恢复环境。

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

为了让应用在云端正常运行，您需要预配 Web 和应用虚拟机。根据目标 RTO 级别和公司政策，调用灾难恢复、在云端预配工作负载和重新路由流量的整个过程可以手动完成，也可以自动完成。

为了加快基础架构的预配速度并实现自动化，请考虑以代码形式管理基础架构。您可以使用 Cloud Build（一种持续集成服务）自动将 Terraform 清单应用到您的环境。如需了解详情，请参阅使用 Terraform、Cloud Build 和 GitOps 以代码形式管理基础架构。

最佳做法

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

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

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

  • 使用第三种计算环境。在此环境中，系统可以在修改数据之前检查仲裁。

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

    对于 SQL 数据库，您可以在客户端开始使用新的主实例之前，使原始主实例无法访问，从而避免脑裂问题。如需了解详情，请参阅 Cloud SQL 数据库灾难恢复。

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

• 在使用备用系统时，请确保所有工作负载都具有可移植性。所有工作负载都应具有可移植性（如果应用支持且可行），以便系统在不同环境之间保持一致。您可以考虑使用容器和 Kubernetes 来实现此方法。通过使用 Google Kubernetes Engine (GKE) Enterprise 版，您可以简化构建和运营。

• 将备用系统的部署集成到 CI/CD 流水线中。 此集成有助于确保应用版本和配置在不同环境之间保持一致。

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

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

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

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

  • 通过多提供商 DNS 配置，简化在本地和云环境中具有依赖项的混合应用的部署或迁移。

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

• 使用备用系统时，请使用负载平衡器创建自动故障切换。请注意，负载均衡器硬件可能会发生故障。

• 使用 Cloud Load Balancing 而不是硬件负载平衡器来应对使用此架构模式时出现的一些情况。内部客户端请求或外部客户端请求可以根据不同的指标（例如基于权重的流量拆分）重定向到主环境或 DR 环境。如需了解详情，请参阅全球外部应用负载平衡器的流量管理概览。

• 如果从 Google Cloud 到其他环境的出站数据传输量较高，请考虑使用 Cloud Interconnect 或跨云互连。Cloud Interconnect 有助于优化连接性能，并可能降低满足特定条件的流量的出站数据传输费用。如需了解详情，请参阅 Cloud Interconnect 价格。

• 不妨考虑使用 Google Cloud Marketplace 上您首选的合作伙伴解决方案，以帮助您轻松完成数据备份、复制和其他符合您要求的任务，包括实现 RPO 和 RTO 目标。

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

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

云爆发模式

互联网应用可能会遇到极大的使用波动。虽然大多数企业应用不会面临这一挑战，但许多企业必须处理另一种爆发性工作负载：批量作业或 CI/CD 作业。

此架构模式依赖于跨多个计算环境的应用的冗余部署。其目标是提高容量和/或弹性。

虽然您可以通过超量预配资源，在基于数据中心的计算环境中支撑爆发性工作负载，但这种方法性价比不高。对于批量作业，您可以通过延长其执行时间段来优化使用，但如果这些作业对时间要求较高，则延迟作业并不切实可行。

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

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

这种模式的主要驱动因素是节省资金，以及减少响应规模要求变化所需的时间和工作。使用此方法，您只需为处理额外负载时使用的资源付费。这意味着您无需超量预配基础设施。您可以利用按需云资源，并根据需求和任何预定义的指标扩缩云资源。因此，您的公司可以避免在高需求时期发生服务中断。

云爆发方案的一个潜在要求是工作负载可移植性。如果您允许将工作负载部署到多个环境，则必须将环境之间的差异抽象化。例如，借助 Kubernetes，您可以在使用不同基础设施的各种环境中实现工作负载级别的一致性。如需了解详情，请参阅 GKE Enterprise 混合环境参考架构。

设计考虑事项

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

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

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

• 您可以将 Cloud Load Balancing 与混合连接网络端点组 (NEG) 后端搭配使用，而不是实现跟踪资源的机制。您可以使用此负载均衡器将内部客户端请求或外部客户端请求路由到位于本地和Google Cloud 中，且基于不同指标（例如基于权重的流量拆分）的后端。此外，您还可以根据 Google Cloud中工作负载的负载均衡响应容量来扩缩后端。如需了解详情，请参阅全球外部应用负载平衡器的流量管理概览。

  此方法具有多项其他优势，例如利用 Google Cloud ArmorDDoS 防护功能、WAF 和使用 Cloud CDN 在云边缘缓存内容。不过，您需要调整混合网络连接的大小以处理额外流量。

• 正如工作负载可移植性中所强调的，应用可以通过最少的更改移植到不同的环境，以实现工作负载一致性，但这并不意味着应用在两种环境中都能同样良好地运行。底层计算、基础设施安全功能或网络基础设施的差异以及与依赖服务的邻近性通常决定了性能。通过测试，您可以获得更准确的情况，并了解预期性能。

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

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

• 如果您打算在低需求时期关停所有 Google Cloud 资源，则主要使用 DNS 路由政策进行流量负载均衡可能并不总是最优做法。这主要是因为：

  • 资源可能需要一些时间进行初始化，然后才能响应用户。
  • DNS 更新在互联网上的传播往往比较慢。

  因此：

  • 即使没有资源可用于处理用户的请求，用户也可能会被路由到 Cloud 环境。
  • 当 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 端点。此策略有许多地理定位 DNS 路由政策的应用场景，包括将 Google Cloud 与存在 Google Cloud 区域的本地部署搭配使用的混合应用。

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

    如需了解详情，请参阅混合 DNS 的参考架构。

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

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

• 在适用的情况下使用容器实现工作负载可移植性。此外，GKE Enterprise 可以成为实现该设计的关键技术。如需了解详情，请参阅 GKE Enterprise 混合环境参考架构。

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

• 如果您计划长期使用此架构，并且出站数据传输量较大，请考虑使用 Cloud Interconnect。Cloud Interconnect 有助于优化连接性能，并可能降低满足特定条件的流量的出站数据传输费用。如需了解详情，请参阅 Cloud Interconnect 价格。

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

• 通过在环境之间建立通用身份，对使用您的系统的用户进行身份验证，以便系统能够跨环境边界安全地进行身份验证。

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

混合云和多云架构模式：后续步骤

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