你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

有关使用可用性区域和区域的建议

  • 项目

适用于此 Azure Well-Architected 框架可靠性清单建议：

RE：05 在不同级别添加冗余，尤其是对于关键流。 根据确定的可靠性目标，将冗余应用于计算、数据、网络和其他基础结构层。

相关指南：高可用性多区域设计 | 冗余

本指南介绍有关确定何时跨可用性区域或区域部署工作负载的建议。

为 Azure 设计解决方案时，需要决定是跨一个区域中的多个可用性区域进行部署，还是部署到多个区域。 此决策会影响解决方案的可靠性、成本和性能，以及团队操作解决方案的能力。 本指南提供有关影响决策的关键业务要求、可考虑的方法、每种方法所涉及的权衡以及每种方法对 Azure Well-Architected 框架核心支柱的影响的信息。

决定用于解决方案的最佳 Azure 区域是一个关键选择。 选择 Azure 区域指南介绍了如何在多个地理区域中选择和操作。 选择如何在解决方案中使用区域和可用性区域也会影响 Well-Architected Framework 的几个支柱：

  • 可靠性：选择的部署方法有助于缓解各种类型的风险。 通常，通过将工作负载分散到地理分布程度更高的区域，可以实现更高的复原能力。
  • 成本优化：某些体系结构方法需要部署的资源比其他方法多，这可能会增加资源成本。 其他方法涉及跨地理隔离的可用性区域或区域发送数据，这可能会产生网络流量费用。 此外，请务必考虑管理资源的持续成本，在有全面的业务要求时，这种成本通常更高。
  • 性能效率：可用性区域通过高带宽、低延迟的网络链路连接在一起，这足以让大多数工作负载跨区域启用同步复制和通信。 但是，如果工作负载已经过测试，并且对跨区域的网络延迟很敏感，则可能需要考虑将工作负载的组件物理定位在一起，以最大程度地降低通信时的延迟。
  • 卓越运营：复杂的体系结构需要付出更多精力来部署、配置和管理。 此外，对于高度可用的解决方案，可能需要规划如何故障转移到辅助资源集。 故障转移、故障回复和以透明方式重定向流量可能很复杂，尤其是在需要手动步骤时。 最好是自动执行部署和管理过程。 有关详细信息，请参阅卓越运营支柱指南，包括 OE：05 基础结构即代码、 OE：09 任务自动化、 OE：10 自动化设计和OE：11 部署实践。

无论如何设计解决方案，安全支柱都适用。 通常，决定是否以及如何使用可用性区域和区域不会改变安全状况。 Azure 对每个区域和可用性区域应用相同的安全严格。

提示

对于许多生产工作负荷， 区域冗余部署 提供了最佳平衡。 可以使用 异步数据备份将此方法扩展到另一个区域。 如果不确定要选择哪种方法，请从此类部署开始。

如果需要这些方法提供的特定优势，但要注意所涉及的权衡，请考虑其他工作负载方法。

定义

术语 定义
主动-主动 一种体系结构，其中解决方案的多个实例同时主动处理请求。
主动-被动 一种体系结构，在该体系结构中，解决方案的一个实例被指定为主 实例并处理 流量，如果主实例不可用，则部署一个或多个 辅助 实例来提供流量。
异步复制 一种数据复制方法，其中将数据写入并提交到一个位置。 稍后，更改将复制到另一个位置。
可用性区域 区域中的一组独立的数据中心。 每个可用性区域独立于其他可用性区域，具有自己的电源、冷却和网络基础结构。 许多区域支持可用性区域。
数据中心 包含服务器、网络设备和其他硬件以支持 Azure 资源和工作负载的设施。
本地冗余部署 一种部署模型，其中资源在不引用可用性区域的情况下部署到单个区域。 在支持可用性区域的区域中，资源可能部署在该区域的任何可用性区域中。
多区域部署 将资源部署到多个 Azure 区域的部署模型。
配对区域 两个 Azure 区域之间的关系。 某些 Azure 区域 连接到另一个定义的区域，以启用特定类型的多区域解决方案。 较新的 Azure 区域未配对。
区域 包含一组数据中心的地理外围。
区域体系结构 Azure 区域的特定配置，包括可用性区域的数量以及该区域是否与另一个区域配对。
同步复制 一种数据复制方法，其中将数据写入并提交到多个位置。 每个位置都必须确认写入操作已完成，然后才能将整个写入操作视为完成。
区域 (固定) 部署 将资源部署到特定可用性区域的部署模型。
区域冗余部署 跨多个可用性区域部署资源的部署模型。 Microsoft 管理数据同步、流量分配和故障转移（如果区域发生中断）。

