Azure 应用服务的可靠性

本文介绍 Azure 应用服务的可靠性支持，并介绍了可用性区域的区域内部复原能力以及跨区域灾难恢复和业务连续性。 有关 Azure 中可靠性原则的更详细概述，请参阅 Azure 可靠性。

Azure 应用服务是基于 HTTP 的服务，用于托管 Web 应用程序、REST API 和移动后端；并将 Microsoft Azure 的强大功能添加到应用程序，例如：

• 安全性
• 负载均衡
• 自动缩放
• 自动化管理

若要了解 Azure 应用服务如何增强应用程序工作负载的可靠性和复原能力，请参阅为何使用应用服务？

可靠性建议

本部分包含针对实现复原能力和可用性的建议。 每个建议可归入以下两个类别之一：

• 运行状况项涵盖配置项目和构成 Azure 工作负载的主要组件的正确功能等方面，例如 Azure 资源配置设置、对其他服务的依赖项等。

• 风险项涵盖可用性和恢复要求、测试、监视、部署和其他项目（如果未解决，则会增加环境中出现问题的可能性）等方面。

可靠性建议优先级矩阵

每项建议都根据以下优先级矩阵进行标记：

映像	优先级	说明
	高	需要立即修复。
	中	在 3-6 个月内修复。
	低	需要审查。

可靠性建议摘要

类别	优先级	建议
高可用性		ASP-1 - 部署区域冗余应用服务计划
复原能力		ASP-2 - 使用支持可用性区域的应用服务计划
		ASP-4 - 为生产和测试创建单独的应用服务计划
伸缩性		ASP-3 - 避免频繁纵向扩展或缩减
		ASP-5 - 启用“自动缩放/自动扩展”，以确保有足够的资源可用于服务请求

高可用性

ASP-1 - 部署区域冗余应用服务计划

若要增强业务关键型工作负载的复原能力和可靠性，建议使用区域冗余部署新的应用服务计划。 按照步骤 重新部署到可用性区域支持，配置管道以在新的应用服务计划中重新部署 Web 应用，然后使用蓝绿部署方法故障转移到新站点。

通过将应用程序分布在多个可用性区域中，即使在数据中心级别出现故障的情况下，也可以确保其持续运行。 有关 Azure 应用服务中可用性区域支持的详细信息，请参阅可用性区域支持。

// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://docs.azure.cn/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A

resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, tags, param1=sku_tier, param2="Not Zone Redundant"

复原

ASP-2 - 使用支持可用性区域的应用服务计划

可用性区域支持仅适用于某些应用服务计划。 若要查看使用可用性区域所需的计划，请参阅可用性区域先决条件。

// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the "Standard", "Premium", or "IsolatedV2" SKU tiers.

resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
        tolower(sku_tier) !contains "premium" and
        tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, tags, param1= strcat("SKU=",sku_tier)

ASP-4 - 为生产和测试创建单独的应用服务计划

若要增强业务关键型工作负载的复原能力和可靠性，应将现有的应用服务计划和应用服务环境迁移到可用性区域支持。 通过将应用程序分布在多个可用性区域中，即使在数据中心级别出现故障的情况下，也可以确保其持续运行。 有关 Azure 应用服务中可用性区域支持的详细信息，请参阅可用性区域支持。

伸缩性

ASP-3 - 避免频繁纵向扩展或缩减

建议避免频繁纵向扩展或缩减 Azure 应用服务实例。 相反，请选择可以处理典型工作负载的适当层和实例大小，并横向扩展实例以适应流量的变化。 纵向扩展或缩减可能会触发应用程序重启，这可能会导致服务中断。

ASP-5 - 启用“自动缩放/自动扩展”，以确保有足够的资源可用于服务请求

建议为 Azure 应用服务启用自动缩放/自动扩展，以确保有足够的资源来处理传入的请求。 自动缩放是基于规则的缩放，而自动扩展根据 HTTP 流量执行自动传入和横向扩展。 有关详细信息，请参阅 Azure 应用服务中的自动扩展或在 Azure 中开始使用自动缩放。

