Azure 逻辑应用的业务连续性和灾难恢复Business continuity and disaster recovery for Azure Logic Apps

为了帮助降低不可预测的事件对业务和客户造成的影响,请确保部署一个灾难恢复 (DR) 解决方案,以便可以保护数据、快速还原用于支持关键业务功能的资源,并使操作持续运行以保持业务连续性 (BC)To help reduce the impact and effects that unpredictable events have on your business and customers, make sure that you have a disaster recovery (DR) solution in place so that you can protect data, quickly restore the resources that support critical business functions, and keep operations running to maintain business continuity (BC). 例如,中断可能包括服务中断、底层基础结构或组件(例如存储、网络或计算资源)损毁、不可恢复的应用程序故障,甚至整个数据中心损毁。For example, disruptions can include outages, losses in underlying infrastructure or components such as storage, network, or compute resources, unrecoverable application failures, or even a full datacenter loss. 准备好业务连续性和灾难恢复 (BCDR) 解决方案后,企业或组织可以更快地对计划内或计划外中断做出响应,并缩短客户的停机时间。By having a business continuity and disaster recovery (BCDR) solution ready, your enterprise or organization can respond more quickly to interruptions, planned or unplanned, and reduce downtime for your customers.

本文提供在使用 Azure 逻辑应用构建自动化工作流时可以应用的 BCDR 指导和策略。This article provides BCDR guidance and strategies that you can apply when you build automated workflows by using Azure Logic Apps. 逻辑应用工作流可以减少需要编写的代码量,帮助你更轻松地在应用、云服务与本地系统之间集成和协调数据。Logic app workflows help you more easily integrate and orchestrate data between apps, cloud services, and on-premises systems by reducing how much code that you have to write. 规划 BCDR 时,不仅需要考虑到逻辑应用,而且还必须考虑到下述要在逻辑应用中使用的 Azure 资源:When you plan for BCDR, make sure that you consider not just your logic apps, but also these Azure resources that you use with your logic apps:

主要和辅助位置Primary and secondary locations

每个逻辑应用需要指定用于部署的位置。Each logic app needs to specify the location that you want to use for deployment. 此位置是全球多租户 Azure 中的某个公共区域,例如“中国北部”。This location is either a public region in global multi-tenant Azure, such as "China North".

备注

如果逻辑应用还使用存储在集成帐户中的 B2B 项目(例如贸易合作伙伴、协议、架构、映射和证书),则集成帐户和逻辑应用必须指定同一位置。If your logic app also works with B2B artifacts, such as trading partners, agreements, schemas, maps, and certificates, which are stored in an integration account, both your integration account and logic apps must specify the same location.

此灾难恢复策略侧重于将主要逻辑应用设置为故障转移到也可以使用 Azure 逻辑应用的备用位置中的待机或备份逻辑应用。This disaster recovery strategy focuses on setting up your primary logic app to failover onto a standby or backup logic app in an alternate location where Azure Logic Apps is also available. 这样,在主要逻辑应用发生损毁、中断或故障时,辅助逻辑应用就可以接管工作。That way, if the primary suffers losses, disruptions, or failures, the secondary can take on the work. 此策略要求辅助逻辑应用和从属资源已在备用位置中部署且准备就绪。This strategy requires that your secondary logic app and dependent resources are already deployed and ready in the alternate location.

如果你遵循了良好的 DevOps 实践,则已经使用 Azure 资源管理器模板定义并部署了逻辑应用及其从属资源。If you follow good DevOps practices, you already use Azure Resource Manager templates to define and deploy your logic apps and their dependent resources. 资源管理器模板提供的功能允许你先使用单个部署定义,然后使用参数文件来提供用于每个部署目标的配置值。Resource Manager templates give you the capability to use a single deployment definition and then use parameter files to provide the configuration values to use for each deployment destination. 此功能意味着,可将同一逻辑应用部署到不同的环境(例如开发、测试和生产环境)。This capability means that you can deploy the same logic app to different environments, for example, development, test, and production. 还可以将同一逻辑应用部署到不同的 Azure 区域,该应用支持那些使用配对区域的灾难恢复策略。You can also deploy the same logic app to different Azure regions, which supports disaster recovery strategies that use paired-regions.

对于故障转移策略,逻辑应用和位置必须满足以下要求:For the failover strategy, your logic apps and locations must meet these requirements:

  • 辅助逻辑应用实例能够访问主要逻辑应用实例所能访问的应用、服务和系统。The secondary logic app instance has access to the same apps, services, and systems as the primary logic app instance.

  • 这两个逻辑应用实例的主机类型相同。Both logic app instances have the same host type. 因此,这两个实例将部署到全球多租户 Azure 中的区域,使逻辑应用能够直接访问 Azure 虚拟网络中的资源。So, both instances are deployed to regions in global multi-tenant Azure, which let your logic apps directly access resources in an Azure virtual network. 有关 BCDR 配对区域的最佳做法和详细信息,请参阅业务连续性和灾难恢复 (BCDR):Azure 配对区域For best practices and more information about paired regions for BCDR, see Business continuity and disaster recovery (BCDR): Azure paired regions.

