可用性区域是给定区域中数据中心的物理分隔集合。 跨区域部署资源可确保仅限于某个区域的中断不会影响应用程序的可用性。 此体系结构演示了如何通过在区域冗余体系结构中进行部署来提高应用服务环境部署的复原能力。 这些区域与距离无关。 它们可映射到不同订阅的不同物理位置。 此体系结构假定单个订阅部署。
支持可用性区域的 Azure 服务可以是区域性服务和/或区域冗余服务。 区域性服务可部署到特定区域。 区域冗余服务可跨区域自动部署。 有关详细指南和建议，请参阅可用性区域支持。 App 服务环境支持区域冗余部署。
在将应用服务环境配置为区域冗余时，平台会自动将 Azure 应用服务计划的实例部署到所选地区中的三个区域。 因此，最小应用服务计划实例计数始终为 3。
GitHub 中提供了本体系结构的参考实现。
体系结构
下载此体系结构的 Visio 文件。
此参考实现中应用服务环境子网中的资源与标准应用服务环境部署体系结构中的资源相同。 此参考实现使用应用服务环境 v3 和 Azure Cache for Redis 的区域冗余功能来提高可用性。 请注意，此参考体系结构的范围仅限于单个区域。
工作流
以下部分描述了此体系结构中使用的服务的可用性性质：
应用服务环境 v3 可配置为区域冗余。 只能在创建应用服务环境期间配置区域冗余，并且只能在支持所有应用服务环境 v3 依赖项的区域中配置区域冗余。 区域冗余应用服务环境中的每个应用服务计划至少需要有三个实例，这样才能在三个区域中部署它们。 最低费用针对的是 9 个实例。 有关详细信息，请参阅定价指南。 有关详细指导和建议，请参阅应用服务环境对可用性区域的支持。
Azure 虚拟网络跨越单个地区的所有可用性区域。 虚拟网络中的子网也跨可用性区域。 有关详细信息，请参阅应用服务环境的网络要求。
应用程序网关 v2 是区域冗余的。 与虚拟网络一样，它在每个地区跨多个可用性区域。 因此，如参考体系结构所示，对于高度可用的系统来说，一个应用程序网关就已足够。 该参考体系结构使用应用程序网关的 WAF SKU，它基于 Open Web Application Security Project (OWASP) 的核心规则集 (CRS) 的实现来提供针对常见威胁和漏洞的增强保护。 有关详细信息，请参阅缩放应用程序网关 v2 和 WAF v2。
Azure 防火墙具有对高可用性的内置支持。 它可跨多个区域，无需任何其他配置。
如果需要，还可以在部署防火墙时配置特定的可用性区域。 有关详细信息，请参阅 Azure 防火墙和可用性区域。 （参考体系结构中未使用此配置。）
Microsoft Entra ID 是一种跨越可用性区域和地区的高度可用、高度冗余的全局服务。 有关详细信息，请参阅推进 Microsoft Entra 可用性。
GitHub Actions 在此体系结构中提供持续集成和持续部署 (CI/CD) 功能。 由于应用服务环境位于虚拟网络中，因此虚拟机用作虚拟网络中的 jumpbox，以便在应用服务计划中部署应用。 该操作在虚拟网络外部生成应用。 如需增强安全性和实现无缝 RDP/SSH 连接，请考虑对 jumpbox 使用 Azure Bastion。
Azure Cache for Redis 是一项区域冗余服务。 区域冗余缓存在跨多个可用性区域部署的 VM 上运行。 该服务提供更高的复原能力和可用性。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可用性
应用服务环境
可以跨可用性区域部署应用服务环境，为业务关键型工作负载提供复原能力和可靠性。 此配置也称为“区域冗余”。
实现区域冗余时，平台会跨所选地区中的三个区域自动部署应用服务计划的实例。 因此，最小应用服务计划实例计数始终为 3。 如果指定容量大于 3，并且实例数可被 3 整除，则会均匀部署这些实例。 否则，任何剩余实例将添加到剩余区域或部署在剩余的两个区域中。
- 你将在创建应用服务环境时配置可用性区域。
- 在该应用服务环境中创建的所有应用服务计划都至少需要三个实例。 它们将自动实现区域冗余。
- 可以在创建新的应用服务环境时指定可用性区域。 无法将现有的应用服务环境转换为使用可用性区域。
- 可用性区域仅在一部分区域中受支持。
有关详细信息，请参阅Azure App 服务中的可靠性。
复原
在应用服务环境中运行的应用程序构成应用程序网关的后端池。 当针对应用程序的请求来自公共 Internet 时，网关会将该请求转发到在应用服务环境中运行的应用程序。 此参考体系结构在主 Web 前端 votingApp 中实现运行状况检查。 此运行状况探测会检查 Web API 和 Redis 缓存是否正常。 可以在 Startup.cs 中看到实现此探测的代码：
var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
Path = "/health"
};
services.AddHealthChecks()
.AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
.AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));
以下代码演示了 commands_ha.azcli 脚本如何配置应用程序网关的后端池和运行状况探测：
# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
"name": "votapp",
"routingPriority": 100,
"hostName": "${APPGW_APP1_URL}",
"backendAddresses": [
{
"fqdn": "${INTERNAL_APP1_URL}"
}
],
"probePath": "/health"
}
]
如果有任何组件（Web 前端、API 或缓存）未通过运行状况探测，应用程序网关会将请求路由到后端池中的其他应用程序。 此配置可确保请求始终路由到完全可用的应用服务环境子网中的应用程序。
运行状况探测也是在标准参考实现中实现的。 如果运行状况探测失败，网关只会返回错误。 但是，高度可用的实现提高了应用程序的复原能力和用户体验的质量。
成本优化
成本优化就是减少不必要的费用和提高运营效率。 有关详细信息，请参阅成本优化支柱概述。
高可用性体系结构的成本注意事项与标准部署类似。
以下差异会影响成本：
- 你需要为一个区域冗余应用服务环境至少 9 个应用服务计划实例付费。 有关详细信息，请参阅应用服务环境定价。
- Azure Cache for Redis 也是一项区域冗余服务。 区域冗余缓存在跨多个可用性区域部署的 VM 上运行，以提高复原能力和可用性。
高度可用、可复原且高度安全的系统的代价是成本增加。 请使用定价计算器来评估你在定价方面的需求。
部署注意事项
此参考实现使用与标准部署相同的生产级 CI/CD 管道，只有一个跳转盒 VM。 但是，你可能决定对三个区域中的每个区域都使用一个 jumpbox。 此体系结构仅使用一个 jumpbox，因为跳转框不会影响应用的可用性。 jumpbox 仅用于部署和测试。
部署此方案
若要了解如何部署此体系结构的参考实现，请参阅 GitHub 自述文件。 使用脚本进行高可用性部署。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Deep Bhattacharya |云解决方案架构师
- Sandy Su |云解决方案架构师
若要查看非公开领英个人资料，请登录领英。
后续步骤
可以根据预期的峰值负载容量在同一区域或跨多个区域水平缩放应用程序，从而修改此体系结构。 在多个区域复制应用程序可能有助于缓解地理分布更广泛的数据中心故障带来的风险，例如地震或其他自然灾害带来的风险。 若要详细了解水平缩放，请参阅使用应用服务环境进行异地分布式缩放。 对于全局和高度可用的路由解决方案，请考虑使用 Azure Front Door。