Azure Functions 的可靠性
本文介绍 Azure Functions 中的可靠性支持，还介绍了可用性区域的区域内部复原能力以及跨区域恢复和业务连续性。 有关 Azure 中可靠性原则的更详细概述，请参阅 Azure 可靠性。
高级（弹性高级）计划和专用（应用服务）计划均可使用对 Azure Functions 的可用性区域支持。 本文重点介绍适用于高级计划的区域冗余支持。 有关专用计划的区域冗余，请参阅将应用服务迁移到可用性区域支持。
可用性区域支持
Azure 可用性区域是每个 Azure 地区内的至少三个在物理上独立的数据中心组。 每个区域中的数据中心都配备了独立的电源、冷却系统和网络基础结构。 在本地区域发生故障的情况下，设计可用性区域，以便一个区域受到影响时，其余两个区域支持区域服务、容量和高可用性。
故障范围包括软件和硬件故障，以及地震、洪水和火灾等事件。 容错是通过 Azure 服务的冗余和逻辑隔离来实现的。 有关 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 |
先决条件
可用性区域支持是高级计划的一个属性。 下面是目前在启用可用性区域时的要求/限制：
只能在为函数应用创建高级计划时启用可用性区域。 无法将现有高级计划转换为使用可用性区域。
必须为函数应用的存储帐户使用区域冗余存储帐户 (ZRS)。 如果使用不同类型的存储帐户，Functions 可能会在区域性中断期间显示意外行为。
同时支持 Windows 和 Linux。
必须承载于弹性高级或专用托管计划中。 若要了解如何将区域冗余与专用计划配合使用，请参阅将应用服务迁移到可用性区域支持。
- 可用性区域支持目前不适用于消耗计划中的函数应用。
托管在高级计划中的函数应用的始终就绪实例计数必须至少为 3 个。
- 如果指定的实例计数小于 3，平台将在后台强制执行此最小计数。
如果你未使用高级计划、未使用支持可用性区域的缩放单元、不在支持的区域或者不确定，请参阅迁移指南。
定价
启用可用性区域不会产生相关的额外费用。 区域冗余高级应用服务计划的定价与单个区域高级计划的相同。 对于你所使用的每个应用服务计划，我们会根据所选的 SKU、指定的容量以及根据自动缩放条件缩放到的任何实例收费。 如果启用了可用性区域，但为应用服务计划指定的容量少于 3 个，则平台将为该应用服务计划强制实施最小实例计数 3，并对这 3 个实例收费。
创建区域冗余高级计划和函数应用
目前可通过两种方式部署区域冗余的高级计划和函数应用。 可以使用 Azure 门户或 ARM 模板。
打开 Azure 门户并导航到“创建函数应用”页。 可在此处找到有关在门户中创建函数应用的信息。
在“基本信息”页中，填写函数应用的字段。 请特别注意下表中提到了区域冗余具体要求的字段（下面的屏幕截图中也突出显示了这些字段）。
设置 建议的值 有关区域冗余的说明 区域 首选区域 要在其下创建此新函数应用的订阅。 必须从上面的列表中选择一个启用了可用性区域的区域。 
在“托管”页中，填写函数应用托管计划的字段。 请特别注意下表中提到了区域冗余具体要求的字段（下面的屏幕截图中也突出显示了这些字段）。
设置 建议的值 有关区域冗余的说明 存储帐户 一个区域冗余存储帐户 如前面的先决条件部分中所述，我们强烈建议为区域冗余的函数应用使用区域冗余存储帐户。 计划类型 函数高级计划 本文将详细说明如何在高级计划中创建区域冗余的应用。 区域冗余目前在消耗计划中不可用。 可以在此文中找到有关应用服务计划的区域冗余的信息。 区域冗余 已启用 此字段填充用于确定你的应用是否为区域冗余应用的标志。 除非你选择了支持区域冗余的区域，否则无法选择 Enabled，如步骤 2 中所述。
在函数应用创建过程的其余步骤中，请照常创建函数应用。 在创建过程的其余步骤中，没有任何字段会影响区域冗余。
创建并部署区域冗余的计划后，在新计划中托管的任何函数应用将被视为区域冗余的应用。
可用性区域迁移
Azure 函数应用目前不支持就地迁移现有函数应用实例。 有关如何将公共多租户高级计划从非可用性区域迁移到可用性区域的支持的信息，请参阅《将应用服务迁移到可用性区域支持》。
区域故障体验
区域冗余的函数应用的所有可用函数应用实例均已启用并正在处理事件。 在某个区域出现故障时，Functions 会检测丢失的实例并根据需要自动尝试查找新的替换实例。 弹性缩放行为仍适用。 但是，在区域故障的情况下，不能保证额外实例的请求可以成功，因为系统会尽力回填丢失的实例。 即使同一区域中的其他局部区域发生服务中断，部署在启用了可用性区域的高级计划中的应用程序也会继续运行。 但是，非运行时行为仍有可能受到其他可用区域中的中断的影响。 这些受影响的行为可能包括高级计划缩放、应用程序创建、应用程序配置和应用程序发布。 高级计划的区域冗余仅保证已部署应用程序的持续正常运行时间。
在 Functions 将实例分配到区域冗余高级计划时，它使用由基础 Azure 虚拟机规模集提供的最大程度区域均衡。 当每个区域在高级计划使用的所有其他区域中具有相同数量的 VM（或 VM 数相差 1）时，高级计划被视为已实现均衡。
跨区域灾难恢复和业务连续性
灾难恢复 (DR) 是指从会导致故障时间和数据丢失的高影响事件（例如自然灾害或部署失败）中恢复。 不管灾难的原因是什么，最好的补救措施就是一个定义全面且经过测试的 DR 计划，以及一个主动支持 DR 的应用程序设计。 在开始考虑创建灾难恢复计划之前，请参阅设计灾难恢复策略的建议。
在 DR 方面，Azure 使用共同责任模型。 在共担责任模型中，Azure 会确保基线基础结构和平台服务可用。 同时，许多 Azure 服务不会自动复制数据，也不会从失败区域回退以交叉复制到另一个启用的区域。 对于这些服务，你负责设置适用于工作负载的灾难恢复计划。 大多数在 Azure 平台即服务 (PaaS) 产品/服务上运行的服务都提供支持 DR 的功能和指导，你可以使用特定于服务的功能来支持快速恢复，从而帮助制定 DR 计划。
本部分介绍可用于部署函数来实现灾难恢复的一些策略。
有关 Durable Functions 的灾难恢复，请参阅 Azure Durable Functions 中的灾难恢复和地理分布。
多区域灾难恢复
由于没有可用的内置冗余，因此函数在特定 Azure 区域中的函数应用中运行。 为了避免中断期间执行丢失，可以通过冗余方式将相同的函数部署到多个区域的函数应用。 若要详细了解多区域部署，请参阅高可用性多区域 Web 应用程序中的指南。
在多个区域运行相同的函数代码时，可以考虑使用两种模式：主动-主动和主动-被动。
HTTP 触发器函数的主动-主动模式
使用主动-主动模式时，两个区域中的函数都以重复或轮流的方式主动运行和处理事件。
重要
不过，强烈建议对非 HTTPS 触发器函数使用主动-被动模式。 对于非 HTTP 触发的函数，可以创建主动-主动部署。 但是，需要考虑两个活动区域如何相互交互或相互协调。 如果向两个区域部署了同一函数应用，并且每个区域都在同一服务总线队列上触发，那么在对该队列执行取消排队操作时，这两个区域属于竞争性使用者。 虽然这意味着每条消息仅由多个实例中的一个进行处理，但也意味着在单个服务总线实例上仍然存在单一故障点。
可以改为部署两个服务总线队列，其中一个位于主要区域，另一个位于次要区域。 在这种情况下，可以拥有两个函数应用，每个函数应用都指向区域中活跃的服务总线队列。 此拓扑面临的挑战是如何在两个区域之间分发队列消息。 通常情况下，这意味着每个发布服务器都会尝试将消息发布到两个区域，并且每条消息都由两个活动的函数应用进行处理。 虽然这样会形成所需的“主动/主动”模式，但也会在复制计算以及何时/如何合并数据方面带来其他难题。
非 HTTP 触发器函数的主动-被动模式
建议对事件驱动的非 HTTP 触发函数（例如服务总线和事件中心触发的函数）使用主动-被动模式。
若要为非 HTTP 触发器函数创建冗余，请使用主动-被动模式。 使用主动-被动模式时，函数在接收事件的区域中主动运行，而第二个区域中的相同函数保持空闲状态。 主动-被动模式提供了一种每条消息仅由一个函数处理的方法，通过提供了一种机制，便于在发生灾难时故障转移到次要区域。 函数应用使用合作伙伴服务的故障转移行为，例如 Azure 服务总线异地恢复和 Azure 事件中心异地恢复。
请考虑使用 Azure 事件中心触发器的示例拓扑。 在这种情况下，主动/被动模式需要涉及以下组件：
Azure 事件中心已同时部署到主要区域和次要区域。
已启用异地灾难恢复以将主事件中心和辅助事件中心配对。 这还会创建一个“别名”，用于连接到事件中心，并从主要区域切换到次要区域，而无需更改连接信息。
函数应用部署到主要和次要（故障转移）区域，次要区域的应用实质上处于空闲状态，因为消息不会发送到该区域。
函数应用在其各自事件中心的直接（非别名）连接字符串上触发。
事件中心的发布服务器应发布到别名连接字符串。
在故障转移之前，发送到共享别名的发布服务器将路由到主事件中心。 主要函数应用专门侦听主事件中心。 次要函数应用处于被动和空闲状态。 启动故障转移后，发送到共享别名的发布服务器会路由到次要事件中心。 次要函数应用现在将处于活动状态并开始自动触发。 可以完全从事件中心驱动到次要区域的有效故障转移，并且仅当各自的事件中心处于活动状态时，函数才变为活动状态。
详细了解如何在服务总线和事件中心之间进行故障转移以及需要注意的事项。