关键设计策略

Azure 在全球的足迹很大。 Azure 区域 是包含一组数据中心的地理外围。 需要全面了解 Azure 区域和可用性区域。

Azure 区域具有多种配置，也称为 区域体系结构。

许多 Azure 区域提供 可用性区域，这些区域是独立的数据中心组。 在一个区域内，可用性区域距离足够近，可以与其他可用性区域建立低延迟连接，但它们相距足够远，可以降低多个区域受到本地中断或天气影响的可能性。 可用性区域具有独立的电源、冷却和网络基础结构。 它们的设计目的是在一个区域遇到服务中断时，其余区域支持区域服务、容量和高可用性。

下图显示了多个示例 Azure 区域。 区域 1 和 2 支持可用性区域。

显示数据中心、可用性区域和区域的示意图。

如果部署到 包含可用性区域的 Azure 区域，则可以同时使用多个可用性区域。 通过使用多个可用性区域，可以在大型大都市区域中的单独物理数据中心内保留应用程序和数据的单独副本。

有两种方法可以在解决方案中使用可用性区域：

  • 区域 资源固定到特定可用性区域。 可以跨不同区域组合多个区域性部署，以满足高可用性要求。 你负责管理数据复制和跨区域分发请求。 如果单个可用性区域中发生中断，则由你负责故障转移到另一个可用性区域。
  • 区域冗余 资源分布在多个可用性区域。 Microsoft 管理跨区域分布请求以及跨区域复制数据。 如果单个可用性区域中发生中断，Microsoft 会自动管理故障转移。

Azure 服务支持其中一种或两种方法。 平台即服务 (PaaS) 服务通常支持区域冗余部署。 基础结构即服务 (IaaS) 服务通常支持区域性部署。 有关 Azure 服务如何使用可用性区域的详细信息，请参阅 具有可用性区域支持的 Azure 服务。

当 Microsoft 将更新部署到服务时，我们会尝试使用对你造成干扰最小的方法。 例如，我们的目标是一次将更新部署到单个可用性区域。 此方法可以减少更新可能对活动工作负荷产生的影响，因为当更新正在进行时，工作负载可以继续在其他区域中运行。 但是，工作负载团队最终有责任确保其工作负载在平台升级期间继续正常运行。 例如，使用 具有灵活业务流程模式的虚拟机规模集或大多数 Azure PaaS 服务时，Azure 会智能地放置资源，以减少平台更新的影响。 此外，还可以考虑 过度预配 （部署更多资源实例），以便在升级其他实例时某些实例保持可用。 有关 Azure 如何部署更新的详细信息，请参阅 推进安全部署做法。

许多区域也有 配对区域。 配对区域支持某些类型的多区域部署方法。 某些较新的区域 有多个可用性区域，并且没有配对区域。 你仍然可以将多区域解决方案部署到这些区域，但使用的方法可能有所不同。

有关 Azure 如何使用区域和可用性区域的详细信息，请参阅 什么是 Azure 区域和可用性区域？

了解共同的责任

共担责任原则描述了云提供商 (Microsoft) 与你之间的责任划分方式。 根据所使用的服务类型，你可能承担或多或少的运行服务的责任。

Microsoft 提供可用性区域和区域，使你能够灵活地设计解决方案以满足你的要求。 使用托管服务时，Microsoft 将承担更多资源管理责任，其中甚至可能包括数据复制、故障转移、故障回复以及与运行分布式系统相关的其他任务。

你自己的代码需要 建议的做法和设计模式才能正常处理故障。 这些做法在故障转移操作期间更为重要，例如在发生可用性区域或区域故障转移时发生的做法，因为区域或区域之间的故障转移通常需要应用程序重试与服务的连接。

确定关键业务和工作负载要求

若要就如何在解决方案中使用可用性区域和区域做出明智的决策，需要了解你的要求。 这些要求应由解决方案设计人员和业务利益干系人之间的讨论驱动。

风险容忍度

不同的组织具有不同程度的风险容忍度。 即使在组织内部，每个工作负载的风险容忍度也通常不同。 大多数工作负载不需要极高的可用性。 但是，某些工作负载非常重要，甚至值得缓解不太可能发生的风险，例如影响大地理区域的重大自然灾害。

下表列出了在云环境中应考虑的一些常见风险：

风险 示例 可能性
硬件中断 硬盘或网络设备出现问题。

