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