若要使应用程序能够更灵活地应对与区域相关的硬件故障、网络中断和自然灾害，请务必设计 Azure 工作负载，使其具有区域复原能力。 在区域中跨多个可用性区域分配资源时，可以降低影响关键服务的单区域中断的风险。
尽管最佳做法是在初始规划和部署工作负荷期间解决区域复原问题，但通常希望将现有的非复原工作负荷转换为区域复原配置。 一般情况下，为现有工作负荷启用区域复原的处理非常简单，Azure 将继续简化该过程。 但是，对工作负荷所做的任何更改都可能会带来大量风险。 了解所涉及的风险后，你将能够评估并确定这些工作负荷中的哪些工作负载和服务对业务至关重要，然后首先将区域复原能力应用于影响最大的资源。
本文概述了在 Azure 工作负荷中启用区域复原的关键注意事项。 它还有助于规划和实施成功过渡到更具弹性的体系结构。
小窍门
如果目前正在设计工作负荷或计划对当前工作负荷进行设计评审，请务必遵循 有关在 Azure Well-Architected 框架（WAF）中设计冗余的建议。 Web应用程序防火墙(WAF)建议指南可帮助你在多个层面设计工作负荷冗余，特别关注关键工作流程。 为了支持可用性区域采用，它还概述了多区域部署和部署标记等策略。
什么是区域复原能力？
Azure 服务可以通过两种主要方式实现针对可用性区域中断情况的复原能力：
区域冗余服务： 许多 Azure 服务支持区域冗余。 这些服务会在可用性区域之间自动复制数据，分发传入请求，并在区域故障期间故障转移到不同的区域。 每个服务都以对特定服务有意义的方式支持这些功能。 某些服务默认为区域冗余，而其他服务可能需要配置区域冗余。
区域服务： 某些 Azure 服务是区域性服务，这意味着它们可以固定到特定的可用性区域。 若要使用区域服务实现区域复原，请在多个可用性区域中部署服务的独立实例。 你可能还需要管理流量分布、数据复制以及实例之间的故障转移。
某些服务可以部署在区域冗余配置或区域性配置中。 在大多数情况下，最好在可以时部署区域冗余服务。
有关详细信息，请参阅 可用性区域支持类型。
区域启用过程
使用以下步骤系统地查看 Azure 工作负荷，确定区域复原优先级，并为每个组件启用区域复原能力。
先决条件
在开始之前，请执行以下操作：
标识每个工作负荷。 工作负荷是指应用程序资源、数据和支持基础结构的集合，它们协同工作以实现定义的业务成果。 有关工作负荷以及如何定义它们的详细信息，请参阅 Well-Architected 框架工作负载。
确定每个工作负荷的用户和系统流的优先级。 了解工作负荷的关键路径和依赖项，以确定要首先让区域复原的组件。 有关如何使用关键流分析确定工作流优先级的详细信息，请参阅 确定工作负荷的优先级以获取区域复原能力。
为每个工作负荷和流分配重要性分级。 此分级可帮助你了解潜在中断对业务的影响，并指导你决定哪些工作负荷优先用于区域复原。 此外，请考虑重新配置工作负荷时可接受的停机时间。
可以使用分类根据工作负荷的关键性对工作负荷进行分类。 此方法可帮助你将精力集中在最重要的服务上。
请考虑以下示例分类，对工作负荷进行分类。
工作负荷类型 Description 中断的影响 任务关键型 必须高度可靠、始终可用、可复原故障和可作的关键流和工作负荷 对基本功能的任何中断都会立即造成灾难性的业务损害，或给人类生命带来风险。 业务关键型 运行重要业务功能的基本流和工作负载 中断可能会造成一些财务损失或品牌损失。 业务运营 提高业务运营效率，但对客户不直接提供服务 可以容忍某种级别的中断。 行政 内部生产流和工作负载与业务运营不一致 可以容忍中断。 有关如何根据关键性分级对工作负荷进行分类的详细信息，请参阅 为每个流分配关键性分级。
验证 Azure 资源所在的区域是否支持可用性区域。 请参阅 Azure 区域列表。 如果某个区域不支持可用性区域，请考虑将资源重新定位到某个区域。 有关详细信息，请参阅 跨资源组、订阅或区域移动 Azure 资源。
步骤 1：确定 Azure 服务的区域复原优先级
确定哪些工作负荷流对业务至关重要后，可以专注于这些流所依赖的 Azure 服务。 某些 Azure 服务比其他服务对应用程序更为重要。 确定这些服务的优先级，以帮助确保应用程序在发生区域故障时保持可用且具有复原能力。
根据 Azure 服务组对工作负荷的关键性，使用以下指南确定 Azure 服务组的优先级。 确定区域复原服务优先级时，请考虑特定的应用程序体系结构和业务需求。
从网络服务开始。 工作负荷倾向于共享网络服务，因此这些服务的复原能力增加可以同时提高多个工作负荷的复原能力。
许多核心网络服务都是区域冗余的，但应该专注于 Azure ExpressRoute 网关、Azure VPN 网关、Azure 应用程序网关、Azure 负载均衡器和 Azure 防火墙等组件。
提高运行数据存储的韧性。 作数据存储包含多个工作负荷经常使用的宝贵数据，因此提高这些数据存储的可用性可以帮助许多工作负荷。
若要实现作数据存储复原，请专注于 Azure SQL 数据库、Azure SQL 托管实例、Azure 存储、Azure Data Lake Storage、Azure Cosmos DB、Azure PostgreSQL 灵活服务器、Azure MySQL 灵活服务器和 Azure Redis 缓存等服务。
确定计算服务的优先级。 这些服务通常很容易在区域之间复制和分发，因为它们是无状态的。
计算服务包括 Azure 虚拟机、Azure 虚拟机规模集、Azure Kubernetes 服务（AKS）、Azure 应用服务、应用服务环境、Azure Functions、Azure Service Fabric 和 Azure 容器应用。
查看关键流使用的剩余业务关键型资源。 这些资源可能不如前面列出的资源那么重要，但它们仍然在应用程序的功能中扮演角色，你应考虑它们进行区域复原。
查看您企业运营资源的其他部分。 做出有关是否使其区域复原的明智决策。 此评审包括可能与关键工作负荷不直接相关的服务，但仍有助于整体应用程序性能和可靠性。
步骤 2：评估区域配置方法
在您确定工作负荷和 Azure 服务的优先级之后，请识别为每个服务启用可用性区域支持所需的方法，并了解配置区域可靠性所需执行的操作。
每个 Azure 可靠性服务指南都提供了一个部分，介绍如何为该服务启用区域复原能力。 本部分可帮助你了解使每个服务区域具有复原能力所需的工作量，以便可以相应地规划策略。 有关特定服务的详细信息，请参阅 Azure 可靠性服务指南。
使用 区域配置表 快速了解常见 Azure 服务的方法。
重要
如果工作负载包括部署在单个区域配置中的组件，请计划增强这些组件以抵御区域故障。 一种常见方法是将单独的实例部署到另一个可用性区域，并在必要时在它们之间切换。
步骤 3：测试延迟
使工作负荷区域具有复原能力时，请考虑可用性区域之间的延迟。 有时，某些旧系统不能容忍跨区域流量引入的少量额外延迟，尤其是在数据层中启用同步复制时。 如果怀疑跨区域延迟可能会影响工作负荷，请在启用区域复原之前和之后运行测试。
Azure 服务的区域配置方法
每个 Azure 服务都提供特定类型的可用性区域支持，该支持基于服务的预期用途和内部体系结构。 如果你的资源未配置为使用可用性区域（或 非区域 资源），则可能需要使用可用性区域支持重新配置它。 该服务的可靠性指南提供了指向可用性区域配置说明的指导或链接。
本部分概述了不同类型的区域配置方法，以及每个服务支持的方法。
重要
在资源上启用 区域冗余 时，该资源会自动具有抵抗区域故障的能力。 使用 区域 配置将资源固定到特定可用性区域时，资源不会自动区域冗余。 必须使其具备抵抗区域故障的能力。 对于分区服务，本文反映了定位到区域的复杂性和成本。 有关实现区域复原的额外步骤的详细信息，请参阅 服务的可靠性指南。
区域配置表列出了许多 Azure 服务支持的区域配置方法，并包含指向该服务的每个可靠性指南的链接。 可靠性指南提供有关如何配置非区域服务资源以启用可用性区域支持的信息。
下表描述了每个区域配置方法，包括启用可用性区域所需的工作量和停机时间。
| 方法 | Description | 典型工作量级别 | 可能需要停机 |
|---|---|---|---|
| 始终具有区域间复原能力 | 服务在默认情况下，在支持可用性区域的地区具有区域复原能力。 无需执行任何操作。 | None | 否 |
| 启用 | 所需的最小配置更改，例如在设置中启用区域冗余。 此过程不会影响可用性，但请考虑对成本或性能的影响。 | Low | 否 |
| 修改 | 可能需要一些配置更改，例如重新部署依赖资源或修改网络设置。 | 中等 | 是的 |
| 重新部署 | 需要进行重大更改，例如重新部署整个资源、应用程序或服务，或将数据迁移到新服务。 | High | 是的 |
了解为服务启用可用性区域支持的成本。 对于许多服务，启用可用性区域不会增加成本。 但某些服务需要特定层、特定数量的容量单位或两者。 使用可用性区域时，其他服务会收取不同的费率。 下一部分的表列出了每个服务的典型成本影响。
注释
本文中的信息总结了启用可用性区域支持的典型方法，并概述了典型的成本影响。 但一些因素可能会影响它适用于特定解决方案的方式。 例如，某些服务被列为 始终具有区域复原能力，但此指定仅适用于特定区域或服务的特定层。 将这些表用作起点，但查看提到的其他资源以了解特定详细信息。
按区域配置方法划分的 Azure 服务
下表总结了许多 Azure 服务的可用性区域支持，并提供一种方法，包括成本影响，以便为每个服务启用可用性区域支持。
| 服务 | 可以是区域冗余的 | 可以是区域性的 | 典型的区域配置方法 | 典型的成本影响 |
|---|---|---|---|---|
| Azure AI 搜索 |
|
始终具有区域间复原能力 | N/A | |
| Azure API 管理 |
|
|
修改 | 最低所需等级 |
| Azure 应用配置 |
|
始终具有区域间复原能力 | N/A | |
| Azure 应用程序服务 |
|
启用 | 所需的最低层级和实例数量 | |
| Azure 应用服务 - 应用服务环境 |
|
启用 | 所需的最少实例数量 | |
| Azure 应用程序网关 |
|
|
始终具有区域间复原能力 | N/A |
| Azure 备份 |
|
重新部署 | 适度增加成本 | |
| Azure Batch |
|
重新部署 | 不会对相同数量的虚拟机（VM）产生任何成本影响 | |
| Azure Blob 存储服务 |
|
启用 | 适度增加成本 | |
| Azure Cache for Redis - 企业版 |
|
重新部署 | 无成本影响 | |
| Azure Cache for Redis - 标准版和高级版 |
|
启用 | 最低所需等级 | |
| Azure 容器应用 |
|
重新部署 | 所需的最低副本数量 | |
| Azure 容器注册表 |
|
始终具有区域间复原能力 | N/A | |
| 用于 NoSQL 的 Azure Cosmos DB |
|
修改 | 如果使用自动缩放或多区域写入，则为无。 | |
| Azure 数据工厂 |
|
始终具有区域间复原能力 | N/A | |
| Azure Data Lake Storage |
|
启用 | 适度增加成本 | |
| Azure Database for MySQL - 灵活配置服务器 |
|
重新部署 | 需要主实例和高可用性 (HA) 实例 | |
| Azure Database for PostgreSQL-“灵活服务器” |
|
启用 | 需要主实例和 HA 实例 | |
| Azure 磁盘存储（托管磁盘） |
|
|
启用 | 适度增加成本 |
| Azure 事件中心：所有其他层 |
|
始终具有区域间复原能力 | N/A | |
| Azure ExpressRoute |
|
|
修改 | 取决于级别 |
| Azure 文件 |
|
启用 | 适度增加成本 | |
| Azure 防火墙 |
|
|
修改 | 无成本影响 |
| Azure Functions |
|
重新部署 | 所需的最低层级和实例数量 | |
| Azure Key Vault |
|
始终具有区域间复原能力 | N/A | |
| Azure Kubernetes 服务 (AKS) |
|
重新部署 | 无成本影响 | |
| Azure 负载均衡器 |
|
|
修改 | 无成本影响 |
| Azure 逻辑应用 - 消耗层 |
|
始终具有区域间复原能力 | N/A | |
| Azure 逻辑应用 - 标准层 |
|
重新部署 | 所需的最低层级和实例数量 | |
| Azure 托管 Grafana |
|
重新部署 | 适度增加成本 | |
| Azure 队列存储 |
|
启用 | 适度增加成本 | |
| Azure 服务总线 |
|
始终具有区域间复原能力 | N/A | |
| Azure Service Fabric |
|
|
重新部署 | 不会对相同数量的 VM 产生任何成本影响 |
| Azure Site Recovery |
|
重新部署 | Site Recovery 不会对成本造成影响，副本存储的成本会适中增加 | |
| Azure SQL 数据库：业务关键层 |
|
启用 | 无成本影响 | |
| Azure SQL 数据库：常规用途层 |
|
启用 | 适度增加成本 | |
| Azure SQL 数据库：超大规模层 |
|
重新部署 | 所需的最低副本数量 | |
| Azure SQL 数据库：高级层 |
|
启用 | 无成本影响 | |
| Azure SQL 托管实例 |
|
启用 | 适度增加成本 | |
| Azure 表存储 |
|
启用 | 适度增加成本 | |
| Azure 虚拟机规模集 |
|
|
重新部署 | 不会对相同数量的 VM 产生任何成本影响 |
| Azure 虚拟机 |
|
重新部署 | 不会对相同数量的 VM 产生任何成本影响 | |
| Azure 虚拟网络 |
|
始终具有区域间复原能力 | N/A | |
| 公共 IP 地址 |
|
|
始终具有区域间复原能力 | N/A |