Durable Functions 计费Durable Functions billing

Durable Functions 的计费方式与 Azure Functions 相同。Durable Functions is billed the same way as Azure Functions. 有关详细信息,请参阅 Azure Functions 定价For more information, see Azure Functions pricing.

在 Azure Functions 消耗计划中执行业务流程协调程序函数时,需要注意一些计费行为。When executing orchestrator functions in Azure Functions Consumption plan, you need to be aware of some billing behaviors. 以下部分更详细地介绍了这些行为及其影响。The following sections describe these behaviors and their effect in more detail.

业务流程协调程序函数重播计费Orchestrator function replay billing

业务流程协调程序函数在业务流程的整个生存期内可能会重播多次。Orchestrator functions might replay several times throughout the lifetime of an orchestration. Azure Functions 运行时将每次重播视为不同的函数调用。Each replay is viewed by the Azure Functions runtime as a distinct function invocation. 出于此原因,在 Azure Functions 消耗计划中,每次重播业务流程协调程序函数都会产生费用。For this reason, in the Azure Functions Consumption plan you're billed for each replay of an orchestrator function. 其他计划类型不会对业务流程协调程序函数重播收费。Other plan types don't charge for orchestrator function replay.

业务流程协调程序函数中的等待和生成Awaiting and yielding in orchestrator functions

当业务流程协调程序函数使用 await (C#) 或 yield (JavaScript) 等待某个异步操作完成时,运行时会将该特定执行视为已完成。When an orchestrator function waits for an asynchronous action to finish by using await in C# or yield in JavaScript, the runtime considers that particular execution to be finished. 业务流程协调程序函数的计费此时会停止。The billing for the orchestrator function stops at that point. 在下一次业务流程协调程序函数重播之前,计费不会恢复。It doesn't resume until the next orchestrator function replay. 你不需要对业务流程协调程序函数中的等待或生成所花费的任何时间付费。You aren't billed for any time spent awaiting or yielding in an orchestrator function.

备注

某些运行时将调用其他函数的函数视为反模式。Functions calling other functions is considered by some to be an antipattern. 原因是存在一个所谓“双重计费”的问题。 This is because of a problem known as double billing. 当某个函数直接调用另一个函数时,两者会同时运行。When a function calls another function directly, both run at the same time. 被调用函数正在实际运行代码,而调用函数正在等待响应。The called function is actively running code while the calling function is waiting for a response. 在这种情况下,必须为调用函数等待被调用函数运行所花费的时间付费。In this case, you must pay for the time the calling function spends waiting for the called function to run.

业务流程协调程序函数不会双重计费。There is no double billing in orchestrator functions. 业务流程协调程序函数在等待活动函数或子业务流程的结果时计费将会停止。An orchestrator function's billing stops while it waits for the result of an activity function or sub-orchestration.

持久 HTTP 轮询Durable HTTP polling

HTTP 功能一文中所述,业务流程协调程序函数可对外部终结点发出长时间运行的 HTTP 调用。Orchestrator functions can make long-running HTTP calls to external endpoints as described in the HTTP features article. 在遵循异步 202 模式时,CallHttpAsync 方法 (C#) 和 callHttp 方法 (JavaScript) 可在内部轮询 HTTP 终结点。The CallHttpAsync method in C# and the callHttp method in JavaScript might internally poll an HTTP endpoint while following the asynchronous 202 pattern.

内部 HTTP 轮询操作目前不会产生直接费用。There currently isn't direct billing for internal HTTP polling operations. 但是,内部轮询可能导致业务流程协调程序函数定期重播。However, internal polling might cause the orchestrator function to periodically replay. 你要支付这些内部函数重播的标准费用。You'll be billed standard charges for these internal function replays.

Azure 存储事务Azure Storage transactions

Durable Functions 默认使用 Azure 存储通过 Blob 租约来持久保存状态、处理消息和管理分区。Durable Functions uses Azure Storage by default to keep state persistent, process messages, and manage partitions via blob leases. 此存储帐户由你拥有,因此,任何事务成本都从你的 Azure 订阅计收。Because you own this storage account, any transaction costs are billed to your Azure subscription. 有关 Durable Functions 使用的 Azure 存储项目的详细信息,请参阅任务中心一文。For more information about the Azure Storage artifacts used by Durable Functions, see the Task hubs article.

多种因素会影响 Durable Functions 应用产生的实际 Azure 存储成本:Several factors contribute to the actual Azure Storage costs incurred by your Durable Functions app:

  • 单个函数应用与单个任务中心关联,后者共享一组 Azure 存储资源。A single function app is associated with a single task hub, which shares a set of Azure Storage resources. 这些资源由函数应用中的所有 Durable Functions 使用。These resources are used by all durable functions in a function app. 函数应用中的实际函数数目不会影响 Azure 存储事务成本。The actual number of functions in the function app has no effect on Azure Storage transaction costs.
  • 每个函数应用实例在内部使用指数退避轮询算法轮询存储帐户中的多个队列。Each function app instance internally polls multiple queues in the storage account by using an exponential-backoff polling algorithm. 空闲应用实例的轮询队列频率低于活跃的应用,因此事务成本更低。An idle app instance polls the queues less often than does an active app, which results in fewer transaction costs. 有关 Durable Functions 队列轮询行为的详细信息,请参阅“性能和缩放”一文的“队列轮询”部分For more information about Durable Functions queue-polling behavior, see the queue-polling section of the Performance and Scale article.
  • 在 Azure Functions 消耗中运行时,Azure Functions 规模控制器将在后台定期轮询所有任务中心队列。When running in the Azure Functions Consumption, the Azure Functions scale controller regularly polls all task-hub queues in the background. 在中小规模的函数应用中,只有一个规模控制器实例轮询这些队列。If a function app is under light to moderate scale, only a single scale controller instance will poll these queues. 如果函数应用横向扩展到大量实例,可以添加更多的规模控制器实例。If the function app scales out to a large number of instances, more scale controller instances might be added. 这些附加的规模控制器实例可能会增大队列事务总成本。These additional scale controller instances can increase the total queue-transaction costs.
  • 每个函数应用实例争用一组 Blob 租约。Each function app instance competes for a set of blob leases. 这些实例将定期调用 Azure Blob 服务,以续订持有的租约,或尝试获取新租约。These instances will periodically make calls to the Azure Blob service either to renew held leases or to attempt to acquire new leases. 任务中心的已配置分区计数决定了 Blob 租约数。The task hub's configured partition count determines the number of blob leases. 横向扩展到更多函数应用实例可能会增大与这些租约操作相关的 Azure 存储事务成本。Scaling out to a larger number of function app instances likely increases the Azure Storage transaction costs associated with these lease operations.

可以在 Azure 存储定价文档中找到有关 Azure 存储定价的详细信息。You can find more information on Azure Storage pricing in the Azure Storage pricing documentation.

后续步骤Next steps