// under-development

可用性区域支持

Azure 可用性区域是每个 Azure 地区内的至少三个在物理上独立的数据中心组。 每个区域中的数据中心都配备了独立的电源、冷却系统和网络基础结构。 在本地区域发生故障的情况下，设计可用性区域，以便一个区域受到影响时，其余两个区域支持区域服务、容量和高可用性。

故障范围包括软件和硬件故障，以及地震、洪水和火灾等事件。 容错是通过 Azure 服务的冗余和逻辑隔离来实现的。 有关 Azure 中可用性区域的详细信息，请参阅地区和可用性区域。

已启用 Azure 可用性区域的服务旨在提供适当级别的可靠性和灵活性。 可以通过两种方式进行相关配置。 可以采用区域冗余配置，实现跨区域自动复制，也可以采用区域性配置，将实例固定到特定区域。 还可以将这些方法结合。 有关区域与区域冗余体系结构的详细信息，请参阅有关使用可用性区域和区域的建议。

可以跨可用性区域 (AZ) 部署 Azure 应用服务，以帮助实现业务关键型工作负载的复原能力和可靠性。 此体系结构也称为区域冗余。

将应用服务配置为区域冗余时，平台会自动将 Azure 应用服务计划的实例分布到所选区域的三个区域。

使用区域冗余部署的实例扩展是在以下规则中确定的，即使在应用横向缩减时也是如此：

• 最小应用服务计划实例计数为 3。
• 如果指定容量大于 3，并且实例数可被 3 整除，则这些实例会均匀分布。
• 任何超过 3*N 的实例计数会分布在剩余的一两个区域中。

可用性区域支持是应用服务计划的一个属性。 可以使用应用服务环境 v3 在托管的多租户环境或专用环境中创建应用服务计划。 若要详细了解应用服务环境 v3，请参阅应用服务环境 v3 概述。

对于未配置为区域冗余的应用服务，VM 实例无法复原区域，并且可能会在该地区的任何区域发生中断时出现故障时间。

有关企业部署体系结构的信息，请参阅使用应用服务环境进行高可用性企业部署。

先决条件

下面是目前在启用可用性区域时的要求/限制：

• 同时支持 Windows 和 Linux。

• 可用性区域仅在较新的应用服务占用情况中受支持。 即使使用的是某个受支持的区域，如果资源组不支持可用性区域，也会收到错误。 若要确保工作负载位于支持可用性区域的缩放单元上，可能需要创建新的资源组、应用服务计划和应用服务。

• 应用服务计划必须是支持可用性区域的以下计划之一:

  • 在使用应用服务高级版 v2 或高级版 v3 计划的多租户环境中。
  • 在使用应用服务环境 v3 的专用环境中，它与独立 v2 应用服务计划一起使用。

• 对于专用环境，应用服务环境必须为 v3。

  重要

  应用服务环境 v2 和 v1 将于 2024 年 8 月 31 日停用。 应用服务环境 v3 更易于使用，并且运行在功能更强大的基础结构上。 要详细了解应用服务环境 v3，请参阅应用服务环境概述。 如果当前正在使用应用服务环境 v2 或 v1，并且希望升级到 v3，请按照本文中的步骤迁移到新版本。

• 强制实施三个区域的最小实例计数。 如果指定的实例计数小于 3，平台将在后台强制执行此最小计数。

• 只能在创建新的应用服务计划时指定可用性区域。 无法将现有的应用服务计划转换为使用可用性区域。

• 以下区域支持在多租户环境中运行的 Azure 应用服务:

  • 由世纪互联运营的 Azure：中国北部 3

• 若要查看哪些区域支持适用于应用服务环境 v3 的可用性区域，请查看区域。

创建启用可用性区域的资源

部署多租户区域冗余应用服务

az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6