示例:多租户 AzureExample: Multi-tenant Azure

此示例演示了此方案的主要和辅助逻辑应用实例,这些实例部署到了全球多租户 Azure 中的单独区域。This example shows primary and secondary logic app instances, which are deployed to separate regions in the global multi-tenant Azure for this scenario. 单个资源管理器模板定义了逻辑应用实例以及这些逻辑应用所需的从属资源。A single Resource Manager template defines both logic app instances and the dependent resources required by those logic apps. 单独的参数文件指定用于每个部署位置的配置值:Separate parameter files specify the configuration values to use for each deployment location:

位于不同位置的主要和辅助逻辑应用实例

与资源的连接Connections to resources

Azure 逻辑应用提供内置的触发器和操作以及数百个托管连接器,逻辑应用可以使用它们来处理其他应用、服务、系统和其他资源,例如 Azure 存储帐户、SQL Server 数据库、Office 365 Outlook 电子邮件帐户等。Azure Logic Apps provides built-in triggers and actions plus hundreds of managed connectors that your logic app can use to work with other apps, services, systems, and other resources, such as Azure Storage accounts, SQL Server databases, Office 365 Outlook email accounts, and so on. 如果逻辑应用需要访问这些资源,你可以创建连接来验证对这些资源的访问。If your logic app needs access to these resources, you create connections that authenticate access to these resources. 每个连接是位于特定位置的单独 Azure 资源,不可由其他位置中的资源使用。Each connection is a separate Azure resource that exists in a specific location and can't be used by resources in other locations.

对于灾难恢复策略,请考虑从属资源相对于逻辑应用实例所在的位置:For your disaster recovery strategy, consider the locations where dependent resources exist relative to your logic app instances:

  • 主要实例和从属资源位于不同的位置。Your primary instance and dependent resources exist in different locations. 在这种情况下,辅助实例可以连接到相同的从属资源或终结点。In this case, your secondary instance can connect to the same dependent resources or endpoints. 但是,应该专门为辅助实例创建连接。However, you should create connections specifically for your secondary instance. 这样,如果主要位置不可用,辅助位置的连接将不受影响。That way, if your primary location becomes unavailable, your secondary's connections aren't affected.

    例如,假设主要逻辑应用连接到 Salesforce 之类的外部服务。For example, suppose that your primary logic app connects to an external service such as Salesforce. 通常,外部服务的可用性和位置与逻辑应用的可用性无关。Usually, the external service's availability and location are independent from your logic app's availability. 在这种情况下,辅助实例可以连接到同一服务,但应具有自身的连接。In this case, your secondary instance can connect to the same service but should have its own connection.

  • 主要实例和从属资源位于同一位置。Both your primary instance and dependent resources exist in the same location. 在这种情况下,从属资源应在不同的位置具有备份或复制的版本,以便辅助实例仍可访问这些资源。In this case, dependent resources should have backups or replicated versions in a different location so that your secondary instance can still access those resources.

    例如,假设主要逻辑应用连接到位于同一位置或区域的服务(例如 Azure SQL 数据库)。For example, suppose that your primary logic app connects to a service that's in the same location or region, for example, Azure SQL Database. 如果这整个区域变得不可用,则该区域中的 Azure SQL 数据库服务也可能不可用。If this entire region becomes unavailable, the Azure SQL Database service in that region is also likely unavailable. 在这种情况下,你会希望辅助实例使用复制的数据库或备份数据库,并与该数据库建立单独的连接。In this case, you'd want your secondary instance to use a replicated or backup database along with a separate connection to that database.

本地数据网关On-premises data gateways

如果逻辑应用在多租户 Azure 中运行并需要访问 SQL Server 数据库之类的本地资源,则需在本地计算机上安装本地数据网关If your logic app runs in multi-tenant Azure and needs access to on-premises resources such as SQL Server databases, you need to install the on-premises data gateway on a local computer. 然后,可以在 Azure 门户中创建数据网关资源,以便在你与资源建立连接时,逻辑应用可以使用网关。You can then create a data gateway resource in the Azure portal so that your logic app can use the gateway when you create a connection to the resource.

与逻辑应用资源一样,数据网关资源与某个位置或 Azure 区域相关联。The data gateway resource is associated with a location or Azure region, just like your logic app resource. 在灾难恢复策略中,请确保数据网关一直可供逻辑应用使用。In your disaster recovery strategy, make sure that the data gateway remains available for your logic app to use. 如果有多个网关安装,可以为网关启用高可用性You can enable high availability for your gateway when you have multiple gateway installations.

