本文档是三篇文档中的第二篇。文中讨论了常见的混合云和多云架构模式。并描述了这些模式最适合的场景。最后，它还提供了在 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中，您可以通过在单个区域的多个可用区1或多个区域部署该应用的冗余组件来提高应用的弹性，并实现切换功能。冗余是提高应用整体可用性的关键因素之一。对于在混合云和多云环境中采用分布式设置的应用，请务必保持一致的可用性水平。
如需提高本地环境或其他云环境中系统的可用性，请考虑您的应用及其组件需要哪些硬件或软件冗余（以及故障切换机制）。理想情况下，您应考虑服务或应用在所有环境中的各种组件和支持基础架构（包括混合连接可用性）中的可用性。此概念也称为应用或服务的复合可用性。
根据组件或服务之间的依赖项，应用的复合可用性可能会高于或低于单个服务或组件的可用性。如需了解详情，请参阅复合可用性：计算云基础架构的总体可用性。
为了实现所需的系统可靠性级别，请定义明确的可靠性指标，并设计能够在不同环境中有效自我修复和承受中断的应用。如需帮助您确定衡量服务客户体验的适当方法，请参阅根据用户体验目标定义可靠性。
混合云和多云连接
分布式应用组件之间的通信要求应影响您选择混合网络连接选项。每种连接选项都有其优点和缺点，并且需要考虑特定的驱动因素，例如成本、流量、安全性等。如需了解详情，请参阅连接性设计注意事项部分。
易管理性
一致且统一的管理和监控工具对于成功实现混合云和多云设置（无论是否具有工作负载可移植性）至关重要。短期内，这些工具可能会增加开发、测试和运营费用。从技术层面来说，您使用的云服务提供商越多，管理环境就越复杂。大多数公有云服务提供商不仅有不同的功能，而且还使用不同的工具、服务等级协议 (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) 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 与后端服务（例如微服务）分离。
- 保护应用免受后端代码更改的影响。
- 支持现有的 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 与混合连接搭配使用。也就是说，您可以将云负载均衡的优势扩展到在本地计算环境中托管的服务。这种方法支持分阶段将工作负载迁移到 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 数据库选项说明
分区多云模式
分区多云架构模式结合了由不同云服务提供商运营的多个公有云环境。这种架构可让您灵活地在最佳计算环境中部署应用，该环境考虑到了本系列第一部分中讨论的多云驱动因素和注意事项。
下图展示了分区多云架构模式。
此架构模式可以通过两种不同的方式构建。第一种方法基于在不同的公有云环境中部署应用组件。此方法也称为复合架构，与分层混合架构模式是同样的方法。 但是，它使用至少两个云环境，而不是使用本地环境和一个公有云。在复合架构中，单个工作负载或应用使用多个云中的组件。第二种方法是在不同的公有云环境中部署不同的应用。以下列表介绍了第二种方法的一些业务驱动因素，但并非详尽无遗：
- 在两家企业合并和收购的场景中，全面集成托管在不同云环境中的应用。
- 提升灵活性并满足组织内的各种云偏好。采用这种方法可鼓励组织部门选择最符合其特定需求和偏好的云服务提供商。
- 在多区域或全球云部署中运营。如果企业需要遵守特定地区或国家的数据驻留法规，但其主要云服务提供商在该地区或国家没有云区域，那么企业就需要从该位置的可用云服务提供商中进行选择。
采用分区多云架构模式时，您可以选择保留根据需要将工作负载从一个公有云环境迁移到另一个公有云环境的能力。在这种情况下，工作负载的可移植性就成为关键要求。如果您将工作负载部署到多个计算环境，并希望保留在环境之间移动工作负载的功能，则必须将环境之间的差异抽象化。借助 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 功能，它可提供灵活性、敏捷性并推动转型。
分区多云架构模式有助于在主要云服务提供商尚未推出云区域或入网点的位置降低延迟时间并提升用户体验的整体质量。当使用高容量和低延迟的多云连接（例如 Cross-Cloud Interconnect 和使用分布式 CDN 的 CDN 互连）时，此模式尤为有用。
您可以跨多个云服务提供商部署应用，以便可在其他云服务提供商提供的最佳服务中进行选择。
分区多云架构模式可促进和加速合并和收购场景，在此场景中，两个企业的应用和服务可能托管在不同的公有云环境中。
最佳做法
- 首先部署非任务关键型工作负载。然后，这种在次要云中的初始部署可用作未来部署或迁移的模式。但是，如果法律或法规要求特定工作负载位于特定云区域，而主要云服务提供商在所要求的地区未推出云区域，则此方法可能不适用。
- 最大限度减少在不同公有云环境中运行的系统之间的依赖项，尤其是在同步处理通信时。这些依赖项会降低性能和整体可用性，并可能产生额外的出站数据传输费用。
- 如需将环境之间的差异抽象化，请考虑在应用支持且可行的情况下使用容器和 Kubernetes。
- 确保 CI/CD 流水线和用于部署和监控的工具在云环境之间保持一致。
- 选择可为您使用的应用提供最高效和最有效的通信解决方案的最优网络架构模式。
- 为了满足您的可用性和性能预期，请针对端到端高可用性 (HA)、低延迟和适当的吞吐量级别进行设计。
为了保护敏感信息，我们建议对所有传输中的通信进行加密。
- 如果需要在连接层进行加密，根据所选的混合连接解决方案，有多种选项可供选择。这些选项包括 VPN 隧道、通过 Cloud Interconnect 实现的高可用性 VPN 和 MACsec for Cross-Cloud Interconnect。
如果您在多云分区架构模式中使用多个 CDN，并且使用来自 Google Cloud的大数据文件填充其他 CDN，不妨考虑使用 Google Cloud 与受支持的提供商之间的 CDN Interconnect 链路来优化此流量，并可能降低其费用。
在环境之间扩展身份管理解决方案，以便系统可以跨环境边界安全地进行身份验证。
如需有效平衡 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的 Sensitive Data Protection 功能，例如去标识化技术。借助这些技术，您可以使用随机生成或预先确定的密钥（如果适用且符合相关法规）遮盖、加密和替换敏感数据（例如个人身份信息 [PII]）。
- 如果您当前具有 Hadoop 或 Spark 工作负载，请考虑将作业迁移到 Dataproc，并将现有 HDFS 数据迁移到 Cloud Storage。
执行从私有计算环境到 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构建而成。在 Google Cloud中，您可以使用 Cloud SQL 等托管式数据库作为开发和测试选项。开发和测试可以使用与本地环境相同的数据库引擎和版本，也可以使用功能等效的版本，或者在测试阶段之后部署到生产环境的新版本。不过，由于这两个环境的底层基础架构不尽相同，因此这种性能负载测试方法无效。
以下场景非常适合环境混合模式：
- 在适用且可行的情况下，依赖 Kubernetes 作为通用运行时层，实现所有环境中的功能等效。Google Kubernetes Engine (GKE) Enterprise 版可以成为实现此方法的关键技术。
- 确保工作负载的可移植性，并忽略计算环境之间的差异。借助零信任服务网格，您可以控制和维护不同环境之间所需的通信隔离。
- 在公有云中运行开发和功能测试环境。这些环境在功能上等效于其他环境，但在性能等非功能性方面可能有所不同。此概念如上图所示。
- 在私有计算环境中运行用于生产、预演环境以及性能（负载测试）和可靠性测试的环境，确保功能和非功能等效性。
设计考虑事项
- 业务需求：每种应用部署和发布策略都有其优点和缺点。为确保您选择的方法符合您的具体要求，请根据对业务需求和限制的全面评估做出选择。
- 环境差异：在此模式中，使用此云环境的主要目标是进行开发和测试。最终状态是在专用本地环境（生产环境）中托管经过测试的应用。为避免开发和测试的功能在云环境中可能按预期运行，但在生产环境（本地）中失败，技术团队必须了解和理解这两种环境的架构和功能。这包括对其他应用和硬件基础架构的依赖项，例如执行流量检查的安全系统。
- 治理：若要控制贵公司可以在云端开发哪些内容以及可以使用哪些数据进行测试，请使用审批和治理流程。此流程还可以帮助贵公司确保其在开发和测试环境中不会使用本地生产环境中不存在的任何云端功能。
- 成功标准：必须制定明确、预定义且可衡量的测试成功标准，且这些标准应与贵组织的软件质量保证标准保持一致。请将这些标准应用于您开发和测试的任何应用。
- 冗余：虽然开发和测试环境可能不需要像生产环境那样高可靠性，但它们仍然需要冗余功能以及测试不同故障场景的能力。您的失败场景要求可能会促使设计在开发和测试环境中包含冗余性。
优点
在公有云中运行开发和功能测试工作负载具有多项优势：
- 您可以根据需要自动启动和停止环境。例如，您可以为每个提交或拉取请求预配整个环境，允许运行测试，然后再次关闭环境。此方法还具有以下优势：
- 您可以通过在虚拟机实例处于非活动状态时将其停止，或者仅按需预配环境来降低费用。
- 您可以为每个拉取请求启动短时性环境，从而加快开发和测试速度。这样做还可以减少维护开销，并减少构建环境中的不一致性。
- 在公有云中运行这些环境有助于增加对云及相关工具的了解和信心，这可能有助于迁移其他工作负载。如果您决定使用容器和 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 方案时，需要全面分析多项考虑因素，包括：
- 易管理性
- 安全
- 整体可行性。
- 费用
- 如果持续进行云间通信，多个云提供商可能会产生出站数据传输费用，这可能会造成高昂费用。
- 复制数据库时，流量可能会很大。
- 总体拥有成本 (TCO) 和管理跨云网络基础架构的费用。
如果您的数据需要留在您所在的国家/地区以满足监管要求，您可以选择使用位于您所在国家/地区的第二家云服务提供商作为灾难恢复选项。使用第二个云服务商时，假定无法使用本地环境构建混合设置。为避免重新架构云解决方案，理想情况下，第二个云服务提供商应提供您在该区域内所需的所有功能和服务。
设计考虑事项
- 灾难恢复预期：企业希望实现的 RPO 和 RTO 目标应指导您的灾难恢复架构和构建规划。
- 解决方案架构：采用此模式时，您需要复制本地环境的现有功能和特性，以满足您的 DR 预期。因此，您需要评估重新托管、重构或重构应用的可行性和可行性，以便在云环境中提供相同（或更优化）的功能和性能。
- 设计和构建：在云环境中部署企业工作负载几乎总是需要先构建着陆区。如需了解详情，请参阅 Google Cloud中的着陆区设计。
DR 调用：在 DR 设计和流程中，请务必考虑以下问题：
- 什么会触发灾难恢复场景？例如，主要站点中的特定功能或系统发生故障可能会触发灾难恢复。
- 如何调用对 DR 环境的故障切换？是手动审批流程，还是可以自动化以实现较低的 RTO 目标？
- 系统故障检测和通知机制应如何设计，才能根据预期的 RTO 调用故障切换？
- 在检测到故障后，流量如何重定向到 DR 环境？
通过测试来验证您对这些问题的回答。
测试：全面测试和评估向 DR 故障切换。确保其符合您的 RPO 和 RTO 预期。这样，您就可以在需要时更放心地调用 DR。每当对流程或技术解决方案进行新的更改或更新时，请重新进行测试。
团队技能：一个或多个技术团队必须具备在云环境中构建、运营和排查生产工作负载的技能和专业知识，除非您的环境由第三方管理。
优点
使用 Google Cloud 实现业务连续性具有多种优势：
- 由于 Google Cloud 在全球多个区域设有数据中心，因此您可以使用它将数据备份或复制到同一大洲内的其他位置。您还可以将数据备份或复制到其他大洲的位置。
- Google Cloud 支持将数据存储在 Cloud Storage 的双区域或多区域存储桶中。数据以冗余方式存储在至少两个不同的地理区域。存储在双区域和多区域存储分区中的数据会使用默认复制跨地理区域进行复制。
- 提供以下一个或多个选项，以降低构建灾难恢复方案的资本支出和运营支出：
- 已停止的虚拟机实例仅产生存储费用，并且比正在运行的虚拟机实例便宜很多。也就是说，您可以最大限度地降低维护冷备用系统的费用。
- Google Cloud 的按用量计费模式意味着，您只需为实际使用的存储和计算容量付费。
- 借助弹性功能（例如自动扩缩），您可以根据需要自动扩缩或缩减 DR 环境。
例如，下图显示了一个在本地环境（生产环境）中运行的应用，该应用使用Google Cloud 上的恢复组件，并搭配使用 Compute Engine、Cloud SQL 和 Cloud Load Balancing。在这种情况下，数据库是使用基于虚拟机的数据库或使用 Google Cloud 托管的数据库（例如 Cloud SQL）预配的，以便通过持续数据复制实现更快速的恢复。您可以从预先创建的快照启动 Compute Engine 虚拟机，以便在正常运行期间降低费用。采用这种设置后，在发生失败事件后，DNS 需要指向 Cloud Load Balancing 外部 IP 地址。
如需在云端运行应用，您需要预配 Web 和应用虚拟机。根据目标 RTO 级别和公司政策，调用 DR、在云端预配工作负载以及重定向流量的整个过程可以手动或自动完成。
如需加快基础架构的预配速度并实现自动化预配，不妨考虑以代码形式管理基础架构。您可以使用 Cloud Build（一种持续集成服务）自动将 Terraform 清单应用到您的环境。如需了解详情，请参阅使用 Terraform、Cloud Build 和 GitOps 以代码形式管理基础架构。
最佳做法
使用业务连续性模式时，请考虑以下最佳实践：
- 创建记录基础架构以及故障切换和恢复过程的灾难恢复计划。
- 根据业务影响分析和确定的必要 RPO 和 RTO 目标，考虑采取以下措施：
- 如果您仅备份数据，不妨考虑使用切换模式。否则，网状模式可能是复制现有环境网络架构的理想之选。
- 最大限度减少在不同环境中运行的系统之间的依赖项，尤其是在同步处理通信时。这些依赖项会降低性能并降低整体可用性。
避免出现脑裂问题。如果跨环境双向复制数据，您可能会遇到脑裂问题。当两个双向复制数据的环境彼此失去通信时，就会出现脑裂问题。这种分屏可能会导致这两个环境中的系统都断定另一个环境不可用，并且自己拥有对数据的独占访问权。这可能会导致对数据进行冲突的修改。有两种常见方法可以避免分脑问题：
- 使用第三个计算环境。在这种环境中，系统可以在修改数据之前检查是否达到了仲裁要求。
允许在恢复连接后对有冲突的数据修改进行协调。
对于 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 目标）。
测试和评估灾难恢复调用场景，了解应用从灾难事件中恢复的容易程度（与目标 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 应用。