考虑为关键任务系统实现业务连续性的主要原因是帮助组织在故障事件期间和之后保持弹性并继续开展业务运营。通过复制多个地理区域的系统和数据并避免单点故障，您可以将影响本地基础架构的自然灾害风险降至最低。其他故障场景包括严重的系统故障、网络安全攻击，甚至系统配置错误。
优化系统以使其能够承受故障是建立有效业务连续性的关键。系统可靠性可能会受到多种因素的影响，包括但不限于性能、弹性、正常运行时间、安全性和用户体验。如需详细了解如何在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 的按用量计费模式意味着，您只需为实际使用的存储和计算容量付费。
- 借助弹性功能（例如自动扩缩），您可以根据需要自动扩缩或缩减灾难恢复环境。
例如，下图显示了一个在本地环境（生产环境）中运行的应用，该应用使用 Compute Engine、Cloud SQL 和 Cloud 负载均衡在Google Cloud 上使用恢复组件。在此场景中，数据库是使用基于虚拟机的数据库或 Google Cloud 托管式数据库（例如 Cloud SQL）预配的，以便通过持续数据复制实现更快速的恢复。您可以从预先创建的快照启动 Compute Engine 虚拟机，以便在正常运行期间降低费用。采用这种设置后，在发生失败事件后，DNS 需要指向 Cloud Load Balancing 外部 IP 地址。
如需在云端运行应用，您需要预配 Web 和应用虚拟机。根据目标 RTO 级别和公司政策，调用灾难恢复、在云端预配工作负载以及重定向流量的整个过程可以手动或自动完成。
如需加快基础架构的预配速度并实现自动化预配，不妨考虑以代码形式管理基础架构。您可以使用 Cloud Build（一种持续集成服务）自动将 Terraform 清单应用到您的环境。如需了解详情，请参阅使用 Terraform、Cloud Build 和 GitOps 以代码形式管理基础架构。
最佳做法
使用业务连续性模式时，请考虑以下最佳实践：
- 创建记录基础架构以及故障切换和恢复过程的灾难恢复计划。
- 根据业务影响分析和确定的必要 RPO 和 RTO 目标，考虑采取以下措施：
- 如果仅备份数据，不妨考虑使用切换模式。否则，网状模式可能是复制现有环境网络架构的理想之选。
- 最大限度减少在不同环境中运行的系统之间的依赖项，尤其是在同步处理通信时。这些依赖项会降低性能并降低整体可用性。
避免出现脑裂问题。如果跨环境双向复制数据，您可能会遇到脑裂问题。当两个双向复制数据的环境彼此失去通信时，就会出现脑裂问题。这种分屏可能会导致两个环境中的系统都断定另一个环境不可用，并且自己拥有对数据的独占访问权。这可能会导致对数据进行冲突的修改。有两种常见方法可以避免分脑问题：
- 使用第三个计算环境。在这种环境中，系统可以在修改数据之前检查是否达到了仲裁要求。
允许在恢复连接后对有冲突的数据修改进行协调。
对于 SQL 数据库，您可以在客户端开始使用新的主实例之前使原始主实例无法访问，以避免出现脑裂问题。如需了解详情，请参阅 Cloud SQL 数据库灾难恢复。
确保持续集成/持续交付系统和工件代码库不会成为单点故障。当一个环境不可用时，您仍须能够部署新版本或应用配置更改。
使用备用系统时，请确保所有工作负载都具有可移植性。所有工作负载都应具有可移植性（如果应用支持且可行），以便系统在不同环境之间保持一致。您可以通过考虑容器和 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 或 Cross-Cloud Interconnect。 Google Cloud Cloud Interconnect 有助于优化连接性能，并可能降低满足特定条件的流量的出站数据传输费用。如需了解详情，请参阅 Cloud Interconnect 价格。
不妨考虑在 Google Cloud Marketplace 上使用首选的合作伙伴解决方案，以便更轻松地执行数据备份、复制以及满足您要求的其他任务（包括 RPO 和 RTO 目标）。
测试和评估灾难恢复调用场景，了解应用从灾难事件中恢复的容易程度（与目标 RTO 值相比）。
对传输中的通信进行加密。为了保护敏感信息，我们建议对所有传输中的通信进行加密。如果需要在连接层进行加密，根据所选的混合连接解决方案，有多种选项可供选择。这些选项包括 VPN 隧道、通过 Cloud Interconnect 实现的高可用性 VPN 和 MACsec for Cloud Interconnect。