备注

如果逻辑应用在集成服务环境 (ISE) 中运行,并为本地数据源使用版本受 ISE 控制的连接器,则你不需要数据网关,因为 ISE 连接器提供对本地资源的直接访问。If your logic app runs in an integration service environment (ISE) and uses only ISE-versioned connectors for on-premises data sources, you don't need the data gateway because ISE connectors provide direct access to the the on-premises resource.

如果没有任何版本受 ISE 控制的连接器可供你所需要的本地资源使用,逻辑应用仍可使用全球多租户 Azure(而不是 ISE)中运行的非 ISE 连接器创建连接。If no ISE-versioned connector is available for the on-premises resource that you want, your logic app can still create the connection by using a non-ISE connector, which runs in the global multi-tenant Azure, not your ISE. 但是,此连接需要本地数据网关。However, this connection requires the on-premises data gateway.

主动-主动角色与主动-被动角色Active-active versus active-passive roles

可以设置主要位置和辅助位置,使这些位置中的逻辑应用实例可以充当以下角色:You can set up your primary and secondary locations so that your logic app instances in these locations can play these roles:

主要-辅助角色Primary-secondary role 说明Description
主动-主动Active-active 位于两个位置的主要和辅助逻辑应用实例按照以下任一模式来主动处理请求:The primary and secondary logic app instances in both locations actively handle requests by following either of these patterns:

- 负载均衡:可让两个实例侦听某个终结点,并根据需要对发往每个实例的流量进行负载均衡。- Load balance : You can have both instances listen to an endpoint and load balance traffic to each instance as necessary.

- 竞争性使用者:可让两个实例充当竞争性使用者,使实例竞争来自队列的消息。- Competing consumers : You can have both instances act as competing consumers so that the instances compete for messages from a queue. 如果有一个实例失败,另一个实例会接管工作负荷。If one instance fails, the other instance takes over the workload.

主动-被动Active-passive 主要逻辑应用实例主动处理整个工作负荷,而辅助实例是被动性的(已禁用或处于非活动状态)。The primary logic app instance actively handles the entire workload, while the secondary instance is passive (disabled or inactive). 辅助实例会等待主要实例不可用或者因中断或故障而无法正常工作的信号出现,然后以主动实例的角色接管工作负荷。The secondary waits for a signal that the primary is unavailable or not working due to disruption or failure and takes over the workload as the active instance.
组合Combination 有些逻辑应用充当主动-主动角色,还有一些逻辑应用充当主动-被动角色。Some logic apps play an active-active role, while other logic apps play an active-passive role.

主动-主动设置示例Active-active examples

这些示例演示了主动-主动设置,其中的两个逻辑应用实例主动处理请求或消息。These examples show the active-active setup where both logic app instances actively handle requests or messages. 其他某个系统或服务在实例之间分配请求或消息,例如,此类系统或服务的选项如下:Some other system or service distributes the requests or messages between instances, for example, one of these options:

  • “物理”负载均衡器,例如用于路由流量的硬件组件A "physical" load balancer, such as a piece of hardware that routes traffic

  • “软性”负载均衡器,例如 Azure 负载均衡器Azure API 管理A "soft" load balancer such as Azure Load Balancer or Azure API Management. 可以使用 API 管理来指定策略,以便确定如何对传入的流量进行负载均衡。With API Management, you can specify policies that determine how to load balance incoming traffic. 也可使用支持状态跟踪的服务,例如 Azure 服务总线Or, you can use a service that supports state tracking, for example, Azure Service Bus.

    尽管此示例主要演示了 Azure 负载均衡器,但你可以使用最适合自己方案的需求的选项:Although this example primarily shows Azure Load Balancer, you can use the option that best suits your scenario's needs:

    使用负载均衡器或有状态服务的“主动-主动”设置

  • 每个逻辑应用实例充当一个使用者,让两个实例竞争来自队列的消息:Each logic app instance acts as a consumer and have both instances compete for messages from a queue:

    使用“竞争性使用者”的“主动-主动”设置

主动-被动设置示例Active-passive examples

此示例演示了主动-被动设置,其中的主要逻辑应用实例在一个位置处于活动状态,而辅助实例在另一个位置保持非活动状态。This example shows the active-passive setup where the primary logic app instance is active in one location, while the secondary instance remains inactive in another location. 如果主要实例遇到中断或故障,你可以让操作员运行一个脚本,以激活辅助实例来接管工作负荷。If the primary experiences a disruption or failure, you can have an operator run a script that activates the secondary to take on the workload.

使用“竞争性使用者”的“主动-被动”设置