"resources": [
  {
    "type": "Microsoft.Web/serverfarms",
    "apiVersion": "2018-02-01",
    "name": "your-appserviceplan-name-here",
    "location": "chinanorth3",
    "sku": {
        "name": "P1v3",
        "tier": "PremiumV3",
        "size": "P1v3",
        "family": "Pv3",
        "capacity": 3
    },
    "kind": "app",
    "properties": {
        "zoneRedundant": true
    }
  }
]

使用专用环境部署区域冗余应用服务

若要了解如何在独立 v2 计划上创建应用服务环境 v3，请查看创建应用服务环境。

疑难解答

容错

要为可用性区域失败做好准备，应过度预配服务容量，以确保解决方案可以容忍 1/3 的容量损失，并在区域范围的中断期间继续正常运行，而不会降低性能。 由于平台将 VM 分散到三个区域，并且你至少需要考虑一个区域的故障，因此将峰值工作负载实例计数乘以“区域/(区域-1)”或 3/2。 例如，如果你的典型峰值工作负载需要四个实例，则应预配六个实例：（2/3 * 6 个实例）= 4 个实例。

区域故障体验

流量将路由到所有可用的应用服务实例。 在区域关闭时，应用服务平台将检测丢失的实例并自动尝试查找新的替换实例并根据需要分散流量。 如果配置了自动缩放，并且如果确定需要更多实例，则自动缩放还会向应用服务发出请求以添加更多实例。 请注意，自动缩放行为与应用服务平台行为无关，并且自动缩放实例计数规范不需要是三的倍数。

即使同一 Azure 区域中的其他局部区域发生服务中断，在启用了可用性区域的应用服务计划中部署的应用程序也仍可正常运行并为流量提供服务。 但是，非运行时行为（包括应用服务计划缩放、应用程序创建、应用程序配置和应用程序发布）可能仍然会受其他可用性区域中的中断的影响。 应用服务计划的区域冗余仅确保已部署应用程序的持续正常运行时间。

应用服务平台将实例分配给区域冗余应用服务计划时，它使用由基础 Azure 虚拟机规模集提供的最大程度区域均衡。 如果每个区域具有相同数量的 VM，或者与在应用服务计划使用的所有其他区域中的 VM 数相差 1，则应用服务计划“已实现均衡”。

可用性区域迁移

无法将现有应用服务实例或环境资源从非可用性区域支持迁移到可用性区域支持。 要获取对可用性区域的支持，需要创建启用了可用性区域的资源。

定价

启用可用性区域不会产生额外的成本。 区域冗余应用服务的定价与单区域应用服务相同。 将根据应用服务计划 SKU、指定的容量以及根据自动缩放条件扩展到的任何实例向你收费。 如果启用可用性区域但指定的容量小于 3，则平台将强制执行最小实例计数 3，并针对这三个实例向你收费。 有关应用服务环境 v3 的定价信息，请查看定价。

跨区域灾难恢复和业务连续性

灾难恢复 (DR) 是指从会导致故障时间和数据丢失的高影响事件（例如自然灾害或部署失败）中恢复。 不管灾难的原因是什么，最好的补救措施就是一个定义全面且经过测试的 DR 计划，以及一个主动支持 DR 的应用程序设计。 在开始考虑创建灾难恢复计划之前，请参阅设计灾难恢复策略的建议。

在 DR 方面，Azure 使用共同责任模型。 在共担责任模型中，Azure 会确保基线基础结构和平台服务可用。 同时，许多 Azure 服务不会自动复制数据，也不会从失败区域回退以交叉复制到另一个启用的区域。 对于这些服务，你负责设置适用于工作负载的灾难恢复计划。 大多数在 Azure 平台即服务 (PaaS) 产品/服务上运行的服务都提供支持 DR 的功能和指导，你可以使用特定于服务的功能来支持快速恢复，从而帮助制定 DR 计划。

本部分介绍部署到应用服务的 Web 应用的一些常见策略。

