在 Azure 中， 区域 资源是固定到单个区域的资源。 由于区域资源位于单个可用性区域中， 因此它不 具有区域复原能力。 如果包含资源的区域有问题，则资源可能会遇到停机。
某些 Azure 服务需要或允许部署区域资源。 可以选择按区域部署资源，因为延迟注意事项或特定的服务要求。 你甚至可以选择将一组资源固定到单个区域。
本文描述了一些情境，说明为何可能选择部署单区域（单一区域）资源而不是区域冗余资源，同时介绍您在面对区域故障时，如何确保您的解决方案具备弹性的注意事项和责任。
资源部署类型
在 Azure 中，只有某些部署类型提供区域复原能力。 下表显示了三种资源部署类型：它们是否支持区域复原、区域分发、如何配置资源以及建议以供其使用：
| 资源部署类型 | 区域复原支持 | 区域分布 | 配置方式 | 建议 |
|---|---|---|---|---|
| Zone-redundant | 始终具有区域复原能力 | 可用区冗余资源分布在多个可用区，并且能够抵御可用区故障。 如果一个区域中发生故障，服务可以在其他区域中继续运行。 | 某些区域冗余资源跨可用性区域提供自动区域冗余，而另一些资源则要求手动启用区域冗余。 检查服务的 可靠性指南，以了解启用复原能力所需的条件 | 尽可能始终使用区域冗余资源，尤其是在生产部署中。 |
| Zonal | 不自动。 如果你选择启用区域复原，则有责任启用区域复原能力。 区域资源与其他区域中的故障隔离，但自己的区域发生故障可能会导致停机。 |
为资源选择区域。 | 如果有多个资源需要 区域对齐 （放置在同一区域中），则需要 在每个 资源上配置同一区域。 | 仅当需要这样做时，才应使用区域资源。 若要使解决方案区域具有复原能力，你有责任设计和实现多区域解决方案。 |
| 非区域（区域） | None | 如果区域提供可用性区域支持，Azure 可能会使用该区域中的任何区域。 | 没有为非区域资源提供区域配置。 | 由于无法使非区域资源具有区域复原能力，因此请避免对具有可用性区域的区域中的所有生产工作负荷进行非区域部署。 |
有关三种资源部署类型和可用性区域的详细信息，请参阅 什么是可用性区域？
合并区域冗余和区域资源的工作负荷
许多工作负载结合了区域性资源和区域冗余资源。 例如，工作负荷可能包括数据库层的一组区域 VM、Azure 应用服务上托管的区域冗余 Web 服务器，以及一个区域冗余负载均衡器，用于将流量发送到数据库 VM：
将区域和区域冗余资源合并到工作负荷中时，请务必考虑每个资源以及整个解决方案的行为（如果有可用性区域出现问题）。 通常，区域冗余服务会自动从区域中断中恢复，但几乎不会丢失数据，Azure 会管理整个过程。 对于区域资源，您负责配置自动故障转移或执行任何手动恢复活动。 若要了解每个服务在区域关闭方案中的行为方式、了解职责和 Azure 的责任，以及如何监视区域关闭事件的服务的运行状况， 请查看服务的可靠性指南。
何时使用区域部署
仅当需要这样做时，才应使用区域资源。 单区域部署的常见原因是，部署资源必须是区域、特定服务仅在特定区域中可用，或者工作负荷对区域间延迟异常敏感时。
重要
某些 Azure 服务提供区域或区域冗余部署的选项。 如果没有使用区域部署的强烈原因，则应使用区域冗余部署。
需要区域部署的资源
少数 Azure 服务仅支持区域部署，并且不提供区域冗余部署。
虚拟机 是区域资源的示例。 但是，可以使用虚拟机规模集创建虚拟机集。 规模集可以实现区域冗余性，这意味着虚拟机在该集内分布在多个可用区。 规模集是实现许多 VM 工作负载区域弹性的好方法。
小窍门
如果部署多个执行类似函数的 VM，建议使用区域冗余规模集，而不是单独部署的单实例 VM。
某些服务提供仅在特定区域中可用的选项。 例如，某些使用高级 GPU 的 VM 类型可能仅在区域中的特定区域中可用，这意味着不能跨多个区域部署它们。 若要检查哪些区域和区域支持所需的 VM 类型，请使用以下资源：
- 按区域提供的产品 ，用于检查每个区域中可用的 VM 类型。
- 检查 VM SKU 可用性 ，检查特定区域的每个区域中支持的 VM 类型和大小。
如果所需的 VM 类型仅在所用区域中的单个区域中可用，则可能需要考虑对该 VM 进行单个区域的部署，然后找到其他方法来增强 VM 对区域故障的抵御能力。 但是，仍应确保解决方案的其他部分具有区域复原能力。
若要查看哪些服务需要或支持区域部署，请参阅 具有可用性区域支持的 Azure 服务。
区域间延迟
如果你有极其敏感的延迟工作负荷，则可以选择使用区域资源而不是区域冗余资源，即使服务支持区域冗余部署也是如此。
可用性区域由低延迟网络连接，区域间往返延迟通常小于 2 毫秒。 对于大多数工作负荷，区域间延迟并不重要，跨可用性区域分布资源的复原优势明显超过了在区域之间发送流量的微不足道的性能影响。 但是，少数工作负荷对区域间延迟异常敏感。 这些工作负载可能包括：
遗留本地应用程序。 某些旧工作负载可以包含最初为本地环境设计的应用程序。 这些工作负荷假定组件（其他应用程序、数据库和其他服务）并置在同一主机上，或彼此物理相邻。
非常大规模的同步复制。 有时，有状态应用程序和数据库使用 同步复制进行大量写入操作。 同步复制意味着在写入作被视为完成之前将数据写入多个 副本 。 跨可用性区域分发副本可提高复原能力，但在使用同步复制时，区域间延迟可能会增加工作负荷的写入延迟。 大多数情况下，增加的延迟并不重要，但由于某些应用程序的设计方式，额外的延迟有时在大规模上可能会变得有问题。
重要
工作负荷对区域间延迟敏感是不寻常的。 不要假设工作负荷受到影响，除非测试特定工作负荷和需求的延迟。
如果怀疑工作负荷可能受区域间延迟影响，则应按照以下步骤在实际测试环境中测试特定工作负荷的影响：
定义可接受的性能要求。 区域间流量会增加少量延迟，但对于大多数工作负荷来说，这通常并不明显或影响。 请定义 您的 工作负荷可接受的性能。
在单个可用性区域中运行性能测试。 建立一组基线性能指标。
重要
测试实际工作负荷，包括应用程序、协议、配置和 Azure 区域。 使用实际负载。 查看基准或执行综合测试是不够的，因为它们不显示特定解决方案的行为方式。
启用区域间复制。 根据所使用的组件，可以启用区域冗余，或者可以在区域之间移动副本。
重新运行性能测试。 收集之前收集的相同指标。
将性能影响与要求进行比较。 使用要求和性能数据做出有关延迟与区域中断复原之间的权衡的明智决策。
如果测试表明延迟对于您的工作负载不可接受的高，请考虑执行以下措施：
请尝试使用另一组区域。 不同区域之间的延迟可能会略有变化，因为区域可以彼此具有不同的物理距离。
小窍门
如果要跨 Azure 订阅进行测试，请查看 逻辑到物理区域映射 ，以确保测试所需的物理区域集。
如果有另一个 Azure 区域满足数据驻留的总体需求和其他因素，请尝试在该区域中使用多个区域。
请考虑是否可以重新设计应用程序以减少所需的区域间通信量。 例如，你可能能够将多个小型数据库操作整合到一个操作中。 此方法可以减少延迟对工作负荷的影响。
如果没有这些作有帮助，则可以选择使用区域 VM 和其他受支持的 Azure 服务在单个可用性区域中运行特定的工作负荷或组件。 然后，你将负责使区域组件具备弹性以应对区域中断。 请查看本文的其余部分，了解职责和一些要考虑的方法。
你对区域部署的责任
每当其可用性区域遇到中断时，区域资源都面临停机的风险。 在部署区域资源时，您有责任确保您的工作负载能够抵御区域级故障。
重要
区域资源本身不具备抵御区域故障的能力。 必须设计一些方法，以便通过制定包含区域关闭方案的综合计划来缓解区域故障的风险。
部署区域资源时，若要使其具有区域复原能力，需要考虑以下责任：
部署和配置多个资源： 应将单独的区域资源手动部署到不同的区域或区域。 确定如何使配置在每个资源之间保持一致。 最好使用基础结构即代码（IaC）方法，从而帮助你快速部署多个相同的资源。
流量路由和分发。 需要选择一个负载均衡器组件，确保其自身跨区域具有弹性，并将其配置为在不同区域的资源之间分配流量。 通常配置路由策略（例如主动-主动或主动-被动）、自动运行状况检查和故障转移过程。 有关 Azure 中可用的负载均衡服务的详细信息，请参阅 负载均衡选项。
复制或数据备份。 对于任何有状态资源，你有责任保护它们存储的数据，并确保它安全地存储在多个区域中。 通常，您将复制配置到另一个可用性区域中的服务实例。 在某些情况下，你可能会依赖备份数据。 但是，在发生区域故障期间，备份需要更长的恢复时间，这要求你具有更高的恢复时间目标（RTO）。 它们还会导致更多的数据丢失，这需要更高的恢复点目标（RPO）。
区域故障检测和响应过程实现。 你需要确定如何监视区域资源的运行状况，决定何时考虑它们状态不佳，然后触发响应行动，比如在另一个区域或地区恢复操作。
区域恢复过程。 区域恢复后，你负责执行所需的任何恢复操作，例如回切到主区域的资源。
区域部署复原的常见方法
若要做出有关使用区域资源实现区域复原的最佳方法的明智决策，请考虑以下因素：
查看整个工作负荷。 了解每个组件在区域关闭事件中的行为方式，包括区域冗余和区域资源以及任何 非区域资源。 使用 每个服务的可靠性指南 来了解每个服务在区域关闭方案中的工作原理的详细信息，以及如何监视服务运行状况以了解区域关闭事件。
了解区域故障期间可接受的数据丢失。 RPO 限定您能接受的数据丢失量。
许多 Azure 区域冗余资源为区域故障提供零 RPO，这意味着不会发生数据丢失。 它们通常通过跨区域同步复制所有更改来实现此 RPO。
规划区域部署时，需要在区域发生故障时确保满足工作负荷的 RPO 要求。
了解区域故障期间的可允许停机时间。 您的恢复时间目标 (RTO) 指定您可以接受多少停机时间。
Azure 的区域冗余资源通常为区域故障提供非常低的 RTO，通常需要几秒钟的停机时间。
规划区域部署时，需要确保满足工作负荷的 RTO 要求。 如果 RTO 较低，则可能需要依赖于自动检测和恢复过程。 更高的 RTO 为响应过程提供了更大的灵活性。
了解成本。 区域资源通常单独计费，因此部署多个区域资源会增加资源成本。
设计用于复原能力的区域性部署
设计区域部署以实现复原能力时，需要考虑是使用可用性区域来实现 高可用性 还是 灾难恢复。 这两个概念之间的区别取决于 RTO 和 RPO 要求。
如果你有较低的 RTO 和较低的 RPO 要求，则需要将可用性区域视为 高可用性 构造。 但是，如果 RTO 和 RPO 更高，可以选择将可用性区域视为 灾难恢复 构造。 有关这些概念的详细信息，请参阅什么是业务连续性、高可用性和灾难恢复？ 工作负荷层可帮助你确定要求和必要措施。
为高可用性而设计
请考虑跨多个区域部署自己的高可用性体系结构。 高度可用的体系结构要求跨多个区域部署的组件进行自动和频繁的数据复制，并在发生区域故障时在这些组件之间实现自动故障转移。
在区域 VM 上部署的某些应用程序提供内置的高可用性支持，例如，可识别副本。 例如，如果在 Azure VM 上使用 SQL Server， 可用性组 将提供流量路由和故障转移功能。 可以选择是使用同步复制还是异步复制。 有关详细信息，请参阅 Azure VM 上的 SQL Server 业务连续性和 HADR。
灾难恢复设计
灾难恢复不同于高可用性，因为在灾难方案中，可以容忍更多的停机时间和数据丢失。 RTO 和 RPO 通常以小时或更长时间进行度量。
灾难恢复计划可帮助你规划可能遇到的不同情况，以及你希望如何使用自动化和手动过程的组合来响应它们。
规划区域部署时，以下灾难恢复方法可以帮助：
Azure Site Recovery 区域到区域灾难恢复： 当需要不同区域中 VM 之间的磁盘级异步复制时，此方法非常有用。 有关详细信息，请参阅 在可用性区域之间启用 Azure VM 灾难恢复。
Azure Site Recovery 区域到区域灾难恢复： Azure Site Recovery 支持区域到区域灾难恢复，并依赖于异步复制。 此方法使你能够将故障转移到另一个 Azure 区域的某个区域，而不是转移到主要区域的另一个区域。 有关详细信息，请参阅 将 Azure VM 复制到另一个 Azure 区域。
基于备份的灾难恢复： 如果解决方案可以容忍较高的 RTO 和高 RPO，则可以考虑将备份用作灾难恢复策略。 如果区域遇到服务中断，则可以将备份还原到另一个区域或区域。 还需要考虑是在解决方案中预先创建其他 Azure 资源，还是在故障转移过程中创建它们。
在区域体系结构中，通常负责存储和复制这些备份。
Azure 备份是提供托管备份的常用服务。 它支持区域冗余备份，以及在配对的 Azure 区域中进行地理复制的备份。 有关详细信息，请参阅什么是 Azure 备份服务？ 某些应用程序提供内置备份功能。 例如， Azure VM 上的 SQL Server 提供了一系列备份功能。
有关可以考虑的其他方法的详细信息，请参阅 有关在 Azure Well-Architected Framework 中使用可用性区域和区域的建议。