主动-主动和主动-被动设置的组合Combination with active-active and active-passive

此示例演示了一种组合设置,其中的主要位置包含两个主动逻辑应用实例,辅助位置包含主动-被动逻辑应用实例。This example shows a combined setup where the primary location has both active logic app instances, while the secondary location has active-passive logic app instances. 如果主要位置遇到中断或故障,辅助位置中的主动逻辑应用(已在处理部分工作负荷)可以接管整个工作负荷。If the primary location experiences a disruption or failure, the active logic app in the secondary location, which is already handling a partial workload, can take over the entire workload.

  • 在主要位置,一个主动逻辑应用侦听 Azure 服务总线队列中的消息,另一个主动逻辑应用使用 Office 365 Outlook 轮询触发器检查电子邮件。In the primary location, an active logic app listens to an Azure Service Bus queue for messages, while another active logic app checks for emails by using a Office 365 Outlook polling trigger.

  • 在辅助位置,主动逻辑应用会侦听并竞争来自同一服务总线队列的消息,通过这种方式与主要位置中的逻辑应用配合工作。In the secondary location, an active logic app works with the logic app in the primary location by listening and competing for messages from the same Service Bus queue. 同时,被动的非活动逻辑应用处于待机等待状态,它在主要位置不可用时检查电子邮件,但它处于禁用状态,以避免重复读取电子邮件。Meanwhile, a passive inactive logic app waits on standby to check for emails when the primary location becomes unavailable but is disabled to avoid rereading emails.

使用重复触发器的“主动-被动”和“主动-被动”设置组合

逻辑应用状态和历史记录Logic app state and history

当逻辑应用被触发并开始运行时,该应用的状态会存储在应用启动时所在的位置,不可传输到另一位置。When your logic app is triggered and starts running, the app's state is stored in the same location where the app started and is non-transferable to another location. 如果发生故障或中断,则会放弃任何正在进行的工作流实例。If a failure or disruption happens, any in-progress workflow instances are abandoned. 如果设置了主要位置和辅助位置,新的工作流实例会在辅助位置开始运行。When you have a primary and secondary locations set up, new workflow instances start running at the secondary location.

减少放弃的进行中实例数Reduce abandoned in-progress instances

若要最大程度地减少放弃的进行中工作流实例数,可以从可实现的各种消息模式中进行选择,例如:To minimize the number of abandoned in-progress workflow instances, you can choose from various message patterns that you can implement, for example:

  • 固定传送名单模式Fixed routing slip pattern

    此企业消息模式将业务流程拆分为较小的阶段。This enterprise message pattern that splits a business process into smaller stages. 对于每个阶段,需设置一个逻辑应用来处理该阶段的工作负荷。For each stage, you set up a logic app that handles the workload for that stage. 若要相互通信,逻辑应用可以使用异步消息传送协议,例如 Azure 服务总线队列或主题。To communicate with each other, your logic apps use an asynchronous messaging protocol such as Azure Service Bus queues or topics. 将流程划分为较小的阶段可以减少在有故障的逻辑应用实例上受到阻滞的业务流程的数目。When you divide a process into smaller stages, you reduce the number of business processes that might get stuck on a failed logic app instance. 有关此模式的其他常规信息,请参阅企业集成模式 - 传送名单For more general information about this pattern, see Enterprise integration patterns - Routing slip.

    此示例显示了一种传送名单模式,其中的每个逻辑应用代表一个阶段,使用服务总线队列与流程中的下一个逻辑应用通信。This example shows a routing slip pattern where each logic app represents a stage and uses a Service Bus queue to communicate with the next logic app in the process.

    将业务流程拆分为使用 Azure 服务总线队列相互通信的逻辑应用所表示的阶段

    如果主要和辅助逻辑应用实例在其所在位置遵循相同的传送名单模式,你可以为这些实例设置主动-主动角色,通过这种方式实现竞争性使用者模式If both primary and secondary logic app instances follow the same routing slip pattern in their locations, you can implement the competing consumers pattern by setting up active-active roles for those instances.

  • 进程管理器(中介)模式Process manager (broker) pattern

  • 无超时的扫视锁定模式Peek-lock without timeout pattern

访问触发器和运行历史记录Access to trigger and runs history

若要详细了解逻辑应用在过去的工作流执行情况,可以查看该应用的触发器和运行历史记录。To get more information about your logic app's past workflow executions, you can review the app's trigger and runs history. 逻辑应用的历史记录执行历史记录存储在该逻辑应用的运行位置或区域,这意味着你无法将此历史记录迁移到其他位置。A logic app's history execution history is stored in the same location or region where that logic app ran, which means you can't migrate this history to a different location. 如果主要实例故障转移到辅助实例,你只能在运行这些实例的相应位置访问每个实例的触发器和运行历史记录。If your primary instance fails over to a secondary instance, you can only access each instance's trigger and runs history in the respective locations where those instances ran. 但是,可以通过将逻辑应用设置为向 Azure Log Analytics 工作区发送诊断事件,来获取有关逻辑应用历史记录的与位置无关的信息。However, you can get location-agnostic information about your logic app's history by setting up your logic apps to send diagnostic events to an Azure Log Analytics workspace. 然后,可以查看在多个位置运行的各个逻辑应用的运行状况和历史记录。You can then review the health and history across logic apps that run in multiple locations.

