本文介绍 Azure Functions 中的可靠性支持，还介绍了可用性区域的区域内部复原能力以及跨区域恢复和业务连续性。 有关 Azure 中可靠性原则的更详细概述，请参阅 Azure 可靠性。
Azure Functions 的可用性区域支持取决于 Functions 托管计划：
| 托管计划 | 支持级别 | 有关详细信息 |
|---|---|---|
| 灵活消费计划 | 预览 | 选择本文顶部的 Flex Consumption。 |
| 弹性高级计划 | 乔治亚州 | 选择本文顶部的Premium。 |
| 专用（应用服务）计划 | 乔治亚州 | 请参阅 Azure 应用服务中的可靠性。 |
| 消耗计划 | n/a | 消耗计划不支持。 |
可用性区域是每个 Azure 区域内在物理上独立的数据中心组。 当一个区域发生故障时，服务可以故障转移到其余区域中的一个。
有关 Azure 中可用性区域的详细信息，请参阅什么是可用性区域？
Azure Functions 支持区域冗余部署。
可用性区域支持
重要
在 Flex Consumption 计划中托管应用时，对可用性区域的支持目前为预览版。
将 Flex Consumption 计划应用配置为区域冗余时，平台会自动将函数应用的实例分散到所选区域中的区域，并针对始终就绪实例和按需实例使用不同的规则。
在 Flex Consumption 计划中启用区域冗余时，实例分布在以下规则中确定：
将 Elastic Premium 函数应用计划配置为区域冗余时，平台会自动将函数应用实例分散到所选区域中的区域。
使用区域冗余部署的实例扩展是在以下规则中确定的，即使在应用横向缩减时也是如此：
- 最小函数应用实例计数为 3。
- 如果指定容量大于区域数，则仅当容量是区域数的倍数时，实例才会均匀分布。
- 对于容量值超过区域数 * 实例数，额外实例分布在剩余区域中。
重要
Azure Functions 可在 Azure 应用服务平台上运行。 在应用服务平台中，托管高级计划函数应用的计划称为弹性高级计划，SKU 名称如下所示 EP1。 如果您选择在高级计划上运行您的函数应用，请确保创建一个从 SKU 名称 E 开始的计划，例如 EP1。 以P开头的应用服务计划 SKU 名称，例如P1V2（高级 V2 小型计划），是专用托管计划。 由于这些计划是独享版而非弹性高级版，因此，SKU 名称以 P 开头的计划不会动态扩展，并且可能会增加成本。
区域可用性
目前，并非所有区域都支持弹性消耗计划的区域冗余。 可以使用 Azure CLI 查看支持它的区域：
如果尚未这样做，请使用 Azure CLI 安装和登录到 Azure：
az login使用
az login命令登录到 Azure 帐户。使用此命令
az functionapp list-flexconsumption-locations和选项--zone-redundant=true可返回当前支持区域冗余弹性消耗计划的区域列表：az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table
在 Azure 门户中创建 Flex Consumption 应用时，如果您选择的区域支持，Zone redundancy页面的部分将被启用。
区域冗余高级计划在以下区域中可用：
| 美洲 | 欧洲 | 中东 | 非洲 | 亚太区 |
|---|---|---|---|---|
| 巴西南部 | 法国中部 | 以色列中部 | 南非北部 | 澳大利亚东部 |
| 加拿大中部 | 德国中西部 | 卡塔尔中部 | 印度中部 | |
| 美国中部 | 意大利北部 | 阿拉伯联合酋长国北部 | 中国北部 3 | |
| 美国东部 | 北欧 | 东亚 | ||
| 美国东部 2 | 挪威东部 | 日本东部 | ||
| 美国中南部 | 瑞典中部 | 东南亚 | ||
| 美国西部 2 | 瑞士北部 | |||
| 美国西部 3 | 英国南部 | |||
| 西欧 |
先决条件
可用区支持是 Flex Consumption 计划的一个功能属性。 下面是使用可用性区域的当前注意事项：
- 可以在 创建应用期间在计划中启用可用性区域。
- 可以通过更新计划资源设置 来启用或禁用可用性区域 。
- 必须为函数应用的默认主机存储帐户使用区域冗余存储帐户（ZRS）。 如果使用不同类型的存储帐户，应用可能会在区域中断期间行为异常。
- 必须托管在 Flex 消耗计划上。
可用性区域支持是高级计划的一个属性。 下面是可用性区域的当前注意事项：
- 只能在创建应用时在计划中启用可用性区域。 无法将现有高级计划转换为使用可用性区域。
- 必须为函数应用的默认主机存储帐户使用区域冗余存储帐户（ZRS）。 如果使用不同类型的存储帐户，应用可能会在区域中断期间行为异常。
- 同时支持 Windows 和 Linux。
- 在高级计划上托管的函数应用必须至少有三个 始终就绪的实例。
- 如果指定的实例计数小于 3，平台将在后台强制执行此最小计数。
- 如果你未使用高级计划、未使用支持可用性区域的缩放单元、不在支持的区域或者不确定，请参阅迁移指南。
定价
启用可用性区域不会产生相关的单独计量器。 用于区域冗余 Flex 消耗应用的实例的定价与单个区域 Flex 消耗应用相同。 若要了解详细信息，请参阅计费。
在应用程序中启用可用性区域时，如果每个函数缩放函数或组的始终就绪实例配置少于两个实例，平台会自动为每个函数缩放函数或组创建两个始终就绪类型的实例。 这些新实例也作为始终就绪的实例计费。
启用可用性区域不会产生相关的额外费用。 区域冗余高级应用服务计划的定价与单个区域高级计划相同。 对于你所使用的每个应用服务计划，我们会根据所选的 SKU、指定的容量以及根据自动缩放条件缩放到的任何实例收费。 如果在少于三个实例的计划上启用可用性区域，则平台会针对该应用服务计划强制实施最小实例计数 3，并且你对所有三个实例收费。
在区域冗余计划中创建函数应用程序
目前可通过多种方式部署区域冗余的 Flex Consumption 应用。
在 Azure 门户中，转到“创建函数应用”页。 有关在门户中创建函数应用的详细信息，请参阅创建函数应用。
选择 弹性消耗 ，然后选择 “选择 ”按钮。
在 “创建函数应用”（弹性消耗） 页上的 “基本信息 ”选项卡上，输入函数应用的设置。 请特别注意下表中提到了区域冗余具体要求的设置（以下屏幕截图中也突出显示了这些设置）。
设置 建议的值 有关区域冗余的说明 区域 首选支持的区域 创建 Flex 消耗计划的区域。 必须选择支持可用性区域的区域。 选择“区域可用性列表”。 区域冗余 已启用 此设置指定应用是否为区域冗余。 只有在选择支持区域冗余的区域时，才能选择 Enabled。
在“存储”选项卡上，输入函数应用存储帐户的设置。 请特别注意下表中提到了区域冗余具体要求的设置。
设置 建议的值 有关区域冗余的说明 存储帐户 一个区域冗余存储帐户 如先决条件部分中所述，我们强烈建议为区域冗余的函数应用使用区域冗余存储帐户。 在函数应用创建过程的其余步骤中，请照常创建函数应用。 在创建过程的其余步骤中，没有任何设置会影响区域冗余。
创建和部署区域冗余计划后，新计划上托管的 Flex Consumption 函数应用被视为区域冗余。
将 Flex 消耗计划更新为区域冗余计划
更改应用的冗余区域需要重启，这会导致应用停机。
在将 Flex 消耗计划更新为区域冗余之前，应将默认主机存储帐户也更新为区域冗余。 如果对应用的部署容器使用单独的存储帐户，还应将其更新为区域冗余。
为存储帐户即将发生的更改做准备，请使用以下步骤：
- 查看 存储注意事项。
- 创建或标识区域冗余存储帐户，作为应用的默认主机存储帐户。
- 更新应用的存储相关应用程序设置，例如
AzureWebJobsStorage，引用区域冗余存储帐户。 请参阅 “使用应用程序设置”。 - 更新应用的部署存储帐户，该帐户可能与与应用关联的存储帐户相同或不同。 请参阅 “配置部署设置”。
更新应用使用的存储帐户后，可以使用 Bicep 或 ARM 模板将 Flex Consumption 计划更新为区域冗余计划。 Azure 门户目前不支持对计划进行区域冗余更新。
目前可通过两种方式部署区域冗余的高级计划和函数应用。 可以使用 Azure 门户或 ARM 模板。
在 Azure 门户中，转到“创建函数应用”页。 有关在门户中创建函数应用的详细信息，请参阅创建函数应用。
选择“Functions 高级计划”，然后选择“选择”按钮。
在“创建函数应用(Functions 高级计划)”页的“基本信息”选项卡上，输入函数应用的设置。 请特别注意下表中提到了区域冗余具体要求的设置（以下屏幕截图中也突出显示了这些设置）。
设置 建议的值 有关区域冗余的说明 区域 首选支持的区域 在其中创建弹性高级计划的区域。 必须选取支持可用性区域的地区。 选择“区域可用性列表”。 定价计划 弹性高级计划之一。 有关详细信息，请参阅可用的实例 SKU。 本文将说明如何在高级计划中创建区域冗余的应用。 区域冗余目前在消耗计划中不可用。 有关应用服务计划的区域冗余的信息，请参阅 Azure 应用服务的可靠性。 区域冗余 已启用 此设置指定应用是否为区域冗余。 除非你选择了支持区域冗余的区域，否则无法选择 Enabled，如之前所述。
在“存储”选项卡上，输入函数应用存储帐户的设置。 请特别注意下表中提到了区域冗余具体要求的设置。
设置 建议的值 有关区域冗余的说明 存储帐户 一个区域冗余存储帐户 如先决条件部分中所述，我们强烈建议为区域冗余的函数应用使用区域冗余存储帐户。 在函数应用创建过程的其余步骤中，请照常创建函数应用。 在创建过程的其余步骤中，没有任何设置会影响区域冗余。
创建并部署区域冗余的计划后，在新计划中托管的任何函数应用将被视为区域冗余的应用。
可用性区域迁移
目前无法更改现有函数应用的弹性高级计划的可用性区域支持。 有关如何将公共多租户高级计划从不可使用区域迁移到可用性区域支持的信息，请参阅 将应用服务迁移到可用性区域支持。
区域故障体验
区域冗余 Flex 消耗计划的所有可用函数应用实例均已启用并正在处理事件。 即使同一地区的其他区域发生中断，弹性消费应用仍会继续运行。 但是，由于其他可用性区域的故障，非运行时行为可能会受到影响。 可能影响可用性的标准函数应用行为包括：
- 规模化
- 应用创建
- 配置更改
- 部署
Flex Consumption 计划的区域冗余仅保证正在运行的已部署应用程序的持续运行时间。
当某个区域出现故障时，Functions 会检测丢失的实例，并根据需要自动尝试在可用区域中查找或创建替换实例。 在区域性服务中断期间，平台会尝试在剩余的可用区域上恢复平衡。
区域冗余的函数应用的所有可用函数应用实例均已启用并正在处理事件。 在某个区域出现故障时，Functions 会检测丢失的实例并根据需要自动尝试查找新的替换实例。 弹性缩放行为仍适用。 但是，在发生区域故障的情况下，无法保证对更多实例的请求能够成功，因为系统按照尽力而为的原则填补丢失的实例。 即使同一区域中的其他局部区域发生服务中断，部署在启用了可用性区域的高级计划中的应用程序也会继续运行。 但是，非运行时行为仍有可能受到其他可用区域中的中断的影响。 这些受影响的行为可能包括高级计划缩放、应用程序创建、应用程序配置和应用程序发布。 高级计划的区域冗余仅保证已部署应用程序的持续正常运行时间。
在 Functions 将实例分配到区域冗余高级计划时，它使用由基础 Azure 虚拟机规模集提供的最大程度区域均衡。 如果每个区域在高级计划使用的其他所有区域中具有相同数量的虚拟机，或者减去一个虚拟机，则高级计划被视为均衡计划。
跨区域灾难恢复和业务连续性
灾难恢复（DR）是指组织用来从高影响事件（例如自然灾害或导致停机和数据丢失的部署）中恢复的做法。 不管灾难的原因是什么，最好的补救措施就是一个定义全面且经过测试的 DR 计划，以及一个主动支持 DR 的应用程序设计。 在开始创建灾难恢复计划之前，请参阅 有关设计灾难恢复策略的建议。
对于灾难恢复，Microsoft使用共同责任模型。 在此模型中，Microsoft确保基线基础结构和平台服务可用。 但是，许多 Azure 服务不会自动复制数据，也不会从失败的区域回退到另一个已启用的区域。 对于这些服务，你负责设置适用于工作负载的灾难恢复计划。 在 Azure 平台即服务 (PaaS) 产品/服务上运行的大多数服务都提供支持 DR 的功能和指南。 可以使用服务特定的功能来支持快速恢复，从而帮助制定灾难恢复计划。
本部分介绍一些可用于部署函数应用以允许灾难恢复的策略。
有关 Durable Functions 的灾难恢复，请参阅 Azure Durable Functions 中的灾难恢复和地理分布。
多区域灾难恢复
由于没有可用的内置冗余，因此函数在特定 Azure 区域中的函数应用中运行。 为了避免中断期间执行丢失，可以通过冗余方式将相同的函数部署到多个区域的函数应用。 若要详细了解多区域部署，请参阅高可用性多区域 Web 应用程序中的指南。
在多个区域运行相同的函数代码时，可以考虑使用两种模式：主动-主动和主动-被动。
HTTP 触发器函数的主动-主动模式
使用主动-主动模式时，两个区域中的函数都以重复或轮流的方式主动运行和处理事件。 你应将主动-主动模式与 Azure Front Door 结合使用，以处理关键的 HTTP 触发函数，这些函数可以在多个区域运行的函数之间路由和轮询 HTTP 请求。 Front Door 还可定期检查每个终结点的运行状况。 当一个区域中的函数停止响应运行状况检查时，Azure Front Door 会将该函数退出轮转，仅将流量转发到剩余的正常函数。
有关示例，请参阅有关如何 通过将 API 部署到分布式 Azure 区域中的地理区域来实现地理定位模式的示例。
非 HTTP 触发器函数的主动-被动模式
建议对事件驱动的非 HTTP 触发函数（例如服务总线和事件中心触发的函数）使用主动-被动模式。
若要为非 HTTP 触发器函数创建冗余，请使用主动-被动模式。 使用主动-被动模式时，函数在接收事件的区域中主动运行，而第二个区域中的相同函数保持空闲状态。 主动-被动模式提供了一种每条消息仅由一个函数处理的方法，通过提供了一种机制，便于在发生灾难时故障转移到次要区域。 函数应用使用合作伙伴服务的故障转移行为，例如 Azure 服务总线异地恢复和 Azure 事件中心异地恢复。
请考虑使用 Azure 事件中心触发器的示例拓扑。 在这种情况下，主动/被动模式需要涉及以下组件：
- Azure 事件中心已同时部署到主要区域和次要区域。
- 已启用异地灾难恢复以将主事件中心和辅助事件中心配对。 这还会创建一个“别名”，用于连接到事件中心，并从主要区域切换到次要区域，而无需更改连接信息。
- 函数应用部署到主要和次要（故障转移）区域，次要区域的应用实质上处于空闲状态，因为消息不会发送到该区域。
- 函数应用在其各自事件中心的直接（非别名）连接字符串上触发。
- 事件中心的发布服务器应发布到别名连接字符串。
在故障转移之前，发送到共享别名的发布服务器将路由到主事件中心。 主要函数应用专门侦听主事件中心。 次要函数应用处于被动和空闲状态。 启动故障转移后，发送到共享别名的发布服务器会路由到次要事件中心。 次要函数应用现在将处于活动状态并开始自动触发。 可以完全从事件中心驱动到次要区域的有效故障转移，并且仅当各自的事件中心处于活动状态时，函数才变为活动状态。
详细了解如何在服务总线和事件中心之间进行故障转移以及需要注意的事项。
非 HTTPS 触发器函数的主动-主动模式
尽管建议对非 HTTPS 触发器函数使用 主动-被动模式 ，但仍可以为非 HTTP 触发的函数创建主动-主动部署。 在实现此模式之前，必须考虑两个活动区域如何相互交互或协调。
例如，设想将相同的服务总线触发的函数代码部署到两个区域，但都在同一服务总线队列上触发。 在这种情况下，两个函数在对单个队列取消排队时都充当竞争使用者。 虽然每个消息只能由两个应用实例之一进行处理，但也意味着仍有一个故障点，即单个服务总线实例。
可以改为部署两个服务总线队列，其中一个在主要区域中，一个位于次要区域中。 在这种情况下，可以拥有两个函数应用，每个函数应用都指向区域中活跃的服务总线队列。 此拓扑面临的挑战是如何在两个区域之间分发队列消息。 通常情况下，这意味着每个发布服务器都会尝试将消息发布到两个区域，并且每条消息都由两个活动的函数应用进行处理。 虽然这样会形成所需的“主动/主动”模式，但也会在复制计算以及何时/如何合并数据方面带来其他难题。