主机重启。		 高。 任何复原策略都应考虑到这些风险。
数据中心中断 整个数据中心的电源、冷却或网络故障。

大都市区一部分的自然灾害。		 中型
区域中断 影响广大地理区域的重大自然灾害。

导致一个或多个 Azure 服务在整个区域中不可用的网络或服务问题。		 低

降低每个工作负载可能的风险是理想的做法，但这样做并不实用或经济高效。 请务必与业务利益干系人进行公开讨论，以便你可以就应缓解的风险做出明智的决策。

提示

无论可靠性目标如何，所有工作负载都必须具有一些灾难恢复缓解措施。 如果工作负荷需要高可用性目标，则缓解策略应是全面的，并且应降低发生低概率事件的风险。 对于其他工作负载，请根据准备接受哪些风险以及需要缓解的风险做出明智的决定。

复原能力要求

了解工作负载的复原能力要求非常重要，包括恢复时间目标 (RTO) 和恢复点目标 (RPO) 。 这些目标可帮助你确定要排除的方法。如果没有明确的要求，则无法就采用哪种方法做出明智的决定。 有关详细信息，请参阅 目标功能和非功能性要求。

服务级别目标

应了解解决方案的预期运行时间服务级别目标 (SLO) 。 例如，你可能有一个业务要求，即解决方案需要满足 99.9% 的运行时间。

Azure 为每个服务提供服务级别协议 (SLA) 。 SLA 指示应从服务中获得的运行时间级别，以及实现预期 SLA 所需的条件。 但是，请记住，Azure SLA 指示服务可用性的方式并不总是与你考虑工作负载运行状况的方式匹配。

体系结构决策会影响解决方案的 复合 SLO。 通常，解决方案中构建的冗余越多，SLO 可能就越高。 在区域冗余或多区域配置中部署服务时，许多 Azure 服务提供更高的 SLA。 查看所使用的每个 Azure 服务的 SLA，以确保了解如何最大程度地提高服务的复原能力和 SLA。

数据驻留

某些组织对可以存储和处理其数据的物理位置施加限制。 有时，这些要求基于法律或法规标准。 在其他情况下，组织可能决定采用数据驻留策略，以避免客户担心。 如果有严格的数据驻留要求，则可能需要使用单区域部署或使用 Azure 区域和服务子集。

注意

避免对数据驻留要求做出毫无根据的假设。 如果需要遵守特定的法规标准，请验证这些标准实际指定的内容。

用户位置

通过了解用户所在的位置，你可以就如何根据需要优化延迟和可靠性做出明智的决策。 Azure 提供了许多选项来支持地理位置分散的用户群。

如果用户集中在一个区域，则单区域部署可以简化操作要求并降低成本。 但是，需要考虑单区域部署是否满足可靠性要求。 对于任务关键型应用程序，即使用户已并置，仍应使用多区域部署。

如果用户在地理上分散，则跨多个区域部署工作负载可能有意义。 Azure 服务提供不同的功能来支持多区域部署，你可以使用 Azure 的全球足迹来改善用户体验，并使应用程序更接近用户群。 可以使用 部署标记模式 或 Geodes 模式，或者跨多个区域复制资源。

即使用户位于不同的地理区域，也要考虑是否需要多区域部署。 考虑是否可以通过使用全球流量加速（如 Azure Front Door 提供的加速）在单个区域内实现要求。

预算

如果在有限的预算下操作，请务必考虑部署冗余工作负荷组件所涉及的成本。 这些成本可能包括额外的资源费用、网络成本，以及管理更多资源和更复杂的环境的运营成本。

复杂性

避免解决方案体系结构中不必要的复杂性是一种很好的做法。 引入的复杂性越多，就越难做出有关体系结构的决策。 复杂的体系结构更难操作，更难保护，而且通常性能不佳。 遵循 简单性原则。

Azure 简化

通过提供区域和可用性区域，Azure 使你可以选择满足需求的部署方法。 有多种方法可供选择，每种方法都带来好处并产生成本。

为了说明可以使用的部署方法，请考虑一个示例方案。 假设你正在考虑部署一个包含将数据写入某种存储的应用程序的新解决方案：

显示用户连接到连接到存储的应用程序的关系图。

此示例不特定于任何特定的 Azure 服务。 它旨在提供一个简单的示例来说明基本概念。

可通过多种方式部署此解决方案。 每种方法都提供一组不同的优势，并产生不同的成本。 在高级别上，可以考虑 本地冗余、 区域性 (固定) 、 区域冗余或 多区域 部署。 下表汇总了一些主要问题：