触发器类型指导Trigger type guidance

在逻辑应用中使用的触发器类型决定了可以在灾难恢复策略中使用哪些选项来设置不同位置的逻辑应用。The trigger type that you use in your logic apps determines your options for how you can set up logic apps across locations in your disaster recovery strategy. 下面是可以在逻辑应用中使用的触发器类型:Here are the available trigger types that you can use in logic apps:

重复触发器Recurrence trigger

重复触发器独立于任何特定的服务或终结点,只根据指定的计划(而不能根据其他任何条件)激发,例如:The Recurrence trigger is independent from any specific service or endpoint, and fires solely based a specified schedule and no other criteria, for example:

  • 按固定的频率和间隔,例如每隔 10 分钟一次A fixed frequency and interval, such as every 10 minutes
  • 按更高级的计划,例如,每月最后一个星期一的下午 5:00A more advanced schedule, such as the last Monday of every month at 5:00 PM

通过重复触发器启动逻辑应用时,需要使用主动-被动角色设置主要和辅助逻辑应用实例。When your logic app starts with a Recurrence trigger, you need to set up your primary and secondary logic app instances with the active-passive roles. 若要降低恢复时间目标 (RTO)(表示在发生中断或灾难后恢复业务流程所需的目标持续时间),可以使用主动-被动角色被动-主动角色的组合来设置逻辑应用实例。To reduce the recovery time objective (RTO), which refers to the target duration for restoring a business process after a disruption or disaster, you can set up your logic app instances with a combination of active-passive roles and passive-active roles. 在此设置中,可在不同的位置拆分计划。In this setup, you split the schedule across locations.

例如,假设某个逻辑应用需要每隔 10 分钟运行一次。For example, suppose that you have a logic app that needs to run every 10 minutes. 可以设置逻辑应用和位置,以便在主要位置不可用时,辅助位置可以接管工作:You can set up your logic apps and locations so that if the primary location becomes unavailable, the secondary location can take over the work:

使用重复触发器的“主动-被动”和“被动-主动”设置组合

  • 在主要位置中,为这些逻辑应用设置主动-被动角色In the primary location, set up active-passive roles for these logic apps:

    • 对于启用了“主动”模式的逻辑应用,将重复触发器设置为在计划的小时一开始就启动,并每隔 20 分钟重复一次,例如在上午 9:00、上午 9:20 等时间启动。For the active enabled logic app, set the Recurrence trigger to start at the top of the hour and repeat every 20 minutes, for example, 9:00 AM, 9:20 AM, and so on.

    • 对于禁用了“被动”模式的逻辑应用,将重复触发器设置为相同的计划,但在计划的小时过去 10 分钟后启动,并每隔 20 分钟重复一次,例如在上午 9:10、上午 9:30 等时间启动。For the passive disabled logic app, set the Recurrence trigger to same schedule but start at 10 minutes past the hour and repeat every 20 minutes, for example, 9:10 AM, 9:30 AM, and so on.

  • 在辅助位置,为这些逻辑应用设置被动-主动角色:In the secondary location, set up passive-active for these logic apps:

    • 对于禁用了“被动”模式的逻辑应用,将重复触发器的计划设置为与主要位置中的主动逻辑应用相同,即,在计划的小时一开始就启动,并每隔 20 分钟重复一次,例如在上午 9:00、上午 9:10 等时间启动。For the passive disabled logic app, set the Recurrence trigger to the same schedule as the active logic app in the primary location, which is at the top of hour and repeat every 20 minutes, for example, 9:00 AM, 9:10 AM, and so on.

    • 对于启用了“主动”模式的逻辑应用,将重复触发器的计划设置为与主要位置中的被动逻辑应用相同,即,在计划的小时过去 10 分钟后启动,并每隔 20 分钟重复一次,例如在上午 9:10、上午 9:20 等时间启动。For the active enabled logic app, set the Recurrence trigger to the same schedule as the passive logic app in the primary location, which is to start at 10 minutes past the hour and repeat every 20 minutes, for example, 9:10 AM, 9:20 AM, and so on.

