你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

教程：在 Azure 应用服务中创建高度可用的多区域应用

高可用性和容错是架构良好的解决方案的关键组成部分。可靠的配置包括意外故障的紧急计划，以减少停机时间并自动使系统保持运行。

将应用部署到云时，请选择该云中的某个区域作为应用基础结构基础。如果仅将应用部署到单个区域，并且该区域不可用，则应用也不可用。根据应用服务级别协议（SLA）的条款，缺乏可用性可能是不能接受的。若要确保可用性，请在云中的多个区域部署应用及其服务。

本教程介绍如何部署高度可用的多区域 Web 应用。此过程实现由 Web 应用和 Azure Front Door 组成的简单方案。可以扩展概念以支持其他基础结构模式。例如，如果您的应用连接到 Azure 数据库服务或存储帐户，请参阅 SQL 数据库的活动异地复制和Azure 存储冗余。有关更详细场景的参考体系结构，请参阅 .NET 可靠的 Web 应用模式。

在本教程中，你将了解：

在单独的区域中创建相同的应用服务应用
创建具有访问限制的Azure Front Door以阻止对应用服务的公共访问

Prerequisites

如果没有Azure帐户，请在开始前创建一个 free 帐户。

为完成此教程：

在 Azure Cloud Shell 中使用 Bash 环境。有关详细信息，请参阅 Get started with Azure Cloud Shell。
如果希望在本地运行 CLI 引用命令，install Azure CLI。如果在 Windows 或 macOS 上运行，请考虑在 Docker 容器中运行Azure CLI。有关详细信息，请参阅如何在 Docker 容器中运行Azure CLI。
- 如果使用本地安装，请使用 az login 命令登录到Azure CLI。要完成身份验证过程，请遵循终端中显示的步骤。有关其他登录选项，请参阅使用 Azure CLI 进行身份验证。
- 出现提示时，请在首次使用时安装 Azure CLI 扩展。有关扩展的详细信息，请参阅使用 Azure CLI 使用和管理扩展。
- 运行 az version 以查找所安装的版本和依赖库。若要升级到最新版本，请运行 az upgrade。

查看方案体系结构

以下体系结构示意图显示了你在本教程中创建的基础结构。它由不同区域中的两个相同的应用服务应用组成。第一个 Web 应用位于活动区域中。这是负责处理传入流量的主要应用。第二个应用位于备用区域中，并等待主应用的可用性。 Azure Front Door尝试将流量路由到主 Web 应用。当主要区域不可用时，流量将路由到备用 Web。在关系图中，虚线表示基于区域状态的流量路由。配置了访问限制，因此阻止从 Internet 直接访问应用。

显示多区域应用服务架构的图。

Azure提供了各种负载均衡和流量路由选项。本教程选择了Azure Front Door，因为它涉及托管在多个区域中Azure 应用服务上托管的面向 Internet 的 Web 应用。如果配置与本教程中的示例不同，请参阅为方案选择负载均衡解决方案。

本教程中的方案提供以下行为：

相同的应用服务应用部署在两个不同的区域中。
直接发送到 Web 应用程序的公共流量将被阻止。
Azure Front Door 将流量路由到主要区域中的活动应用。
次要区域中的备用应用可以根据需要处理流量请求。

创建资源组

本教程需要两个在不同Azure区域中运行的 Web 应用的实例。

查看可用的区域对，并为 Web 应用选择两个配对区域。

在本教程中，这两个区域称为 <primary-region> （eastus）和 <standby-region> （westus）。

为本教程中配置的所有资源创建资源组。本教程在<primary-region>位置创建资源组。

az group create --name <resource-group> --location <primary-region>

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--name`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--location`	`<primary-region>`	资源组的区域位置。本教程对资源组和主要 Web 应用使用相同的区域位置。	`eastus`

在实际实现中，对每个区域/资源使用单独的资源组。分离允许在灾难恢复情况下隔离资源。

有关详细信息，请参阅 az group create 命令参考。

创建两个应用服务计划

创建两个应用服务计划，每个 Web 应用一个。在想要在其中创建相应应用的区域位置创建每个计划。

对于此命令，请使用您之前选择的区域对。将活动区域用于主 Web 应用，将被动区域用于备用 Web 应用。

运行以下命令，为主 Web 应用创建应用服务计划，然后再次运行该命令，为备用应用创建计划。

az appservice plan create --name <app-service-plan> --resource-group <resource-group> --is-linux --location `<region>`

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--name`	`<app-service-plan>`	Web 应用的应用服务计划的名称。每个计划实例必须具有唯一的名称。	`zava-primary-plan` `zava-standby-plan`
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--location`	`<region>`	Web 应用的区域位置。	- 主 Web 应用，活动区域 `eastus` - 备用 Web 应用、被动区域 `westus`

