Azure Functions 中的事件驱动缩放Event-driven scaling in Azure Functions

在消耗和高级计划中,Azure Functions 通过添加 Functions 主机的额外实例来缩放 CPU 和内存资源。In the Consumption and Premium plans, Azure Functions scales CPU and memory resources by adding additional instances of the Functions host. 实例数取决于触发函数的事件数。The number of instances is determined on the number of events that trigger a function.

消耗计划中 Functions 主机的每个实例仅限使用 1.5 GB 内存和 1 个 CPU。Each instance of the Functions host in the Consumption plan is limited to 1.5 GB of memory and one CPU. 主机实例是整个函数应用,这意味着函数应用中的所有函数共享某个实例中的资源并同时缩放。An instance of the host is the entire function app, meaning all functions within a function app share resource within an instance and scale at the same time. 共享同一消耗计划的函数应用单独缩放。Function apps that share the same Consumption plan scale independently. 在高级计划中,计划大小决定该实例上该计划中所有应用的可用内存和 CPU。In the Premium plan, the plan size determines the available memory and CPU for all apps in that plan on that instance.

函数代码文件存储在函数主要存储帐户中的 Azure 文件共享上。Function code files are stored on Azure Files shares on the function's main storage account. 删除函数应用的主存储帐户时,函数代码文件将被删除并且无法恢复。When you delete the main storage account of the function app, the function code files are deleted and cannot be recovered.

运行时缩放Runtime scaling

Azure Functions 使用名为“缩放控制器”的组件来监视事件率以及确定是要横向扩展还是横向缩减。Azure Functions uses a component called the scale controller to monitor the rate of events and determine whether to scale out or scale in. 缩放控制器针对每种触发器类型使用试探法。The scale controller uses heuristics for each trigger type. 例如,使用 Azure 队列存储触发器时,它会根据队列长度和最旧队列消息的期限进行缩放。For example, when you're using an Azure Queue storage trigger, it scales based on the queue length and the age of the oldest queue message.

Azure Functions 的缩放单位为函数应用。The unit of scale for Azure Functions is the function app. 横向扩展函数应用时,将分配额外的资源来运行 Azure Functions 主机的多个实例。When the function app is scaled out, additional resources are allocated to run multiple instances of the Azure Functions host. 相反,计算需求下降时,扩展控制器将删除函数主机实例。Conversely, as compute demand is reduced, the scale controller removes function host instances. 当函数应用中没有运行函数时,实例数最终会“缩减”为零。The number of instances is eventually "scaled in" to zero when no functions are running within a function app.


冷启动Cold Start

当你的函数应用空闲一定的分钟数后,平台可能会将用于运行你的应用的实例数量缩减为零。After your function app has been idle for a number of minutes, the platform may scale the number of instances on which your app runs down to zero. 下次请求将存在从零扩展到一所增加的延迟。The next request has the added latency of scaling from zero to one. 此延迟称为“冷启动”。This latency is referred to as a cold start. 函数应用所需的依赖项的数目可能会影响冷启动时间。The number of dependencies required by your function app can impact the cold start time. 冷启动对于同步操作(例如,必须返回响应的 HTTP 触发器)来说更是一个问题。Cold start is more of an issue for synchronous operations, such as HTTP triggers that must return a response. 如果冷启动会影响你的函数,请考虑在高级计划中运行,或在启用了“始终可用”设置的专用计划中运行。If cold starts are impacting your functions, consider running in a Premium plan or in a Dedicated plan with the Always on setting enabled.

了解缩放行为Understanding scaling behaviors