在应用服务中创建 Web 应用并在资源创建过程中选择 Azure 区域时，它是单区域应用。 当该区域在灾难期间变为不可用时，应用程序也变得不可用。 如果使用多区域地理体系结构在次要 Azure 区域中创建相同的部署，则应用程序更容易遭受单区域灾难，从而保证业务连续性。 跨区域的任何数据复制都允许恢复最后一个应用程序状态。

对于 IT，业务连续性计划主要由恢复时间目标 (RTO) 和恢复点目标 (RPO) 驱动。 有关 RTO 和 RPO 的详细信息，请参阅恢复目标。

当发生区域性灾难时，围绕恢复时间目标维护服务级别协议是不切实际的，通常只围绕恢复点目标来设计灾难恢复策略（即专注于恢复数据，而不是尽量减少中断）。 但是，借助 Azure，部署应用服务进行自动异地复制故障转移不仅可行，甚至可以很简单。 这样一来，就可以兼顾 RTO 和 RPO，从而进一步提高应用程序的抗灾难能力。

根据所需的 RTO 和 RPO 指标，三种灾难恢复体系结构通常用于应用服务多租户环境和应用服务环境。 下表描述了每个体系结构：

多区域地理位置中的灾难恢复

有多种方法可以在主动-主动或主动-被动体系结构中跨 Azure 区域复制 Web 应用内容和配置，例如使用应用服务备份和还原。 但是，备份和还原会创建时间点快照，并最终导致跨区域出现 Web 应用版本控制挑战。 有关回退和还原指导与灾难恢复指导之间的比较，请参阅下表：

备份和还原与灾难恢复

为了避免备份和还原方法的限制，请将 CI/CD 管道配置为将代码部署到两个 Azure 区域。 请考虑使用 Azure Pipelines 或 GitHub Actions。 有关详细信息，请参阅持续部署到 Azure 应用服务。

服务中断检测、通知和管理

• 建议为 Web 应用设置监视和警报，以便在灾难期间及时通知。 有关详细信息，请参阅 Application Insights 可用性测试。

• 若要在 Azure 中管理应用程序资源，请使用基础结构即代码 (IaC) 机制。 在跨多个区域的复杂部署中，若要独立管理区域并以可靠方式使配置跨区域保持同步，需要一个可预测、可测试和可重复的流程。 请考虑使用 IaC 工具，例如 Azure 资源管理器模板或 Terraform。

设置灾难恢复和中断检测

若要为多区域地理位置中的灾难恢复做好准备，可以使用主动-主动或主动-被动体系结构。

主动-主动体系结构

在主动-主动灾难恢复体系结构中，相同的 Web 应用部署在两个单独的区域中，Azure Front Door 用于将流量路由到两个活动区域。

在此示例体系结构中：

• 相同的 Azure 应用服务应用部署在两个单独的区域，包括定价层和实例计数。
• 阻止直接发送到应用服务应用的公共流量。
• Azure Front Door 用于将流量路由到这两个活动区域。
• 发生灾难时，其中一个区域变为脱机状态，Azure Front Door 专门将流量路由到保持联机状态的区域。 此类异地故障转移期间的 RTO 接近于零。
• 应使用 CI/CD 解决方案将应用程序文件部署到这两个 Web 应用。 这样可以确保 RPO 几乎为零。
• 如果应用程序主动修改文件系统，最大限度减少 RPO 的最佳方式是仅写入已装载的 Azure 存储共享，而不是直接写入 Web 应用的 /home 内容共享。 然后，将 Azure 存储冗余功能（GZRS 或 GRS）用于装载式共享，其 RPO 约为 15 分钟。

在 Azure 应用服务中为 Web 应用创建主动-主动体系结构的步骤汇总如下：

1. 在两个不同的 Azure 区域中创建两个应用服务计划。 以相同方式配置这两个应用服务计划。

2. 创建 Web 应用的两个实例，每个应用服务计划中一个实例。

