标准的单租户逻辑应用程序与消费型多租户逻辑应用程序之间的差异

Azure Logic Apps是一个基于云的平台，用于创建和运行自动化逻辑应用工作流，用于集成应用、数据、服务和系统。 借助此平台，可以快速为企业和企业到企业 (B2B) 方案开发高度可缩放的集成解决方案。 创建逻辑应用资源时，可以选择“消费型”或者“标准”托管选项。 消费逻辑应用只能有一个在 multitenant Azure Logic Apps 中运行的工作流。 标准逻辑应用可以有一个或多个在单租户 Azure Logic Apps 或 App Service Environment v3（ASE v3）中运行的工作流。

在选择要创建的逻辑应用资源之前，请查看以下指南，了解不同的逻辑应用工作流类型之间的对比。 然后，可以做出更好的选择，确定哪个逻辑应用工作流和环境最适合你的方案、解决方案要求，以及要部署和运行工作流的目标。

如果你不熟悉 Azure Logic Apps，请查看 什么是 Azure Logic Apps？ 和 什么是 c1>逻辑应用工作流？

逻辑应用工作流类型和环境

下表总结了消耗型逻辑应用工作流和标准型逻辑应用工作流之间的差异。 你还将了解单租户环境与多租户环境在部署、托管和运行工作流方面的差异。

标准逻辑应用和工作流

Standard 逻辑应用和工作流由重新设计的单租户Azure Logic Apps运行时提供支持。 此运行时使用 Azure Functions 扩展性模型并在Azure Functions运行时上托管为扩展。 此设计为逻辑应用工作流提供可移植性、灵活性和更高的性能，以及继承自 Azure Functions 平台和Azure App Service生态系统的其他功能和优势。 例如，可以在 Azure App Service Environment v3（仅限 Windows 计划）0 中创建、部署和运行基于单租户的逻辑应用及其工作流。

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

若要了解有关可移植性、灵活性和性能改进的详细信息，请继续阅读以下各节。 有关单租户Azure Logic Apps运行时和Azure Functions扩展性的详细信息，请查看以下文档：

• Azure Logic Apps任意位置运行 - 深度剖析运行时
• Azure Functions 简介
• Azure Functions触发器和绑定

可移植性和灵活性

创建 标准 逻辑应用和工作流时，可以在其他环境中部署和运行工作流。 如果将 Visual Studio Code 与 Azure Logic Apps（Standard） 扩展配合使用，则可以locally开发、生成和运行开发环境中的工作流，而无需部署到Azure。

与多租户模型相比，这些功能提供重大改进和实质性优势，这要求针对Azure中的现有正在运行的资源进行开发。 用于自动执行 Consumption 逻辑应用资源部署的多租户模型基于Azure Resource Manager模板（ARM 模板），该模板合并和处理应用和基础结构的资源预配。

借助标准型逻辑应用资源，部署会容易一些，因为可以将应用部署与基础结构部署分离开来。 可以将单租户的 Azure Logic Apps 运行时和工作流打包在一起，作为逻辑应用资源或项目的一部分。 可以使用构建、组装和压缩逻辑应用程序资源的通用步骤或任务，将其打包为可部署的工件。 若要部署基础结构，仍可以使用 ARM 模板来单独预配这些资源，并结合其他用于此目的的进程和管道。

若要部署应用，请将artifacts复制到主机环境，然后启动应用以运行工作流。 或者，使用您已了解和使用的工具和流程，将工件集成到部署流水线中。 这样，无论用于开发的技术堆栈如何，都可以使用自己选择的工具进行部署。

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

性能

借助标准型逻辑应用，可以在同一逻辑应用资源和租户中创建和运行多个工作流。 借助这种一对多映射，这些工作流共享例如计算、处理、存储和网络等资源，由于它们的邻近性，从而提供更好的性能。

Standard 逻辑应用资源和单租户Azure Logic Apps运行时通过将更受欢迎的托管连接器作为内置连接器操作提供，进一步实现了重要改进。 例如，可以使用内置连接器操作于 Azure Service Bus、Azure Event Hubs、SQL Server 和其他服务。 同时，托管连接器版本仍然可用并且可以继续工作。

