使用可用性区域和区域的体系结构策略

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

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

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

• 可靠性： 部署方法可帮助你缓解各种类型的风险。 一般情况下，通过将工作负荷分散到更地理分散的区域，可以实现更高的复原能力。

• 成本优化： 某些体系结构方法要求部署的资源比其他方法多，这会增加资源成本。 其他方法涉及跨地理隔离的可用性区域或区域发送数据，这可能会产生网络流量费用。 此外，请务必考虑管理资源的持续成本，这在具有全面的业务需求时通常更高。

• 性能效率： 可用性区域通过高带宽、低延迟的网络链路连接在一起。 此链接足以让大多数工作负荷跨区域启用同步复制和通信。 但是，如果你测试工作负荷并确定它对跨区域的网络延迟很敏感，则可能需要考虑将工作负荷的组件物理定位在一起，以最大程度地减少通信时的延迟。

• 卓越运营： 复杂的体系结构需要花费更多精力来部署、配置和管理。 对于高度可用的解决方案，可能还需要计划如何故障转移到一组辅助资源。 故障转移、故障回复和以透明方式重定向流量可能很复杂，尤其是在需要手动步骤时。 最佳做法是自动执行部署和管理过程。 有关详细信息，请参阅卓越运营支柱指南，包括 OE：05 基础结构即代码、 OE：09 任务自动化、 OE：10 自动化设计和OE：11 部署实践。

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

定义

了解如何在 Azure 中组织区域和可用性区域

Azure 在世界各地有许多数据中心。 Azure 区域 是包含一组数据中心的地理外围。 需要完全了解 Azure 区域和可用性区域。

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

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

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

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

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

• 区域资源 固定到特定的可用性区域。 可以跨不同区域合并多个区域部署以满足较高的可靠性要求。 你负责跨区域管理数据复制和分发请求。 如果在单个可用性区域中发生中断，则需负责故障转移到另一个可用性区域。

• 区域冗余资源 分布在多个可用性区域。 Microsoft管理请求的分布以及跨区域复制数据。 如果在单个可用性区域中发生中断，Microsoft会自动管理故障转移。

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

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

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

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

了解共同的责任

共同责任原则描述了云提供商和你之间的责任划分方式。 根据你使用的服务类型，你可能需要承担或多或少的运营服务的责任。

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

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

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

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

风险容忍度

不同的组织具有不同程度的风险容忍度。 即使在单个组织中，风险容忍度也通常因工作负荷而异。 大多数工作负荷不需要极其高可用性。 但是，某些工作负荷非常关键，因此值得缓解甚至不太可能的风险，例如影响大地理区域的重大自然灾害。

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

它非常适合用于缓解每个工作负荷的每个可能的风险。 但是，这种方法并不实用或经济高效。 请务必与业务利益干系人进行公开讨论，以便你可以就应缓解的风险做出明智的决策。

复原要求

请务必了解工作负荷的复原要求，包括恢复时间目标（RTO）和恢复点目标（RPO）。 这些目标可帮助你确定排除哪些方法。如果没有明确的要求，则无法就要遵循的方法做出明智的决定。 有关详细信息，请参阅 用于标识和分级流的体系结构策略。

服务级别目标

你应该了解解决方案的预期运行时间服务级别目标（SLO）。 例如，你的解决方案可能需要满足 99.9% 运行时间的业务要求。

Azure 为每个服务提供服务级别协议（SLA）。 SLA 指示应从服务期望的运行时间级别，以及实现预期 SLA 所需的条件。 但是，请记住，Azure SLA 定义服务可用性的方式可能并不总是与评估工作负荷运行状况的方式保持一致。

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

数据驻留

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

用户位置

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

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

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

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

预算

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

复杂性

最好避免解决方案体系结构中不必要的复杂性。 引入的复杂性越复杂，对体系结构做出决策就越困难。 复杂的体系结构更难作，更难保护，而且性能较低。 确保遵循 简单性原则。

示例方案