现在,如果主要位置发生中断性事件,则可激活备用位置中的被动逻辑应用。Now, if a disruptive event happens in the primary location, activate the passive logic app in the alternate location. 这样,如果发现故障会持续较长时间,则可利用此设置来限制该延迟时段内遗漏的重复周期数。That way, if finding the failure takes time, this setup limits the number of missed recurrences during that delay.

轮询触发器Polling trigger

若要定期检查是否可从特定服务或终结点提供要处理的新数据,可以让逻辑应用使用轮询触发器根据固定的重复计划反复调用该服务或终结点。To regularly check whether new data for processing is available from a specific service or endpoint, your logic app can use a polling trigger that repeatedly calls the service or endpoint based on a fixed recurrence schedule. 服务或终结点提供的数据可以是以下任一类型:The data that the service or endpoint provides can have either of these types:

  • 静态数据,描述始终可供读取的数据Static data, which describes data that is always available for reading
  • 不稳定数据,描述读取后不再可用的数据Volatile data, which describes data that is no longer available after reading

为了避免反复读取相同的数据,逻辑应用需要在客户端、服务器端、服务端或系统端维护状态,记住以前读取了哪些数据。To avoid repeatedly reading the same data, your logic app needs to remember which data was previously read by maintaining state either on the client side or on the server, service, or system side.

  • 处理客户端状态的逻辑应用使用可以维护状态的触发器。Logic apps that work with client-side state use triggers that can maintain state.

    例如,从电子邮件收件箱读取新邮件的触发器必须能够记住最近读取的邮件。For example, a trigger that reads a new message from an email inbox requires that the trigger can remember the most recently read message. 这样,仅当下一封未读邮件抵达时,该触发器才启动逻辑应用。That way, the trigger starts the logic app only when the next unread message arrives.

  • 处理服务器端、服务端或系统端状态的逻辑应用使用服务器端、服务端或系统端的属性值或设置。Logic apps that work with server, service, or system-side state use property values or settings that are on the server, service, or system side.

    例如,从数据库中读取某行的基于查询的触发器要求该行包含已设置为 FALSEisRead 列。For example, a query-based trigger that reads a row from a database requires that the row has an isRead column that's set to FALSE. 每当触发器读取某行时,逻辑应用就会通过将 isRead 列从 FALSE 更改为 TRUE 来更新该行。Every time that the trigger reads a row, the logic app updates that row by changing the isRead column from FALSE to TRUE.

    对于采用排队语义的服务总线队列或主题,这种服务器端方法的工作方式是类似的,其中的触发器可以在逻辑应用处理消息的同时读取和锁定消息。This server-side approach works similarly for Service Bus queues or topics that have queuing semantics where a trigger can read and lock a message while the logic app processes the message. 当逻辑应用完成处理操作以后,触发器会从队列或主题中删除消息。When the logic app finishes processing, the trigger deletes the message from the queue or topic.

从灾难恢复的角度讲,当你设置逻辑应用的主要和辅助实例时,请确保根据逻辑应用是在客户端还是服务器端跟踪状态来考虑这些行为:From a disaster recovery perspective, when you set up your logic app's primary and secondary instances, make sure that you account for these behaviors based on whether your logic app tracks state on the client side or on the server side:

  • 对于处理客户端状态的逻辑应用,请确保该逻辑应用不会多次读取同一条消息。For a logic app that works with client-side state, make sure that your logic app doesn't read the same message more than one time. 在任意特定时间,只能有一个位置包含主动逻辑应用实例。Only one location can have an active logic app instance at any specific time. 在主要实例故障转移到备用位置之前,请确保备用位置中的逻辑应用实例处于非活动状态或禁用状态。Make sure that the logic app instance in the alternate location is inactive or disabled until the primary instance fails over to the alternate location.

    例如,Office 365 Outlook 触发器维护客户端状态并跟踪最近读取的电子邮件的时间戳,以避免读取重复项。For example, the Office 365 Outlook trigger maintains client-side state and tracks the timestamp for the most recently read email to avoid reading a duplicate.

  • 对于处理服务器端状态的逻辑应用,可将逻辑应用实例设置为充当主动-主动角色,在这种情况下,这些实例以竞争性使用者的身份工作;或者将其设置为主动-被动角色,在这种情况下,备用实例会等待主要实例故障转移到备用位置。For a logic app that works with server-side state, you can set up your logic app instances to play either active-active roles where they work as competing consumers or active-passive roles where the alternate instance waits until the primary instance fails over to the alternate location.

    例如,从消息队列(如 Azure 服务总线队列)读取消息时会使用服务器端状态,因为排队服务会在消息中维护锁,以防其他客户端读取相同的消息。For example, reading from a message queue, such as an Azure Service Bus queue, uses server-side state because the queuing service maintains locks on messages to prevent other clients from reading the same messages.

    备注

    如果逻辑应用需要按特定顺序读取消息(例如,从服务总线队列读取),你可以使用竞争性使用者模式,但只能对服务总线会话结合使用此模式(也称为顺序保护模式)。If your logic app needs to read messages in a specific order, for example, from a Service Bus queue, you can use the competing consumer pattern but only when combined with Service Bus sessions, which is also known as the sequential convoy pattern. 否则,必须使用主动-被动角色设置逻辑应用实例。Otherwise, you must set up your logic app instances with the active-passive roles.