有关详细信息，请参阅 az appservice plan create 命令参考。

创建两个应用程序

创建两个应用服务 Web 应用。将每个应用放在相应的应用服务计划和区域位置。

确定--runtime Web 应用的语言版本。

您可以运行以下命令来获取可用运行时的列表：
```
az webapp list-runtimes
```
如果打算使用本教程中所述的示例 Node.js 应用，请将 <language-version> 该值设置为 NODE:24-lts。

创建两个 Web 应用。运行以下命令以创建主 Web 应用，然后再次运行该命令以创建备用应用。

az webapp create --name <web-app-name> --resource-group <resource-group> --plan <app-service-plan> --runtime <language-version>

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--name`	`<web-app-name>`	Web 应用的名称。每个应用必须具有全局唯一的名称。有效字符为 `a-z`， `0-9`以及 `-`。	`zava-primary-app` `zava-standby-app`
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--name`	`<app-service-plan>`	Web 应用的应用服务计划的名称。	`zava-primary-plan` `zava-standby-plan`
`--runtime`	`<language-version>`	Web 应用的运行时语言版本。	`NODE:24-lts`

有关详细信息，请参阅 az webapp create 命令参考。

确定每个网络应用程序的defaultHostName值。主机名格式为 <web-app-name>.azurewebsites.net.

扫描每个 Web 应用的命令输出并找到该值，或为每个 Web 应用运行以下命令：

az webapp show --name <web-app-name> --resource-group <resource-group> --query "hostNames"

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--name`	`<web-app-name>`	Web 应用的名称。	`zava-primary-app` `zava-standby-app`
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`

在 Azure 门户中，每个应用的主机名在 web 应用 Overview 页上可见。

记录主机名值供以后使用。使用主机名定义用于Azure Front Door部署的后端地址。

确认可以访问新的 Web 应用。
1. 在浏览器中，输入主 Web 应用的主机名，例如 zava-primary-app.azurewebsites.net。
  
  连接成功后，会看到以下消息：
2. 使用备用 Web 应用的主机名重复测试。

配置Azure Front Door

多区域部署可以使用 主动-主动 或 主动-被动 配置。主要区域处于活动状态，备用区域为被动区域。

主动-主动配置会将请求分发到多个活动区域。
主动-被动配置在备用（被动）区域中保持运行实例，但除非主要（主动）区域发生故障，否则不会在那里发送流量。

Azure Front Door允许启用这两种配置。有关设计应用程序以实现高可用性和容错的详细信息，请参阅设计评审清单以了解可靠性。

创建个人资料

创建 Azure Front Door Premium 实例，用于将流量路由到 Web 应用。

查看 Azure Front Door 层级比较，然后选择适合您部署的层级。

本教程使用 Azure Front Door Premium （Premium_AzureFrontDoor）。

如果想要部署 Azure Front Door Standard，请记住，标准层不支持使用 WAF 策略部署托管规则。

运行以下命令以创建配置文件：

az afd profile create --profile-name <front-door-profile> --resource-group <resource-group> --sku <front-door-tier>

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--profile-name`	`<front-door-profile>`	Azure Front Door配置文件的名称。名称在资源组中必须唯一。	`zava-profile`
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--sku`	`<front-door-tier>`	用于部署的 Azure Front Door 的层级 SKU。	`Premium_AzureFrontDoor` （推荐） `Standard_AzureFrontDoor`

有关详细信息，请参阅 az afd profile create 命令参考。

添加终结点

在配置文件中创建终结点。创建第一个终结点后，可以在配置文件中创建多个终结点。

az afd endpoint create --resource-group <resource-group> --endpoint-name <front-door-endpoint> --profile-name <front-door-profile> --enabled-state Enabled

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--endpoint-name`	`<front-door-endpoint>`	Azure Front Door配置文件下终结点的名称。该名称在全球范围内必须唯一。	`zava-endpoint`
`--profile-name`	`<front-door-profile>`	Azure Front Door配置文件的名称。	`zava-profile`

有关详细信息，请参阅 az afd endpoint create 命令参考。

创建源组

在将应用程序部署到 Azure Front Door 时，需要一个源站作为你的 Web 应用后端的终结点。有关详细信息，请参阅 Azure Front Door 中的源和源组。源存储在一个源组中。

在 Azure Front Door 配置文件中创建源组，以包含两个 Web 应用的源。

az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
   --probe-request-type <probe-request> \
   --probe-protocol <probe-protocol> \
   --probe-interval-in-seconds <probe-interval> \
   --probe-path <probe-path> \
   --sample-size <sample-size> \
   --successful-samples-required <required-samples> \
   --additional-latency-in-milliseconds <extra-latency>

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--origin-group-name`	`<front-door-origin-group>`	Azure Front Door源组的名称。该名称在全球范围内必须唯一。	`zava-origin-group`
`--profile-name`	`<front-door-profile>`	Azure Front Door配置文件的名称。	`zava-profile`
`--probe-request-type`	`<probe-request>`	健康探针请求类型。	`GET`
`--probe-protocol`	`<probe-protocol>`	用于运行状况探测的协议。	`Http`
`--probe-interval-in-seconds`	`<probe-interval>`	运行状况探测之间间隔的秒数。	60
`--probe-path`	`<probe-path>`	源的相对路径，用于确定源的运行状况。	`/`（反斜杠）
`--sample-size`	`<sample-size>`	负载均衡决策要考虑的样本数。	4
`--successful-samples-required`	`<required-samples>`	采样期间必须成功的样本数。	3
`--additional-latency-in-milliseconds`	`<extra-latency>`	使探测落入最低延迟桶的额外延迟（以毫秒为单位）。	50

