本文是介绍 Google Cloud 中的灾难恢复 (DR) 的系列文章中的第六篇，介绍了使用 Google Cloud 设计工作负载架构的过程，以及能够应对云基础架构服务中断的基础组件。
该系列包含以下部分：
- 灾难恢复规划指南
- 灾难恢复基础组件
- 数据的灾难恢复场景
- 应用的灾难恢复场景
- 为受限于位置的工作负载设计灾难恢复架构
- 针对云基础架构服务中断设计灾难恢复架构（本文档）
简介
随着企业将工作负载迁移到公有云，他们需要将对构建弹性本地系统的理解转换为 Google Cloud 等云服务商的超大规模基础架构。本文将有关灾难恢复的行业标准概念（例如，恢复时间目标 (RTO) 和恢复点目标 (RPO)）映射到 Google Cloud 基础架构。
本文档中的指导遵循了 Google 的一项关键原则，从而实现极高的服务可用性：针对故障进行规划。虽然 Google Cloud 可提供高度可靠的服务，但灾难会引起自然灾害、光纤断裂和复杂的不可预测的基础架构故障，这些灾难都会导致服务中断。通过规划服务中断，Google Cloud 客户可以利用“内置”灾难恢复机制的 Google Cloud 产品，构建能够以可预测的方式处理这些不可避免的事件的应用。
灾难恢复是一个宽泛的主题，不只是涵盖基础架构故障（例如软件 bug 或数据损坏），您应制定全面的端到端方案。但是，本文重点介绍了整个灾难恢复方案的一部分：如何设计能够应对云基础架构服务中断的应用。具体来说，本文将分步演示：
- Google Cloud 基础架构、灾难事件如何表现为 Google Cloud 服务中断，以及如何设计 Google Cloud 架构以最大限度地减少服务中断的频率和范围。
- 架构规划指南，该指南提供了一个框架，以便您根据所需的可靠性结果对应用进行分类和设计。
- 具有您可能希望在应用中使用的内置灾难恢复功能的精选 Google Cloud 产品的详细列表。
如需详细了解通用灾难恢复规划以及如何将 Google Cloud 用作本地灾难恢复策略中的一个组件，请参阅灾难恢复规划指南。此外，虽然高可用性是与灾难恢复密切相关的概念，但本文未对其进行介绍。如需详细了解如何设计架构以实现高可用性，请参阅 Google Cloud 架构框架。
关于术语的说明：本文引用了可用性来讨论在一段时间内是否能够有效访问和使用某个产品，而可靠性指的是一组特性，包括可用性以及耐用性和正确性等特性。
如何设计 Google Cloud 以实现恢复能力
Google 数据中心
传统数据中心依赖于尽可能提高各个组件的可用性。在云端，扩缩功能可让 Google 等运营商使用虚拟化技术将服务分布到多个组件，从而超越传统组件的可靠性。这意味着，您可以改变可靠性架构思维模式，而不再考虑之前所担心的有关本地环境的诸多细节。您可以针对 Google Cloud 产品及其指明的可靠性指标进行规划，而不必考虑组件的各种故障模式（例如，制冷和电源输送）。这些指标反映了整个底层基础架构的总体服务中断风险。这使您可以更专注于应用设计、部署和操作，而不是基础架构管理。
Google 凭借我们构建和运行现代数据中心的丰富经验设计其基础架构，从而满足严格的可用性目标。Google 是数据中心设计领域的全球领导者。从电源到制冷再到网络，每个数据中心技术都有其自己的冗余和缓解措施，包括 FMEA 方案。Google 的数据中心所采用的构建方式可以平衡多种不同风险，并且可为客户提供一致的 Google Cloud 产品预期可用性水平。Google 可凭借其经验模拟整体物理和逻辑系统架构的可用性，从而确保数据中心设计符合预期。Google 的工程师们在运营上会竭尽全力，以帮助确保符合这些预期。实际衡量的可用性通常远远超出我们的设计目标。
通过将所有数据中心风险和缓解措施提炼成面向用户的产品，Google Cloud 可让您减轻设计和运营方面的负担。相反，您可以专注于从设计层面在 Google Cloud 地区和区域实现可靠性。
区域和地区
很多地区和区域都提供了 Google Cloud 产品。地区是物理上独立的地理位置，包含三个或三个以上的区域。地区表示物理物理组中的资源组，它们在物理和逻辑基础架构方面具有高度独立的独立性。同一地区中的区域之间有着高带宽、低延迟网络连接。例如，日本的 asia-northeast1 地区包含三个区域：asia-northeast1-a、asia-northeast1-b 和 asia-northeast1-c。
Google Cloud 产品分为区域性资源、地区性资源或多地区性资源。
区域性资源托管在单个区域中。该区域发生服务中断可能会影响其中的所有资源。例如，某个 Compute Engine 实例在单个指定区域中运行；如果硬件故障导致该区域的服务中断，则该 Compute Engine 实例在中断期间不可用。
地区性资源以冗余方式部署在一个地区内的多个区域中。因此，与区域性资源相比，地区性资源具有较高的可靠性。
多地区性资源分布在相同地区内和不同地区之间。通常情况下，多地区性资源比地区性资源具有更高的可靠性。但是，在此层级上，产品必须优化可用性、性能和资源效率。因此，了解您决定使用的每个多地区性产品所做的权衡非常重要。本文档后面部分介绍了具体产品的相应权衡。
如何利用区域和地区实现可靠性
Google SRE 可通过各种方法和技术在全球各地顺畅利用计算基础架构，从而管理和扩缩 Gmail 和 Google 搜索等高可靠性的全球用户产品。这包括使用全球负载平衡将流量从不可用位置重定向到其他位置、在全球多个位置运行多个副本，以及在各个不同位置复制数据。Cloud Load Balancing、Google Kubernetes Engine 和 Cloud Spanner 等产品也可为 Google Cloud 客户提供上述同样的功能。
Google Cloud 通常设计的产品可为区域和地区提供以下可用性级别：
| 资源 | 示例 | 可用性设计目标 | 隐含的停机时间 |
|---|---|---|---|
| 区域性 | Compute Engine、Persistent Disk | 99.9% | 8.75 小时/年 |
| 地区性 | 地区级 Cloud Storage、复制的 Persistent Disk、地区级 Google Kubernetes Engine | 99.99% | 52 分钟/年 |
将 Google Cloud 可用性设计目标与可接受的停机时间级别进行比较，可确定相应的 Google Cloud 资源。虽然传统设计侧重于通过提高组件级可用性来改进生成的应用可用性，但云模型专注于组合组件来实现此目标。Google Cloud 中的许多产品都使用此方法。例如，Cloud Spanner 提供一个组合多个地区的多地区数据库，从而实现 99.999% 的可用性。
组合非常重要，因为如果没有它，您的应用可用性无法超过您所用的 Google Cloud 产品的可用性；事实上，除非您的应用从不发生故障，否则它的可用性低于底层 Google Cloud 产品的可用性。本部分其余内容简要介绍了如何通过区域性和地区性产品的组合来实现高于单区域或单地区所提供的应用可用性。下一部分提供了将这些原则应用于您的应用的实用指南。
规划区域服务中断的范围
基础架构故障通常会在单个地区造成服务中断。一个区域内，地区旨在最大限度地降低与其他地区关联故障的风险，并且地区中的服务中断通常不会影响同一区域内其他地区的服务。范围限定至区域的服务中断不一定意味着整个区域都不可用，而只是定义了突发事件的边界。有可能出现某区域发生服务中断不会对该区域中的特定资源产生切实影响的情况。
这种情况比较少见，但另请务必注意，一个地区内的多个区域最终仍会在某个时间点发生相关服务中断。当两个或两个以上区域发生服务中断时，系统将应用下面的地区性服务中断范围策略。
地区性资源旨在通过从多个区域组合提供服务来防范区域服务中断。如果支持地区性资源的某一区域服务中断，则可自动从其他区域获得该资源。如需了解详情，请仔细查看附录中的产品功能说明。
Google Cloud 仅提供少量区域性资源，即 Compute Engine 虚拟机 (VM) 和 Persistent Disk。如果您计划使用区域性资源，则需要通过在位于多个区域中的区域性资源之间设计、构建和测试故障转移及恢复来自行执行资源组合。部分策略包括：
- 在运行状况检查确定某个区域遇到问题时，使用 Cloud Load Balancing 将流量快速路由到其他区域中的虚拟机。
- 使用 Compute Engine 实例模板和/或代管式实例组在多个区域中运行和扩缩相同的虚拟机实例。
- 使用地区级 Persistent Disk 将数据同步复制到一个地区中的其他区域。如需了解详情，请参阅使用地区级 Persistent Disk 的高可用性选项。
规划地区性服务中断的范围
地区性服务中断是指影响单个地区中的多个区域的服务中断。这种服务中断规模较大、发生频率较低，可能是由于自然灾害或大规模基础架构故障引起的。
对于旨在提供 99.99% 可用性的地区性产品，服务中断仍可转换为特定产品每年近一个小时的停机时间。因此，如果此服务中断时长不可接受，则您的关键应用可能需要实施多地区灾难恢复方案。
多地区性资源旨在通过从多个地区提供服务来防范地区服务中断。如上所述，多地区产品会在延迟时间、一致性和费用之间进行权衡。最常见的权衡是在同步数据复制和异步数据复制之间权衡。异步复制可实现更短的延迟，但代价是在服务中断期间会有数据丢失的风险。因此，请务必查看附录中的产品功能说明以了解详情。
如果您要使用地区性资源并且能够始终应对地区性服务中断，则您必须通过在位于多个地区的地区性资源之间设计、构建和测试故障转移及恢复来自行执行资源组合。除了上述区域性策略（也可以在不同地区中应用）之外，还请考虑以下策略：
- 地区性资源应将数据复制到次要地区、多地区存储选项（如 Cloud Storage）或混合云选项（如 Anthos）。
- 在制定地区性服务中断缓解措施后，请定期对其进行测试。很少情况会比您认为能够应对单地区服务中断更差，只是发现这种情况在现实生活中并非如此。
Google Cloud 实现恢复能力和可用性的方法
Google Cloud 会定期超越其可用性设计目标，但您不应认为，这一出色的过往表现就是您可以设计的最低可用性。相反，您应该选择其设计的目标超过应用预期可靠性的 Google Cloud 依赖项，这样应用停机时间加上 Google Cloud 停机时间便会实现您所寻求的结果。
一个精心设计的系统可以回答以下问题：“如果区域或地区出现 1 分钟、5 分钟、10 分钟或 30 分钟服务中断，会发生什么情况？”您应该在多个层面考虑这一问题，包括：
- 在服务中断期间，我的客户会遇到什么情况？
- 如何检测是否发生服务中断？
- 在服务中断期间，我的应用会发生什么？
- 在服务中断期间，我的数据会发生什么？
- 由于交叉依赖项导致服务中断，我的其他应用会发生什么？
- 在解决服务中断后，我需要做什么才能恢复？谁解决服务中断？
- 我需要在哪个时间段内通知发生服务中断？
为 Google Cloud 中的应用设计灾难恢复的分步指南
前面部分介绍了 Google 如何构建云端基础架构，以及用于处理区域性和地区性服务中断的一些方法。
本部分帮助您开发一个框架，以便您根据所需的可靠性结果将组合原则应用于您的应用。
第 1 步：收集现有要求
第一步是定义应用的可用性要求。大多数公司在这一领域已有一定程度的设计指导，这可能是在公司内部制定的，也可能源自法规或其他法律要求。该设计指导通常会纳入两个关键指标：恢复时间目标 (RTO) 和恢复点目标 (RPO)。在商业术语中，RTO 的意思是“灾难发生后多久应用才能启动和运行”。RPO 的意思是“发生灾难时我可以接受丢失多少数据”。
过去，企业已针对各种灾难事件（从组件故障到地震）定义了 RTO 和 RPO 要求。这在本地环境中很有用，因为在本地环境中规划人员必须通过整个软件和硬件堆栈映射 RTO/RPO 要求。在云端，您无需再定义包含此类详情的要求，因为提供商会负责这一点。相反，您可以根据损失范围（整个区域或地区）定义 RTO 和 RPO 要求，而无需考虑根本原因。对于 Google Cloud，这可简化您针对以下 3 种场景收集的要求：地区性服务中断、区域性服务中断或极不可能发生的多地区服务中断。
由于认识到并不是每个应用都具有相同的重要性，因此大多数客户都会按重要性层级对其应用分类，并且可以根据这些重要性层级应用特定 RTO/RPO 要求。将 RTO/RPO 和应用重要性相结合后，通过回答以下方面的问题可简化设计给定应用架构的过程：
- 应用需要在同一地区内的多个区域中运行，还是需要在多个地区内的多个区域中运行？
- 应用可以依赖哪些 Google Cloud 产品？
以下是一个要求收集练习的输出示例：
按示例组织 Co 的应用重要性定义的 RTO 和 RPO：
| 应用重要性 | 应用百分比 | 示例应用 | 区域服务中断 | 地区服务中断 |
|---|---|---|---|---|
| 层级 1
（最重要） |
5% | 通常是全球应用或外部面向客户的应用，例如实时付款和电子商务店面。 | RTO 为零 RPO 为零 |
RTO 为 4 小时 RPO 为 1 小时 |
| 层级 2 | 35% | 通常是地区性应用或重要的内部应用，例如 CRM 或 ERP。 | RTO 为 4 小时 RPO 为零 |
RTO 为 24 小时 RPO 为 4 小时 |
| 层级 3 （最不重要） |
60% | 通常是团队或部门应用，例如后台、请假、国内差旅、会计和 HR。 | RTO 为 12 小时 RPO 为 24 小时 |
RTO 为 28 天 RPO 为 24 小时 |
第 2 步：将功能映射到可用产品
第二步是了解您的应用将使用的 Google Cloud 产品的恢复能力。大多数公司都会查看相关产品信息，然后添加有关如何修改其架构的指导，以适应产品功能与恢复能力要求之间的差距。本部分介绍了针对此领域的数据和应用限制的一些常见方面和建议。
如前所述，Google 支持灾难恢复的产品广泛适用于两种类型的服务中断范围：地区性和区域性。部分服务中断的规划方式与对完全服务中断进行灾难恢复采用的方式相同。这会为默认情况下哪些产品适合于每种场景提供一个最初的高层矩阵。
Google Cloud 产品一般功能
（请参阅附录，了解特定产品功能）
| 所有 Google Cloud 产品 | 可跨区域自动复制的地区性 Google Cloud 产品 | 可跨地区自动复制的多地区性或全球 Google Cloud 产品 | |
|---|---|---|---|
| 区域内的组件发生故障 | 覆盖* | 覆盖 | 覆盖 |
| 区域服务中断 | 未覆盖 | 覆盖 | 覆盖 |
| 地区服务中断 | 未覆盖 | 未覆盖 | 覆盖 |
* 除产品文档中所述的具体情况外，所有 Google Cloud 产品均能够应对组件故障。这是典型的情况，产品能够直接访问或静态映射到一个特定硬件（如内存或固态磁盘 (SSD)）。
RPO 如何限制产品选择
在大多数云部署中，数据完整性是针对服务需要考虑的最重要的架构方面。至少某些应用的 RPO 要求为零，这意味着如果发生服务中断，数据不应丢失。这通常需要将数据同步复制到其他区域或地区。同步复制需要权衡费用和延迟，因此虽然许多 Google Cloud 产品可以在不同区域之间进行同步复制，但只有少数 Google Cloud 产品可以在不同地区之间进行同步复制。这种费用和复杂性权衡意味着应用内不同类型的数据具有不同的 RPO 值是常见情况。
对于 RPO 大于零的数据，应用可以利用异步复制。如果丢失的数据可以轻松重新创建，或者可以从黄金数据源恢复（如果需要），则可以执行异步复制。如果在预期的区域性和地区性服务中断期间少量数据丢失是可以接受的权衡，则异步复制也是一个合理的选择。此外，异步复制对以下情况下也很有用：在暂时性服务中断期间，已写入受影响位置但尚未复制到其他位置的数据在服务中断解决后通常变得可用。这意味着，永久性数据丢失的风险低于服务中断期间失去数据访问权限的风险。
关键操作：确定您是否确实需要 RPO 为零，如果需要，确定您是否可以针对部分数据进行此设置，这会大大增加您可以使用的支持灾难恢复的服务范围。在 Google Cloud 中，实现 RPO 为零意味着主要为应用使用区域性产品，默认情况下，这些产品能够应对零扩缩但不是地区范围扩缩的服务中断。
RTO 如何限制产品选择
云计算的一个主要优势是能够按需部署基础架构；但是，这与即时部署不同。应用的 RTO 值需要满足应用所用的 Google Cloud 产品的总 RTO，以及您的工程师或 SRE 重启虚拟机或应用组件所必须执行的任何操作。RTO（以分钟为单位）表示设计的应用可以自动从灾难恢复，而无需任何人工干预，或者只需执行最少步骤（例如，将按钮推送到故障转移）。这种系统的费用和复杂性过去一直都非常高，但 Google Cloud 产品（如负载平衡器和实例组）使此设计更加经济实惠和简单。因此，您应该考虑对大多数应用进行自动故障转移和恢复。请注意，为不同地区之间的此类热故障转移设计系统非常复杂且费用高；只有极少数的关键服务能保证这种能力。
大多数应用的 RTO 介于一小时与一天之间，这允许在灾难情况下进行暖故障转移，部分应用组件在备份模式（例如数据库）下始终保持运行，而其他应用组件在发生实际灾难（例如 Web 服务器）时进行扩容。对于这些应用，强烈建议您对扩容事件进行自动处理。RTO 超过一天的服务具有最低重要性，并且通常可以通过备份恢复或从头开始创建。
关键操作：确定您是否确实需要 RTO 为零（接近于零）以进行地区性故障转移，如果需要，确定您是否可以针对部分服务进行此设置。此操作会更改运行和维护服务的费用。
第 3 步：开发您自己的参考架构和指南
建议在最后一步构建您自己的公司专用架构模式，以帮助您的团队标准化灾难恢复方法。大多数 Google Cloud 客户都会为其开发团队提供指南，该指南会将开发团队各自业务恢复能力期望与 Google Cloud 中的两大类服务中断场景相匹配。这样一来，团队可以轻松划分哪些支持灾难恢复的产品适合各重要性级别。
制定产品准则
我们再看一下上面的示例 RTO/RPO 表，假设您有一个指南，其中列出了每个重要性层级默认允许的产品。请注意，虽然某些产品已默认识别为不适合，但您可以随时添加自己的复制和故障转移机制来启用跨区域或跨地区同步，但此练习不在本文的讨论范围内。该表还链接到有关每个产品的详细信息，以帮助您了解这些产品对管理区域或地区服务中断的能力。
示例组织 Co 的架构模式示例 - 区域服务中断恢复能力：
| Google Cloud 产品 | 产品是否符合示例组织的区域性服务中断要求（根据相应的产品配置） | ||
|---|---|---|---|
| 层级 1 | 层级 2 | 层级 3 | |
| Compute Engine | 是 | 是 | 是 |
| Dataflow | 否 | 否 | 否 |
| BigQuery | 否 | 否 | 是 |
| Google Kubernetes Engine | 是 | 是 | 是 |
| Cloud Storage | 是 | 是 | 是 |
| Cloud SQL | 否 | 是 | 是 |
| Cloud Spanner | 是 | 是 | 是 |
| Cloud Load Balancing | 是 | 是 | 是 |
此表是仅基于上述假设性层级的示例。
示例组织 Co 的架构模式示例 - 地区服务中断恢复能力：
| Google Cloud 产品 | 产品是否符合示例组织的地区性服务中断要求（根据相应的产品配置） | ||
|---|---|---|---|
| 层级 1 | 层级 2 | 层级 3 | |
| Compute Engine | 是 | 是 | 是 |
| Dataflow | 否 | 否 | 否 |
| BigQuery | 否 | 否 | 是 |
| Google Kubernetes Engine | 是 | 是 | 是 |
| Cloud Storage | 否 | 否 | 否 |
| Cloud SQL | 是 | 是 | 是 |
| Cloud Spanner | 是 | 是 | 是 |
| Cloud Load Balancing | 是 | 是 | 是 |
此表是仅基于上述假设性层级的示例。
为展示如何使用这些产品，以下部分逐步介绍了每个假设性应用重要性级别对应的一些参考架构。这些是有针对性的简要说明，介绍了关键的架构决策，并不代表完整的解决方案设计。
层级 3 架构示例
| 应用重要性 | 区域服务中断 | 地区服务中断 |
|---|---|---|
| 层级 3 （最不重要） |
RTO 为 12 小时 RPO 为 24 小时 |
RTO 为 28 天 RPO 为 24 小时 |
（灰显图标表示要启用恢复的基础架构）
此架构描述了传统的客户端/服务器应用：内部用户连接到在由永久性存储数据库支持的计算实例上运行的应用。
请务必注意，此架构所支持的 RTO 和 RPO 值比所需的高。但是，如果其他手动步骤可能费用很高或不可靠，您还应考虑将这些步骤消除。例如，从夜间备份恢复数据库可支持 24 小时的 RPO，但这通常需要可能无法空闲的有技能的人员（例如数据库管理员），尤其是多个服务同时受影响的情况下。借助 Google Cloud 的按需基础架构，您可以实现此功能而无需进行主要的费用权衡取舍，因此该架构对区域性服务中断使用 Cloud SQL 高可用性，而不是使用手动备份/恢复。
针对区域服务中断的关键架构决策 - RTO 为 12 小时，RPO 为 24 小时：
- 使用内部负载平衡器为用户提供可扩缩的接入点，从而支持自动故障转移至其他区域。尽管 RTO 为 12 小时，手动更改 IP 地址甚至是 DNS 更新所花费的时间都可能比预期要长。
- 地区级代管实例组配置有多个区域但资源最少。这样可以优化费用，但仍支持虚拟机在备份区域中快速扩容。
- 高可用性 Cloud SQL 配置允许自动故障转移到其他区域。重新创建和恢复数据库比重新创建和恢复 Compute Engine 虚拟机要困难得多。
针对地区服务中断的关键架构决策 - RTO 为 28 小时，RPO 为 24 小时：
- 仅在发生地区性服务中断时才会在地区 2 中构建负载平衡器。使用 Cloud DNS 提供已编排但手动地区性故障转移功能，因为地区 2 中的基础架构仅在发生地区服务中断时可用。
- 仅在发生地区服务中断时才会构建新的代管实例组。这可以优化费用，但如果大部分地区性服务中断时间较短，则不太可能调用新的代管实例组。请注意，为简单起见，上图未显示重新部署或复制必要的 Compute Engine 映像所需的关联工具。
- 系统会重新创建一个新的 Cloud SQL 实例，并通过备份恢复数据。同样，某地区发生长时间服务中断的风险极低，因此这是另一种费用优化权衡。
- 使用多地区级 Cloud Storage 存储这些备份。这可在 RTO 和 RPO 内提供自动区域和地区性恢复能力。
层级 2 架构示例
| 应用重要性 | 区域服务中断 | 地区服务中断 |
|---|---|---|
| 层级 2 | RTO 为 4 小时 RPO 为零 |
RTO 为 24 小时 RPO 为 4 小时 |
此架构描述了一个内部用户在其中连接到计算实例可视化层的数据仓库，以及一个填充后端数据仓库的数据提取和转换层。
此架构的某些单独的组件不直接支持其层级所要求的 RPO；但是，由于这些组件结合使用的方式，整体服务符合 RPO 要求。在本示例中，由于 Dataflow 是区域性产品，因此应遵循针对高可用性设计的建议，以防止在区域性服务中断期间丢失数据。不过，Cloud Storage 层是黄金数据源并支持 RPO 为零。这意味着，在区域 a 发生服务中断时，可通过区域 b 将任何丢失的数据重新提取至 BigQuery。
针对区域服务中断的关键架构决策 - RTO 为 4 小时，RPO 为零：
- 使用负载平衡器为用户提供可扩缩的接入点，从而支持自动故障转移至其他区域。尽管 RTO 为 4 小时，手动更改 IP 地址甚至是 DNS 更新所花费的时间都可能比预期要长。
- 数据可视化计算层的地区级代管实例组配置有多个区域但资源最少。这样可以优化费用，但仍支持虚拟机快速扩容。
- 地区级 Cloud Storage 用作最初数据提取的暂存层，从而提供自动区域恢复能力。
- 使用 Dataflow 从 Cloud Storage 中提取数据并转换数据，然后将其加载至 BigQuery。在某个区域发生服务中断时，这是一个无状态过程，可在其他区域中重启。
- BigQuery 为数据可视化前端提供数据仓库后端。发生区域服务中断时，任何丢失的数据都将从 Cloud Storage 中重新提取。
针对地区服务中断的关键架构决策 - RTO 为 24 小时，RPO 为 4 小时：
- 使用每个地区中的负载平衡器为用户提供可扩缩的接入点。使用 Cloud DNS 提供已编排但手动地区性故障转移功能，因为地区 2 中的基础架构仅在发生地区服务中断时可用。
- 数据可视化计算层的地区级代管实例组配置有多个区域但资源最少。在负载平衡器重新配置之前，该实例组无法访问，但不需要手动干预。
- 地区级 Cloud Storage 用作最初数据提取的暂存层。这会同时加载到两个地区，以满足 RPO 要求。
- 使用 Dataflow 从 Cloud Storage 中提取数据并转换数据，然后将其加载至 BigQuery。发生地区服务中断时，将使用 Cloud Storage 中的最新数据填充 BigQuery。
- BigQuery 提供数据仓库后端。在正常操作下，数据仓库后端会间歇性进行刷新。发生地区服务中断时，最新数据将通过 Dataflow 从 Cloud Storage 中重新提取。
层级 1 架构示例
| 应用重要性 | 区域服务中断 | 地区服务中断 |
|---|---|---|
| 层级 1 （最重要） |
RTO 为零 RPO 为零 |
RTO 为 4 小时 RPO 为 1 小时 |
此架构描述了一个外部用户在其中连接到 Google Kubernetes Engine 中运行的一组微服务的移动应用后端基础架构。Cloud Spanner 为实时数据提供后端数据存储层，历史数据会流式传输到每个地区中的 BigQuery 数据湖。
同样，此架构的某些单独的组件不直接支持其层级所要求的 RPO；但是，由于这些组件结合使用的方式，整体服务符合 RPO 要求。在本示例中，BigQuery 用于分析查询。系统会同时从 Cloud Spanner 中为每个地区输送数据。
针对区域服务中断的关键架构决策 - RTO 为零，RPO 为零：
- 使用负载平衡器为用户提供可扩缩的接入点，从而支持自动故障转移至其他区域。
- 地区级 Google Kubernetes Engine 集群用于配置有多个区域的应用层。这样可在每个地区内实现 RTO 为零。
- 多地区级 Cloud Spanner 用作数据持久层，从而提供自动区域级数据恢复能力和事务一致性。
- BigQuery 为应用提供分析功能。系统会单独从 Cloud Spanner 为每个地区输送数据，并且应用会单独访问每个地区。
针对地区服务中断的关键架构决策 - RTO 为 4 小时，RPO 为 1 小时：
- 使用负载平衡器为用户提供可扩缩的接入点，从而支持自动故障转移至其他地区。
- 地区级 Google Kubernetes Engine 集群用于配置有多个区域的应用层。在发生地区服务中断时，备用地区中的集群会自动扩缩以应对额外的处理负载。
- 多地区级 Cloud Spanner 用作数据持久层，从而提供自动地区级数据恢复能力和事务一致性。这是实现跨地区 RPO 为 1 小时的关键组件。
- BigQuery 为应用提供分析功能。系统会单独从 Cloud Spanner 为每个地区输送数据，并且应用会单独访问每个地区。此架构可弥补 BigQuery 组件的不足，使其满足整体应用要求。
附录：产品参考
本部分介绍了客户应用中最常使用并且可轻松利用来满足灾难恢复需求的 Google Cloud 产品的架构和灾难恢复功能。
共同主题
许多 Google Cloud 产品提供单地区或多地区配置。区域性产品能够应对区域服务中断，多地区产品和全球产品能够应对地区服务中断。一般来说，这意味着在服务中断期间，应用遇到中断情况最少。Google 可通过一些常见架构方法实现这些结果，这反映了上述架构指导。
- 冗余部署：应用后端和数据存储部署在一个地区内的多个区域中，以及一个多地区位置内的多个地区中。
数据复制：产品在冗余位置之间使用同步或异步复制。
同步复制表示当您的应用进行 API 调用来创建或修改由产品存储的数据时，只有在产品将数据写入多个位置后，您的应用才会收到成功响应。同步复制可确保您在 Google Cloud 基础架构服务中断期间不会失去对任何数据的访问权限，因为您可以在一个可用的后端位置获取所有数据。
虽然此方法可最大程度保护数据，但它可能会在延迟和性能方面进行权衡。使用同步复制的多地区产品在这方面的权衡最为显著，通常大约出现 10 秒或 100 秒的额外延迟。
异步复制表示当您的应用进行 API 调用来创建或修改由产品存储的数据时，在产品将数据写入一个位置后，您的应用就会收到成功响应。写入请求之后，产品会将数据复制到其他位置。
此方法在 API 可提供比同步复制更低的延迟和更高的吞吐量，但要以牺牲数据保护为代价。如果写入数据的位置在复制完成之前发生了服务中断，则在该位置服务中断得到解决之前，您会失去对该数据的访问权限。
通过负载平衡处理服务中断：Google Cloud 使用软件负载平衡将请求路由到适当的应用后端。与 DNS 负载平衡等其他方法相比，此方法可缩短服务中断的系统响应时间。当 Google Cloud 位置发生服务中断时，负载平衡器会快速检测到该位置部署的后端已变为“运行状况不佳”，并将所有请求定向到备用位置中的后端。这样，产品就可以在某位置发生服务中断期间继续处理您的应用的请求。该位置的服务中断解决后，负载平衡器会检测该位置的产品后端的可用性，并继续在该位置发送流量。
Compute Engine
Compute Engine 是 Google Cloud 的基础架构即服务。Compute Engine 使用 Google 的全球性基础架构为客户提供虚拟机（及相关服务）。
Compute Engine 实例是区域性资源，因此在发生区域服务中断时，实例默认不可用。Compute Engine 提供了代管实例组 (MIG)，它可以在一个地区内单个区域中和多个区域之间，通过预配置的实例模板自动扩容额外的虚拟机。MIG 非常适合那些需要对区域损失具有恢复能力且无状态的应用，但需要进行配置和资源规划。多个地区级 MIG 可用于为无状态应用实现地区服务中断恢复能力。
具有有状态工作负载的应用仍可以使用有状态 MIG（Beta 版），但在进行容量规划时需要特别注意，因为有状态 MIG 不会横向扩容。无论是哪种情况，都请务必提前正确配置和测试 Compute Engine 实例模板及 MIG，以确保故障转移到其他区域的功能正常。如需了解详情，请参阅上面的架构模式部分。
Dataproc
Dataproc 具有流式和批量数据处理功能。Dataproc 的架构设计为一个地区级控制层面，让用户可以管理 Dataproc 集群。控制层面不依赖于给定地区中的个别区域。因此，在发生区域性服务中断期间，您可以保留对 Dataproc API 的访问权限，包括创建新集群的权限。
集群在 Compute Engine 中运行。由于集群属于区域性资源，因此区域性服务中断会导致集群不可用，或者会销毁集群。Dataproc 不会自动截取集群状态快照，因此区域服务中断可能会导致正在处理的数据丢失。Dataproc 不会保留服务中的用户数据。用户可以配置其流水线，以将结果写入多个数据存储区；您应该考虑数据存储区的架构，并选择具有所需灾难恢复能力的产品。
如果某个区域发生服务中断，您可以选择在另一个区域中重新创建集群的新实例，方法是选择其他区域，或者使用 Dataproc 中的“自动选择区域”功能自动选择可用区域。集群可用后，数据处理就可以继续进行。您还可以运行启用了高可用性模式的集群，从而降低部分区域服务中断影响主节点，因此影响整个集群的可能性。
Dataflow
Dataflow 是 Google Cloud 的全代管式无服务器数据处理服务，可用于流处理和批处理流水线。Dataflow 作业在本质上属于区域级；在默认配置中，Dataflow 作业不会在区域性服务中断期间保留中间计算结果。此类默认 Dataflow 流水线的典型恢复方法是在其他区域或地区中重启作业，然后重新处理输入数据。
设计 Dataflow 流水线架构以实现高可用性
如果区域或地区发生服务中断，您可以将通过对 Pub/Sub 主题重复使用同一订阅来避免数据丢失。作为 Dataflow“正好一次”保证的一部分，Dataflow 只有在以下情况下才会确认 Pub/Sub 中的消息：这些消息持久保留在目标位置，或者已对消息执行分组/时间数据选取操作并将其保存在 Dataflow 的持久性流水线状态中。如果未执行分组/时间数据选取操作，则通过重复使用订阅故障转移到其他区域或地区中的其他 Dataflow 作业会导致流水线输出数据发生数据丢失。
如果流水线使用了分组或时间数据选取，则您可以在区域性或地区性服务中断后使用 Pub/Sub 的还原功能或 Kafka 的重放功能来重新处理数据元素，以获得相同的计算结果。如果流水线所使用的业务逻辑不依赖于服务中断之前的数据，则可最大限度减少流水线输出的数据丢失，一直减少至 0 个元素。如果流水线业务逻辑依赖于服务中断之前处理的数据（例如，如果使用了长滑动窗口，或者如果全局时间窗口存储了不断增加的计数器），则 Dataflow 可提供一个截取快照功能（目前处于预览模式）以提供流水线状态的快照备份。
BigQuery
BigQuery 是一个无服务器、扩缩能力极强且经济实惠的云数据仓库，旨在提升您的业务敏捷性。BigQuery 支持对用户数据集使用两种不同的可用性相关的配置选项。
单地区配置
在单地区配置中，数据以冗余方式存储在单个地区内的两个区域中。写入 BigQuery 的数据首先会写入主要区域，然后异步复制到次要区域。这样可以防止该地区内的单个区域不可用。在发生区域服务中断时，已写入主要区域但尚未复制到次要区域的数据在服务中断得到解决之前不可用。在发生极其罕见的区域被销毁的情况下，该数据可能会永久丢失。
多地区（美国/欧盟）配置
与单地区配置类似，在美国/欧盟多地区配置中，数据以冗余方式存储在一个地区内的两个区域中。此外，BigQuery 会在第二个地区中保存数据的其他备份副本。如果主要地区发生服务中断，则系统会从次要地区传送数据。在主要地区恢复之前，尚未复制的数据不可用。
Google Kubernetes Engine
Google Kubernetes Engine (GKE) 可简化 Google Cloud 上的容器化应用的部署，从而提供代管式 Kubernetes 服务。您可以选择地区级集群拓扑或区域级集群拓扑。
- 创建区域级集群时，GKE 会在选定区域中预配一个控制层面机器，并在同一区域中预配工作器机器（节点）。
- 对于地区级集群，GKE 会在选定地区内的三个不同区域中预配三个控制层面机器。默认情况下，节点也分布在三个区域中，但您可以选择创建具有仅在一个区域中预配的节点的地区级集群。
- 多区域级集群与区域级集群类似，前者包含一个主节点机器，但还能够将节点分布在多个区域中。
区域性服务中断：为避免区域性服务中断，请使用地区级集群。控制层面和节点分布在一个地区内的三个不同区域中。一个区域发生服务中断不会影响其他两个区域中部署的控制层面和工作器节点。
地区级服务中断：缓解地区性服务中断需要在多个地区中进行部署。虽然多地区拓扑目前未作为内置产品功能提供，但它是现如今很多 GKE 客户所采用的方法，可手动实现。您可以创建多个地区级集群在多个地区中复制您的工作负载，并使用多集群 Ingress 控制发送到这些集群的流量。
Cloud Key Management Service
Cloud Key Management Service (Cloud KMS) 提供可扩缩且高度耐用的加密密钥资源管理系统。Cloud KMS 将其所有数据和元数据存储在 Cloud Spanner 数据库中，该数据库通过同步复制可提高数据耐用性和可用性。
您可以在单个地区、多个地区或在全球范围内创建 Cloud KMS 资源。
如果某个区域发生服务中断，则 Cloud KMS 将不间断地继续处理来自同一地区或不同地区中的其他区域的请求。由于数据是同步复制的，因此不会造成数据丢失或损坏。该地区服务中断解决后，完全冗余性将恢复。
如果某个地区发生服务中断，则在该地区再次可用之前，该地区中的地区性资源会处于离线状态。请注意，即使在一个地区内，至少 3 个副本保留在不同区域中。如果需要更高的可用性，则资源应存储在多地区配置或全球配置中。多地区配置和全球配置旨在发生地区性服务中断时，通过以地理位置冗余方式在多个地区存储和传送数据来保持可用。
Cloud Identity
Cloud Identity 服务分布在多个地区中，并使用动态负载平衡。Cloud Identity 不允许用户选择资源范围。如果特定区域或地区发生服务中断，则流量会自动分配到其他区域或地区。
在大多数情况下，永久性数据会通过同步复制在多个地区中镜像。考虑到性能原因，一些系统（例如影响大量实体的缓存或更改）会跨地区异步复制。如果存储最新数据的主要地区发生服务中断，则在该主要地区变为可用之前，Cloud Identity 会从其他位置传送过时数据。
Persistent Disk
区域和地区配置中提供了 Persistent Disk。
区域级 Persistent Disk 托管在单个区域中。如果区域级 Persistent Disk 所在的区域不可用，则在该区域服务中断解决之前，该 Persistent Disk 无法使用。
地区级 Persistent Disk 可在同一地区中的两个区域之间同步复制数据。如果虚拟机所在的区域发生服务中断，您可以将地区级 Persistent Disk 强制挂接到该 Persistent Disk 所在的次要区域中的虚拟机实例。如需执行此任务，您必须在该区域中启动另一个虚拟机实例，或者在该区域中维护一个热备用虚拟机实例。
Cloud Storage
Cloud Storage 可提供全球统一、可扩缩且高度耐用的对象存储。您可以在一个大洲内的单地区、双地区或多地区中创建 Cloud Storage 存储分区。
如果某个区域发生服务中断，则系统会自动、透明地从相应地区中的其他位置传送不可用区域中的数据。从最初写入开始，数据和元数据以冗余方式跨区域存储。当某个区域变得不可用时，任何写入都不会丢失。
如果某个地区发生服务中断，则在该地区再次可用之前，该地区中的地区级存储分区会处于离线状态。如果需要更高的可用性，则您应考虑将数据存储在双地区配置或多地区配置中。双地区和多地区旨在发生地区性服务中断时，通过使用异步复制以地理位置冗余方式在多个地区存储数据来保持可用。
Cloud Storage 使用 Cloud Load Balancing 从多个地区传送双地区和多地区存储分区。在发生地区性服务中断的情况下，传送不会中断。由于地理位置冗余是异步实现的，因此某些最近写入的数据在服务中断过程中可能无法访问，并且在受影响地区发生数据物理销毁的情况下可能会丢失。
Container Registry
Container Registry 提供可扩缩的托管式 Docker Registry 实现，可安全、私密地存储 Docker 容器映像。Container Registry 实现了 HTTP Docker Registry API。
Container Registry 是一项全球服务，默认情况下以冗余方式将映像元数据同步存储到多个区域和地区。容器映像存储在 Cloud Storage 多地区级存储分区中。借助此存储策略，Container Registry 能够在所有情况下提供区域性服务中断恢复能力，并能够为 Cloud Storage 已异步复制到多个地区的任何数据提供地区性服务中断恢复能力。
Pub/Sub
Pub/Sub 是一种用于应用集成和流式分析的消息传递服务。Pub/Sub 主题是全球性的，这意味着可从任何 Google Cloud 位置查看和访问这些主题。但是，任何给定消息都存储在一个距离发布者最近且资源位置存储政策允许的 Google Cloud 地区中。因此，主题可能会将消息存储在整个 Google Cloud 的不同地区中。Pub/Sub 消息存储政策可以限制存储消息的地区。
区域性服务中断：发布 Pub/Sub 消息后，系统会将其同步写入相应地区内至少两个区域中的存储空间。因此，如果一个区域变得不可用，则对客户没有任何可见的影响。
区域级服务中断：在某区域发生服务中断期间，存储在该区域内的消息无法访问。管理操作（例如创建和删除主题及订阅）属于多区域级操作，可以应对任何一个 Google Cloud 区域发生服务中断。此外，只要消息存储政策允许至少一个区域，并且您的应用使用全球端点 (pubsub.googleapis.com) 或多个区域端点，发布操作也同样适用于区域中断。默认情况下，Pub/Sub 不限制消息存储位置。
如果您的应用依赖于消息排序，请查看 Pub/Sub 团队提供的详细解释。消息排序保证按区域提供，如果您使用全局端点，可能会中断。
Cloud Composer
Cloud Composer 是 Google Cloud 的代管式 Apache Airflow 实现。Cloud Compose 的架构设计为一个地区级控制层面，让用户可以管理 Cloud Composer 集群。控制层面不依赖于给定地区中的个别区域。因此，在发生区域性服务中断期间，您可以保留对 Cloud Composer API 的访问权限，包括创建新集群的权限。
集群在 Google Kubernetes Engine 中运行。由于集群属于区域性资源，因此区域性服务中断会导致集群不可用，或者会销毁集群。服务中断时当前正在执行的工作流可能会在完成之前停止。这意味着，服务中断会导致部分已执行的工作流（包括用户已将工作流配置为要完成的任何外部操作）的状态丢失。这样可能会导致外部不一致，具体取决于工作流，例如，工作流在多步骤执行过程中停止来修改外部数据存储区。因此，在设计 Airflow 工作流时，您应考虑恢复流程，包括如何检测部分未执行的工作流的状态、如何修复任何部分数据更改等等。
在某区域发生服务中断期间，您可以选择使用 Cloud Composer 在另一个区域中启动集群的新实例。集群可用后，工作流就可以继续进行。根据您的偏好设置，您可能希望在另一个区域中运行空闲副本集群，并在发生区域性服务中断时切换到该副本集群。
Cloud SQL
Cloud SQL 是一项适用于 MySQL、PostgreSQL 和 SQL Server 的全代管式关系型数据库服务。Cloud SQL 使用代管式 Compute Engine 虚拟机来运行数据库软件。Cloud SQL 为地区冗余提供高可用性配置，从而保护数据库不受区域服务中断的影响。您可以预配跨地区副本以保护数据库不受地区服务中断的影响。由于该产品还提供不能应对区域或地区服务中断的区域选项，因此您应该谨慎选择高可用性配置和/或跨地区副本。
区域服务中断：高可用性选项可在一个地区内的两个不同区域中创建主虚拟机实例和备用虚拟机实例。在正常操作期间，主虚拟机实例会处理所有请求，并将数据库文件写入地区级 Persistent Disk，该 Persistent Disk 会同步复制到主要区域和备用区域。如果区域服务中断影响主实例，则 Cloud SQL 会启动故障转移，在此期间，Persistent Disk 会挂接到备用虚拟机且流量会重新路由。
在此过程中，数据库必须初始化，包括处理已写入事务日志但未应用于数据库的任何事务。未处理的事务的数量和类型会增加 RTO 时间。最近的写入可能会导致未处理的事务积压。RTO 时间主要受以下因素的影响：(a) 最近的写入活动；(b) 最近对数据库架构的更改。
最后，区域性服务中断解决后，您可以手动触发故障恢复操作以在主要区域继续传送数据。
如需详细了解高可用性选项，请参阅 Cloud SQL 高可用性文档。
地区服务中断：跨地区副本选项可在其他地区中创建主实例的读取副本，以保护您的数据库不受地区性服务中断的影响。跨地区复制使用异步复制功能，可让主实例在副本实例提交事务之前先提交事务。事务在主实例上提交和在副本实例上提交之间的时间差称为“复制延迟”（可以进行监控）。此指标反映了尚未从主实例发送到副本实例的事务，以及副本实例已收到但尚未处理的事务。在地区性服务中断期间，未发送到副本实例的事务会变得不可用。副本实例已收到但未处理的事务会影响恢复时间，如下所述。
Cloud SQL 建议您使用包含一个副本的配置测试您的工作负载，以确定“每秒安全事务数 (TPS)”上限，即不会使复制延迟时间累积的最大持续 TPS。如果您的工作负载超过安全 TPS 上限，复制延迟时间会累积，对 RPO 和 RTO 值产生不利影响。一般来说，请避免使用易受复制延迟影响的小型实例配置（vCPU 核心小于 2 个，磁盘小于 100GB 或 PD-HDD）。
如果发生地区性服务中断，您必须决定是否手动提升读取副本。这是一项手动操作，因为提升可能会导致脑裂情况，在此情况下，尽管提升时主实例延迟，提升的副本仍会接受新事务。这在地区性服务中断解决后可能会导致问题，您必须调整从未从主实例传播到副本实例的事务。如果这对您的需求有影响，您可以考虑使用跨地区同步复制数据库产品（如 Cloud Spanner）。
用户触发提升过程后，提升过程将遵循与在高可用性配置中激活备用实例类似的步骤：读取副本必须处理事务日志且负载平衡器必须重定向流量。处理事务日志会增加总恢复时间。
如需详细了解跨地区副本选项，请参阅 Cloud SQL 跨地区副本文档。
Cloud Logging
Cloud Logging 由两个主要部分组成：日志路由器和 Cloud Logging 存储。
日志路由器处理流式日志事件，并将日志定向到 Cloud Storage、Pub/Sub、BigQuery 或 Cloud Logging 存储。
Cloud Logging 存储是一项用于存储、查询和管理日志合规性的服务。它支持许多用户和工作流，包括开发、合规性、问题排查和主动提醒。
日志路由器和传入的日志：在某区域发生服务中断期间，Cloud Logging API 会将日志路由到相应地区中的其他区域。通常，日志路由器路由到 Cloud Logging、BigQuery 或 Pub/Sub 的日志会尽快写入其最终目标位置，而发送到 Cloud Storage 的日志会缓冲并按小时批量写入。
日志条目：发生区域性或地区性服务中断时，在受影响的区域或地区中已缓冲且尚未写入导出目标位置的日志条目会变得无法访问。基于日志的指标也会在日志路由器中计算，并受到相同的限制条件约束。在将日志传送到所选日志导出位置后，日志将根据目标位置服务进行复制。导出到 Cloud Logging 存储的日志会同步复制到一个地区的两个区域中。如需了解其他目标位置类型的复制行为，请参阅本文中的相关部分。请注意，导出到 Cloud Storage 的日志每小时都会进行批处理和写入。因此，我们建议您使用 Cloud Logging 存储空间、BigQuery 或 Pub/Sub，以尽量减少受中断影响的数据量。
日志元数据：接收器和排除配置等元数据在全球范围内存储，但在地区范围内缓存，因此如果发生服务中断，地区日志路由器实例会正常运行。单个地区服务中断对该地区之外无任何影响。
Cloud Spanner
Cloud Spanner 是一种具备扩缩能力、扩容能力极强的多版本、同步复制以及具备关系语义的高度一致性数据库。
区域 Cloud Spanner 实例在单个区域中三个地区之间同步复制数据。对某个区域 Cloud Spanner 实例的写入将同步发送到所有 3 个副本，并在至少 2 个副本（其中的大多数数量为 2/3）提交写入之后向客户端确认。这样，通过提供对所有数据的访问权限，Cloud Spanner 可以适应区域故障，因为最新写入仍然存在，并且使用 2 个副本仍可达成大部分仲裁。
Cloud Spanner 的单区域实例包括一个写入地区，即跨三个区域中的 5 个地区同步复制数据（两个读写副本分别位于默认前导区域和另一个区域中；一个副本位于见证者地区）。对多区域 Cloud Spanner 实例执行写入操作后，至少要等待 3 个副本（大部分是 3 个，共 5 个）提交的写入操作。如果在一个地区或区域发生故障，Cloud Spanner 可以访问所有数据（包括最新的写入），并可以处理读写请求，因为数据会在至少 3 个地区中持续存在 2 个区域。
如需详细了解这些配置，请参阅 Cloud Spanner 实例文档；如需详细了解 Cloud Spanner 复制的工作原理，请参阅复制文档。