你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用范围：Azure 逻辑应用（消耗型 + 标准型）
借助 Azure 逻辑应用可以创建和运行可在云中缩放的自动化集成工作流。 本文介绍适用于 Azure 逻辑应用和相关资源的计量、计费和定价模型的工作原理。 有关特定定价费率、成本计划或不同托管环境等信息，请查看以下内容：
消耗（多租户）
在多租户 Azure 逻辑应用中，逻辑应用及其工作流在定价和计费方面将遵循消耗计划。 可以通过多种方式创建此类逻辑应用，例如，当选择“逻辑应用(消耗)”资源类型时、使用 Visual Studio Code 中的“Azure 逻辑应用(消耗)”扩展，或者当创建自动化任务时 。
下表汇总了当以下组件与多租户 Azure 逻辑应用中的逻辑应用和工作流一起使用时，消耗模型如何处理它们的计量和计费：
| 组件 | 度量和计费 |
|---|---|
| 触发器和操作 | 消耗模型包含按 Azure 订阅提供的初始免费内置操作数，工作流可以运行这些内置操作。 当执行的内置操作数超出此数量后，会对每次执行进行计量，并按照消耗计划中的操作定价进行计费 。 对于其他操作类型，例如托管连接器，将按照消耗计划中的标准或企业连接器定价进行计费 。 有关详细信息，请参阅消耗模型中的触发器和操作。 |
| 存储操作 | 仅对与数据保留相关的存储消耗进行计量，例如保存工作流运行历史记录中的输入和输出。 计费遵循适用于消耗计划的数据保留定价。 有关详细信息，请参阅存储操作。 |
| 集成帐户 | 根据所创建的并与逻辑应用一起使用的集成帐户类型进行计量。 计费遵循集成帐户定价。 有关详细信息，请参阅集成帐户。 |
消耗模型中的触发器和操作
除开针对每个 Azure 订阅所包含的工作流可以运行的初始免费内置操作数，消耗模型将基于操作的每次执行对操作进行计量和计费，无论整个工作流是否成功运行、完成，甚至是否已实例化。 一个操作通常执行一次，除非操作启用了重试尝试。 相应地，一次执行通常进行一次调用，除非操作支持并启用了分块或分页以获取大量数据。 如果启用了分块或分页，一次操作执行可能需要进行多次调用。
消耗模型按执行对操作进行计量和计费，而不是按调用来对操作进行计量和计费。 例如，假设一个工作流从轮询触发器开始，该触发器通过定期对终结点进行出站调用来获取记录。 无论触发器是触发还是跳过（例如，当触发器检查终结点但未找到任何数据或事件时），出站调用都将作为单次执行进行计量和计费。 触发器状态控制是否已创建和运行工作流实例。 现在，假设此操作还支持并启用了分块或分页。 如果此操作必须执行 10 次调用才能完成所有数据的获取，尽管进行了多次调用，但仍会将此操作作为单次执行来进行计量和计费。
注意
默认情况下，返回数组的触发器具有已启用的“拆分”设置。 此设置会生成一个触发器事件（可以在触发器历史记录中查看该事件）和一个工作流实例 for each 数组项。 所有工作流实例都并行运行，以便同时处理数组项。 计费适用于所有触发器事件，无论触发器状态为“成功”还是“已跳过”。 即使在触发器未实例化并启动工作流的情况下，触发器仍可计费，但触发器状态为“成功”、“失败”或“已跳过”。
下表汇总了当以下操作类型与多租户 Azure 逻辑应用中的逻辑应用和工作流一起使用时，消耗模型如何处理它们的计量和计费：
| 操作类型 | 说明 | 度量和计费 |
|---|---|---|
| 内置 | 这些操作使用 Azure 逻辑应用运行时直接本机运行。 在设计器中，你可以在“内置”标签下找到这些操作。 例如，HTTP 触发器和请求触发器是内置触发器。 HTTP 操作和响应操作是内置操作。 其他内置操作包括工作流控制操作（例如循环和条件）、数据操作和批处理操作等。 |
消耗模型包含按 Azure 订阅提供的初始免费内置操作数，工作流可以运行这些内置操作。 当执行的内置操作数超出此数量后，将按照操作定价来对内置操作的执行进行计费。 注意：某些托管连接器操作也作为内置操作提供，这些操作的执行包含在初始免费操作数中。 当执行的这些操作数超出初始免费操作数后，将按照操作定价来对这些操作进行计费，而不是按照标准或企业连接器定价来进行计费 。 |
| 托管连接器 | 这些操作在 Azure 中单独运行。 在设计器中，你可以在“标准”或“企业”标签下找到这些操作 。 | 这些操作的执行遵循标准或企业连接器定价 。 注意：预览版企业连接器操作的执行遵循消耗计划中的标准连接器定价。 |
| 自定义连接器 | 这些操作在 Azure 中单独运行。 在设计器中，你可以在“自定义”标签下找到这些操作。 有关连接器数量、吞吐量和超时的限制，请参阅 Azure 逻辑应用中的自定义连接器限制。 | 这些操作的执行遵循标准连接器定价。 |
有关消耗模型如何处理在其他操作（例如循环）内运行的操作、处理多个项目（例如数组）的操作以及重试策略的操作的详细信息，请参阅其他操作行为。
消耗模型的成本估算提示
以下提示有助于更准确地估计消耗成本：
请考虑任何给定日可能到达的消息或事件数，而不是仅基于轮询间隔进行计算。
当某个事件或消息满足触发器条件时，许多触发器将立即尝试读取任何其他满足条件的等待事件或消息。 此行为意味着，即使你选择较长的轮询间隔，触发器也基于符合启动工作流条件的等待事件或消息的数量进行触发。 遵循此行为的触发器包括 Azure 服务总线和 Azure 事件中心。
例如，假设你设置了一个每天检查终结点的触发器。 当触发器检查终结点并找到 15 个满足条件的事件时，触发器触发并运行相应工作流 15 次。 逻辑应用服务会计量这 15 个工作流执行的所有操作，包括触发器请求。
标准（单租户）
在单租户 Azure 逻辑应用中，逻辑应用及其工作流在定价和计费方面遵循标准计划。 可以通过多种方式创建此类逻辑应用，例如，当选择“逻辑应用(标准)”资源类型时或者使用 Visual Studio Code 中的“Azure 逻辑应用(标准)”扩展 。 此定价模型要求逻辑应用使用托管计划和定价层，与消耗计划的不同之处在于，你需要为预留容量和专用资源付费，无论你是否使用了它们。
使用 逻辑应用（标准） 资源类型创建逻辑应用时，可以选择托管选项，例如 工作流服务计划、 应用服务环境 V3 或 混合。
重要
如果选择 应用服务环境 V3，还必须选择 应用服务计划。 应用服务计划仅适用于应用服务环境 v3 (ASE v3)。
在单租户 Azure 逻辑应用中公开发布标准逻辑应用工作流时，不再提供以下计划和资源：Functions Premium 计划、应用服务环境 v1 和应用服务环境 v2。
下表总结了当以下组件与单租户 Azure 逻辑应用中的逻辑应用和工作流一起使用时，标准模型如何处理这些组件的计量和计费：
| 组件 | 度量和计费 |
|---|---|
| 虚拟 CPU (vCPU) 和内存 | 对于托管选项工作流服务计划和应用服务环境 V3，还可以选择一个定价层，用于确定适用于计算和内存容量的资源级别和定价费率。 有关详细信息，请参阅标准模型中的定价层。 有关混合部署，请参阅标准（混合部署）。 |
| 触发器和操作 | 标准模型包含无限的免费内置操作数，工作流可以运行这些内置操作。 如果工作流使用任何托管连接器操作，将根据每次调用进行计量，同时将按照与消耗计划相同的标准或企业连接器定价来进行计费。 有关详细信息，请参阅标准模型中的触发器和操作。 |
| 存储操作 | 将对由 Azure 逻辑应用运行的任何存储操作进行计量。 例如，当服务保存工作流运行历史记录中的输入和输出时，就会运行存储操作。 计费将遵循所选的定价层。 有关详细信息，请参阅存储操作。 |
| 集成帐户 | 如果创建集成帐户以供逻辑应用使用，将基于所创建的集成帐户类型进行计量。 计费将遵循集成帐户定价。 有关详细信息，请参阅集成帐户。 |
标准模型中的定价层
所选用于为逻辑应用（标准）资源进行计量和计费的定价层包含虚拟 CPU (vCPU) 和内存资源的特定计算量。 如果选择 应用服务环境 V3 作为托管选项和应用服务计划（特别是独立 V2 服务计划定价层），则需为应用服务计划使用的实例和运行逻辑应用工作流付费。 此外没有其他费用。 有关详细信息，请参阅应用服务计划 - 独立 V2 服务计划定价层。
如果选择了工作流标准托管计划，则可以从以下层中进行选择：
| 定价层 | 虚拟 CPU (vCPU) | 内存 (GB) |
|---|---|---|
| WS1 | 1 | 3.5 |
| WS2 | 2 | 7 |
| WS3 | 4 | 14 |
重要
以下示例仅用于演示，提供了示例估计来大致展示定价层的工作原理。 有关基于 Azure 逻辑应用可用的特定区域的特定 vCPU 和内存定价，请参阅 Azure 逻辑应用定价页上所选区域的标准计划。
假设在示例区域中，以下资源每小时的费率为：
| 资源 | 每小时费率（示例区域） |
|---|---|
| vCPU | 每 vCPU 0.192 美元 |
| 内存 | 每 GB 0.0137 美元 |
以下计算提供预估的每月费率：
<每月费率> = 730 小时（每月）* [（<vCPU 数 * >vCPU 每小时费率<）+（内存 GB 数> * <GB 内存每小时费率）]><>
根据上述信息，下表列出了每个定价层以及该定价层中资源的预估每月费率：
| 定价层 | 虚拟 CPU (vCPU) | 内存 (GB) | 每月费率（示例区域） |
|---|---|---|---|
| WS1 | 1 | 3.5 | 175.16 美元 |
| WS2 | 2 | 7 | 350.33 美元 |
| WS3 | 4 | 14 | 700.65 美元 |
标准模型中的触发器和操作
除开工作流可以运行的无限数量的免费内置操作，标准模型将基于操作的每次调用对操作进行计量和计费，无论整个工作流是否成功运行、完成，甚至是否已实例化。 一个操作通常执行一次，除非操作启用了重试尝试。 相应地，一次执行通常进行一次调用，除非操作支持并启用了分块或分页以获取大量数据。 如果启用了分块或分页，一次操作执行可能需要进行多次调用。 标准模型按调用对操作进行计量和计费，而不是按执行来对操作进行计量和计费。
例如，假设一个工作流从轮询触发器开始，该触发器通过定期对终结点进行出站调用来获取记录。 出站调用会被计量和计费，无论触发器是否触发或被跳过。 触发器状态控制是否已创建和运行工作流实例。 现在，假设此操作还支持并启用了分块或分页。 如果此操作必须执行 10 次调用才能完成所有数据的获取，那么将按调用来对此操作进行计量和计费。
下表总结了当以下操作类型与单租户 Azure 逻辑应用中的逻辑应用和工作流一起使用时，标准模型如何处理这些操作类型的计量和计费：
| 操作类型 | 说明 | 度量和计费 |
|---|---|---|
| 内置 | 这些操作使用 Azure 逻辑应用运行时直接本机运行。 在设计器中，可以在连接器库中的“内置”下找到这些操作。 例如，HTTP 触发器和请求触发器是内置触发器。 HTTP 操作和响应操作是内置操作。 其他内置操作包括工作流控制操作（例如循环和条件）、数据操作和批处理操作等。 |
标准模型包含无限的免费内置操作数。 注意：某些托管连接器操作也作为内置操作提供。 尽管内置操作是免费的，但标准模型仍会使用与消耗模型相同的标准或企业连接器定价来对托管连接器操作进行计量和计费 。 |
| 托管连接器 | 这些操作在共享全球 Azure 中单独运行。 在设计器中，可以在连接器库中的“运行时”>“共享”下找到这些操作。 | 标准模型按照与消耗模型相同的标准或企业连接器定价来对托管连接器操作进行计量和计费 。 注意：预览版企业连接器操作遵循消耗计划中的标准连接器定价。 |
| 自定义连接器 | 目前，在基于单租户的逻辑应用工作流中只能创建并使用自定义内置连接器操作。 | 标准模型包含无限的免费内置操作数。 有关吞吐量和超时的限制，请参阅 Azure 逻辑应用中的自定义连接器限制。 |
若要详细了解标准模型如何处理在其他操作（例如循环）内运行的操作、处理多个项（例如数组）的操作以及重试策略的操作，请查看其他操作行为。
标准 - 混合部署
此托管选项采用按需付费的计费模型，您只需支付所需的费用，并可以根据动态工作量灵活调整资源，无需为高峰使用量预先购入资源。 你负责以下各项：
已启用 Azure Arc 的 Kubernetes 基础结构
您的 SQL Server 许可证
用于支持标准逻辑应用工作负载的 vCPU 使用量的计费费用
有关详细信息，请参阅以下各节：
计费费用计算，基于逻辑应用混合部署模型定价部分中的费率。
逻辑应用工作流中任何托管（共享）连接器操作（例如 Microsoft Teams 或 Microsoft Office 365）的计费费用。
这些操作遵循 标准定价。
vCPU 使用计算
标准逻辑应用的 vCPU 使用情况会影响计费费用。 vCPU 是指 CPU 核心数，但此比率不一定为 1：1。 以下公式计算逻辑应用的 vCPU 使用情况：
vCPU 用法 = （已分配的 vCPU#） x （副本数）
| 价值 | 说明 |
|---|---|
| 分配的 vCPU 数 | 默认情况下，逻辑应用程序被分配了一定数量的 vCPU。 创建逻辑应用资源后，可以随时 更改此 vCPU 分配 。 注意：分配给逻辑应用的任何 vCPU 都来自 副本 vCPU，因此分配范围从 0.25 到 2 个核心。 有关详细信息，请参阅下一行。 |
| 副本数 | 副本是发生工作流触发器事件时部署的逻辑应用资源修订或版本的新实例。 由于应用在任意时间的缩放需求，副本数量可能会有所不同。 可以更改每个版本或修订版的 最小和最大副本数 ，以满足缩放需求。 注意：每个副本限制为两个 vCPU。 分配给逻辑应用的任何 vCPU 都来自副本 vCPU，因此分配范围为 0.25 到 2 个核心。 |
计费费用计算
以下公式计算您的每小时计费标准，该费用基于 vCPU 使用情况和 逻辑应用混合部署模型定价部分中 的每小时美元 (USD) 费率，适用于您的逻辑应用已启用的情况。
每小时费用 = （vCPU 使用情况） x （每小时费率）
例如，下表显示了一些计费费用计算示例：
| 分配的 vCPU 数量 | 副本数 | vCPU 使用情况 | 每小时美元汇率 | 每小时收费 |
|---|---|---|---|---|
| 1 | 1 | （1 x 1） = 1 | $0.22 | （1 x $0.22） = $0.22 |
| 0.5 | 2 | （0.5 x 2） = 1 | $0.22 | （1 x $0.22） = $0.22 |
| 0.5 | 1 | (0.5 x 1) = 0.5 | $0.22 | （0.5 x $0.22） = $0.11 |
其他操作行为
下表汇总了消耗和标准模型如何处理在其他操作（例如循环）内部运行的操作、处理多个项（例如数组）的操作以及重试策略的操作：
| 操作 | 说明 | 消耗 | 标准 |
|---|---|---|---|
| 循环操作 | 循环操作（例如 For each 或 Until 循环）可以包含在每个循环周期内运行的其他操作 。 | 除开所包含的初始内置操作数，每次循环运行时，都会对循环操作以及此循环中的每个操作进行计量。 如果某一操作处理集合中的任何项，例如列表或数组，那么这些项的数量也会用于计量计算中。 例如，假设有一个 For each 循环，其中包含处理一个列表的操作。 服务会将列表项的数量与循环中的操作数量相乘，再加上启动循环的操作数。 因此，包含 10 个项的列表的计算公式为 (10 * 1) + 1，即 11 个操作执行。 定价取决于操作类型是内置操作、标准连接器操作还是企业连接器操作。 |
除了包含的内置操作次数外，其他方面与消耗模型相同。 |
| 重试策略 | 针对受支持的操作，可以通过设置重试策略来实现基本的异常和错误处理。 | 除开初始的内置操作数，将对原始的操作执行以及每次重试的执行进行计量。 例如，对于一个执行 5 次重试的操作，将按 6 次执行来对此操作进行计量和计费。 定价取决于操作类型是内置操作、标准连接器操作还是企业连接器操作。 |
除了包含的内置操作次数外，其他方面与消耗模型相同。 |
存储操作
Azure 逻辑应用将 Azure 存储用于任何所需的存储事务，例如使用队列来调度触发器操作或使用表和 blob 来存储工作流状态。 根据工作流中的操作，存储成本会有所不同，因为不同的触发器、操作和有效负载会产生不同的存储操作和需求。 服务还会根据逻辑应用资源的运行历史记录保留限制来保存和存储工作流运行历史记录中的输入和输出。 可以在逻辑应用资源级别（而不是工作流级别）管理此保留限制。
下表汇总了消耗和标准模型如何处理存储操作的计量和计费：
| 型号 | 说明 | 度量和计费 |
|---|---|---|
| 消耗（多租户） | 存储资源和使用量会附加到逻辑应用资源上。 | 按照适用于消耗计划的数据保留定价仅对与数据保留相关的存储消耗进行计量和计费。 |
| 标准（单租户） | 可以使用自己的 Azure 存储帐户，这使你能够更灵活地对工作流的数据进行更好的控制。 | 计量和计费将遵循 Azure 存储定价模型。 存储成本在 Azure 计费发票中单独列出。 提示：为了帮助你更好地了解工作流可以运行的存储操作的数量及成本，请尝试使用逻辑应用存储计算器。 可以选择示例工作流或使用现有的工作流定义。 第一个计算估计工作流中的存储操作数。 然后，可以通过 Azure 定价计算器使用这些数字来估算可能的成本。 有关详细信息，请参阅以下资源： - 估算单租户 Azure 逻辑应用中工作流的存储需求和成本。 - 查看执行和存储使用情况的指标 - Azure 逻辑应用中的限制 |
本地数据网关
本地数据网关是所创建的单独的 Azure 资源，使逻辑应用工作流可以使用特定网关支持的连接器访问本地数据。 网关资源本身不会产生费用，但通过网关运行的操作会产生费用，具体取决于逻辑应用使用的定价和计费模型。
集成帐户
集成帐户是一个单独的 Azure 资源，可以将它创建为容器来定义和存储企业到企业 (B2B) 项目，例如贸易合作伙伴、协议、架构和映射等。 创建此帐户并定义这些项目后，将此帐户链接到逻辑应用，使你可以在工作流中使用这些项目和各种 B2B 操作来探索、构建和测试使用 EDI 和 XML 处理功能的集成解决方案。
下表汇总了消耗和标准模型如何处理集成帐户的计量和计费：
| 型号 | 度量和计费 |
|---|---|
| 消耗（多租户） | 计量和计费根据所使用的帐户层使用集成帐户定价。 |
| 标准（单租户） | 计量和计费根据所使用的帐户层使用集成帐户定价。 |
有关详细信息，请查看以下文档：
其他不计量或计费的项
在所有定价模型中，不会对以下项进行计量或计费：
- 由于工作流在完成前停止而未运行的操作
- 禁用的逻辑应用程序或工作流，因为它们在处于非活动状态时不会创建新实例。