请求触发器Request trigger

请求触发器使得逻辑应用可从其他应用、服务和系统调用,它通常用于提供以下功能:The Request trigger makes your logic app callable from other apps, services, and systems and is typically used to provide these capabilities:

  • 为逻辑应用提供一个可由他人调用的直接 REST APIA direct REST API for your logic app that others can call

    例如,使用请求触发器启动逻辑应用,使其他逻辑应用可以使用“调用工作流 - 逻辑应用”操作来调用触发器。For example, use the Request trigger to start your logic app so other logic apps can call the trigger by using the Call workflow - Logic Apps action.

  • 为逻辑应用提供 Webhook 或回调机制A webhook or callback mechanism for your logic app

  • 可让你手动运行用户操作或例程来调用逻辑应用(例如,使用某个执行特定任务的 PowerShell 脚本)A way that you can manually run user operations or routines to call your logic app, for example, by using a PowerShell script that performs a specific task

从灾难恢复的角度讲,请求触发器是一个被动接收方,因为逻辑应用不会执行任何工作,只是等待其他某个服务或系统显式调用触发器。From a disaster recovery perspective, the Request trigger is a passive receiver because the logic app doesn't do any work and waits until some other service or system explicitly calls the trigger. 作为被动终结点,可以通过以下方式设置主要和辅助实例:As a passive endpoint, you can set up your primary and secondary instances in these ways:

  • 主动-主动:两个实例都主动处理请求或调用。Active-active: Both instances actively handle requests or calls. 调用方或路由器在这些实例之间平衡或分配流量。The caller or router balances or distributes traffic between those instances.

  • 主动-被动:仅主要实例处于活动状态并处理所有工作,辅助实例只有在主要实例遇到中断或故障时才工作。Active-passive: Only the primary instance is active and handles all the work, while the secondary instance waits until the primary experiences disruption or failure. 调用方或路由器决定何时调用辅助实例。The caller or router determines when to call the secondary instance.

可将 Azure API 管理这种建议的体系结构用作那些使用请求触发器的逻辑应用的代理。As a recommended architecture, you can use Azure API Management as a proxy for the logic apps that use Request triggers. API 管理提供内置的跨区域复原能力,以及在多个终结点之间路由流量的功能API Management provides built-in cross-regional resiliency and the capability to route traffic across multiple endpoints.

Webhook 触发器Webhook trigger

Webhook 触发器通过向服务传递回调 URL,为逻辑应用提供订阅该服务的功能。 A webhook trigger provides the capability for your logic app to subscribe to a service by passing a callback URL to that service. 然后,逻辑应用可以侦听并等待特定的事件在该服务终结点上发生。Your logic app can then listen and wait for a specific event to happen at that service endpoint. 发生该事件时,服务会使用回调 URL 来调用 Webhook 触发器,然后,后者会运行逻辑应用。When the event happens, the service calls the webhook trigger by using the callback URL, which then runs the logic app. 启用后,Webhook 触发器会订阅此服务。When enabled, the webhook trigger subscribes to the service. 禁用后,该触发器会取消订阅此服务。When disabled, the trigger unsubscribes from the service.

从灾难恢复的角度讲,需将使用 Webhook 触发器的主要和辅助实例设置为充当主动-被动角色,因为只能有一个实例从订阅的终结点接收事件或消息。From a disaster recovery perspective, set up primary and secondary instances that use webhook triggers to play active-passive roles because only one instance should receive events or messages from the subscribed endpoint.

评估主要实例的运行状况Assess primary instance health

若要使灾难恢复策略发挥作用,解决方案需要能够通过特定方式执行以下任务:For your disaster recovery strategy to work, your solution needs ways to perform these tasks:

本部分介绍一种可以直接使用或者作为自己设计的基础使用的解决方案。This section describes one solution that you can use outright or as a foundation for your own design. 下面是此解决方案的统括性视觉概览:Here's a high-level visual overview for this solution:

创建监视器逻辑应用,用于监视主要位置中的运行状况检查逻辑应用

检查主要实例的可用性Check primary instance availability

