Azure 逻辑应用的单租户与多租户

Azure 逻辑应用是一个基于云的平台,用于创建和运行集成应用、数据、服务和系统的自动化逻辑应用工作流。 借助此平台,可以快速为企业和企业到企业 (B2B) 方案开发高度可缩放的集成解决方案。 若要创建逻辑应用,请使用逻辑应用(消耗版)资源类型或逻辑应用(标准版)资源类型 。 “消耗”资源类型在多租户 Azure 逻辑应用中运行,而“标准”资源类型在单租户 Azure 逻辑应用环境中运行 。

在选择要使用的资源类型之前,请阅读本文以了解资源类型和服务环境之间的比较方式。 然后可以确定最合适方案需求、解决方案要求以及要在其中部署和运行工作流的环境的类型。

如果你刚接触 Azure 逻辑应用,请查看以下文档:

资源类型和环境

若要创建逻辑应用工作流,请根据你的方案、解决方案要求、所需功能以及要在其中运行工作流的环境来选择逻辑应用资源类型。

下表简要概述了逻辑应用(标准版)资源类型和逻辑应用(消耗版)资源类型之间的差异 。 你还将了解单租户环境与多租户环境在部署、托管和运行逻辑应用工作流方面的差别。

资源类型 好处 资源共享和使用 定价和计费模型 限制管理
逻辑应用(消耗)

主机环境:多租户 Azure 逻辑应用
- 最容易入门

- 仅为你使用的部分付费

- 完全托管
单个逻辑应用只单个能有一个工作流。

跨 Azure Active Directory 租户的逻辑应用共享相同的处理(计算)、存储和网络等。

为实现高可用性,已启用异地冗余存储 (GRS)
消耗(按执行付费) Azure 逻辑应用管理这些限制的默认值,但如果特定限制存在更改值的选项,则可以更改其中某些值。
逻辑应用(标准版)

主机环境:
单租户 Azure 逻辑应用
- 通过单租户 Azure 逻辑应用运行时运行。 当前不支持部署槽位。

- 更多的内置连接器,可大规模实现更高吞吐量和更低成本

- 围绕运行时和性能设置的更多控制和微调功能

- 集成了对虚拟网络和专用终结点的支持。

- 创建自己的内置连接器。

单个逻辑应用可以有多个有状态和无状态工作流。

单个逻辑应用和租户中的工作流共享相同的处理(计算)、存储和网络等。
标准,基于处于所选定价层的托管计划。

