你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Microsoft 致力于确保 Azure 服务一直可用。 但是，可能会发生计划外服务中断。 当应用程序需要复原能力时，应为应用配置异地冗余。
还应制定灾难恢复计划来处理区域性服务中断。 灾难恢复计划的一个重要部分是准备在主要副本不可用时故障转移到应用和存储帐户的辅助副本。
本文介绍使用 Azure Functions 的 Durable Functions 功能配置灾难恢复和异地分发的示例方案。
背景
在 Durable Functions 中，所有状态默认保留在 Azure 存储中。 任务中心是用于业务流程和实体的 Azure 存储资源的逻辑容器。 业务流程协调程序、活动和实体函数只能在它们属于同一任务中心时相互交互。 本文介绍用于保持这些 Azure 存储资源高度可用的方案时的任务中心。
业务流程和实体可以通过通过 HTTP 或另一种受支持的 Azure Functions 触发器类型触发的 客户端函数 触发。 业务流程和实体也可以通过 内置 HTTP API 触发。 为简单起见，本文重点介绍涉及 Azure 存储和基于 HTTP 的函数触发器的方案，以及用于提高可用性并在灾难恢复期间最大限度地减少停机时间的选项。 本文未显式介绍其他触发器类型，例如 Azure 服务总线或 Azure Cosmos DB 触发器。
本文中的方案基于主动/被动配置，最适合使用 Azure 存储。 此模式包括将备份（被动）函数应用部署到其他区域。 Azure 流量管理器 监视用于 HTTP 可用性的主要（活动）函数应用。 当主应用程序失败时，它会切换到备用函数应用程序。 有关详细信息，请参阅 优先级流量路由方法。
一般注意事项
为 Durable Functions 配置主动/被动故障转移配置时，请记住以下注意事项：
- 本文中的指南假定你使用默认 的 Azure 存储提供程序 来存储 Durable Functions 运行时状态。 还可以配置备用存储提供程序，这些提供程序将状态存储在其他位置，例如在 SQL Server 数据库中。 备用存储提供程序可能需要不同的灾难恢复和异地分发策略。 有关详细信息，请参阅 Durable Functions 存储提供程序。
- 建议的主动/被动配置可确保客户端始终可以通过 HTTP 触发新业务流程。 但是，当两个函数应用在存储中共享相同的任务中心时，某些后台存储事务可以在应用之间分布。 由于此分布，此配置可能会导致次要函数应用的出口成本增加。
- 基础存储帐户和任务中心都在主要区域中创建。 函数应用共享此存储帐户和任务中心。
- 冗余部署的所有函数应用在通过 HTTP 激活时必须共享相同的函数访问密钥。 Azure Functions 运行时公开了一个 管理 API ，可用于以编程方式添加、删除和更新函数密钥。 还可以使用 Azure 资源管理器 API 管理密钥。
方案 1：使用共享存储进行负载均衡计算
为了减轻当函数应用资源不可用时发生停机时间的可能性，此方案使用部署到不同区域的两个函数应用。 建议将此方案作为故障转移的解决方案。
流量管理器配置为检测主函数应用中的问题，并自动将流量重定向到次要区域中的函数应用。 此函数应用共享相同的 Azure 存储帐户和任务中心。 函数应用的状态不会丢失，工作可以正常恢复。 将运行状况还原到主要区域后，Azure 流量管理器会自动开始将请求路由到该函数应用。
使用此部署方案有几个好处：
- 如果计算基础结构失败，可以在故障转移区域中恢复工作，而不会丢失数据。
- 流量管理器负责自动故障转移到正常的函数应用。
- 服务中断结束后，流量管理器会自动重新建立到主函数应用的流量。
特定于方案的注意事项
如果使用专用的 Azure 应用服务计划部署函数应用，则复制故障转移数据中心中的计算基础结构会增加成本。
此方案涵盖计算基础结构中断，但存储帐户仍然是函数应用的单一故障点。 如果发生 Azure 存储中断，应用程序将停机。
如果函数应用已故障转移，延迟会增加，因为应用跨区域访问其存储帐户。
当函数应用处于故障转移中时，它会访问原始区域中的存储服务。 网络出口流量可能会导致更高的成本。
此方案取决于流量管理器。 客户端应用程序可能需要一些时间才能再次从流量管理器请求函数应用地址。 有关详细信息，请参阅 流量管理器的工作原理。
从 Durable Functions 扩展版本 2.3.0 开始，可以使用同一存储帐户和任务中心配置安全地运行两个函数应用。 第一个开始获取应用程序级 Blob 租约，该租约会阻止其他应用从任务中心队列中窃取消息。 如果第一个应用停止运行，则其租约将过期。 第二个应用可以获取租约并开始处理任务中心消息。
对于 2.3.0 之前的扩展版本，配置为使用相同的存储帐户处理消息并同时更新存储项目的函数应用。 此并发活动会导致总体延迟和出口成本更高。 如果主要应用和副本应用部署了不同的代码，即使是暂时的，业务流程也可能无法正常运行，因为两个应用中的业务流程协调程序函数不一致。
需要异地分发进行灾难恢复的所有应用都应使用 Durable Functions 扩展版本 2.3.0 或更高版本。
方案 2：使用区域存储或区域持久任务计划程序进行负载均衡计算
上述方案仅涵盖仅限于计算基础结构的故障。 当存储服务或持久任务计划程序失败时，函数应用也会中断。
为了确保 Durable Functions 的持续作，第二种方案会在托管函数应用的每个区域中部署专用存储帐户或持久任务计划程序。 使用持久任务计划程序时，我们目前建议采用此灾难恢复方法。
此方法对前面的方案进行了改进：
- 区域状态隔离：每个函数应用都链接到其自己的区域存储帐户或持久任务计划程序。 如果函数应用失败，流量管理器会将流量重定向到次要区域。 由于每个区域中的函数应用使用其本地存储或持久任务计划程序，Durable Functions 可以使用本地状态继续处理。
- 故障转移时没有添加延迟：故障转移期间，会并置函数应用和状态提供程序（存储帐户或持久任务计划程序），因此故障转移区域中没有额外的延迟。
- 恢复状态支持失败：如果某个区域中的存储帐户或持久任务计划程序失败，Durable Functions 将在该区域失败。 Durable Functions 失败会触发重定向到次要区域。 由于计算和应用状态都是按区域隔离的，因此故障转移区域中的 Durable Functions 仍可正常运行。
特定于方案的注意事项
- 如果使用专用应用服务计划部署函数应用，则复制故障转移数据中心中的计算基础结构会增加成本。
- 当前状态未故障转移。 在主要区域恢复之前，现有业务流程和实体会有效地暂停和不可用。 保留延迟和尽量减少出口成本的权衡是否可接受取决于应用程序的要求。
方案 3：使用共享 GRS 进行负载均衡计算
此方案是对第一个方案（实现共享存储帐户）的修改。 主要区别在于存储帐户是在启用异地复制的情况下创建的。
此方案提供与第一种方案相同的功能优势，但也可实现其他数据恢复优势：
- 异地冗余存储（GRS）和读取访问 GRS（RA-GRS）将存储帐户的可用性最大化。
- 如果 Azure 存储服务发生区域性中断，可以 手动启动到次要副本的故障转移。 在发生灾难导致区域丢失的极端情况下，Microsoft可能会启动区域故障转移。 在这种情况下，无需执行任何作。
- 发生故障转移时，Durable Functions 的状态将保留到存储帐户的最后一次复制。 复制通常每隔几分钟进行一次。
有关详细信息，请参阅 Azure 存储灾难恢复计划和故障转移。
特定于方案的注意事项
- 故障转移到副本可能需要一些时间。 在故障转移完成和 Azure 存储 DNS 记录更新之前，函数应用将继续不可访问。
- 使用异地复制的存储帐户会增加成本。
- GRS 复制以异步方式复制数据。 由于复制过程的延迟，某些最新事务可能会丢失。
- 如第一个方案所述，我们建议在此策略中部署的函数应用使用 Durable Functions 扩展版本 2.3.0 或更高版本。