缩放可根据多种因素而异,可根据选定的触发器和语言以不同的方式缩放。Scaling can vary on a number of factors, and scale differently based on the trigger and language selected. 需要注意缩放行为的以下几个细节:There are a few intricacies of scaling behaviors to be aware of:

  • 最大实例数:单个函数应用最多只能横向扩展到 200 个实例。Maximum instances: A single function app only scales out to a maximum of 200 instances. 不过,单个实例每次可以处理多个消息或请求,因此,对并发执行数没有规定的限制。A single instance may process more than one message or request at a time though, so there isn't a set limit on number of concurrent executions. 可根据需要指定一个较低的最大值来限制缩放。You can specify a lower maximum to throttle scale as required.
  • 新实例率:对于 HTTP 触发器,将最多每隔 1 秒分配一次新实例。New instance rate: For HTTP triggers, new instances are allocated, at most, once per second. 对于非 HTTP 触发器,将最多每隔 30 秒分配一次新实例。For non-HTTP triggers, new instances are allocated, at most, once every 30 seconds. 高级计划中运行时,缩放速度会更快。Scaling is faster when running in a Premium plan.
  • 缩放效率:对于服务总线触发器,请使用资源的 管理 权限,以实现最有效的缩放。Scale efficiency: For Service Bus triggers, use Manage rights on resources for the most efficient scaling. 使用 侦听 权限时,由于队列长度不能用于通知缩放决策,缩放不够准确。With Listen rights, scaling isn't as accurate because the queue length can't be used to inform scaling decisions. 若要详细了解如何在服务总线访问策略中设置权限,请参阅共享访问授权策略To learn more about setting rights in Service Bus access policies, see Shared Access Authorization Policy. 有关事件中心触发器,请参阅参考文章中的缩放指南For Event Hub triggers, see the scaling guidance in the reference article.

限制横向扩展Limit scale out

建议限制应用可用于横向扩展的最大实例数。最常见的情况是下游组件(如数据库)的吞吐量有限。You may wish to restrict the maximum number of instances an app used to scale out. This is most common for cases where a downstream component like a database has limited throughput. 默认情况下,消耗计划函数可横向扩展到最多 200 个实例,高级计划函数可横向扩展到最多 100 个实例。By default, Consumption plan functions scale out to as many as 200 instances, and Premium plan functions will scale out to as many as 100 instances. 可修改 functionAppScaleLimit 值来指定特定应用的较低最大值。You can specify a lower maximum for a specific app by modifying the functionAppScaleLimit value. 若要不受限制,可将 functionAppScaleLimit 设置为 0null,或介于 1 和应用最大值之间的有效值。The functionAppScaleLimit can be set to 0 or null for unrestricted, or a valid value between 1 and the app maximum.

az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>

可缩放应用的最佳做法和模式Best practices and patterns for scalable apps

函数应用的许多方面会影响其缩放,包括主机配置、运行时占用空间和资源效率。There are many aspects of a function app that impacts how it scales, including host configuration, runtime footprint, and resource efficiency. 有关详细信息,请查看性能注意事项一文的“可扩展”部分For more information, see the scalability section of the performance considerations article. 还要注意随着函数应用的扩展,连接是如何实施的。You should also be aware of how connections behave as your function app scales. 有关详细信息,请参阅如何在 Azure Functions 中管理连接For more information, see How to manage connections in Azure Functions.

若要详细了解如何在 Node.js 中进行缩放,请参阅 Azure Functions Node.js 开发人员指南 - 缩放和并发For more information on scaling in Node.js, see Azure Functions Node.js developer guide - Scaling and concurrency.

计费模式Billing model

不同计划的计费在 Azure Functions 定价页中有详细介绍。Billing for the different plans is described in detail on the Azure Functions pricing page. 使用量在 Function App 级别聚合,只会统计函数代码的执行时间。Usage is aggregated at the function app level and counts only the time that function code is executed. 以下是计费单位:The following are units for billing:

  • 以千兆字节/秒 (GB-s) 计量的资源消耗量。Resource consumption in gigabyte-seconds (GB-s). 根据内存大小和函数应用中所有函数的执行时间组合计算得出。Computed as a combination of memory size and execution time for all functions within a function app.
  • 执行Executions. 每次为响应事件触发而执行函数时记为一次。Counted each time a function is executed in response to an event trigger.

帐单常见问题解答中可以找到有关如何了解消费帐单的有用查询和信息。Useful queries and information on how to understand your consumption bill can be found on the billing FAQ.

后续步骤Next steps