有关详细信息，请参阅 az afd origin-group create 命令参考。

将源添加到源组

将每个 Web 应用的源添加到Azure Front Door源组。

为主 Web 应用添加源。将 --priority 参数设置为 1，通知Azure Front Door此应用是流量的主要接收器。

az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \
   --origin-group-name <front-door-origin-group> \
   --origin-name <web-app-origin-name> \
   --origin-host-header <web-app-name>.azurewebsites.net \
   --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \
   --http-port <origin-port> --https-port <origin-secure-port>

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--host-name`	`<web-app-name>.azurewebsites.net`	主 Web 应用的主机名。主机名将 Web 应用名称（如 `zava-primary-app` 主机标识符 `azurewebsites.net`）组合在一起。	`zava-primary-app.azurewebsites.net`
`--profile-name`	`<front-door-profile>`	Azure Front Door配置文件的名称。	`zava-profile`
`--origin-group-name`	`<front-door-origin-group>`	Azure Front Door 源组的名称。	`zava-origin-group`
`--origin-name`	`<web-app-origin-name>`	主 Web 应用的源名称。名称在源组中必须是唯一的。	`primary-origin`
`--origin-host-header`	`<web-app-name>.azurewebsites.net`	发送给主 Web 应用源的请求所使用的主机标头。如果未指定值，请求主机名将确定此值。 Azure CDN源（例如Web 应用、Blob 存储和云服务）默认要求此主机标头值与源主机名匹配。	`zava-primary-app.azurewebsites.net`
`--priority`	`<origin-priority>`	源组中此源的优先级。对于主 Web 应用，将优先级设置为 1。 Azure Front Door使用优先级值跨源和活动区域进行负载均衡。该值必须介于 1 和 5 之间。	1
`--weight`	`<origin-weight>`	源组中用于负载均衡的源的权重。该值必须介于 1 和 1000 之间。	1000
`--enabled-state`	`<origin-state>`	指示是否启用此源来接收流量。	`Enabled`
`--http-port`	`<origin-port>`	用于向源发出的 HTTP 请求的端口。	80
`--https-port`	`<origin-secure-port>`	用于对源的安全 HTTPS 请求的端口。	443

有关详细信息，请参阅 az afd origin create 命令参考。

再次运行该命令，并为备用 Web 应用添加源。该命令使用相同的参数，但具有以下唯一参数值：

参数	值	说明	示例
`--host-name`	`<web-app-name>.azurewebsites.net`	备用 Web 应用的主机名。	`zava-standby-app.azurewebsites.net`
`--origin-name`	`<web-app-origin-name>`	备用 Web 应用的源名称。	`standby-origin`
`--origin-host-header`	`<web-app-name>.azurewebsites.net`	发送给备用 Web 应用源的请求所使用的主机标头。	`zava-standby-app.azurewebsites.net`
`--priority`	`<origin-priority>`	源组中此源的优先级。对于备用 Web 应用，请将优先级设置为 2。 Azure Front Door尝试将所有流量定向到主源。当主源不可用时，流量会路由到备用源。	2

添加路由规则

添加路由规则，将Azure Front Door终结点映射到源组。路由将请求从终结点转发到源组。

创建路由规则，将Azure Front Door终结点映射到源组：

az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> `
   --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> `
   --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link>

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--profile-name`	`<front-door-profile>`	Azure Front Door配置文件的名称。	`zava-profile`
`--endpoint-name`	`<front-door-endpoint>`	Azure Front Door 配置文件下的终结点名称。	`zava-endpoint`
`--forwarding-protocol`	`<protocol-type>`	将流量转发到后端应用时，此路由规则使用的协议。	`MatchRequest`
`--route-name`	`<route-rule-name>`	路由规则的名称。在 Azure Front Door 配置文件中必须是唯一的。	`zava-route-rule`
`--https-redirect`	`<secure-redirect>`	指示是否自动将 HTTP 流量重定向到 HTTPS 流量。	`Enabled`
`--origin-group-name`	`<front-door-origin-group>`	Azure Front Door源组的名称。	`zava-origin-group`
`--supported-protocols`	`<protocol-list>`	此路由规则支持的协议列表。使用空格分隔协议类型。	`Http Https`
`--link-to-default-domain`	`<domain-link>`	指示此路由是否链接到默认终结点域。	`Enabled`

