使用应用服务环境的高可用性企业部署

可用性区域是给定区域中数据中心的物理分隔集合。 可以跨区域部署资源，以确保限制为某个区域的中断不会影响应用程序的可用性。 此体系结构介绍如何通过在区域冗余体系结构中部署应用服务环境部署来提高其复原能力。 这些区域与邻近度无关。 它们可映射到不同订阅的不同物理位置。 此体系结构假定单个订阅部署。

支持可用性区域的 Azure 服务可以是区域性服务和/或区域冗余服务。 可以将区域服务部署到特定区域。 你可以跨区域自动部署区域冗余服务。 有关详细信息，请参阅 可用性区域支持。 应用服务环境支持 区域冗余部署。

为区域冗余配置应用服务环境时，平台会自动在所选区域中可用区域的最大数目中部署 Azure 应用服务计划的实例。 区域中必须至少有两个区域可用才能启用区域冗余。 因此，最小应用服务计划实例计数始终为 2。 平台确定可用于应用服务环境的区域数。

Architecture

下载此体系结构的 Visio 文件 。

GitHub 中提供了本体系结构的参考实现。

此参考实现中的应用服务环境子网中的资源与 标准应用服务环境部署体系结构中的资源匹配。 此参考实现使用应用服务环境 v3 和 Azure Cache for Redis 的区域冗余功能来提高可用性。 此参考体系结构的范围仅限于单个区域。

Components

本部分介绍此体系结构中服务的可用性性质。

• 应用服务环境 v3 支持 区域冗余。 在 支持区域冗余的区域，可以在应用服务环境的生命周期内随时配置区域冗余。 区域冗余应用服务环境中的每个应用服务计划必须至少包含两个实例，以确保跨两个或更多区域进行部署。 可以在同一应用服务环境中合并区域冗余和非区域冗余计划。 若要配置只有一个实例的计划，请先禁用该计划的区域冗余。 区域冗余不会产生额外的费用。 只需为正在使用的独立 v2 实例付费。 有关详细信息，请参阅应用服务环境中的应用服务环境定价和可靠性。

• Azure 虚拟网络 跨单个区域内的所有可用性区域。 虚拟网络中的子网还会跨可用性区域扩展。 有关详细信息，请参阅虚拟网络中的应用服务环境和可靠性的网络要求。

• Azure 应用程序网关 v2 是区域冗余的。 与虚拟网络一样，它跨每个区域中的多个可用性区域。 因此，单个应用程序网关提供高可用性，如参考体系结构所示。 参考体系结构使用应用程序网关的 Web 应用程序防火墙 SKU，它增加了对常见威胁和漏洞的防护。 此保护基于开放 Web 应用程序安全项目（OWASP）的核心规则集（CRS）的实现。 有关详细信息，请参阅 应用程序网关 v2 中的可靠性。

• Azure 防火墙 包括对高可用性的内置支持。 它可以使用多个区域，而无需额外配置。

  部署防火墙时，还可以配置特定的可用性区域。 有关详细信息，请参阅 Azure 防火墙可用性区域支持。 参考体系结构不使用此配置。

• Microsoft Entra ID 是跨可用性区域和区域的高可用性、高度冗余的全局服务。 有关详细信息，请参阅 高级Microsoft Entra ID 可用性。

• GitHub Actions 在此体系结构中提供持续集成和持续部署 (CI/CD) 功能。 应用服务环境驻留在虚拟网络中，因此虚拟机（VM）在虚拟网络中提供跳转盒，以便在应用服务计划中部署应用。 该操作在虚拟网络外部生成应用。 若要增强安全性和无缝远程桌面协议（RDP）和安全外壳（SSH）连接，请考虑将 Azure Bastion 用于 jumpbox。

• Azure Cache for Redis 是一项区域冗余服务。 区域冗余缓存在跨多个可用性区域部署的 VM 上运行。 该服务提供更高的复原能力和可用性。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。

Reliability

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。

Jumpboxes

此参考实现使用与标准部署相同的生产级 CI/CD 管道，只有一个 jumpbox VM。 但是，可以对三个区域中的每个区域使用一个 jumpbox。 此体系结构仅使用一个 jumpbox，因为 jumpbox 不会影响应用的可用性。 jumpbox 支持部署和测试。

应用服务环境

你可以跨可用性区域部署应用服务环境，以便为业务关键型工作负荷提供复原和可靠性。 此配置也称为“区域冗余”。

实现区域冗余时，平台会自动在所选区域中的两个或更多区域之间部署应用服务计划的实例。 因此，最小应用服务计划实例计数始终为 2。

• 可以在创建应用服务环境时或在环境的生命周期中的任何时间点 配置可用性区域 。

• 在该应用服务环境中创建的所有应用服务计划至少需要两个实例才能启用区域冗余。 如果应用服务环境是区域冗余的，则可以有选择地为各个应用服务计划启用和禁用区域冗余。 若要将应用服务计划扩展到单个实例，请禁用该计划的区域冗余，然后继续执行缩减作。

• 只有一 部分区域 支持可用性区域。

有关详细信息，请参阅 应用服务中的可靠性。

复原能力

在应用服务环境中运行的应用程序构成了应用程序网关的 后端池 。 当对应用程序的请求来自公共 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 Azure Application Gateway script
cat <<EOF > appgwApps.parameters.json
[
  {
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "probePath": "/health"
  }
]

如果任何组件（包括 Web 前端、API 或缓存）失败，则应用程序网关会将请求路由到后端池中的其他应用程序。 此配置可确保请求始终路由到完全可用的应用服务环境子网中的应用程序。

标准引用实现还使用运行状况探测。 在该实现中，如果运行状况探测失败，网关将返回错误。 但是，高度可用的实现提高了应用程序的复原能力和用户体验的质量。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅成本优化设计评审核对清单。

高可用性体系结构的成本注意事项类似于标准部署。

以下差异会影响成本：

• 可用性区域支持不会产生额外的费用。 只需为使用的实例付费。 有关详细信息，请参阅应用服务环境定价。

• Azure Redis 缓存是区域冗余服务。 区域冗余缓存在跨多个可用性区域的 VM 上运行，以提供更高的复原能力和可用性。 此配置引入了与区域冗余相关的额外费用，以支持区域之间的数据传输。

对高度可用、可复原且高度安全的系统的权衡包括增加某些 Azure 服务的成本。 若要评估要求和估算成本，请使用 定价计算器。

部署此方案

若要部署此体系结构的参考实现，请参阅 GitHub 自述文件。 使用脚本进行高可用性部署。

供稿人

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

• Deep Bhattacharya |云解决方案架构师
• Sandy Su |云解决方案架构师

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤

若要修改此体系结构，可以根据预期的峰值负载容量，水平缩放同一区域或多个区域中的应用程序。 跨多个区域复制应用程序有助于缓解更广泛的地理数据中心故障的风险，例如地震或其他自然灾害造成的故障。

• 有关水平缩放的详细信息，请参阅 使用应用服务环境进行异地分布式缩放。
• 对于全局和高度可用的路由解决方案，请考虑使用 Azure Front Door。