使用新的内置连接器操作时，将创建称为“内置连接”或“服务提供程序连接”的连接。 其托管连接对应项称为 API 连接，这些连接是作为独立的 Azure 资源创建和运行的，你还必须使用 ARM 模板来部署它们。 内置操作及其连接在本地运行于与工作流相同的进程中。 两者都托管在单一租户 Azure Logic Apps 运行时。 因此，由于与工作流的邻近性，内置操作及其连接提供的性能更好。 此设计也适用于部署管道，因为服务提供商连接被打包到同一构建工件中。

数据存储地

Standard逻辑应用资源托管在单租户Azure Logic Apps中，不会在您部署这些逻辑应用资源的区域之外存储、处理或复制数据，这意味着您的工作流中的数据保留在您创建和部署其父资源的同一区域中。

创建、生成和部署选项

若要基于所需环境创建逻辑应用资源，你有多个选择，例如：

单租户环境

多租户环境

虽然开发体验因创建 Consumption 或 Standard 逻辑应用资源而异，但可以在 Azure 订阅下查找和访问所有已部署的逻辑应用。

例如，在 Azure portal 中，Logic apps 页显示 Consumption 和 Standard 逻辑应用资源。 在 Visual Studio Code 中，已部署的逻辑应用显示在您的 Azure 订阅下，但 Consumption 逻辑应用显示在 Azure 窗口的 Azure Logic Apps (Consumption) 扩展中，而 Standard 逻辑应用显示在 Resources 部分下。

有状态和无状态工作流

在标准型逻辑应用中，可以创建以下工作流类型：

• 有状态

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

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

• 无状态

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

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

  注意事项

  在无状态工作流中，只能使用推送触发器，而不能指定工作流的运行计划。 这些基于 Webhook 的触发器会等待事件发生或数据变得可用。 例如，重复触发器仅适用于有状态工作流。 若要启动工作流，请选择推送触发器，例如请求、事件中心或Service Bus触发器。 若要详细了解受限、不可用或不受支持的触发器、操作和连接器，请查看已更改、受限、不可用或不受支持的功能。

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

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

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

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

可以使用请求触发器、HTTP Webhook 触发器，或者具有 ApiConnectionWebhook 类型且可接收 HTTPS 请求的托管连接器触发器，使工作流可从同一标准型逻辑应用中存在的其他工作流调用。

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

• 异步轮询模式

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

• 同步模式（“触发并忘记”）

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

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

• 触发并等待

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

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

其他单租户模型功能

单租户模型和标准型逻辑应用包括许多当前功能和新功能，例如：

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

  • 现在，在标准型工作流中，更多的管理型连接器可用作内置连接器。 内置版本在单租户 Azure Logic Apps 运行时本地运行。 某些内置连接器也被非正式地称为服务提供程序连接器。 要查看列表，请参阅消耗型和标准型内置连接器。

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

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

    • XML：“转换 XML”、“XML 验证”、“使用架构撰写 XML”和“使用架构分析 XML”

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

    注意事项

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

  • Standard 逻辑应用工作流可以从任何位置触发，因为Azure Logic Apps生成共享Access签名（SAS）连接字符串，这些逻辑应用可用于将请求发送到云连接运行时终结点。 Azure Logic Apps将这些连接字符串与其他应用程序设置一起保存，以便在部署Azure时轻松地将这些值存储在Azure Key Vault中。

  • 标准型逻辑应用工作流支持同时启用系统分配的托管标识 和多个用户分配的托管标识，尽管一次只能选择一个要使用的标识。 虽然内置的基于服务提供商的连接器支持使用系统分配的标识，但大多数连接器目前不支持选择用户分配的托管标识进行身份验证，但除了SQL Server和 HTTP 连接器之外。

    注意事项

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

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

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

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

• 当Azure订阅和逻辑应用设置支持时，使用 Application Insights 为逻辑应用启用诊断日志记录和跟踪功能。

• 访问网络功能，例如，当您使用Azure Functions Premium 计划创建和部署逻辑应用时，可以通过专用连接和集成方式与 Azure 虚拟网络进行私人连接，类似于 Azure Functions 的方式。 有关详细信息，请查看以下文档：

  • Azure Functions网络选项

  • Azure Logic Apps随处运行 - 使用Azure Logic Apps的网络可能性

• 在 Standard 逻辑应用中，为单个工作流使用的托管连接重新生成访问密钥。 对于此任务，为 Consumption 逻辑应用执行相同的步骤，但在工作流级别，而不是逻辑应用资源级别。

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