如果运行有状态工作流(这些工作流使用外部存储,Azure 逻辑应用运行时将执行遵循 Azure 存储定价的存储事务。

你可以根据方案的需求更改多个限制的默认值。

重要说明:某些限制的具有固定的上限。 在 Visual Studio Code 中,你对逻辑应用项目配置文件中的默认限制值的更改不会反应在设计器体验中。 有关详细信息,请参阅在单租户 Azure 逻辑应用中编辑中逻辑应用的应用和环境设置

逻辑应用(标准版)资源

逻辑应用(标准版)资源类型由重新设计的单租户 Azure 逻辑应用运行时提供支持。 此运行时采用 Azure Functions 扩展性模型,并作为扩展托管在 Azure Functions 运行时上。 此设计为逻辑应用工作流提供了可移植性、灵活性和更高的性能,以及继承自 Azure Functions 平台和 Azure 应用服务生态系统的其他功能和优势。

标准版资源类型引入了一个可托管多个工作流的资源结构,与 Azure 函数应用托管多个函数的方式类似。 使用一对多映射,同一逻辑应用和租户中的工作流可以共享计算和处理资源,从而基于其邻近性而提供更好的性能。 此结构不同于逻辑应用(消耗版)资源,在消耗版资源中,逻辑应用资源和工作流之间具有一对一的映射关系。

若要了解有关可移植性、灵活性和性能改进的详细信息,请继续阅读以下各节。 或者,有关单租户 Azure 逻辑应用运行时和 Azure Functions 扩展性的详细信息,请查看以下文档:

可移植性和灵活性

使用逻辑应用(标准版)资源类型创建逻辑应用时,可以在其他环境中部署和运行工作流。 如果将 Visual Studio Code 与 Azure 逻辑应用(标准版)扩展一起使用,可以在开发环境中本地开发、生成并运行工作流,而无需将其部署到 Azure。

与多租户模型相比,这些功能提供了重大改进以及实质性的好处,因为多租户模式要求你针对 Azure 中现有的正在运行的资源进行开发。 此外,用于自动执行逻辑应用(消耗计划)资源部署的多租户模型基于 Azure 资源管理器模板(ARM 模板),这些模板组合并处理逻辑应用和基础结构的资源预配。

使用逻辑应用(标准版)资源类型,部署会容易一些,因为可以将应用部署与基础结构部署相分离。 例如,可以将单租户 Azure 逻辑应用运行时和工作流一起打包为逻辑应用的一部分。 可以使用一般步骤或任务来生成、组合逻辑应用资源,并将其压缩到随时可部署的项目中。 若要部署基础结构,仍可以使用 ARM 模板单独预配这些资源以及用于这些目的的其他进程和管道。

若要部署应用,请将项目复制到主机环境,然后启动应用以运行工作流。 或者,使用你了解并使用过的工具和进程将项目集成到部署管道中。 这样,无论用于开发的技术堆栈如何,都可以使用自己选择的工具进行部署。

通过使用标准生成和部署选项,你可以将应用开发与基础结构部署分开进行关注。 因此,你将获得更通用的项目模型,你可以在其中应用多个用于通用应用的类似或相同的部署选项。 为应用生成部署管道以及在发布到生产环境之前运行所需的测试和验证时,还可以从更一致的体验中受益。

性能

使用逻辑应用(标准版)资源类型,可以在同一个逻辑应用和租户中创建和运行多个工作流。 通过这种一对多的映射,这些工作流共享计算、处理、存储和网络等资源,从而基于其邻近性而提供更好的性能。

逻辑应用(标准版)资源类型和单租户 Azure 逻辑应用运行时将更常用的托管连接器作为内置操作提供,从而实现了另一项显著的改进。 例如,你可以将内置操作用于 Azure 服务总线、Azure 事件中心、SQL 等。 同时,托管连接器版本仍然可用并且可以继续工作。

使用新的内置操作时,将创建称为“内置连接”或“服务提供程序连接”的连接 。 它们对应的托管连接称为 API 连接,该连接作为随后必须使用 ARM 模板进行部署的 Azure 资源单独创建并运行。 内置操作及其连接在本地运行于与工作流相同的进程中。 两者都托管在单租户 Azure 逻辑应用运行时上。 因此,由于与工作流的邻近性,内置操作及其连接提供的性能更好。 此设计还适用于部署管道,因为服务提供程序连接被打包到相同的生成项目中。

数据驻留

使用逻辑应用(标准版)资源类型创建的逻辑应用资源托管在单租户 Azure 逻辑应用中,不会在部署这些逻辑应用资源的区域外部存储、处理或复制数据,这意味着,逻辑应用工作流中的数据将保留在创建和部署其父资源的同一区域中。

创建、生成和部署选项

若要基于所需环境创建逻辑应用,可以使用多个选项,例如:

单租户环境

选项 资源和工具 更多信息
Azure 门户 逻辑应用(标准版)资源类型 为单租户逻辑应用创建集成工作流 - Azure 门户
Visual Studio Code Azure 逻辑应用(标准版)扩展 为单租户逻辑应用创建集成工作流 - Visual Studio Code
Azure CLI 逻辑应用 Azure CLI 扩展 目前不可用
Azure 资源管理器 - 本地
- DevOps
单租户 Azure 逻辑应用

多租户环境

选项 资源和工具 更多信息
Azure 门户 逻辑应用(消耗版)资源类型 快速入门:在多租户 Azure 逻辑应用中创建集成工作流 - Azure 门户
Visual Studio Code Azure 逻辑应用(消耗版)扩展 快速入门:在多租户 Azure 逻辑应用中创建集成工作流 - Visual Studio Code
Azure CLI 逻辑应用 Azure CLI 扩展 - 快速入门:在多租户 Azure 逻辑应用中创建和管理集成工作流 - Azure CLI

- az logic

Azure 资源管理器 创建逻辑应用 ARM 模板 快速入门:在多租户 Azure 逻辑应用中创建和部署集成工作流 - ARM 模板
Azure PowerShell Az.LogicApp 模块 Azure PowerShell 入门
Azure REST API Azure 逻辑应用 REST API Azure REST API 参考入门

尽管开发体验因创建的逻辑应用资源类型(消耗版或标准版)而异,但可以在 Azure 订阅下找到并访问所有已部署的逻辑应用 。

例如,在 Azure 门户中,逻辑应用页同时显示消耗版和标准版逻辑应用资源类型 。 在 Visual Studio Code 中,已部署的逻辑应用显示在 Azure 订阅下,但按所使用的扩展进行分组,即“Azure: 逻辑应用(消耗)”和“Azure: 逻辑应用(标准)”。

有状态和无状态工作流

使用逻辑应用(标准版)资源类型,可在同一逻辑应用中创建这些工作流类型:

  • 有状态

    如果需要保留、查看或引用来自先前事件的数据,则创建有状态工作流。 这些工作流将所有操作的输入、输出和状态保存到外部存储。 完成每次运行后,可以通过这些信息来查看工作流运行详细信息和历史记录。 如果服务中断,有状态工作流提供高复原能力。 在服务和系统还原后,你可从已保存的状态重新构造中断的运行,并再次运行工作流来完成操作。 有状态工作流可以比无状态工作流持续运行更长的时间。

    默认情况下,多租户和单租户 Azure 逻辑应用中的有状态工作流以异步方式运行。 所有基于 HTTP 的操作都遵循标准异步操作模式。 在 HTTP 操作调用某个终结点、服务、系统或 API 或向其发送请求后,请求接收方立即返回“202 已接受”响应。 此代码确认接收方已接受请求,但尚未完成处理。 响应可能包括一个 location 标头,该标头指定的 URI 和刷新 ID 可供调用方用于轮询或检查异步请求的状态,直到接收方停止处理并返回“200 正常”成功响应或其他非 202 响应。 但是,调用方不必等待请求完成处理即可继续运行下一操作。

  • 无状态

    如果不需要在每个运行完成后保留、查看或引用外部存储中的先前事件的数据(供以后查看),请创建无状态工作流。 这些工作流将每个操作的所有输入和输出及其状态仅保存在内存中,而不保存在外部存储中。 结果就是,由于外部存储不保存工作流运行详细信息和历史记录,因此无状态工作流可以在更短时间内完成运行(通常不超过 5 分钟)、性能更高、响应时间更短、吞吐量更高且运行成本更低。 不过,如果服务中断,已中断的运行不会自动还原,因此调用方需要重新手动提交已中断的运行。

    无状态工作流在处理总大小不超过 64 KB 的数据或内容(例如文件)时提供最佳性能。 内容较大(例如,多个大型附件)可能会显著降低工作流的性能,甚至会由于内存不足异常而导致工作流崩溃。 如果工作流可能需要处理较大的内容,请改用有状态工作流。

    在无状态工作流中,托管连接器操作可用,但托管连接器触发器不可用。 因此,若要启动工作流,请改为选择内置触发器,例如请求、事件中心或服务总线触发器。 这些触发器在 Azure 逻辑应用运行时中以本机方式运行。 定期触发器仅适用于有状态工作流,不适用于无状态工作流。 若要详细了解受限、不可用或不受支持的触发器、操作和连接器,请查看已更改、受限、不可用或不受支持的功能

    无状态工作流仅同步运行,因此不使用有状态工作流使用的标准异步操作模式。 相反,所有返回“202 已接受”响应的基于 HTTP 的操作都会继续完成工作流执行过程中的下一步。 如果响应包含 location 标头,则无状态工作流不会轮询指定的 URI 来检查状态。 若要遵循标准异步操作模式,请改用有状态工作流。

    为了简化调试,你可为无状态工作流启用运行历史记录(这对性能有一些影响),然后在完成时再禁用运行历史记录。 有关详细信息,请参阅在 Visual Studio Code 中创建基于单租户的工作流在 Azure 门户中创建基于单租户的工作流

重要

你必须决定要在创建时实施的工作流类型(有状态或无状态)。 创建后更改工作流类型会导致运行时错误。

有状态和无状态工作流之前的差异摘要

有状态 无状态
存储运行历史记录、输入和输出 默认情况下,不存储运行历史记录、输入或输出
托管连接器触发器可用且被允许 托管连接器触发器不可用或不被允许
支持分块 不支持分块
支持异步操作 不支持异步操作
在主机配置中编辑默认的最大运行持续时间 非常适用于最大持续时间在 5 分钟以内的工作流
处理大型消息 非常适用于处理小型消息(大小在 64 KB 以内)

有状态和无状态工作流之前的嵌套行为差异

可使用请求触发器HTTP Webhook 触发器,或者具有 ApiConnectionWebhook 类型且可接收 HTTPS 请求的托管连接器触发器,将工作流设置为可从同一“逻辑应用(标准版)”资源中存在的其他工作流调用

下表描述了在父工作流调用子工作流之后,嵌套工作流可遵循的行为模式:

  • 异步轮询模式

    父工作流不会等待子工作流响应其初始调用。 但是,父级会持续检查子级的运行历史记录,直到子级完成运行。 默认情况下,有状态工作流采用这种模式,它非常适合可能会超出请求超时限制的长期运行的子工作流。

  • 同步模式(“触发并忘记”)

    子工作流通过立即返回 202 ACCEPTED 响应来确认父工作流的调用。 但是,父级不会等待子级返回结果。 相反,父级会继续执行工作流中的下一个操作,并在子级完成运行时接收结果。 不包含响应操作的有状态子工作流始终遵循同步模式,并提供运行历史记录供你查看。

    若要启用此行为,请在工作流的 JSON 定义中,将 operationOptions 属性设置为 DisableAsyncPattern。 有关详细信息,请查看触发器和操作类型 - 操作选项

  • 触发并等待

    无状态工作流在内存中运行。 因此,父工作流调用无状态子工作流时,父工作流会等待子工作流返回结果的响应。 此模式的工作方式类似于使用内置的 HTTP 触发器或操作来调用子工作流。 不包含响应操作的无状态子工作流会立即返回 202 ACCEPTED 响应,但父工作流会等待子工作流完成,然后才继续到下一操作。 这些行为仅适用于无状态子工作流。

下表根据父工作流和子工作流是有状态、无状态还是混合工作流类型,来确定子工作流的行为。 表后面的列表

父工作流 子工作流 子工作流行为
有状态 有状态 同步或异步,带有 "operationOptions": "DisableAsyncPattern" 设置
有状态 无状态 触发并等待
无状态 有状态 同步
无状态 无状态 触发并等待

其他单租户模型功能

单租户模型和逻辑应用(标准版)资源类型包括许多当前功能和新功能,例如:

  • 通过超过数百个托管连接器,针对本地系统的服务型软件 (SaaS)、平台即服务 (PaaS) 和服务加连接器创建逻辑应用及其工作流。

    • 现在,在标准逻辑应用工作流中,更多的托管连接器可用作内置连接器。 内置版本在单租户 Azure 逻辑应用运行时上以原生方式运行。 某些内置连接器也被非正式地称为服务提供程序连接器。 有关列表,请查看消耗型和标准型内置连接器

    • 可以使用单租户 Azure 逻辑应用扩展性框架为所需的所有服务创建你自己的自定义内置连接器。 与 Azure 服务总线和 SQL Server 等内置连接器相似,自定义内置连接器可提供更高的吞吐量、低延迟和本地连接,因为它们在与单租户运行时相同的进程中运行。 但是,自定义内置连接器与目前不受支持的自定义托管连接器并不相似。 有关详细信息,请查看自定义连接器概述为单租户 Azure 逻辑应用中的标准逻辑应用创建自定义内置连接器

    • 如果没有集成帐户,可对 Liquid 操作和 XML 操作使用以下操作。 这些操作包括以下操作:

      • XML:转换 XML 和 XML 验证

      • Liquid:将 JSON 转换为 JSON、将 JSON 转换为文本、将 XML 转换为 JSON 以及将 XML 转换为文本

      注意

      若要在单租户 Azure 逻辑应用(标准版)中使用这些操作,需要有 Liquid 映射、XML 映射或 XML 架构。 可以在 Azure 门户中,从逻辑应用的资源菜单的“项目”(下其中包括“架构”和“映射”部分),上传这些项目 。 或者,可以使用相应的“映射”和“架构”文件夹,将这些项目添加到 Visual Studio Code 项目的“项目”文件夹 。 然后,可以在同一逻辑应用资源中跨多个工作流使用这些项目。

    • “逻辑应用(标准)”资源可以在任何位置运行,因为 Azure 逻辑应用可生成共享访问签名 (SAS) 连接字符串,而这些逻辑应用可使用这些字符串将请求发送到云连接运行时终结点。 Azure 逻辑应用服务会将这些连接字符串随其他应用程序设置一起保存,这样你在 Azure 中部署时,可在 Azure Key Vault 中轻松存储这些值。

    • 逻辑应用(标准)资源类型支持同时启用系统分配的托管标识多个用户分配的托管标识,不过,你任何时候都只能选用一个标识。

      注意

      在默认情况下,已启用系统分配的标识,以便在运行时对连接进行身份验证。 该标识与你在创建连接时使用的身份验证凭据或连接字符串不同。 如果禁用该标识,则运行时连接无效。 若要查看此设置,请在逻辑应用菜单的“设置”下,选择“标识” 。

  • 可在 Visual Studio Code 开发环境中本地运行、测试和调试逻辑应用及其工作流。

    在运行和测试逻辑应用之前,可在工作流的 workflow.json 文件中添加和使用断点来简化调试。 不过,断点目前仅可用于操作,不可用于触发器。 有关详细信息,请参阅在 Visual Studio Code 中创建基于单租户的工作流

  • 将逻辑应用及其工作流从 Visual Studio Code 直接发布或部署到各种托管环境中,例如 Azure。

  • 如果你的 Azure 订阅和逻辑应用设置支持,可使用 Application Insights 为逻辑应用启用诊断日志记录和跟踪功能。

  • 访问网络功能(例如连接功能)并以专用方式与 Azure 虚拟网络集成,这与你在使用 Azure Functions 高级计划创建和部署逻辑应用时的 Azure Functions 很相似。 有关详细信息,请查看以下文档:

  • 为逻辑应用(标准版)资源中单个工作流使用的托管连接重新生成访问密钥。 在此任务中,请针对逻辑应用(消耗版)资源在单独工作流级别(而不是逻辑应用资源级别)执行相同步骤

适用于标准版的内置连接器

标准逻辑应用工作流有许多与消耗逻辑应用工作流相同的内置连接器,但并没有全部此类内置连接器。 反之亦然,标准逻辑应用工作流有许多在消耗逻辑应用工作流中不可用的内置连接器。

例如,标准逻辑应用工作流有适用于 Azure Blob、Azure Cosmos DB、Azure 事件中心、Azure 服务总线、DB2、FTP、MQ、SFTP、SQL Server 等的托管连接器和内置连接器。 尽管消耗逻辑应用工作流没有这些相同的内置连接器版本,但其他内置连接器(例如 Azure API 管理、Azure 应用 服务和 Batch)可用。

在单租户 Azure 逻辑应用中,具有特定属性的内置连接器称为“服务提供程序”(非正式)。 一些内置连接器仅支持一种方法来验证与基础服务的连接。 其他内置连接器可以提供选择,例如使用连接字符串、Azure Active Directory (Azure AD) 或托管标识。 所有内置连接器都与重新设计的 Azure 逻辑应用运行时在同一进程中运行。 有关详细信息,请查看标准逻辑应用工作流的内置连接器列表

已更改、受限、不可用或不受支持的功能

对于逻辑应用(标准)资源,下列功能已经过更改,它们目前受限、不可用或不受支持:

  • 触发器和操作内置触发器和操作在 Azure 逻辑应用中本地运行,而托管连接器在 Azure 中托管和运行。 对于标准工作流,一些内置触发器和操作当前不可用,例如滑动窗口、批处理、Azure 应用服务和 Azure API 管理。 若要启动有状态或无状态工作流,请使用内置触发器,例如请求、事件中心或服务总线触发器。 定期触发器仅适用于有状态工作流,不适用于无状态工作流。 在设计器中,内置触发器和操作显示在“内置”选项卡下,而托管连接器触发器和操作显示在“Azure”选项卡下。

    对于无状态工作流,托管连接器操作可用,但托管连接器触发器不可用。 因此,仅当可以选择托管连接器操作时,才会显示“Azure”选项卡。 虽然可为无状态工作流启用托管连接器,但设计器不会显示任何托管连接器触发器供你添加。

    注意

    若要在 Visual Studio Code 中本地运行,基于 Webhook 的触发器和操作需要额外设置。 有关详细信息,请参阅在 Visual Studio Code 中创建基于单租户的工作流

    • 以下触发器和操作已经过更改,或者目前功能受限、不受支持或不可用:

      • 本地数据网关触发器不可用,但网关操作可用 。

      • Azure Functions - 选择 Azure 函数这一内置操作现在名为“Azure 函数操作 - 调用 Azure 函数”。 此操作目前仅适用于通过 HTTP 触发器模板创建的函数。

        在 Azure 门户中,可选择一个 HTTP 触发器函数,你可通过用户体验创建连接来访问此函数。 如果使用 Visual Studio Code 在代码视图或 workflow.json 文件中检查函数操作的 JSON 定义,则操作会使用 connectionName 引用来引用函数。 此版本会将函数的信息抽象化处理为一个连接,可在逻辑应用项目的 connections.json 文件中找到它,这是在 Visual Studio Code 中创建连接后提供的。

        注意

        在单租户模型中,函数操作仅支持查询字符串身份验证。 Azure 逻辑应用会在建立连接时从函数中获取默认密钥、将该密钥存储在应用的设置中,并在调用函数时使用该密钥来进行身份验证。

        与多租户模型一样,如果你续订此密钥(例如通过门户中的 Azure Functions 体验),且由于密钥无效,函数操作会失效。 若要解决此问题,需要重新创建与你想要调用的函数的连接,或者使用新密钥更新应用的设置。

        • 内置操作“内联代码”已重命名为“内联代码操作”,不再需要集成帐户,并且具有更新后的限制

      • Azure 逻辑应用 - 创建逻辑应用工作流这一内置操作现在名为“工作流操作 - 在此工作流应用中调用工作流”。

      • 某些适用于集成帐户的触发器和操作不可用,例如 AS2 (V2) 操作和 RosettaNet 操作。

      • 当前不支持自定义托管连接器。 但是,在使用 Visual Studio Code 时,可以创建自定义内置操作。 有关详细信息,请查看使用 Visual Studio Code 创建基于单租户的工作流

  • 身份验证:以下身份验证类型目前不适用于“逻辑应用(标准)”资源类型:

    • Azure Active Directory 开放式身份验证 (Azure AD OAuth),用于对基于请求的触发器(例如请求触发器和 HTTP Webhook 触发器)进行入站调用。

    • 用户分配的托管标识。 目前,只有系统分配的托管标识可用并且会自动启用。

  • XML 转换:对通过映射引用程序集的支持当前不可用。 此外,当前仅支持 XSLT 1.0。

  • Visual Studio Code 中的断点调试:虽然可在工作流的 workflow.json 文件中添加和使用断点,但目前仅可对操作使用断点,不可将其用于触发器。 有关详细信息,请参阅在 Visual Studio Code 中创建基于单租户的工作流

  • 触发器历史记录和运行历史记录:对于“逻辑应用(标准版)”资源类型,Azure 门户中的触发器历史记录和运行历史记录显示在工作流级别中,而非逻辑应用级别中。 有关详细信息,请查看使用 Azure 门户创建基于单租户的工作流

  • 缩放控件:目前不可在设计器上使用缩放控件。

  • 部署目标:无法将“逻辑应用(标准)”资源类型部署到 Azure 部署槽位 。

  • Azure API 管理:当前无法将逻辑应用(标准版)资源类型导入 Azure API 管理。 但可以导入逻辑应用(消耗版)资源类型。

严格的网络和防火墙流量权限

如果你的环境设有限制流量的严格网络要求或防火墙,则必须允许访问以在工作流中实现任何触发器或操作连接。 可以选择允许来自服务标记的流量,并使用与 Azure 应用服务相同级别的限制或策略。 还需查找完全限定的域名 (FQDN) 并为连接适用这些域名。 有关详细信息,请查看以下文档中的相应部分:

后续步骤

我们还希望你就单租户 Azure 逻辑应用体验提供反馈!