Azure 逻辑应用的业务连续性和灾难恢复
为了帮助降低不可预测的事件对业务和客户造成的影响，请确保部署一个灾难恢复 (DR) 解决方案，以便可以保护数据、快速还原用于支持关键业务功能的资源，并使操作持续运行以保持业务连续性 (BC) 。 例如，中断可能包括服务中断、底层基础结构或组件（例如存储、网络或计算资源）损毁、不可恢复的应用程序故障，甚至整个数据中心损毁。 准备好业务连续性和灾难恢复 (BCDR) 解决方案后，企业或组织可以更快地对计划内或计划外中断做出响应，并缩短客户的停机时间。
本文提供在使用 Azure 逻辑应用构建自动化工作流时可以应用的 BCDR 指导和策略。 逻辑应用工作流可以减少需要编写的代码量，帮助你更轻松地在应用、云服务与本地系统之间集成和协调数据。 规划 BCDR 时，不仅需要考虑到逻辑应用，而且还必须考虑到下述要在逻辑应用中使用的 Azure 资源：
从逻辑应用工作流建立的到其他应用、服务和系统的连接。 有关详细信息，请参阅本主题稍后的与资源的连接。
本地数据网关，这是你在逻辑应用中创建的 Azure 资源，用于在其中访问本地系统中的数据。 每个网关资源在本地计算机上代表一个独立的数据网关安装。 有关详细信息，请参阅本主题稍后的本地数据网关。
集成帐户，将在其中定义和存储逻辑应用对企业到企业 (B2B) 企业集成方案使用的项目。 例如，可以为集成帐户设置跨区域灾难恢复。
主要和辅助位置
每个逻辑应用需要指定用于部署的位置。 此位置是全球多租户 Azure 中的某个公共区域，例如“中国东部 2”。
注意
如果逻辑应用还使用存储在集成帐户中的 B2B 项目（例如贸易合作伙伴、协议、架构、映射和证书），则集成帐户和逻辑应用必须指定同一位置。
如果你遵循了良好的 DevOps 实践，则已经使用 Azure 资源管理器模板定义并部署了逻辑应用及其从属资源。 资源管理器模板提供的功能允许你先使用单个部署定义，然后使用参数文件来提供用于每个部署目标的配置值。 此功能意味着，可将同一逻辑应用部署到不同的环境（例如开发、测试和生产环境）。 还可以将同一逻辑应用部署到不同的 Azure 区域，该应用支持那些使用配对区域的灾难恢复策略。
对于故障转移策略，逻辑应用和位置必须满足以下要求：
辅助逻辑应用实例能够访问主要逻辑应用实例所能访问的应用、服务和系统。
这两个逻辑应用实例的主机类型相同。 因此，这两个实例都被部署到全球多租户 Azure 逻辑应用中的区域或单租户 Azure 逻辑应用中的区域。 有关 BCDR 配对区域的最佳做法和详细信息，请参阅 Azure 中的跨区域复制：业务连续性和灾难恢复。
示例：多租户 Azure
此示例演示了此方案的主要和辅助逻辑应用实例，这些实例部署到全球多租户 Azure 中的单独区域。 单个资源管理器模板定义了逻辑应用实例以及这些逻辑应用所需的从属资源。 单独的参数文件指定用于每个部署位置的配置值：
与资源的连接
Azure 逻辑应用提供数百种连接器操作，逻辑应用工作流可以使用它们来处理其他应用、服务、系统和其他资源，例如 Azure 存储帐户、SQL Server 数据库、工作或学校电子邮件帐户等。 如果逻辑应用需要访问这些资源，你可以创建连接来验证对这些资源的访问。 每个连接是位于特定位置的单独 Azure 资源，不可由其他位置中的资源使用。
对于灾难恢复策略，请考虑从属资源相对于逻辑应用实例所在的位置：
主要实例和从属资源位于不同的位置。 在这种情况下，辅助实例可以连接到相同的从属资源或终结点。 但是，应该专门为辅助实例创建连接。 这样，如果主要位置不可用，辅助位置的连接将不受影响。
例如，假设主要逻辑应用连接到 Salesforce 之类的外部服务。 通常，外部服务的可用性和位置与逻辑应用的可用性无关。 在这种情况下，辅助实例可以连接到同一服务，但应具有自身的连接。
主要实例和从属资源位于同一位置。 在这种情况下，从属资源应在不同的位置具有备份或复制的版本，以便辅助实例仍可访问这些资源。
例如，假设主要逻辑应用连接到位于同一位置或区域的服务（例如 Azure SQL 数据库）。 如果这整个区域变得不可用，则该区域中的 Azure SQL 数据库服务也可能不可用。 在这种情况下，你会希望辅助实例使用复制的数据库或备份数据库，并与该数据库建立单独的连接。
本地数据网关
如果逻辑应用在多租户 Azure 中运行并需要访问 SQL Server 数据库等本地资源，则需要在本地计算机上安装本地数据网关。 然后，可以在 Azure 门户中创建数据网关资源，以便在你与资源建立连接时，逻辑应用可以使用网关。
与逻辑应用资源一样，数据网关资源与某个位置或 Azure 区域相关联。 在灾难恢复策略中，请确保数据网关一直可供逻辑应用使用。 如果有多个网关安装，可以为网关启用高可用性。
注意
如果没有任何版本受 ISE 控制的连接器可供你所需要的本地资源使用，逻辑应用在这种情况下运行时仍可使用全球多租户 Azure 中运行的非 ISE 连接器创建连接。 但是，此连接需要本地数据网关。
主动-主动角色与主动-被动角色
可以设置主要位置和辅助位置，使这些位置中的逻辑应用实例可以充当以下角色：
| 主要-辅助角色 | 说明 |
|---|---|
| 主动-主动 | 位于两个位置的主要和辅助逻辑应用实例按照以下任一模式来主动处理请求： - 负载均衡：可让两个实例都侦听某个终结点，并根据需要对发往每个实例的流量进行负载均衡。 - 竞争性使用者：可让两个实例都充当竞争性使用者，使实例竞争来自队列的消息。 如果有一个实例失败，另一个实例会接管工作负荷。 |
| 主动-被动 | 主要逻辑应用实例主动处理整个工作负荷，而辅助实例是被动性的（已禁用或处于非活动状态）。 辅助实例会等待主要实例不可用或者因中断或故障而无法正常工作的信号出现，然后以主动实例的角色接管工作负荷。 |
| 组合 | 有些逻辑应用充当主动-主动角色，还有一些逻辑应用充当主动-被动角色。 |
主动-主动设置示例
这些示例演示了主动-主动设置，其中的两个逻辑应用实例主动处理请求或消息。 其他某个系统或服务在实例之间分配请求或消息，例如，此类系统或服务的选项如下：
“物理”负载均衡器，例如用于路由流量的硬件组件
“软性”负载均衡器，例如 Azure 负载均衡器或 Azure API 管理。 可以使用 API 管理来指定策略，以便确定如何对传入的流量进行负载均衡。 也可使用支持状态跟踪的服务，例如 Azure 服务总线。
尽管此示例主要演示了 Azure 负载均衡器，但你可以使用最适合自己方案的需求的选项：
每个逻辑应用实例充当一个使用者，让两个实例竞争来自队列的消息：
主动-被动设置示例
此示例演示了主动-被动设置，其中的主要逻辑应用实例在一个位置处于活动状态，而辅助实例在另一个位置保持非活动状态。 如果主要实例遇到中断或故障，你可以让操作员运行一个脚本，以激活辅助实例来接管工作负荷。
主动-主动和主动-被动设置的组合
此示例演示了一种组合设置，其中的主要位置包含两个主动逻辑应用实例，辅助位置包含主动-被动逻辑应用实例。 如果主要位置遇到中断或故障，辅助位置中的主动逻辑应用（已在处理部分工作负荷）可以接管整个工作负荷。
在主要位置，活动逻辑应用侦听 Azure 服务总线队列中的消息，而另一个活动逻辑应用使用 Office 365 Outlook 轮询触发器检查电子邮件。
在辅助位置，主动逻辑应用会侦听并竞争来自同一服务总线队列的消息，通过这种方式与主要位置中的逻辑应用配合工作。 同时，被动的非活动逻辑应用处于待机等待状态，它在主要位置不可用时检查电子邮件，但它处于禁用状态，以避免重复读取电子邮件。
逻辑应用状态和历史记录
当逻辑应用被触发并开始运行时，该应用的状态会存储在应用启动时所在的位置，不可传输到另一位置。 如果发生故障或中断，则会放弃任何正在进行的工作流实例。 如果设置了主要位置和辅助位置，新的工作流实例会在辅助位置开始运行。
减少放弃的进行中实例数
若要最大程度地减少放弃的进行中工作流实例数，可以从可实现的各种消息模式中进行选择，例如：
-
此企业消息模式将业务流程拆分为较小的阶段。 对于每个阶段，需设置一个逻辑应用来处理该阶段的工作负荷。 若要相互通信，逻辑应用可以使用异步消息传送协议，例如 Azure 服务总线队列或主题。 将流程划分为较小的阶段可以减少在有故障的逻辑应用实例上受到阻滞的业务流程的数目。 有关此模式的其他常规信息，请参阅企业集成模式 - 传送名单。
此示例显示了一种传送名单模式，其中的每个逻辑应用代表一个阶段，使用服务总线队列与流程中的下一个逻辑应用通信。
如果主要和辅助逻辑应用实例在其所在位置遵循相同的传送名单模式，你可以为这些实例设置主动-主动角色，通过这种方式实现竞争性使用者模式。
访问触发器和运行历史记录
若要详细了解逻辑应用在过去的工作流执行情况，可以查看该应用的触发器和运行历史记录。 逻辑应用的执行历史记录存储在该逻辑应用的运行位置或区域，这意味着你无法将此历史记录迁移到其他位置。 如果主要实例故障转移到辅助实例，你只能在运行这些实例的相应位置访问每个实例的触发器和运行历史记录。 但是，可以通过将逻辑应用设置为向 Azure Log Analytics 工作区发送诊断事件，来获取有关逻辑应用历史记录的与位置无关的信息。 然后，可以查看在多个位置运行的各个逻辑应用的运行状况和历史记录。
触发器类型指导
在逻辑应用中使用的触发器类型决定了可以在灾难恢复策略中使用哪些选项来设置不同位置的逻辑应用。 下面是可以在逻辑应用中使用的触发器类型：
重复触发器
重复触发器独立于任何特定的服务或终结点，只根据指定的计划（而不能根据其他任何条件）激发，例如：
- 按固定的频率和间隔，例如每隔 10 分钟一次
- 按更高级的计划，例如，每月最后一个星期一的下午 5:00
通过重复触发器启动逻辑应用时，需要使用主动-被动角色设置主要和辅助逻辑应用实例。 若要降低恢复时间目标 (RTO)（表示在发生中断或灾难后恢复业务流程所需的目标持续时间），可以使用主动-被动角色和被动-主动角色的组合来设置逻辑应用实例。 在此设置中，可在不同的位置拆分计划。
例如，假设某个逻辑应用需要每隔 10 分钟运行一次。 可以设置逻辑应用和位置，以便在主要位置不可用时，辅助位置可以接管工作：
在主要位置中，为这些逻辑应用设置主动-被动角色：
对于启用了“主动”模式的逻辑应用，将重复触发器设置为在计划的小时一开始就启动，并每隔 20 分钟重复一次，例如在上午 9:00、上午 9:20 等时间启动。
对于禁用了“被动”模式的逻辑应用，将重复触发器设置为相同的计划，但在计划的小时过去 10 分钟后启动，并每隔 20 分钟重复一次，例如在上午 9:10、上午 9:30 等时间启动。
在辅助位置，为这些逻辑应用设置被动-主动角色：
对于禁用了“被动”模式的逻辑应用，将重复触发器的计划设置为与主要位置中的主动逻辑应用相同，即，在计划的小时一开始就启动，并每隔 20 分钟重复一次，例如在上午 9:00、上午 9:10 等时间启动。
对于启用了“主动”模式的逻辑应用，将重复触发器的计划设置为与主要位置中的被动逻辑应用相同，即，在计划的小时过去 10 分钟后启动，并每隔 20 分钟重复一次，例如在上午 9:10、上午 9:20 等时间启动。
现在，如果主要位置发生中断性事件，则可激活备用位置中的被动逻辑应用。 这样，如果发现故障会持续较长时间，则可利用此设置来限制该延迟时段内遗漏的重复周期数。
轮询触发器
若要定期检查是否可从特定服务或终结点提供要处理的新数据，可以让逻辑应用使用轮询触发器根据固定的重复计划反复调用该服务或终结点。 服务或终结点提供的数据可以是以下任一类型：
- 静态数据，描述始终可供读取的数据
- 不稳定数据，描述读取后不再可用的数据
为了避免反复读取相同的数据，逻辑应用需要在客户端、服务器端、服务端或系统端维护状态，记住以前读取了哪些数据。
处理客户端状态的逻辑应用使用可以维护状态的触发器。
例如，从电子邮件收件箱读取新邮件的触发器必须能够记住最近读取的邮件。 这样，仅当下一封未读邮件抵达时，该触发器才启动逻辑应用。
处理服务器端、服务端或系统端状态的逻辑应用使用服务器端、服务端或系统端的属性值或设置。
例如，从数据库中读取某行的基于查询的触发器要求该行包含已设置为
FALSE的isRead列。 每当触发器读取某行时，逻辑应用就会通过将isRead列从FALSE更改为TRUE来更新该行。对于采用排队语义的服务总线队列或主题，这种服务器端方法的工作方式是类似的，其中的触发器可以在逻辑应用处理消息的同时读取和锁定消息。 当逻辑应用完成处理操作以后，触发器会从队列或主题中删除消息。
从灾难恢复的角度讲，当你设置逻辑应用的主要和辅助实例时，请确保根据逻辑应用是在客户端还是服务器端跟踪状态来考虑这些行为：
对于处理客户端状态的逻辑应用，请确保该逻辑应用不会多次读取同一条消息。 在任意特定时间，只能有一个位置包含主动逻辑应用实例。 在主要实例故障转移到备用位置之前，请确保备用位置中的逻辑应用实例处于非活动状态或禁用状态。
例如，Office 365 Outlook 触发器维护客户端状态并跟踪最近读取的电子邮件的时间戳，以避免读取重复项。
对于处理服务器端状态的逻辑应用，可将逻辑应用实例设置为充当主动-主动角色，在这种情况下，这些实例以竞争性使用者的身份工作；或者将其设置为主动-被动角色，在这种情况下，备用实例会等待主要实例故障转移到备用位置。
例如，从消息队列（如 Azure 服务总线队列）读取消息时会使用服务器端状态，因为排队服务会在消息中维护锁，以防其他客户端读取相同的消息。
注意
如果逻辑应用需要按特定顺序读取消息（例如从服务总线队列读取），你可以使用竞争性使用者模式，但只能对服务总线会话结合使用此模式（也称为顺序保护模式）。 否则，必须使用主动-被动角色设置逻辑应用实例。
请求触发器
请求触发器使得逻辑应用可从其他应用、服务和系统调用，它通常用于提供以下功能：
为逻辑应用提供一个可由他人调用的直接 REST API
例如，使用请求触发器启动逻辑应用，使其他逻辑应用可以使用“调用工作流 - 逻辑应用”操作来调用触发器。
为逻辑应用提供 Webhook 或回调机制
可让你手动运行用户操作或例程来调用逻辑应用（例如，使用某个执行特定任务的 PowerShell 脚本）
从灾难恢复的角度讲，请求触发器是一个被动接收方，因为逻辑应用不会执行任何工作，只是等待其他某个服务或系统显式调用触发器。 作为被动终结点，可以通过以下方式设置主要和辅助实例：
主动-主动：两个实例都主动处理请求或调用。 调用方或路由器在这些实例之间平衡或分配流量。
主动-被动：仅主要实例处于活动状态并处理所有工作，辅助实例只有在主要实例遇到中断或故障时才工作。 调用方或路由器决定何时调用辅助实例。
可将 Azure API 管理这种建议的体系结构用作那些使用请求触发器的逻辑应用的代理。 API 管理提供内置的跨区域复原能力，以及在多个终结点之间路由流量的功能。
Webhook 触发器
Webhook 触发器通过向服务传递回调 URL，为逻辑应用提供订阅该服务的功能。 然后，逻辑应用可以侦听并等待特定的事件在该服务终结点上发生。 发生该事件时，服务会使用回调 URL 来调用 Webhook 触发器，然后，后者会运行逻辑应用。 启用后，Webhook 触发器会订阅此服务。 禁用后，该触发器会取消订阅此服务。
从灾难恢复的角度讲，需将使用 Webhook 触发器的主要和辅助实例设置为充当主动-被动角色，因为只能有一个实例从订阅的终结点接收事件或消息。
评估主要实例的运行状况
若要使灾难恢复策略发挥作用，解决方案需要能够通过特定方式执行以下任务：
本部分介绍一种可以直接使用或者作为自己设计的基础使用的解决方案。 下面是此解决方案的统括性视觉概览：
检查主要实例的可用性
若要确定主要实例是否可用、正在运行且能够正常工作，可以在主要实例所在的同一位置创建一个“运行状况检查”逻辑应用。 然后，可以从备用位置调用此运行状况检查应用。 如果运行状况检查应用成功做出响应，则表示该区域中的 Azure 逻辑应用服务的底层基础结构可用且在正常运行。 如果运行状况检查应用无法做出响应，则可认为该位置不再正常。
对于此任务，请创建一个执行以下任务的基本运行状况检查逻辑应用：
使用请求触发器接收来自监视器应用的调用。
使用“响应”操作返回包含某种状态的响应，该状态指示检查的逻辑应用是否仍可正常运行。
重要
运行状况检查逻辑应用必须使用“响应”操作，这样应用就会以同步而不是异步方式做出响应。
（可选）若要进一步确定主要位置是否正常，可以考虑与此位置中的目标逻辑应用交互的任何其他服务的运行状况。 只需扩展运行状况检查逻辑应用，即可评估这些其他服务的运行状况。
创建监视器逻辑应用
若要监视主要实例的运行状况并调用运行状况检查逻辑应用，请在备用位置创建一个“监视器”逻辑应用。 例如，可以设置监视器逻辑应用，以便在调用运行状况检查逻辑失败时，监视器可将警报发送到运营团队，让他们调查失败以及主要实例无法响应的原因。
重要
确保监视器逻辑应用所在的位置不同于主要位置。 如果主要位置中的 Azure 逻辑应用遇到问题，监视器逻辑应用工作流可能不会运行。
对于此任务，请在辅助位置创建一个执行以下任务的监视器逻辑应用：
使用重复触发器按固定的或计划的重复周期运行。
可将重复周期设置为某个低于恢复时间目标 (RTO) 容许级别的值。
使用 HTTP 操作调用主要位置中的健康状况检查逻辑应用工作流。
还可以创建更复杂的监视器逻辑应用，该应用会在多次失败后调用另一个逻辑应用，后者在主逻辑应用发生故障时自动处理切换到辅助位置。
激活辅助实例
若要自动激活辅助实例，可以创建一个逻辑应用，用于调用 Azure 资源管理器连接器等管理 API，以便激活辅助位置中的相应逻辑应用。 在发生特定次数的失败后，可以扩展监视器应用来调用此激活逻辑应用。
可用性区域的区域冗余
在每个 Azure 区域中，可用性区域是物理上独立的位置，可以容忍本地故障。 此类故障范围包括软件和硬件故障，以及地震、洪水和火灾等事件。 这些区域通过 Azure 服务的冗余和逻辑隔离实现容错。
为了提供复原能力和分布式可用性，任何支持和启用区域冗余的 Azure 区域中都至少存在三个单独的可用性区域。 Azure 逻辑应用平台跨这些区域分发这些区域和逻辑应用工作负载。 如果某个区域发生数据中心故障，此功能是启用可复原体系结构和提供高可用性的关键要求。
目前，此功能为预览版，可用于特定区域中的新消耗逻辑应用。 有关详细信息，请参阅以下文档：
收集诊断数据
可为逻辑应用运行设置日志记录，将生成的诊断数据发送到 Azure 存储、Azure 事件中心和 Azure Log Analytics 等服务处进行进一步的处理。
若要在 Azure Log Analytics 中使用此数据，可以通过设置逻辑应用的诊断设置并将数据发送到多个 Log Analytics 工作区，来提供主要位置和辅助位置的数据。 有关详细信息，请参阅为 Azure 逻辑应用设置 Azure Monitor 日志并收集诊断数据。
若要将数据发送到 Azure 存储或 Azure 事件中心，可以通过设置异地冗余，来提供主要位置和辅助位置的数据。 有关详细信息，请参阅以下文章：