有关详细信息，请参阅 az afd route create 命令参考。

允许大约 15 分钟完成部署。更改可能需要一些时间才能全局传播。

仅通过Azure Front Door限制访问

目前，可以通过在浏览器中输入 Web 应用的主机名来直接访问 Web 应用。如果对应用设置了访问限制，则可以确保流量仅通过Azure Front Door到达应用。

在流量仅通过Azure Front Door服务时，其功能最佳。最佳做法是配置 Web 应用源以阻止未通过Azure Front Door发送的流量。否则，流量可能会绕过Azure Front Door Web 应用程序防火墙、DDoS 防护和其他安全功能。

从Azure Front Door发到应用的流量源自在 AzureFrontDoor.Backend 服务标记中定义的一组已知 IP 范围。通过使用服务标记限制规则，可以将仅源自 Azure Front Door 的流量进行限制。

获取你的 Azure Front Door 配置文件的标识符。

需要配置文件 ID，以确保流量仅源自特定的 Azure Front Door 实例。访问限制会根据从Azure Front Door配置文件发送的唯一 HTTP 标头进一步筛选传入的请求。

az afd profile show --resource-group <resource-group> --profile-name <front-door-profile> --query "frontDoorId"

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--profile-name`	`<front-door-profile>`	Azure Front Door配置文件的名称。	`zava-profile`

命令输出显示配置文件 ID（32 位字母数字值）：

"0000aaaa-1b1b-2c2c-3d3d-444444eeeeee"

在下一步中，你将使用配置文件 ID 作为 <profile-identifier> 的值。

运行以下命令，在主 Web 应用上设置访问限制，并再次运行该命令以对备用应用设置限制。

az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> `
   --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--name`	`<web-app-name>`	要为其设置访问限制的 Web 应用的名称。	`zava-primary-app` `zava-standby-app`
`--priority`	`<access-priority>`	指定访问限制规则在为配置文件定义的所有规则中的优先级。较低的值等同于更高的优先级。	100
`--service-tag`	`<tag-name>`	Azure Front Door 识别的服务标记名称。访问限制适用于服务标记指示的 IP 范围。	`AzureFrontDoor.Backend`
`--http-header`	`x-azure-fdid=<profile-identifier>`	指定一个或多个唯一 HTTP 标头以额外筛选传入流量。访问限制根据从 Azure Front Door 配置文件发送的唯一 HTTP 标头筛选传入请求。标头将Azure Front Door前缀和Azure Front Door实例的配置文件标识符组合在一起。	`x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee`

有关详细信息，请参阅 az webapp config access-restriction add 命令参考。

测试访问限制

确认您的访问限制确实能阻止直接访问您的应用程序。

在浏览器中，输入主 Web 应用的主机名，例如 zava-primary-app.azurewebsites.net。

连接应失败并显示以下消息：
使用备用 Web 应用的主机名重复测试，例如 zava-standby-app.azurewebsites.net。

测试 Azure Front Door 部署

创建 Azure Front Door 标准版或高级版配置文件时，配置可能需要一些时间才能实现全局部署。部署完成后，可以访问前端主机。

获取您的 Azure Front Door 终结点的主机名：

az afd endpoint show --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> --query "hostName"

将以下 <placeholder> 参数值替换为你自己资源的相关信息：

参数	值	说明	示例
`--resource-group`	`<resource-group>`	包含本教程中创建的资源的资源组。	`zava-resource-group`
`--profile-name`	`<front-door-profile>`	Azure Front Door配置文件的名称。	`zava-profile`
`--endpoint-name`	`<front-door-endpoint>`	Azure Front Door 配置文件下的终结点名称。	`zava-endpoint`

命令输出显示终结点主机名：

"zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net"

主机名由终结点名称、唯一的字母数字哈希、标识符和Azure Front Door后缀组成。在下一步中，使用端点主机名。

有关详细信息，请参阅 az afd endpoint show 命令参考。

在浏览器中，输入终结点主机名，例如 zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net。

请求应自动路由到活动区域中的主应用。

连接成功后，会看到以下消息：
测试配对区域中各应用之间的即时全局故障转移。
1. 在浏览器中，输入终结点主机名，例如 zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net。
2. 通过运行 az webapp stop 命令停止主应用。
  
  将以下 <placeholder> 参数值替换为你自己资源的相关信息：
```
az webapp stop --name <primary-web-app> --resource-group <resource-group>
```
3. 刷新浏览器。
  
  如果流量正确重定向到其他区域中的备用应用，应该会看到相同的页面和消息。
  
  提示
  
  可能需要刷新页面几次才能完成故障转移。
  
  可以通过在 Azure 门户中检查 Web 应用的状态来确认Azure Front Door正在重定向到备用应用。在主 Web 应用的 “概述 ”页上，“ 开始” 选项应可用（未灰显）。在备用 Web 应用的 “概述 ”页上，“ 开始” 选项不应可用（灰色）。
4. az webapp stop再次运行该命令并停止备用应用。
  
  将以下 <placeholder> 参数值替换为你自己资源的相关信息：
```
az webapp stop --name <standby-web-app> --resource-group <resource-group>
```
5. 再次刷新浏览器。
  
  如果备用应用也停止，则所有流量路由都应停止。这一次，应会看到一条错误消息：
6. az webapp start运行命令并重启备用应用。
  
  将以下 <placeholder> 参数值替换为你自己资源的相关信息：
```
az webapp start --name <standby-web-app> --resource-group <resource-group>
```
7. 刷新浏览器，应会看到成功的应用连接。

验证会确认你现在可以通过 Azure Front Door 访问应用，并且故障转移功能按预期运行。

如果已完成故障转移测试，请重启主应用。

清理资源

在前面的步骤中，你在资源组中创建Azure资源。如果将来不需要这些资源，请通过在Cloud Shell中运行以下命令来删除资源组。

将 <placeholder> 参数值替换为你自己的资源的信息：

az group delete --name <resource-group>

该命令可能需要几分钟时间才能运行。

从 ARM 或 Bicep 部署

可以使用Azure 资源管理器模板（ARM 模板）或Bicep模板部署本教程中创建的资源。可以从 GitHub 上的高可用性跨区域 Web 应用的 Bicep 文件开始。此模板可帮助你创建一个安全、高度可用的多区域端到端解决方案，并在Azure Front Door后面的不同区域中创建两个 Web 应用。

若要了解如何部署 ARM 和Bicep模板，请参阅 Deploy Bicep 文件以及 Azure CLI。

常见问题

在本教程中，你部署了一个基线基础结构来启用多区域 Web 应用。应用服务提供的功能可帮助确保运行遵循安全最佳做法和建议的应用程序。

本部分包含常见问题解答，可帮助你进一步保护应用，并根据最佳做法部署和管理资源。

管理和部署基础结构和Azure资源

在本教程中，你使用了Azure CLI来部署基础结构资源。请考虑配置持续部署机制来管理应用程序基础结构。由于要在不同的区域中部署资源，因此需要跨区域独立管理这些资源。为了确保每个区域的资源相同，基础结构即代码（如 ARM 模板或 Terraform 应与部署管道（如 Azure Pipelines 或 GitHub Actions）一起使用。正确设置此配置时，对资源的任何更改都会触发所有部署区域中的更新。有关详细信息，请参阅配置持续部署到 Azure 应用服务。

使用过渡槽实现安全部署到生产环境

不建议将应用程序代码直接部署到生产环境和插槽。在推送到生产环境之前，必须有一个安全的位置来测试应用并验证更改。使用过渡槽和槽交换的组合将代码从测试环境移动到生产环境。

在本教程中，你创建了支持使用过渡槽的基线基础结构。可以为 Web 应用的每个实例创建部署槽位，并使用GitHub Actions配置对这些过渡槽的持续部署。与基础结构管理一样，还建议为应用程序源代码配置持续部署，以确保跨区域更改保持同步。如果未配置持续部署，则每次发生代码更改时，都需要手动更新每个区域中的每个应用。

若要使用过渡槽，请遵循以下过程：

对于此过程，你需要一个已准备好部署到应用服务应用的应用。

如果已完成本教程，则可以使用主 Web 应用和备用 Web 应用。但是，需要一个支持足够部署槽位的应用服务计划。有关详细信息，请参阅 Azure 订阅和服务限制、配额和服务限制。

如果没有应用，可以从 Node.js Hello World 示例应用开始。创建 GitHub 存储库分支，以便拥有自己的副本进行更改。
为 Web 应用配置应用服务堆栈设置。

堆栈设置是指用于应用的语言版本或运行时。

可以在Azure门户中配置设置，也可以使用 az webapp config set 命令。如果使用 Node.js 示例，请将堆栈设置设置为 Node 24 LTS。
1. 在 Azure 门户中，转到您的主 web 应用。
2. 在左侧菜单中选择设置>配置。
3. 在 “堆栈设置 ”选项卡中，配置以下设置：
  1. 选择 Stack 值，例如 Node。
  2. 选择版本值，例如 Node 24 LTS。
  3. 选择应用。
4. 重复此过程，为备用 Web 应用配置应用服务堆栈设置。
在Azure门户中设置持续部署。有关如何使用提供程序（如 GitHub Actions）配置持续部署的详细指南，请参阅配置持续部署到 Azure 应用服务。

运行以下命令，为您的主网站应用创建一个名为stage的部署槽。

az webapp deployment slot create --resource-group <resource-group> --name <web-app-name> --slot stage --configuration-source <web-app-name>

再次运行az webapp deployment slot create命令，为备用web 应用创建一个名为stage的过渡槽。
为每个部署槽通过GitHub Actions配置持续部署：
1. 在 Azure 门户中，转到您的主 Web 应用。
2. 在左侧菜单中，选择部署>部署槽位。
3. 在列表中找到阶段槽，然后选择该槽以打开详细信息窗格。
4. 在左侧菜单中，选择 “部署>部署中心”。
5. 在 Settings 选项卡中，将 Source 选项设置为 GitHub：
6. 如果要首次从 GitHub 进行部署，请选择 Authorize 并按照授权提示进行操作。若要从另一个用户的存储库进行部署，请选择“更改帐户”。
7. 使用 GitHub 授权 Azure 帐户后，请选择 Organization、Repository 和 Branch 用于配置 CI/CD。如果找不到组织或存储库，可能需要对GitHub启用更多权限。有关详细信息，请参阅管理对组织存储库的用户访问权限。
  
  如果使用 Node.js 示例应用，请使用以下设置。
  
  设置值
  
  组织 <your-GitHub-organization>
  
  存储库 nodejs-docs-hello-world
  
  分支主要
8. 选择“保存”。

设置	值
组织	`<your-GitHub-organization>`
存储库	nodejs-docs-hello-world
分支	主要

选定存储库和分支中的新提交现在将持续部署到应用服务应用槽中。可以在“日志”选项卡中，跟踪提交和部署。

一个使用发布配置文件来对应用服务进行身份验证的默认工作流文件已添加到您的GitHub存储库。可以转到 <repo-name>/.github/workflows/ 目录来查看此文件。

在应用服务上禁用基本身份验证

可以通过禁用基本身份验证，将对 FTP 和 SCM 终结点的访问权限限制为由 Microsoft Entra ID 支持的用户。

如果使用持续部署工具部署应用程序源代码，则禁用基本身份验证需要执行额外的步骤来配置持续部署。例如，你无法使用发布配置文件，因为它不使用 Microsoft Entra 凭据。相反，需要使用服务主体或 OpenID Connect 凭据。

以下命令为应用服务主 Web 应用和过渡槽以及备用 Web 应用和过渡槽禁用基本身份验证。将以下 <placeholder> 参数值替换为你自己资源的相关信息。

为主 Web 应用禁用生产环境站点和过渡槽的 FTP 访问：

az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<web-app-name> --set properties.allow=false

az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<web-app-name>/slots/stage --set properties.allow=false

再次为备用 Web 应用运行命令。

为主 Web 应用禁用对生产站点和过渡槽的 WebDeploy 端口和 SCM 站点的基本身份验证访问：

az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<primary-web-app> --set properties.allow=false

az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<primary-web-app>/slots/stage --set properties.allow=false

再次为备用 Web 应用运行命令。

有关禁用基本身份验证的详细信息，包括如何测试和监视登录，请参阅在应用服务部署中禁用基本身份验证。

在禁用基本身份验证的情况下，使用持续部署。

如果选择在应用服务应用中允许基本身份验证，则可以在应用服务上使用任何可用的部署方法。例如，可以使用在“过渡槽”部分配置的发布配置文件。

如果禁用应用服务应用的基本身份验证，则持续部署需要服务主体或 OpenID Connect 进行身份验证。如果您使用 GitHub Actions 作为代码仓库，请参阅使用 GitHub Actions 部署到 Azure 应用服务。本教程提供创建服务主体或 OpenID Connect 以使用 GitHub Actions 部署到应用服务的分步说明。还可以按照下一部分中的过程完成该过程。

使用GitHub Actions创建服务主体和凭据

使用 GitHub Actions 和服务主体配置持续部署：

为您的主 Web 应用程序和备用 Web 应用程序创建服务主体：

将以下 <placeholder> 参数值替换为你自己的资源的信息。

az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
   /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \
   /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>

输出是一个 JSON 对象，其中包含的角色分配凭据可提供对应用服务应用的访问权限。

{
  "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888",
  "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a",
  "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

JSON 包括客户端秘钥，该机密当前仅可见。

提示

授予最低访问权限是一种很好的做法。在此示例中，范围仅限于应用，而不是整个资源组。

复制 JSON 对象，以便拥有客户端机密的记录。

将服务主体凭据提供给 Azure 登录操作，作为 GitHub Actions 工作流的一部分。

可以直接在工作流中提供值，或将它们存储为工作流中引用的GitHub机密。将值保存为GitHub机密是更安全的选项。

打开应用的GitHub存储库。
转到 “设置>安全>机密和变量>操作”。

选择 “新建存储库机密 ”，并为以下每个设置创建机密。使用 JSON 输出中的值。

设置	值	示例
AZURE_APP_ID	`<application/client-id>`	`00001111-aaaa-2222-bbbb-3333cccc4444`
AZURE_PASSWORD	`<client-secret>`	`ffffffff-5a5a-6b6b-7c7c-888888888888`
AZURE_TENANT_ID	`<tenant-id>`	`aaaabbbb-6666-cccc-7777-dddd8888eeee`
AZURE_SUBSCRIPTION_ID	`<subscription-id>`	`cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a`

创建GitHub Actions工作流

拥有可以访问应用服务应用的服务主体后，请编辑应用的默认工作流。配置持续部署时，会自动生成这些工作流。

必须使用服务主体而不是发布配置文件进行身份验证。有关示例工作流，请参阅Service principal选项卡中的将工作流文件添加到您的GitHub存储库。以下示例工作流可用于 Node.js 示例应用。

打开应用的GitHub存储库。
转到 <repo-name>/.github/workflows/ 目录。你应该会看到自动生成的工作流。
对于每个工作流文件，请选择 “编辑 ”（铅笔）。

将工作流文件的内容替换为以下内容。该代码假定你已为凭据创建了 GitHub 机密。

在本 env 部分中，配置以下设置：

AZURE_WEBAPP_NAME：将 <web-app-name> 占位符替换为 Web 应用的名称。
NODE_VERSION：指定要使用的节点版本。对于 Node.js 示例，值为 '24.x'.
AZURE_WEBAPP_PACKAGE_PATH：指定 Web 应用项目的路径。默认值为存储库根目录。 '.'
AZURE_WEBAPP_SLOT_NAME：指定应用程序槽名称。公用名为 stage.


 name: Build and deploy Node.js app to Azure Web App

 on:
   push:
     branches:
       - main
   workflow_dispatch:

 env:
   AZURE_WEBAPP_NAME: <web-app-name>   # Your application name
   NODE_VERSION: '24.x'                # Node version to use
   AZURE_WEBAPP_PACKAGE_PATH: '.'      # Path to your web app project
   AZURE_WEBAPP_SLOT_NAME: stage       # Application slot name

 jobs:
   build:
     runs-on: ubuntu-latest

     steps:
       - uses: actions/checkout@v4

       - name: Set up Node.js version
         uses: actions/setup-node@v4
         with:
           node-version: ${{ env.NODE_VERSION }}

       - name: npm install, build
         run: |
           npm install
           npm run build --if-present

       - name: Upload artifact for deployment job
         uses: actions/upload-artifact@v4
         with:
           name: node-app
           path: .

   deploy:
     runs-on: ubuntu-latest
     needs: build
     environment:
       name: 'stage'
       url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

     steps:
       - name: Download artifact from build job
         uses: actions/download-artifact@v4
         with:
           name: node-app

       - uses: azure/login@v2
         with:
           creds: |
             {
               "clientId": "${{ secrets.AZURE_APP_ID }}",
               "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
               "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
               "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
             }

       - name: 'Deploy to Azure Web App'
         id: deploy-to-webapp
         uses: azure/webapps-deploy@v3
         with:
           app-name: ${{ env.AZURE_WEBAPP_NAME }}
           slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
           package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

       - name: logout
         run: |
           az logout

将工作流文件更改直接保存到存储库的主分支并提交。

提交会触发GitHub操作以再次运行并部署代码。这次，服务主体名称用于进行身份验证。

使用槽流量路由测试应用更新

使用槽进行流量路由可将用户流量的预定义部分定向到每个槽。最初，100% 的流量将定向到生产站点。但是，可以将 10% 的流量发送到过渡槽。这种槽流量路由方法会自动将 10% 尝试访问的用户发送到过渡槽。此方法无需更改Azure Front Door实例。若要详细了解应用服务中的交换槽位和暂存环境，请参阅在 Azure 应用服务中设置暂存环境。

将代码从过渡槽移至生产槽

在过渡槽中完成测试和验证后，你可以执行从过渡槽到生产站点的槽交换。你将为每个区域中应用的所有实例完成交换。在槽交换期间，应用服务平台将确保目标槽不会遇到停机。

对主 Web 应用执行切换：

az webapp deployment slot swap --resource-group <resource-group> -name <primary-web-app-name> --slot stage --target-slot production

为你的备用 Web 应用进行交换：

az webapp deployment slot swap --resource-group <resource-group> -name <standby-web-app-name> --slot stage --target-slot production

几分钟后，转到 Azure 门户中的 Azure Front Door 终结点，并验证槽交换成功与否。

此时，你的应用已启动并运行，对应用程序源代码所做的任何更改都会自动触发两个过渡槽的更新。然后，在准备好将此代码移动到生产环境后，可以重复槽交换过程。

使用多区域部署避免中断和连续性问题

通过暂时从Azure Front Door源组中删除正在进行插槽交换的站点，可以避免潜在的跨区域中断或连续性问题。此操作有助于防止客户同时看到不同版本的应用。当你对应用进行重大更改时，它也很有用。临时删除会导致所有流量重定向到其他源。

在 Azure 门户中，转到 Azure Front Door 实例。
在左侧菜单中，选择设置>源组。
在源组列表中，选择包含要暂时删除的槽的源组。
在更新源组窗格中，在源主机名列表中找到要删除的位置。
选择 “更多操作 ”（...） >删除，然后选择“ 更新”。

应用更改可能需要几分钟时间。
准备好允许流量流向已删除的槽时，请返回到“更新源组”窗格。
在顶部，选择“+ 添加源”，将源槽重新加入源组。

创建额外的源组并更改路由关联

如果不想删除和重新添加原点，可以为 Azure Front Door 实例创建额外的原点组。然后，可以将路由关联到指向预期源的源组。

例如，可以创建两个额外的源组，一个用于主要（主动）区域，另一个用于备用（被动）区域。如果主要区域正在进行更改，请将路由与备用区域相关联。如果备用区域正在进行更改，请将路由与主要区域相关联。完成所有更改后，可将路由与包含这两个区域的原始源组相关联。此方法之所以可行，是因为一个路由每次只能与一个源组相关联。

请考虑使用三个源组的配置：

该 Main-Origin 组包含主 Web 应用和备用 Web 应用，每个应用位于各自的区域中。
该 Primary-Origin 组仅包含活动区域中的主 Web 应用。
该 Standby-Origin 组仅包含被动区域中的备用 Web 应用。

假设主 Web 应用正在进行更改。在更改开始之前，将 Main-Origin 组的路由关联更改为 Secondary-Origin 组。此操作可确保所有流量路由到其各自区域中的备用 Web 应用，而其所在区域中的主 Web 应用正在进行更改。

按照以下步骤更改源组的路由关联：

在 Azure 门户中，转到 Azure Front Door 实例。
在左侧菜单中，选择设置>源组。
在源组列表中，找到一个源组，该组显示“路由”列中的“未关联”指示器。
选择 “更多操作 ”（...） >关联终结点和路由。
在 “关联路由 ”窗格中，选择要与源组关联的一个或多个路由，然后选择“ 关联”。

限制对高级工具站点的访问

借助Azure 应用服务，SCM/高级工具站点用于管理应用并部署应用程序源代码。请考虑锁定 SCM/高级工具站点，因为很可能不需要通过 Front Door 访问此站点。例如，你可以设置访问限制，以便仅允许你自己通过所选工具执行测试和启用持续部署。如果使用部署槽（特别是对于生产槽），可以拒绝对 SCM 站点的绝大部分访问，因为测试和验证使用过渡槽来完成。

反馈

此页面是否有帮助？

Last updated on 2026-04-14

通过

教程：在 Azure 应用服务 中创建高度可用的多区域应用

Prerequisites

查看方案体系结构

创建资源组

创建两个应用服务计划

创建两个应用程序

配置Azure Front Door

创建个人资料

添加终结点

创建源组

将源添加到源组

添加路由规则

仅通过Azure Front Door限制访问

测试访问限制

测试 Azure Front Door 部署

清理资源

从 ARM 或 Bicep 部署

常见问题

管理和部署基础结构和Azure资源

使用过渡槽实现安全部署到生产环境

在应用服务上禁用基本身份验证

在禁用基本身份验证的情况下，使用持续部署。

使用GitHub Actions创建服务主体和凭据

创建GitHub Actions工作流

使用槽流量路由测试应用更新

将代码从过渡槽移至生产槽

使用多区域部署避免中断和连续性问题

创建额外的源组并更改路由关联

限制对高级工具站点的访问

相关内容

反馈

其他资源

教程：在 Azure 应用服务中创建高度可用的多区域应用