通过提供区域和可用性区域，Azure 允许你选择符合需求的部署方法。 每个方法提供特定的优势并产生相关的成本。

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

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

可通过多种方式部署此解决方案。 每个方法提供一组不同的优势，并产生不同的成本。 在高级别上，可以考虑本地冗余、区域冗余或多区域部署。 下表总结了一些支柱问题。

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

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

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

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

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

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

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

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

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

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

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

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

• 恢复点： 备份频率确定可能会遇到的数据丢失量，这称为 恢复点。 通常可以控制备份的频率，以便满足 RPO。

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

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

部署方法 2：区域（固定）部署

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

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

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

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

• 需要将资源部署到每个可用性区域，并单独配置和管理这些资源。

• 需要确定如何在可用性区域之间复制数据，然后配置和管理复制。

• 你负责将请求分发到正确的资源，例如使用负载均衡器。 需要确保负载均衡器满足复原能力要求。 还需要确定是使用主动-被动还是主动-主动请求分发模型。

• 如果可用性区域遇到服务中断，则需要处理故障转移，以将流量发送到另一个可用性区域中的资源。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 恢复点： 备份频率确定可能会遇到的数据丢失量，称为 恢复点。 通常可以控制备份的频率以满足 RPO。

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

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

部署方法 4：多区域部署

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

主动和被动区域

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

数据复制

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

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

异步数据复制

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

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

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

同步数据复制

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

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

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

区域体系结构

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

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

合并多区域和多区域方法

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

Azure 服务如何支持部署方法

请务必了解所使用的 Azure 服务的特定详细信息。 例如，某些 Azure 服务要求你在首次部署资源时设置其可用性区域配置，而其他服务则支持稍后更改部署方法。 同样，某些服务功能可能不适用于每个部署方法。

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

用例示例

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

企业的业务线应用程序

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

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

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

内部应用程序

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

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

建议的方法：

• 跨区域备份的本地冗余部署 成本最低，但也存在重大风险。

• 跨区域备份的区域冗余部署 提供更好的复原能力，但成本略高。

旧版应用程序迁移

Fabrikam， Inc.正在将旧版应用程序从本地数据中心迁移到 Azure。 他们计划使用基于 VM 的 IaaS 方法。 应用程序不是针对云环境设计的，应用程序层与数据库之间的通信非常 闲聊。

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

建议的方法：

• Fabrikam 应首先尝试 区域冗余部署。 它们应验证性能是否符合其要求。

• 如果区域冗余解决方案的性能不可接受，他们应考虑使用 跨多个可用性区域（区域 DR）的被动部署（固定）部署。

医疗保健应用程序

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

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

建议的方法：

• 多区域多区域部署（如果有多个区域符合 Lamna 的数据驻留要求）。

• 如果只有一个符合其需求的区域，他们应考虑 使用区域冗余部署 或 跨区域备份的区域冗余部署 ，这些区域提供单区域解决方案。

银行系统

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

业务要求： 此系统至关重要。 任何中断都可能导致客户产生重大财务影响。 因此，伍德格罗夫银行的风险容忍度很低。 系统需要可能的最高可靠性级别，体系结构需要缓解任何可缓解的故障的风险。

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

软件即服务

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

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

建议的方法：

• 多区域多区域部署 通常是软件即服务（SaaS）提供商的最佳选择，尤其是在 部署戳模式中使用时。

• 使用全局流量加速解决方案（例如 Azure Front Door）的单区域冗余部署。

后续步骤

以下参考体系结构和示例方案适用于多区域和多区域解决方案：

• 基线高度可用的区域冗余 Web 应用程序
• 高度可用的多区域 Web 应用程序
• 多区域 N 层应用程序
• 为高可用性和 DR 构建的多层 Web 应用程序

使用以下 Azure 服务跨多个可用性区域实现解决方案：

• Azure Site Recovery：在可用性区域之间启用 Azure VM DR
• Azure NetApp 文件：了解 Azure NetApp 文件的跨区域复制
• Azure 存储冗余