构成要素 本地冗余 固定) 区域 ( 区域冗余 多区域
可靠性 可靠性低 取决于方法 高或非常高的可靠性 高或非常高的可靠性
成本优化 低成本 取决于方法 中等成本 高成本
性能效率 大多数工作负载) 可接受的性能 ( 高性能 大多数工作负载) 可接受的性能 ( 取决于方法
卓越运营 低操作要求 高操作要求 低操作要求 高操作要求

下表总结了一些可以使用的方法，以及它们如何影响体系结构：

体系结构问题 本地冗余 固定) 区域 ( 区域冗余 多区域
符合数据驻留 高 高 高 取决于区域
区域可用性 所有区域 具有可用性区域的区域 具有可用性区域的区域 取决于区域

本文的其余部分介绍了上表中列出的每种方法。 方法列表并不详尽。 你可能决定组合多种方法，或者在解决方案的不同部分使用不同的方法。

部署方法 1：本地冗余部署

如果在部署资源时未指定多个可用性区域或区域，Azure 不会保证资源是部署到单个数据中心，还是跨区域中的多个数据中心进行拆分。 在某些情况下，Azure 也可能在可用性区域之间移动资源。

此图显示了在单个可用性区域中部署到单个数据中心的解决方案。

默认情况下，大多数 Azure 资源都高度可用，在由平台管理的数据中心内具有较高的 SLA 和内置冗余。 但是，从可靠性角度来看，如果区域的任何部分遇到中断，则工作负荷可能会受到影响。 如果是，则解决方案可能不可用，或者数据可能会丢失。

对于对延迟高度敏感的工作负载，此方法还可能导致性能降低。 工作负荷组件可能不会并置在同一数据中心，因此可能会观察到区域内流量的一些延迟。 Azure 还可能在可用性区域之间以透明方式移动服务实例，这可能会对性能产生轻微影响。 但是，对于大多数工作负载来说，这不是一个问题。

下表汇总了一些主要问题：

构成要素 影响
可靠性 可靠性低。 如果数据中心发生故障，服务可能会中断。 但是，可以生成应用程序，以便对其他类型的故障进行复原。
成本优化 最低成本。 只需为每个资源创建一个实例，不会产生任何区域间或区域间带宽成本。
性能效率 对于大多数工作负载：可接受的性能。 此方法可能会提供令人满意的性能。

对于对延迟高度敏感的工作负载：低性能。 不保证组件位于同一可用性区域中，因此，对于对高度延迟敏感的组件，可能会发现性能较低。
卓越运营 操作效率高。 只需部署和管理每个资源的单个实例。

下表从体系结构角度总结了一些关注点：

体系结构问题 影响
符合数据驻留 高。 部署使用此方法的解决方案时，数据存储在所选的 Azure 区域中。
适用区域 高。 此方法可用于任何 Azure 区域。

跨区域备份的本地冗余部署

可以通过将基础结构和数据定期备份到次要区域来扩展本地冗余部署。 此方法添加了额外的保护层，以缓解主要区域中的中断。 如下所示：

显示部署到单个数据中心的解决方案的示意图，其中备份位于另一个区域。

实现此方法时，需要仔细考虑 RTO 和 RPO：

  • 恢复时间：如果发生区域性中断，可能需要在另一个 Azure 区域中重新生成解决方案，这会影响恢复时间。 请考虑使用基础结构即代码 (IaC) 方法生成解决方案，以便在发生重大灾难时快速重新部署到另一个区域。 确保部署工具和流程具有与应用程序一样具有复原能力，以便即使发生中断，也可以使用它们重新部署解决方案。 计划并排练将解决方案还原到工作状态所需的步骤。
  • 恢复点：备份频率确定 (恢复点) 可能会遇到的数据丢失量。 通常可以控制备份的频率，以便满足 RPO 要求。

下表汇总了一些主要问题：

构成要素 影响
可靠性 中等可靠性。 如果数据中心发生故障，服务可能会中断。 数据以异步方式备份到地理上分离的区域，从而通过最大程度地减少数据丢失来减少整个区域中断的影响。 在发生完全区域中断时，可以将操作手动还原到另一个区域。 但是，恢复过程可能很复杂，手动还原到其他区域可能需要一些时间。
成本优化 低成本。 通常，将备份添加到另一个区域的成本仅略高于部署本地冗余资源的成本。
性能效率 对于大多数工作负载：可接受的性能。 此方法可能会提供令人满意的性能。

对于对延迟高度敏感的工作负载：低性能。 不保证组件位于同一可用性区域中，因此，对于对延迟高度敏感的组件，可能会发现性能较低。
卓越运营 在区域内发生任何中断期间：低运营效率。 故障转移由你负责，可能需要手动操作和重新部署。

下表从体系结构角度总结了一些问题：

体系结构问题 影响
符合数据驻留 取决于区域选择。 数据主要存储在指定的 Azure 区域中。 但是，需要选择另一个区域来存储备份，因此请务必选择与数据驻留要求兼容的区域。
适用区域 高。 可以在任何 Azure 区域中使用此方法。

部署方法 2：区域 (固定) 部署

在 区域部署中 ，指定应将资源部署到特定可用性区域。 此方法有时称为 区域固定 部署。

显示部署到特定可用性区域中的解决方案的示意图。使用区域部署方法。

区域性方法可减少组件之间的延迟。 但是，它本身不会提高解决方案的复原能力。 若要提高复原能力，需要将组件的多个实例部署到多个可用性区域中，并决定如何在每个实例之间路由流量。 此示例演示 主动-被动 流量路由方法：

显示部署到多个可用性区域中的解决方案的示意图。使用主动-被动流量路由方法。

在前面的示例中，负载均衡器跨多个可用性区域部署。 请务必考虑如何在不同可用性区域中的实例之间路由流量，因为区域中断还可能会影响部署到该区域的网络资源。 还可以考虑使用完全未部署到区域的全局负载均衡器，例如 Azure Front Door 或 Azure 流量管理器。

使用区域性部署模型时，需要承担许多责任：

  • 需要将资源部署到每个可用性区域，并单独配置和管理这些资源。
  • 需要确定在可用性区域之间复制数据的方式和时间，然后配置和管理复制。
  • 你负责使用负载均衡器等方式将请求分发到正确的资源。 需要确保负载均衡器满足复原要求。 还需要决定是使用主动-被动还是主动-主动请求分发模型。
  • 如果可用性区域遇到中断，则需要处理故障转移，以便将流量发送到另一个可用性区域中的资源。

跨多个可用性区域的主动-被动部署有时称为 区域内 DR 或 Metro DR。

下表总结了一些支柱问题：

构成要素 影响
可靠性 在单个可用性区域中部署时：可靠性低。 区域部署不会为数据中心或可用性区域中的中断提供任何复原能力。 必须跨多个可用性区域部署冗余资源，以实现高复原能力。

在多个可用性区域中部署时：可靠性高。 服务可复原到数据中心或可用性区域中断。
成本优化 部署在单个可用性区域中时：成本低。 单区域部署只需要每个资源的单个实例。

部署在多个可用性区域中时：成本高。 部署资源的多个实例，每个实例单独计费。 还需要为数据复制的区域间流量付费。
性能效率 高性能。 当为请求提供服务的组件位于同一可用性区域中时，延迟可能非常低。
卓越运营 低运营效率。 需要配置和管理服务的多个实例。 需要在可用性区域之间复制数据。 在可用性区域中断期间，故障转移由你负责。

下表从体系结构角度总结了一些问题：

体系结构问题 影响
符合数据驻留 高。 部署使用此方法的解决方案时，数据存储在所选的 Azure 区域中。
适用区域 具有可用性区域的区域。 此方法适用于支持 可用性区域的任何区域。

此方法通常用于基于虚拟机的工作负载。 有关支持区域部署的服务的完整列表，请参阅 可用性区域服务和区域支持。

规划区域性部署时，请验证你使用的可用性区域中是否支持你使用的 Azure 服务。 例如，若要列出每个可用性区域中可用的虚拟机 SKU，请参阅 检查 VM SKU 可用性。

提示

将资源部署到特定可用性区域时，请选择区域编号。 每个 Azure 订阅的区域编号序列都不同。 如果跨多个 Azure 订阅部署资源，请验证应在每个订阅中使用的区域编号。 有关详细信息，请参阅 物理和逻辑可用性区域。

部署方法 3：区域冗余部署

使用此方法时，应用层将分布在多个可用性区域。 请求到达时，内置于服务 (的负载均衡器本身跨越可用性区域) 将请求分散到每个可用性区域中的实例。 如果可用性区域发生中断，负载均衡器会将流量定向到正常可用性区域中的实例。

存储层也分布在多个可用性区域。 应用程序数据的副本通过 同步复制分布在多个可用性区域。 当应用程序对数据进行更改时，存储服务会将更改写入多个可用性区域，并且仅当所有这些更改都完成时，事务才会被视为已完成。 此过程可确保每个可用性区域始终具有数据的最新副本。 如果可用性区域遇到服务中断，则可以使用另一个可用性区域来访问相同的数据。

显示部署到多个可用性区域中的解决方案的示意图。使用区域冗余部署方法。

区域冗余方法可提高解决方案对数据中心中断等问题的复原能力。 但是，由于数据是同步复制的，因此应用程序必须等待数据写入多个可能位于大都市区域不同部分的单独位置。 对于大多数应用程序，区域间通信所涉及的延迟可以忽略不计。 但是，对于某些对延迟高度敏感的工作负载，跨可用性区域的同步复制可能会影响应用程序的性能。

下表总结了一些支柱问题：

构成要素 影响
可靠性 可靠性高。 服务可灵活应对数据中心或可用性区域中断。 数据跨可用性区域同步复制，且无延迟。
成本优化 中等成本。 根据所使用的服务，为启用区域冗余而增加服务层级可能会产生一些成本，或者产生一些区域间网络成本。
性能效率 对于大多数工作负载：可接受的性能。 此方法可能会提供令人满意的性能。

对于对延迟高度敏感的工作负载：低性能。 由于区域间流量或数据复制时间，某些组件可能对延迟很敏感。
卓越运营 高运营效率。 通常只需管理每个资源的单个逻辑实例。 对于大多数服务，在可用性区域中断期间，故障转移由 Microsoft 负责，并且会自动发生。

下表从体系结构角度总结了一些问题：

体系结构问题 影响
符合数据驻留 高。 部署使用此方法的解决方案时，数据存储在所选的 Azure 区域中。
适用区域 具有可用性区域的区域。 此方法适用于支持 可用性区域的任何区域。

此方法适用于许多 Azure 服务，包括 Azure 虚拟机规模集、Azure 应用服务、Azure Functions、Azure Kubernetes 服务、Azure 存储、Azure SQL、Azure 服务总线等。 有关支持区域冗余的服务的完整列表，请参阅 可用性区域服务和区域支持。

跨区域备份的区域冗余部署

可以通过将基础结构和数据定期备份到次要区域来扩展区域冗余部署。 此方法提供区域冗余方法的优势，并添加了一层保护，以缓解极不可能发生完全区域中断的事件。

显示解决方案部署到区域冗余部署中的多个可用性区域，备份位于另一个区域的关系图。

实现此方法时，需要仔细考虑 RTO 和 RPO：

  • 恢复时间：如果发生区域性服务中断，则可能需要在另一个影响恢复时间的 Azure 区域中重新生成解决方案。 请考虑使用 IaC 方法生成解决方案，以便在发生重大灾难时可以快速重新部署到另一个区域。 确保部署工具和进程与应用程序一样具有复原能力，这样即使发生中断，也可以使用它们重新部署解决方案。 规划和排练将解决方案还原到工作状态所需的步骤。

  • 恢复点：备份频率决定了 (恢复点) 可能会遇到的数据丢失量。 通常可以控制备份的频率以满足 RPO。

提示

此方法通常为所有体系结构问题提供良好的平衡。 如果不确定要使用哪种方法，请从这种类型的部署开始。

下表总结了一些支柱问题：

构成要素 影响
可靠性 可靠性非常高。 服务可灵活应对数据中心或可用性区域中断。 对于大多数服务，数据会自动跨区域复制，且无延迟。 数据以异步方式备份到地理隔离的区域。 此备份通过最大程度地减少数据丢失来降低整个区域中断的影响。 完全区域中断后，可以手动将操作还原到另一个区域。 但是，恢复过程可能很复杂，手动还原到其他区域可能需要一些时间。
成本优化 中等成本。 通常，将备份添加到另一个区域的成本仅略高于实现区域冗余的成本。
性能效率 对于大多数工作负载：可接受的性能。 此方法可能会提供令人满意的性能。

对于对延迟高度敏感的工作负载：低性能。 由于区域间流量或数据复制时间，某些组件可能对延迟很敏感。
卓越运营 在可用性区域中断期间：操作效率高。 故障转移由 Microsoft 负责，会自动进行。

在发生区域性服务中断期间：运营效率低。 故障转移由你负责，可能需要手动操作和重新部署。

下表从体系结构角度总结了一些问题：

体系结构问题 影响
符合数据驻留 取决于区域选择。 数据主要存储在指定的 Azure 区域中，但需要选择另一个区域来存储备份。 选择与数据驻留要求兼容的区域。
适用区域 具有可用性区域的区域。 此方法适用于支持 可用性区域的任何区域。

部署方法 4：多区域部署

可以将多个 Azure 区域一起使用，以在广泛的地理区域分发解决方案。 可以使用此多区域方法来提高解决方案的可靠性或支持地理分散的用户。 通过部署到多个区域，还可以降低在单个区域中遇到临时资源容量约束的风险。 如果数据驻留是解决方案的一个重要问题，请仔细考虑使用哪些区域来确保数据仅存储在满足要求的位置。

主动和被动区域

多区域体系结构很复杂，设计多区域解决方案的方法有很多。 对于某些工作负载，让多个区域同时主动处理请求 (主动-主动部署) 是有意义的。 对于其他工作负载，最好指定一 个主要区域 并使用一个或多个 次要区域 进行故障转移 (主动-被动部署) 。 本部分重点介绍第二种方案，其中一个区域处于活动状态，另一个区域为被动区域。 有关主动-主动多区域解决方案的信息，请参阅 部署标记模式 和 Geode 模式。

数据复制

跨区域通信比区域内的通信慢得多。 通常，由于数据需要传输的物理距离较长，两个区域之间的地理距离越大，网络延迟就越大。 有关在两个区域之间连接时的预期网络延迟，请参阅 Azure 网络往返延迟统计信息 。

跨区域网络延迟可能会显著影响解决方案设计，因为需要仔细考虑额外的延迟如何影响数据复制和其他事务。 对于许多解决方案，跨区域体系结构需要 异步 复制，以最大程度地减少跨区域流量对性能的影响。

异步数据复制

跨区域实现异步复制时，应用程序不会等待所有区域确认更改。 在主要区域中提交更改后，事务被视为已完成。 稍后会将更改复制到次要区域。 此方法可确保区域间连接延迟不会直接影响应用程序性能。 但是，由于复制延迟，区域范围的中断可能会导致一些数据丢失。 发生此数据丢失的原因可能是，在主要区域中完成写入后，但在将更改复制到另一个区域之前，某个区域可能会遇到中断。

显示部署到多个区域的解决方案的示意图。数据复制以异步方式进行。

下表总结了一些支柱问题：

构成要素 影响
可靠性 可靠性高。 该解决方案可灵活应对数据中心、可用性区域或整个区域的中断。 数据是复制的，但可能不是同步的，因此在故障转移方案中可能会丢失一些数据。
成本优化 成本高。 你需要在每个区域中部署单独的资源，并且每个资源会产生部署和维护成本。 跨区域的数据复制也可能会产生高昂的成本。
性能效率 高性能。 应用程序请求不需要跨区域流量，因此流量通常延迟较低。
卓越运营 低运营效率。 需要跨多个区域部署和管理资源。 你还负责在发生区域性服务中断期间在区域之间进行故障转移。

下表从体系结构角度总结了一些问题：

体系结构问题 影响
符合数据驻留 取决于区域选择。 此方法要求选择多个区域来运行工作负荷。 选择与数据驻留要求兼容的区域。
适用区域 许多 Azure 区域 是配对的。 某些 Azure 服务使用配对区域自动复制数据。 如果在 没有对的区域运行工作负载，可能需要使用不同的 方法来复制数据。
同步数据复制

如果实现同步多区域解决方案，应用程序需要等待每个 Azure 区域中的写入操作完成，然后事务才会被视为完成。 等待写入操作产生的延迟取决于区域之间的距离。 对于许多工作负载，区域间延迟会使同步复制太慢而无法发挥作用。

显示部署到多个区域的解决方案的示意图。数据复制同步进行。

下表总结了一些支柱问题：

构成要素 影响
可靠性 可靠性非常高。 该解决方案可灵活应对数据中心、可用性区域或整个区域的中断。 数据始终跨区域同步，因此，即使发生完全区域丢失，数据也可在另一个区域中可用并完成。
成本优化 成本高。 你需要在每个区域中部署单独的资源，并且每个资源会产生部署和维护成本。 跨区域的数据复制也可能会产生高昂的成本。
性能效率 低性能。 应用程序请求需要跨区域流量。 根据区域之间的距离，同步复制可能会给请求增加明显的延迟。
卓越运营 低运营效率。 需要跨多个区域部署和管理资源。 你还负责在发生区域性服务中断期间在区域之间进行故障转移。

下表从体系结构角度总结了一些问题：

体系结构问题 影响
符合数据驻留 取决于区域选择。 此方法要求选择多个区域来运行工作负荷。 选择与数据驻留要求兼容的区域。
适用区域 许多 Azure 区域 是配对的。 某些 Azure 服务使用配对区域自动复制数据。 如果在 没有对的区域运行工作负载，可能需要使用不同的 方法来复制数据。

区域体系结构

设计多区域解决方案时，请考虑计划使用的 Azure 区域是否配对。

即使区域未配对，也可以创建多区域解决方案。 但是，用于实现多区域体系结构的方法可能有所不同。 例如，在 Azure 存储中，可以将异地冗余存储 (GRS) 与配对区域配合使用。 如果 GRS 不可用，请考虑使用 Azure 存储 对象复制等功能，或将应用程序设计为写入多个区域。

合并多区域和多区域方法

如果业务需求需要此类解决方案，则应合并多区域和多区域语句。 例如，可以将区域冗余组件部署到每个区域，并配置区域之间的复制。 对于某些解决方案，此方法提供非常高的可靠性。 但是，配置这种类型的方法可能很复杂，而且这种方法可能很昂贵。

重要

任务关键型工作负载应同时使用多个可用性区域 和 多个区域。 有关设计任务关键型工作负载时应提供的注意事项的详细信息，请参阅 任务关键型工作负载文档。

Azure 服务如何支持部署方法

了解所使用的 Azure 服务的具体详细信息非常重要。 例如，某些 Azure 服务要求你在首次部署资源时配置其可用性区域配置，而其他服务则支持稍后更改部署方法。 同样，某些服务功能可能并非在每一种部署方法中都可用。

若要详细了解每个 Azure 服务要考虑的特定部署选项和方法，请访问 可靠性中心。

示例

本部分介绍一些常见用例，以及每个工作负载通常需要考虑的关键要求。 对于每个工作负载，根据本文所述的要求和方法，提供了一种或多种建议的部署方法。

适用于企业的业务线应用程序

Contoso， Ltd.是一家大型制造公司。 该公司正在实施一个业务线应用程序来管理其财务流程的某些组件。

业务要求：系统管理的信息难以替换，因此需要可靠地保存数据。 架构师说，系统需要尽可能少的停机时间和数据丢失。 Contoso 的员工在整个工作日都使用该系统，因此，高性能对于避免团队成员等待非常重要。 成本也是一个问题，因为财务团队必须支付解决方案的费用。

建议的方法： 跨区域备份的区域冗余部署 提供多层高性能复原能力。

内部应用程序

第四咖啡是一个小企业。 该公司正在开发一个新的内部应用程序，员工可以使用该应用程序提交时间表。

业务要求：对于此工作负载，成本效益是主要考虑因素。 Fourth Coffee 评估了停机对业务的影响，并决定应用程序不需要确定复原能力或性能的优先级。 公司接受 Azure 可用性区域或区域中的中断可能导致应用程序暂时不可用的风险。

建议的方法：

旧版应用程序迁移

Fabrikam， Inc.正在将旧版应用程序从本地数据中心迁移到 Azure。 实现将使用基于虚拟机的 IaaS 方法。 应用程序不是为云环境设计的，应用程序层和数据库之间的通信非常多。

业务要求：性能是此应用程序的重中之重。 复原能力也很重要，即使 Azure 数据中心遇到服务中断，应用程序也必须继续工作。

建议的方法：

医疗保健应用程序

Lamna Healthcare 公司正在 Azure 上实施新的电子健康记录系统。

业务要求：由于此解决方案存储的数据的性质，数据驻留至关重要。 Lamna 在严格的监管框架下运营，该框架规定数据必须保留在特定位置。

建议的方法：

银行系统

Woodgrove Bank 通过部署到 Azure 的大型解决方案运行其核心银行业务。

业务要求：这是一个任务关键型系统。 任何中断都可能会对客户造成重大财务影响。 因此，Woodgrove Bank 的风险承受能力非常低。 系统需要尽可能高的可靠性，并且体系结构需要降低可缓解的任何故障的风险。

建议的方法：对于任务关键型系统，请使用 多区域多区域部署。 确保区域符合公司的数据驻留要求。

软件即服务 (SaaS)

Proseware， Inc.构建了世界各地的公司使用的软件。 该公司的用户群在地理上分布广泛。

业务要求：Proseware 需要允许其每个客户选择离客户近的部署区域。 启用此选择对于延迟和客户的数据驻留要求非常重要。

建议的方法：

下面是多区域和多区域解决方案的一些参考体系结构和示例方案：

许多 Azure 服务提供了有关如何使用多个可用性区域的指南，包括以下示例：

可靠性清单

请参阅完整的一组建议。

可靠性清单