若要确定主要实例是否可用、正在运行且能够正常工作,可以在主要实例所在的同一位置创建一个“运行状况检查”逻辑应用。To determine whether the primary instance is available, running, and able to work, you can create a "health-check" logic app that's in the same location as the primary instance. 然后,可以从备用位置调用此运行状况检查应用。You can then call this health-check app from an alternate location. 如果运行状况检查应用成功做出响应,则表示该区域中的 Azure 逻辑应用服务的底层基础结构可用且在正常运行。If the health-check app successfully responds, the underlying infrastructure for the Azure Logic Apps service in that region is available and working. 如果运行状况检查应用无法做出响应,则可认为该位置不再正常。If the health-check app fails to respond, you can assume that the location is no longer healthy.

对于此任务,请创建一个执行以下任务的基本运行状况检查逻辑应用:For this task, create a basic health-check logic app that performs these tasks:

  1. 使用请求触发器接收来自监视器应用的调用。Receives a call from the watchdog app by using the Request trigger.

  2. 使用“响应”操作返回包含某种状态的响应,该状态指示检查的逻辑应用是否仍可正常运行。Respond with a status indicating whether the checked logic app still works by using the Response action.

    重要

    运行状况检查逻辑应用必须使用“响应”操作,这样应用就会以同步而不是异步方式做出响应。The health-check logic app must use a Response action so that the app responds synchronously, not asynchronously.

  3. (可选)若要进一步确定主要位置是否正常,可以考虑与此位置中的目标逻辑应用交互的任何其他服务的运行状况。Optionally, to further determine whether the primary location is healthy, you can factor in the health of any other services that interact with the target logic app in this location. 只需扩展运行状况检查逻辑应用,即可评估这些其他服务的运行状况。Just expand the health-check logic app to assess the health for these other services too.

创建监视器逻辑应用Create a watchdog logic app

若要监视主要实例的运行状况并调用运行状况检查逻辑应用,请在备用位置创建一个“监视器”逻辑应用。To monitor the primary instance's health and call the health-check logic app, create a "watchdog" logic app in an alternate location. 例如,可以设置监视器逻辑应用,以便在调用运行状况检查逻辑失败时,监视器可将警报发送到运营团队,让他们调查失败以及主要实例无法响应的原因。For example, you can set up the watchdog logic app so that if calling the health-check logic fails, the watchdog can send an alert to your operations team so that they can investigate the failure and why the primary instance doesn't respond.

重要

确保监视器逻辑应用所在的位置不同于主要位置。Make sure that your watchdog logic app is in a location that differs from primary location. 如果主要位置中的逻辑应用服务遇到问题,监视器逻辑应用可能不会运行。If the Logic Apps service in the primary location experiences problems, your watchdog logic app might not run.

对于此任务,请在辅助位置创建一个执行以下任务的监视器逻辑应用:For this task, in the secondary location, create a watchdog logic app that performs these tasks:

  1. 使用重复触发器按固定的或计划的重复周期运行。Run based on a fixed or scheduled recurrence by using the Recurrence trigger.

    可将重复周期设置为某个低于恢复时间目标 (RTO) 容许级别的值。You can set the recurrence to a value that below the tolerance level for your recovery time objective (RTO).

  2. 使用 HTTP 操作调用主要位置中的运行状况检查逻辑应用,例如:Call the health-check logic app in the primary location by using the HTTP action, for example:

激活辅助实例Activate your secondary instance

若要自动激活辅助实例,可以创建一个逻辑应用,用于调用 Azure 资源管理器连接器等管理 API,以便激活辅助位置中的相应逻辑应用。To automatically activate the secondary instance, you can create a logic app that calls the management API such as the Azure Resource Manager connector to activate the appropriate logic apps in the secondary location. 在发生特定次数的失败后,可以扩展监视器应用来调用此激活逻辑应用。You can expand your watchdog app to call this activation logic app after a specific number of failures happen.

收集诊断数据Collect diagnostic data

可为逻辑应用运行设置日志记录,将生成的诊断数据发送到 Azure 存储、Azure 事件中心和 Azure Log Analytics 等服务处进行进一步的处理。You can set up logging for your logic app runs and send the resulting diagnostic data to services such as Azure Storage, Azure Event Hubs, and Azure Log Analytics for further handling and processing.

  • 若要在 Azure Log Analytics 中使用此数据,可以通过设置逻辑应用的诊断设置并将数据发送到多个 Log Analytics 工作区,来提供主要位置和辅助位置的数据。If you want to use this data with Azure Log Analytics, you can make the data available for both the primary and secondary locations by setting up your logic app's Diagnostic settings and sending the data to multiple Log Analytics workspaces.

  • 若要将数据发送到 Azure 存储或 Azure 事件中心,可以通过设置异地冗余,来提供主要位置和辅助位置的数据。If you want to send the data to Azure Storage or Azure Event Hubs, you can make the data available for both the primary and secondary locations by setting up geo-redundancy. 有关详细信息,请参阅以下文章:For more information, see these articles:

后续步骤Next steps