3. 创建 Azure Front Door 配置文件，具体要求如下：

   • 一个终结点。
   • 两个源组，每个源组的优先级为 1。 同等优先级告诉 Azure Front Door 将流量平均路由到这两个区域（因此是主动-主动）。
   • 路由。

4. 将网络流量限制为仅从 Azure Front Door 实例流向 Web 应用。

5. 设置和配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。

6. 通过持续部署将代码部署到这两个 Web 应用。

主动-被动体系结构

在此灾难恢复方法中，相同的 Web 应用部署在两个单独的区域中，Azure Front Door 用于仅将流量路由到一个区域（即活动区域）。

在此示例体系结构中：

• 相同的应用服务应用部署在两个不同的区域中。

• 阻止直接发送到应用服务应用的公共流量。

• Azure Front Door 用于将流量路由到主要区域。

• 为了节省成本，辅助应用服务计划配置为包含更少的实例和/或位于较低的定价层中。 有以下三个可能的方式：

  • 首选辅助应用服务计划与主计划具有相同的定价层，实例数或更少。 此方法可确保两个应用服务计划的功能和虚拟机大小奇偶校验。 异地故障转移期间的 RTO 仅取决于横向扩展实例的时间。

  • 不太首选辅助应用服务计划具有相同的定价层类型（例如 PremiumV3）但虚拟机大小较小，实例较少。 例如，主要区域可能位于 P3V3 层，而次要区域位于 P1V3 层。 此方法仍可确保两个应用服务计划的功能奇偶校验，但当次要区域成为活动区域时，由于缺少大小奇偶校验，可能需要手动纵向扩展。 异地故障转移期间的 RTO 同时取决于横向扩展和纵向扩展实例的时间。

  • 最不首选辅助应用服务计划具有与主实例和较小实例不同的定价层。 例如，主要区域可能位于 P3V3 层，而次要区域位于 S1 层。 确保辅助应用服务计划具有应用程序运行所需的所有功能。 两者之间的功能可用性差异可能会导致 Web 应用恢复延迟。 异地故障转移期间的 RTO 同时取决于横向扩展和纵向扩展实例的时间。

• 在次要区域配置为当活动区域变为非活动时进行自动缩放。 建议在主动和被动区域中具有类似的自动缩放规则。

• 在灾难期间，主要区域变为非活动状态，次要区域开始接收流量，并成为活动区域。

• 次要区域变为活动区域后，网络负载会触发预配置的自动缩放规则来横向扩展辅助 Web 应用。

• 如果次要区域还没有作为活动区域运行所需的功能，则可能需要手动纵向扩展定价层。 例如，自动缩放需要标准层或更高版本。

• 当主要区域再次处于活动状态时，Azure Front Door 会自动将流量定向回该区域，并且体系结构将像以前一样返回到主动-被动模式。

• 应使用 CI/CD 解决方案将应用程序文件部署到这两个 Web 应用。 这样可以确保 RPO 几乎为零。

• 如果应用程序主动修改文件系统，最大限度减少 RPO 的最佳方式是仅写入已装载的 Azure 存储共享，而不是直接写入 Web 应用的 /home 内容共享。 然后，将 Azure 存储冗余功能（GZRS 或 GRS）用于装载式共享，其 RPO 约为 15 分钟。

在 Azure 应用服务中为 Web 应用创建主动-被动体系结构的步骤汇总如下：

1. 在两个不同的 Azure 区域中创建两个应用服务计划。 可以使用前面提到的方法之一预配辅助应用服务计划。
2. 为辅助应用服务计划配置自动缩放规则，以便在主要区域变为非活动状态时，该计划缩放到与主要计划相同的实例计数。
3. 创建 Web 应用的两个实例，每个应用服务计划中一个实例。
4. 使用以下项创建 Azure Front Door 配置文件：
   • 一个终结点。
   • 主要区域拥有一个优先级为 1 的源组。
   • 次要区域拥有一个优先级为 2 的次要源组。 优先级的差异告诉 Azure Front Door 在联机时首选主要区域（因此为主动-被动）。
   • 路由。