标准型工作流可以使用许多与消耗型工作流相同的内置连接器，但并非全部。 反之亦然，标准型工作流具有许多在消耗型工作流中不可用的内置连接器。

例如，标准工作流同时具有用于 Azure Blob、Azure Cosmos DB、Azure Event Hubs、Azure Service Bus、DB2、FTP、MQ、SFTP、SQL Server 等的托管连接器和内置连接器。 尽管消费计划工作流没有这些相同的内置连接器版本，但可以使用其他内置连接器，例如 Azure API Management 和 Azure 应用服务。

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

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

对于标准逻辑应用工作流，以下功能不同、当前受限、不可用或不受支持：

• 触发和操作：内置触发器和操作以本机方式在 Azure Logic Apps 中运行，而托管连接器使用 Azure 中的共享资源进行托管和运行。 对于标准工作流，某些内置触发器和操作当前不可用，例如 Azure App Service 操作。 若要启动有状态或无状态工作流，请使用内置触发器，例如请求、事件中心或Service Bus触发器。 定期触发器仅适用于有状态工作流，不适用于无状态工作流。 在连接器库中，选择内置筛选器时，会显示内置触发器和动作；而选择共享筛选器时，则会显示托管连接器触发器和动作。

  无状态工作流只能使用推送触发器，而不能指定工作流的运行计划。 这些基于 Webhook 的触发器会等待事件发生或数据变得可用。 例如，重复触发器仅适用于有状态工作流。 若要启动工作流，请选择推送触发器，例如请求、事件中心或Service Bus触发器。 虽然可为无状态工作流启用托管连接器，但连接器库中不会显示任何托管连接器的轮询触发器供你添加。

  注意事项

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

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

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

      在 Azure 门户中，您可以选择一个 HTTP 触发器函数，并通过用户体验创建连接来访问该函数。 如果使用 Visual Studio Code 查看函数操作的 JSON 定义或 workflow.json 文件，该操作将使用 connectionName 引用函数。 此版本将函数的信息抽象为连接，您可以在逻辑应用项目的connections.json文件中找到该信息，该文件在 Visual Studio Code 中创建连接后可用。

      注意事项

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

      多租户模型中也是如此，如果通过门户中的Azure Functions体验续订此密钥，由于密钥无效，函数操作不再有效。 若要解决此问题，需要重新创建与你想要调用的函数的连接，或者使用新密钥更新应用的设置。

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

    • 内置动作Azure Logic Apps - 选择一个逻辑应用工作流现在工作流操作 - 在此工作流应用中调用工作流。

    • 标准工作流只能有一个触发器，不支持多个触发器。

• 身份验证

  • 某些处理入站调用（例如请求触发器）的基于请求的触发器当前不支持Microsoft Entra ID开放身份验证（Microsoft Entra ID OAuth），而其他触发器（如 HTTP Webhook 触发器）则支持此支持。

• Visual Studio Code 中的断点调试：尽管你可以在工作流的 workflow.json 文件中添加和使用断点，但断点目前仅支持动作，而不是触发器。 有关详细信息，请参阅 在 Visual Studio Code 中创建基于单租户的工作流。

• 触发器历史记录和运行历史记录：对于标准逻辑应用工作流，Azure portal 中的触发器历史记录和运行历史记录显示在工作流级别，而不是逻辑应用资源级别。 有关详细信息，请查阅 使用 Azure portal 创建基于单租户的工作流。

• 传入客户端证书：Standard逻辑应用不支持传入客户端证书，Azure portal中没有逻辑应用的客户端证书设置。 如果使用 ARM 模板部署，请确保未启用客户端证书。

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

如果您的环境对网络要求严格，或有防火墙限制流量，您必须允许工作流中的任何触发器或连接访问。 可以选择允许来自 service tags 的流量，并使用与Azure App Service相同的限制或策略级别。 您还需要查找并使用完全限定域名 (FQDN) 来进行连接。 有关详细信息，请查看以下文档中的相应部分：

• 单租户逻辑应用的防火墙权限——Azure 门户
• 单个租户逻辑应用的防火墙权限：Visual Studio Code

后续步骤

• 在 Azure 门户中创建基于单租户的工作流
• 在 Visual Studio Code 中创建基于单租户的工作流

我们还希望了解您对单租户 Azure Logic Apps 的体验！

• 对于 bug 或问题，在 GitHub 中创建问题。
• 如有问题、请求、意见和其他反馈，请使用此反馈表单。