你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
估算基于消耗的成本
本文介绍如何估算弹性消耗和消耗托管计划的计划成本。
Azure Functions 目前为函数应用提供了以下不同的托管选项，每个选项都有自己的托管计划定价模型：
| 规划 | 说明 |
|---|---|
| 弹性消耗计划 | 需要为运行函数的实例以及任何始终就绪的实例的执行时间付费。 系统会根据传入事件数动态添加和删除实例。 这是建议的动态缩放计划，它还支持虚拟网络集成。 |
| 高级 | 提供与“消耗”计划相同的功能和缩放机制，但具有增强的性能和虚拟网络访问权限。 成本取决于所选的定价层。 若要了解详细信息，请参阅 Azure Functions 高级计划。 |
| 专用（应用服务） （基本或更高层） |
需要在专用 VM 或隔离的环境中运行、自定义映像，或想要使用超额的应用服务计划容量时。 使用常规应用服务计划计费。 成本取决于所选的定价层。 |
| 容器应用 | 在由 Azure 容器应用托管的完全托管环境中创建和部署容器化函数应用，这使你可以将函数与其他微服务、API、网站和工作流作为容器托管的程序一起运行。 |
| 消耗 | 只根据函数应用的运行时间收费。 此计划包括基于订阅的免费授予。 |
重要
弹性消耗计划目前为预览版。
你应该始终选择最支持函数执行的功能、性能和成本要求的选项。 若要了解更多信息，请参阅 Azure Functions 的缩放和托管。
本文重点介绍弹性消耗和消耗计划，因为在这些计划中，计费取决于每个实例内的活动执行周期。
Durable Functions 还可以在这两个计划中运行。 若要详细了解使用 Durable Functions 时的成本注意事项，请参阅 Durable Functions 计费。
基于消耗的成本
基于消耗的成本（包括免费给予）的计算方式视具体计划而定。 有关最新的成本和给予信息，请参阅 Azure Functions 定价页。
在弹性消耗计划中运行应用程序时，可通过两种模式确定成本。 每个模式基于每个实例确定。
| 计费模式 | 说明 |
|---|---|
| 按需 | 在按需模式下运行时，仅对函数代码在可用实例上执行的时间付费。 在按需模式下，不需要最小实例计数。 系统会针对以下内容计费： • 当每个按需实例主动执行函数（以 GB 秒为单位）时，预配的总内存量减去每月 GB-s 的免费额度。 • 执行的总数减去每月执行的免费额度（数量）。 |
| 始终就绪 | 可以配置一个或多个实例，将它们分配给特定触发器类 (HTTP/Durable/Blob) 和单独的函数，这些实例始终可用于处理请求。 启用任何始终就绪的实例后，系统会针对以下内容计费： • 在所有始终就绪实例（称为基线，以 GB-秒为单位）中预配的总内存量。 • 每个始终就绪实例主动执行函数（以 GB-秒为单位）期间预配的总内存量。 • 总执行次数。 在始终就绪的计费模式中，不存在免费赠予。 |
下图表示如何在此计划中确定按需成本：
除了执行时间外，在使用一个或多个始终就绪实例时，还会按较低的基线费率对维护的始终就绪实例数进行计费。 就执行时间的价格而言，与按需执行的实例相比，始终就绪的实例可能更划算。
重要
在本文中，提供价格只是为了帮助理解示例计算。 在估算在弹性消耗计划中运行函数时可能产生的成本时，请务必查看 Azure Functions 定价页面。
对于本节中的示例，请考虑此表中美国东部即用即付的折扣预览定价。
| 模式 | 计量 | 免费每月赠予 | 消耗率 |
|---|---|---|---|
| 点播 | 执行时间 (GB-s) | 100,000 |
$0.000016/GB |
| 点播 | 执行（次数） | 250,000 |
$0.20/百万次执行 |
| 始终就绪 | 基线（空闲）时间 (GB-s) | - | $0.000004/GB |
| 始终就绪 | 执行时间 (GB-s) | - | $0.000009/GB |
| 始终就绪 | 执行（次数） | - | $0.20/百万次执行 |
假设有一个仅由 HTTP 触发器组成的函数应用程序，并具有以下基本事实：
- HTTP 触发器每秒处理 40 个常量请求。
- HTTP 触发器处理 10 个并发请求。
- 实例内存大小设置为
2048 MB。 - 没有配置始终就绪的实例，这意味着应用程序可以扩展到零。
在这种情况下，定价更多地取决于代码执行期间完成的工作类型。 让我们看看两个工作负载方案：
CPU 密集型工作负载：在 CPU 密集型工作负载中，在同一实例中并行处理多个请求没有任何优势。 这意味着你最好将每个请求分发到其自己的实例，以便请求尽快完成而不会发生争用。 在此方案中，应该将 HTTP 触发器并发设置为
1。 对于 10 个并发请求，应用可缩放到大约 10 个实例的稳定状态，并且每个实例都持续活动，一次处理一个请求。由于每个实例的大小约为 2 GB，因此单个连续活动实例的消耗为
2 GB * 3600 s = 7200 GB-s，按照假定的按需执行速率（不应用任何免费赠予）为每个实例每小时$0.1152 USD。 由于 CPU 密集型应用程序扩展到 10 个实例，因此执行时间的总小时速率为$1.152 USD。同样，每秒 40 个请求的按需每次执行费用（没有任何免费授权）等于
40 * 3600 = 144,000，也就是每小时 14.4 万次执行。 那么每小时执行的总成本（无赠予）为0.144 * $0.20，即每小时$0.0288。在此方案中，按需运行 10 个实例的每小时总成本为
$1.152 + $0.0288 = $1.1808 USD。IO 密集型工作负载：在 IO 密集型工作负载中，大部分应用程序时间都花在等待传入请求上，这可能受到网络吞吐量或其他上游因素的限制。 由于输入有限，代码可以同时处理多个操作，而不会产生负面影响。 在此方案中，假设可以在同一实例上处理所有 10 个并发请求。
由于消耗费用仅基于每个活动实例的内存，因此计算出的消耗费用仅为
2 GB * 3600 s = 7200 GB-s，在假定的按需执行速率（不应用任何免费赠款）下，该消耗费用为单个实例每小时$0.1152 USD。与 CPU 密集型方案一样，每秒 40 个请求的按需执行费用（没有任何免费授予）等于
40 * 3600 = 144,000，也就是每小时 14.4 万次执行。 这使得每小时执行的总（无赠予）成本为0.144 * $0.20，即每小时$0.0288。在此场景中，在单个实例上按需运行的总每小时成本为
$0.1152 + $0.0288 = $0.144 USD。
其他相关成本
在估算任何计划中运行函数的总体成本时，请记住，函数运行时将使用其他多个 Azure 服务，而每个服务单独计费。 估算函数应用的定价时，对于与其他 Azure 服务集成的任何触发器和绑定，需要创建这些附加的服务并为其付费。
对于在消耗计划中运行的函数，总成本是函数的执行成本加上带宽和附加服务的成本。
估算函数应用和相关服务的总体成本时，请使用 Azure 定价计算器。
| 相关成本 | 描述 |
|---|---|
| 存储帐户 | 需要为每个函数应用提供一个关联的常规用途 Azure 存储帐户，该帐户单独计费。 函数运行时在内部使用此帐户，但你也可以将其用于存储触发器和绑定。 如果你没有存储帐户，系统会在创建函数应用时创建一个存储帐户。 有关详细信息，请参阅存储帐户要求。 |
| Application Insights | 函数依靠 Application Insights 为函数应用提供高性能的监视体验。 虽然未强制要求，但你应启用 Application Insights 集成。 每月会免费授予遥测数据。 要了解详细信息，请参阅 Azure Monitor 定价页。 |
| 网络带宽 | 根据数据移动的方向和方案，可能会产生数据传输费用。 有关详细信息，请参阅带宽定价详细信息。 |
影响执行时间的行为
函数的以下行为可能会影响执行时间：
触发器和绑定：从函数绑定读取输入以及向其写入输出所花费的时间计为执行时间。 例如，如果函数使用某个输出绑定将消息写入 Azure 存储队列，则执行时间包括将该消息写入该队列所花费的时间，而函数成本计算包括该写入时间。
异步执行：函数等待异步请求（在 C# 中为
await）结果的时间计为执行时间。 “GB 秒”计算基于函数的开始和结束时间，以及该时间段内的内存用量。 计算中不考虑该时间段内发生的 CPU 活动。 也许可以使用 Durable Functions 来降低异步操作期间产生的成本。 业务流程协调程序函数中的等待时间不产生费用。
查看与成本相关的数据
在你的发票中，可以查看“执行总次数 - 函数”和“执行时间 - 函数”的与成本相关的数据，以及实际的计费费用。 但是，此发票数据是过去发票期限的每月聚合。
函数应用级指标
若要更好地了解函数对成本的影响，可以使用 Azure Monitor 查看函数应用当前生成的成本相关指标。
使用 Azure Monitor 指标资源管理器可以图形格式查看消耗计划函数应用的成本相关数据。
在 Azure 门户中，导航到你的函数应用。
在左侧面板中，向下滚动至“监视”，然后选择“指标” 。
在“指标”中，为“聚合”选择“函数执行计数”和“求和”。 这会在图表中将所选时间段内的执行计数之和相加。
选择“添加指标”并重复步骤 2-4，将“函数执行单位”添加到图表中。
生成的图表包含所选时间范围内（在本例中为 2 小时）两个执行指标的总和。
由于执行单位数远远大于执行计数，因此图表只显示执行单位。
此图显示两小时时间段内总共消耗了 11.1 亿个 Function Execution Units（以“MB 毫秒”度量）。 若要转换为 GB 秒，请除以 1024000。 在此示例中，函数应用消耗了 1110000000 / 1024000 = 1083.98 GB 秒。 可以将此值乘以 Functions 定价页上执行时间的当前价格，从而得出这两个小时的成本（假设已用完了所有免费授予的执行时间）。
函数级指标
函数执行单位是执行时间与内存用量的组合，因此很难使用此指标来了解内存用量。 目前无法通过 Azure Monitor 获取内存数据这一指标。 但是，如果要优化应用的内存用量，可以使用 Application Insights 收集的性能计数器数据。
如果尚未执行此操作，你可以在函数应用中启用 Application Insights。 启用此集成后，你可以在门户中查询此遥测数据。
可以使用 Azure 门户中的 Azure Monitor 指标资源管理器或使用 REST API 来获取 Monitor 指标数据。
确定内存用量
在“监视”下选择“日志(分析)”，复制以下遥测查询并将其粘贴到查询窗口中，然后选择“运行”。 此查询返回每个采样时间的总内存用量。
performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value
结果类似于以下示例：
| timestamp [UTC] | name | 值 |
|---|---|---|
| 9/12/2019, 1:05:14.947 AM | 专用字节数 | 209,932,288 |
| 9/12/2019, 1:06:14.994 AM | 专用字节数 | 212,189,184 |
| 9/12/2019, 1:06:30.010 AM | 专用字节数 | 231,714,816 |
| 9/12/2019, 1:07:15.040 AM | 专用字节数 | 210,591,744 |
| 9/12/2019, 1:12:16.285 AM | 专用字节数 | 216,285,184 |
| 9/12/2019, 1:12:31.376 AM | 专用字节数 | 235,806,720 |
确定持续时间
Azure Monitor 可跟踪资源级指标，对于函数来说，就是跟踪函数应用指标。 Application Insights 集成会发出每个函数的指标。 下面是一个示例分析查询，可用于获取函数的平均持续时间：
customMetrics
| where name contains "Duration"
| extend averageDuration = valueSum / valueCount
| summarize averageDurationMilliseconds=avg(averageDuration) by name
| name | averageDurationMilliseconds |
|---|---|
| QueueTrigger AvgDurationMs | 16.087 |
| QueueTrigger MaxDurationMs | 90.249 |
| QueueTrigger MinDurationMs | 8.522 |