5. 将网络流量限制为仅从 Azure Front Door 实例流向 Web 应用。
6. 设置和配置所有其他后端 Azure 服务，例如数据库、存储帐户和身份验证提供程序。
7. 通过持续部署将代码部署到这两个 Web 应用。

被动-冷体系结构

使用被动/冷体系结构在位于另一区域的 Microsoft Azure 存储帐户中创建和维护 Web 应用的常规备份。

在此示例体系结构中：

• 将单个 Web 应用部署到单一区域。

• Web 应用定期备份到同一区域中的 Azure 存储帐户。

• 备份的跨区域复制取决于 Azure 存储帐户中的数据冗余配置。 如果条件允许，应将 Azure 存储帐户设置为 GZRS 。 GZRS 在区域中提供同步区域冗余，在次要区域中提供异步区域冗余。 如果 GZRS 不可用，请将帐户配置为 GRS。 GZRS 和 GRS 的 RPO 约为 15 分钟。

• 若要确保在存储帐户的主要区域不可用时可以检索备份，请启用对次要区域的只读访问权限（存储帐户相应地设置为 RA-GZRS 或 RA-GRS）。 若要详细了解如何设计应用程序以利用异地冗余，请参阅使用异地冗余设计高度可用的应用程序。

• 在 Web 应用区域发生灾难期间，必须使用 Azure 存储帐户中的备份（很可能来自具有读取访问权限的次要区域）手动部署所有必需的App 服务依赖资源。 RTO 可能是几小时或几天。

• 若要最大程度地减少 RTO，强烈建议你提供一个全面的剧本，其中概述了将 Web 应用备份还原到另一个 Azure 区域所需的所有步骤。

在 Azure 应用服务中为 Web 应用创建被动冷区域的步骤汇总如下：

1. 在 Web 应用所在的同一区域中创建 Azure 存储帐户。 选择“标准性能层”，并选择冗余作为异地冗余存储 (GRS) 或异地区域冗余存储 (GZRS)。

2. 启用 RA-GRS 或 RA-GZRS（次要区域的读取访问）。

3. 为 Web 应用配置自定义备份。 你可以决定为 Web 应用备份设置计划，例如每小时一次。

4. 验证是否可以在存储帐户的次要区域检索 Web 应用备份文件。

单区域地理位置中的灾难恢复

如果 Web 应用的区域没有 GZRS 或 GRS 存储，或者你所在的 Azure 区域不是区域对中的一个，则需要利用区域冗余存储 (ZRS) 或本地冗余存储 (LRS) 来创建类似体系结构。 例如，可以如下所示，手动为存储帐户创建次要区域：

创建没有 GRS 和 GZRS 的被动冷区域的步骤汇总如下：

1. 在 Web 应用所在的同一区域中创建 Azure 存储帐户。 选择“标准性能层”，并选择冗余作为区域冗余存储 (ZRS)。

2. 为 Web 应用配置自定义备份。 你可以决定为 Web 应用备份设置计划，例如每小时一次。

3. 验证是否可以在存储帐户的次要区域检索 Web 应用备份文件。

4. 在另一个区域中创建第二个 Azure 存储帐户。 选择“标准性能层”，并选择冗余作为本地冗余存储 (LRS)。

5. 通过使用 AzCopy 等工具，将主要区域中的自定义备份（Zip、XML 和日志文件）复制到次要存储。 例如：

   azcopy copy 'https://<source-storage-account-name>.blob.core.chinacloudapi.cn/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.chinacloudapi.cn/<container-name>/<blob-path>'
   

   你可以将 Azure 自动化与 PowerShell 工作流 Runbook 一起配合使用，以便按计划运行复制脚本。 确保复制计划遵循与 Web 应用备份类似的计划。

后续步骤

• Azure 中的可靠性