你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 应用程序服务
Azure Front Door
将Azure App 服务 Web 应用部署到由于灾难或中断而变得不可用的单个区域时，将面临应用程序不可用的风险。 为了确保应用程序在区域不可用时继续可用，可以实现多区域体系结构。 使用多区域体系结构，可以在次要 Azure 区域中创建相同的部署。 使用次要区域部署，可以复制数据以恢复最后一个应用程序状态;还可以复制其他解决方案组件。
本文介绍三种通常用于App 服务和App 服务环境的多区域体系结构方法。
要考虑的方法
业务连续性计划受两个关键指标的影响：
- 恢复时间目标（RTO），这是灾难期间的最大可容忍停机时间。
- 恢复点目标 （RPO），这是灾难期间可容忍的最大数据丢失。
有关 RTO 和 RPO 等恢复目标的详细信息，请参阅有关定义可靠性目标的恢复目标和建议。
借助 Azure 平台，可以采用不同的方式设计多区域应用程序解决方案。 本文介绍支持不同 RTO 和 RPO 要求的体系结构，并具有其他成本权衡和复杂性：
| 指标 | 主动-主动 | 主动-被动 | 被动/冷 |
|---|---|---|---|
| 反向收购 | 实时或秒 | 分钟数 | 小时 |
| RPO | 实时或秒 | 分钟数 | 小时 |
| 成本 | $$$ | $$ | $ |
| 方案 | 关键任务应用 | 高优先级应用 | 低优先级应用 |
| 能够为多区域用户流量提供服务 | 是 | 否 | 否 |
| 代码部署 | 首选的 CI/CD 管道 | 首选的 CI/CD 管道 | 备份和还原 |
| 在故障期间创建新的 Azure 应用服务资源 | 不是必需 | 不是必需 | 必须 |
虽然此处所述的三种方法很常见，但它们并不是在 Azure 中实现多区域解决方案的唯一方法。 根据自己的要求调整解决方案。
注意
应用程序很可能依赖于 Azure 中的其他服务，例如Azure SQL 数据库、Azure 存储帐户和消息队列。 设计灾难恢复策略时，还需要考虑其中每个依赖的 Azure 服务。
若要详细了解 Azure 服务的多区域解决方案，请参阅 Azure 服务可靠性指南。
监视
请务必为 Web 应用配置监视和警报，以便团队在区域故障期间及时收到通知。 Azure 应用程序 Insights 可用性测试提供了监视应用程序可用性的方法。 有关详细信息，请参阅 Application Insights 可用性测试。
部署
部署和配置多区域解决方案可能比较复杂。 重要的是，每个区域中的实例保持同步。
若要管理 azure 资源的部署和配置（如App 服务），请使用基础结构即代码（IaC）机制。 在跨多个区域的复杂部署中，若要独立管理区域并以可靠方式使配置跨区域保持同步，需要一个可预测、可测试和可重复的流程。 请考虑使用 IaC 工具，例如 Bicep、Azure 资源管理器 模板或 Terraform。
还应将 CI/CD 管道配置为部署代码，包括使用多个区域时。 请考虑使用 Azure Pipelines 或 GitHub Actions。 有关详细信息，请参阅持续部署到 Azure 应用服务。
主动-主动体系结构
在主动-主动体系结构中，相同的 Web 应用部署在两个单独的区域中。 Azure Front Door 用于将流量路由到这两个活动区域：
每个区域的App 服务应用程序使用相同的配置，包括定价层和实例计数。
在正常操作期间，将阻止定向到App 服务应用的公共流量。 流量通过 Azure Front Door 路由到这两个活动区域。 此方法可帮助你确保 Azure Front Door Web 应用程序防火墙（WAF）检查请求，或者以其他方式进行集中保护或管理请求。
在区域故障期间，如果其中一个区域处于脱机状态，Azure Front Door 运行状况探测将检测故障源并重新配置路由，以便将流量专门发送到保持联机的区域。
在故障区域恢复（故障回复）期间，Azure Front Door 运行状况探测会检测正常的源并还原正常的流量路由。
建议
若要满足应用程序内容的零 RPO，请使用 CI/CD 解决方案将应用程序文件部署到这两个 Web 应用。
在可能的情况下，将应用程序状态存储在App 服务文件系统之外，例如在数据库或Azure 存储中。 配置这些组件以满足异地冗余要求。
提示
如果应用程序主动修改文件系统，并且App 服务应用区域具有配对区域，可以通过写入已装载的Azure 存储共享而不是直接写入 Web 应用的 /home 内容共享来减少文件系统的 RPO。 然后，将 Azure 存储冗余功能（GZRS 或 GRS）用于装载式共享，其 RPO 约为 15 分钟。
注意事项
低 RTO： 在此类异地故障转移期间，RTO 取决于运行状况探测检测到故障区域的频率。 默认情况下，探测每 30 秒检查一次，但 可以配置不同的探测频率。
负载均衡和故障转移： 此方法使用 Azure Front Door 进行全局负载均衡、流量分发和故障转移。 Azure 提供其他负载均衡选项，例如Azure 流量管理器。 有关各种选项的比较，请参阅负载均衡选项 - Azure 体系结构中心。
部署主动-主动App 服务 Web 应用
按照以下步骤使用 App 服务为 Web 应用创建主动-主动方法：
在两个不同的 Azure 区域中创建两个应用服务计划。 同样配置两个App 服务计划。
创建 Web 应用的两个实例，每个应用服务计划中一个实例。
创建 Azure Front Door 配置文件，具体要求如下：
- 一个终结点。
- 具有两个源的源组，每个源的优先级为 1。 相同的优先级值指示 Azure Front Door 将流量路由到这两个区域中的应用程序（主动-主动）。
- 路由。
设置和配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。
通过持续部署将代码部署到这两个 Web 应用。
在Azure App 服务教程中创建高度可用的多区域应用介绍了如何设置主动-被动体系结构。 若要部署主动-主动方法，请遵循相同的步骤，但有一个例外：在 Azure Front Door 中，将源组中的两个源配置为优先级为 1。
主动-被动体系结构
在主动-被动体系结构中，相同的 Web 应用部署在两个单独的区域中。 Azure Front Door 用于仅将流量路由到一个区域（ 活动 区域）。
在正常操作期间，Azure Front Door 仅将流量路由到主要区域。 阻止直接发送到应用服务应用的公共流量。
在区域故障期间，如果主要区域变为非活动状态，Azure Front Door 运行状况探测将检测故障源，并开始将流量路由到次要区域中的源。 然后，次要区域将成为活动区域。 次要区域变为活动区域后，网络负载会触发预配置的自动缩放规则来横向扩展辅助 Web 应用。
在故障区域恢复（故障回复）期间，Azure Front Door 会自动将流量定向回主要区域，体系结构将恢复为主动-被动。
注意
如果次要区域还没有作为活动区域运行所需的功能，则可能需要手动纵向扩展定价层。 例如，自动缩放需要标准层或更高版本。
建议
若要满足应用程序内容的零 RPO，请使用 CI/CD 解决方案将应用程序文件部署到这两个 Web 应用。
在可能的情况下，将应用程序状态存储在App 服务文件系统之外，例如在数据库或Azure 存储中。 配置这些组件以满足异地冗余要求。
提示
如果应用程序主动修改文件系统，并且App 服务应用区域具有配对区域，可以通过写入已装载的Azure 存储共享而不是直接写入 Web 应用的 /home 内容共享来减少文件系统的 RPO。 然后，将 Azure 存储冗余功能（GZRS 或 GRS）用于装载式共享，其 RPO 约为 15 分钟。
注意事项
成本控制：相同的App 服务应用部署在两个单独的区域中。 为了节省成本，辅助应用服务计划配置为包含更少的实例和/或位于较低的定价层中。 有以下三个可能的方式：
首选：辅助App 服务计划与主要计划具有相同数量的实例或更少定价层。 此方法可确保两个应用服务计划的功能和虚拟机大小奇偶校验。 异地故障转移期间的 RTO 仅取决于横向扩展实例的时间。
不太首选：辅助App 服务计划具有相同的定价层类型（例如 PremiumV3），但 VM 大小较小，实例较少。 例如，主要区域可能位于 P3V3 层，而次要区域位于 P1V3 层。 此方法仍可确保两个应用服务计划的功能奇偶校验，但当次要区域成为活动区域时，由于缺少大小奇偶校验，可能需要手动纵向扩展。 异地故障转移期间的 RTO 同时取决于横向扩展和纵向扩展实例的时间。
最不首选：辅助App 服务计划具有不同于主实例和较小实例的定价层。 例如，主要区域可能位于 P3V3 层，而次要区域位于 S1 层。 确保辅助应用服务计划具有应用程序运行所需的所有功能。 两者之间的功能可用性差异可能会导致 Web 应用恢复延迟。 异地故障转移期间的 RTO 同时取决于横向扩展和纵向扩展实例的时间。
应在次要区域中配置自动缩放 ，以防流量被重定向，并且请求突然涌入。 建议在主动和被动区域中都制定类似的自动缩放规则。
负载均衡和故障转移： 此方法使用 Azure Front Door 进行全局负载均衡、流量分发和故障转移。 Azure 提供其他负载均衡选项，例如Azure 流量管理器。 有关各种选项的比较，请参阅负载均衡选项 - Azure 体系结构中心。
部署主动-被动App 服务 Web 应用
按照以下步骤使用 App 服务为 Web 应用创建主动-被动方法：
在两个不同的 Azure 区域中创建两个应用服务计划。 可以使用前面提到的方法之一预配辅助应用服务计划。
为辅助应用服务计划配置自动缩放规则，以便在主要区域变为非活动状态时，该计划缩放到与主要计划相同的实例计数。
创建 Web 应用的两个实例，每个应用服务计划中一个实例。
创建 Azure Front Door 配置文件，具体要求如下：
一个终结点。
具有两个源的源组：
- 主要区域中应用程序的优先级为 1 的源。
- 次要区域中应用程序的优先级为 2 的第二个源。
优先级的差异告诉 Azure Front Door 在联机时首选主要区域（因此为主动-被动）。
路由。
设置和配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。
通过持续部署将代码部署到这两个 Web 应用。
教程：在 Azure 应用服务中创建高度可用的多区域应用，演示如何设置主动-被动体系结构。
被动-冷体系结构
在被动/冷体系结构中，Web 应用将部署到单个主要区域。 应用程序文件和某些数据库将备份到Azure 存储帐户中。 备份将复制到另一个区域。 如果主要区域不可用，请手动将另一个应用部署到第二个区域并从备份还原。
注意
被动冷方法依赖于在发生区域故障期间进行手动干预，通常会导致重大停机和数据丢失。 对于大多数生产级解决方案，应考虑主动-主动或主动-被动解决方案。
跨区域复制
此方法使用App 服务备份定期将 Web 应用备份到同一区域中Azure 存储帐户。 通过配置存储帐户来配置备份的跨区域复制。
用于配置跨区域复制的方法取决于区域是否具有对。 有关详细信息，请参阅 具有可用性区域的 Azure 配对区域 和 区域，以及没有区域对。
使用 RA-GZRS 复制（如果可用）。 RA-GZRS 在区域中提供同步区域冗余，并在次要区域中提供异步。 它还在次要区域中提供只读访问权限，这对于确保存储帐户的主要区域不可用时可以检索备份至关重要。
如果 RA-GZRS 不可用，请将帐户配置为 RA-GRS。
RA-GZRS 和 RA-GRS 的 RPO 约为 15 分钟。
有关设计应用程序以利用异地冗余存储的详细信息，请参阅 使用异地冗余设计高度可用的应用程序。
区域关闭体验
如果主要区域不可用，则必须检测区域丢失。 有关详细信息，请参阅 “监视”。
若要准备次要区域以接收流量，请使用次要区域中Azure 存储帐户中的备份部署所有必需的App 服务资源和从属资源。
注意事项
高 RTO： 由于此过程需要手动检测和响应，因此此方案的 RTO 可能为小时甚至数天。 若要最大程度地减少 RTO，请生成并测试全面的 playbook，概述将 Web 应用备份还原到另一个 Azure 区域所需的所有步骤。
即使在次要区域中创建应用程序后，也可能需要处理 DNS 记录和 TLS 证书等复杂性。 确保已计划将流量发送到次要区域所需的每个步骤，并定期测试计划。
高 RPO： 备份可以计划每小时最多发生一次。 如果主应用程序脱机，则还原到次要区域的备份可能已过时。 RPO 取决于备份的频率以及这些备份在区域之间复制的速度。
操作说明步骤
用于配置被动冷部署的步骤取决于区域是否具有对。 有关详细信息，请参阅 具有可用性区域的 Azure 配对区域 和 区域，以及没有区域对。
在 App 服务 中为 Web 应用创建被动冷区域的步骤如下所示：
在 Web 应用所在的同一区域中创建 Azure 存储帐户。 选择标准性能层并选择冗余作为异地冗余存储（GRS）或异地区域冗余存储（GZRS）。
启用 RA-GRS 或 RA-GZRS（次要区域的读取访问）。
为 Web 应用配置自定义备份。 你可以决定为 Web 应用备份设置计划，例如每小时一次。
验证是否可以在存储帐户的次要区域中检索 Web 应用备份文件。
后续步骤
查看Azure App 服务参考体系结构：
- 有关单区域区域冗余应用程序，请参阅 基线高度可用的区域冗余 Web 应用程序。
- 有关主动/被动多区域应用程序，请参阅 高可用性多区域 Web 应用程序。