你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关使用可用性区域和区域的建议
适用于此 Azure 架构良好的框架可靠性清单建议：
| RE：05 | 在不同级别添加冗余，尤其是对于关键流。 根据确定的可靠性目标，将冗余应用到计算、数据、网络和其他基础结构层。 |
|---|
本指南介绍了有关确定何时跨可用性区域或区域部署工作负荷的建议。
设计 Azure 解决方案时，需要确定是跨区域中的多个可用性区域部署，还是部署到多个区域。 此决策会影响解决方案的可靠性、成本和性能，以及团队运行解决方案的能力。 本指南提供有关影响决策的关键业务要求、可以考虑的方法、每个方法所涉及的权衡以及每个方法对 Azure 良好架构框架的核心支柱的影响的信息。
决定最适合解决方案的 Azure 区域是一个关键选择。 “ 选择 Azure 区域”指南 介绍了如何在多个地理区域中选择和操作。 选择在解决方案中使用区域和可用性区域的方式也会影响精心构建的框架的多个支柱：
- 可靠性：选择的部署方法可以帮助你缓解各种类型的风险。 一般情况下，通过将工作负荷分散到更地理分散的区域，可以实现更高的复原能力。
- 成本优化：某些体系结构方法需要部署比其他方法更多的资源，这可能会增加资源成本。 其他方法涉及跨地理隔离的可用性区域或区域发送数据，这可能会产生网络流量费用。 此外，请务必考虑管理资源的持续成本，这在具有全面的业务需求时通常更高。
- 性能效率：可用性区域通过高带宽、低延迟的网络链路连接在一起，这足以使大多数工作负荷能够跨区域启用同步复制和通信。 但是，如果工作负荷已经过测试，并且对跨区域的网络延迟敏感，则可能需要考虑在物理上将工作负荷的组件定位在一起，以最大程度地减少通信时的延迟。
- 卓越运营：复杂的体系结构需要花费更多精力来部署、配置和管理。 此外，对于高度可用的解决方案，可能需要计划如何故障转移到一组辅助资源。 故障转移、故障回复和以透明方式重定向流量可能很复杂，尤其是在需要手动步骤时。 最佳做法是自动执行部署和管理过程。 有关详细信息，请参阅卓越运营支柱指南，包括 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 的全球足迹改善用户体验，并使应用程序更接近用户群。 可以使用部署标记模式或地理区域模式，或者跨多个区域复制资源。
即使用户位于不同的地理区域，也要考虑是否需要多区域部署。 考虑是否可以使用全局流量加速（例如 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 App 服务、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 数据中心遇到服务中断，应用程序也必须继续工作。
建议的方法：
- Fabrikan 应首先尝试 区域冗余部署。 它们应验证性能是否满足其要求。
- 如果区域冗余解决方案的性能不可接受，请考虑使用 跨多个可用性区域（区域 DR）的被动部署（固定）部署。
医疗保健应用程序
Lamna Healthcare 公司正在 Azure 上实施新的电子健康记录系统。
业务要求：由于此解决方案存储的数据的性质，数据驻留至关重要。 Lamna 在严格的监管框架下运行，该框架规定数据必须保留在特定位置。
建议的方法：
银行系统
Woodgrove Bank 从部署到 Azure 的大型解决方案运行其核心银行业务。
业务要求：这是一个任务关键型系统。 任何中断都可能导致客户产生重大财务影响。 因此，伍德格罗夫银行的风险容忍度很低。 系统需要可能的最高可靠性级别，体系结构需要缓解任何可缓解的故障的风险。
建议的方法：对于任务关键型系统，请使用 多区域多区域部署。 确保区域符合公司的数据驻留要求。
软件即服务 (SaaS)
Proseware， Inc.构建了全球公司使用的软件。 该公司的用户群在地理上分布广泛。
业务要求：Proseware 需要让每个客户选择靠近客户的部署区域。 启用此选项对于延迟和客户的数据驻留要求非常重要。
建议的方法：
- 多区域多区域部署通常是 SaaS 提供程序的一个不错的选择，尤其是在部署标记模式中使用时。
- 单区域 冗余部署 与全局流量加速解决方案（如 Azure Front Door）结合使用。
相关链接
以下是多区域和多区域解决方案的一些参考体系结构和示例方案：
许多 Azure 服务提供了有关如何使用多个可用性区域的指南，包括以下示例：
可靠性清单
请参阅完整的建议集。
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