Azure Functions 的缩放和托管Azure Functions scale and hosting

消耗计划在代码运行时自动添加计算能力。The Consumption plan automatically adds compute power when your code is running. 应用在需要处理负载时会扩展,在代码停止运行时会缩减。Your app is scaled out when needed to handle load, and scaled down when code stops running. 无需为空闲的 VM 付费或提前保留容量。You don't have to pay for idle VMs or reserve capacity in advance. 如果你有现有的应用服务计划,还可以在这些计划中运行函数应用。If you have an existing App Service Plan, you can also run your function apps within them.

如果不熟悉 Azure Functions,请参阅 Azure Functions 概述If you aren't familiar with Azure Functions, see the Azure Functions overview.

创建函数应用时,要为应用中的函数选择托管计划。When you create a function app, you choose the hosting plan for functions in the app. Azure Functions 主机的实例在任一计划中均可执行函数。In either plan, an instance of the Azure Functions host executes the functions. 计划类型可控制:The type of plan controls:

  • 主机实例的扩展方式。How host instances are scaled out.
  • 可供每个主机使用的资源。The resources that are available to each host.
  • VNet 连接等实例功能。Instance features like VNet connectivity.

消耗量计划Consumption plan

使用消耗计划时,会根据传入事件数自动添加和删除 Azure Functions 主机实例。When you're using the Consumption plan, instances of the Azure Functions host are dynamically added and removed based on the number of incoming events. 这个无服务器计划会自动缩放,仅在函数运行时,才会产生计算资源费用。This serverless plan scales automatically, and you're charged for compute resources only when your functions are running. 在消费计划中,函数执行在可配置的时间段后超时。On a Consumption plan, a function execution times out after a configurable period of time.

账单将基于执行数量、执行时间和所用内存。Billing is based on number of executions, execution time, and memory used. 账单是基于函数应用内的所有函数聚合而生成的。Billing is aggregated across all functions within a function app. 有关详细信息,请参阅 Azure Functions 定价页For more information, see the Azure Functions pricing page.

消耗计划是默认的宿主计划,它提供了以下优势:The Consumption plan is the default hosting plan and offers the following benefits:

  • 仅当函数运行时才产生费用。Pay only when your functions are running.
  • 即使是在负载较高期间也可自动扩展。Scale out automatically, even during periods of high load.

应用服务计划App Service plan

函数应用也可以像其他应用服务应用(基本、标准、高级和隔离 SKU)一样在相同的专用 VM 上运行。Your function apps can also run on the same dedicated VMs as other App Service apps (Basic, Standard, Premium, and Isolated SKUs). 应用服务计划支持 Linux。App Service plans support Linux.

对于以下情况,可以考虑使用应用服务计划:Consider an App Service plan in the following cases:

  • 具有已运行其他应用服务实例的、未充分利用的现成 VM。You have existing, underutilized VMs that are already running other App Service instances.
  • 想要在 Linux 上运行函数应用,或者想要提供要在其上运行函数的自定义映像。You want to run your function app on Linux, or you want to provide a custom image on which to run your functions.

应用服务计划中函数应用的费用与其他应用服务资源(例如 Web 应用)的费用相同。You pay the same for function apps in an App Service Plan as you would for other App Service resources, like web apps. 如需详细了解如何使用应用服务计划,请参阅 Azure 应用服务计划深入概述For details about how the App Service plan works, see the Azure App Service plans in-depth overview.

借助应用服务计划,可通过添加更多 VM 实例手动进行扩展,也可启用自动缩放。With an App Service plan, you can manually scale out by adding more VM instances, or you can enable autoscale. 有关详细信息,请参阅手动或自动缩放实例计数For more information, see Scale instance count manually or automatically. 还可以通过选择不同的应用服务计划来进行增加。You can also scale up by choosing a different App Service plan. 有关详细信息,请参阅增加 Azure 中的应用For more information, see Scale up an app in Azure.

在应用服务计划上运行 JavaScript 函数时,应选择具有较少 vCPU 的计划。When running JavaScript functions on an App Service plan, you should choose a plan that has fewer vCPUs. 有关详细信息,请参阅选择单核应用服务计划For more information, see Choose single-core App Service plans.

Always OnAlways On

如果在应用服务计划上运行,应启用 AlwaysOn 设置,使函数应用能正常运行。If you run on an App Service plan, you should enable the Always on setting so that your function app runs correctly. 在应用服务计划中,如果函数运行时处于不活动状态,几分钟后就会进入空闲状态,因此只有 HTTP 触发器才能“唤醒”函数。On an App Service plan, the functions runtime goes idle after a few minutes of inactivity, so only HTTP triggers will "wake up" your functions. 只能对应用服务计划使用始终可用。Always on is available only on an App Service plan. 在消耗计划中,平台会自动激活函数应用。On a Consumption plan, the platform activates function apps automatically.

函数应用超时持续时间Function app timeout duration

函数应用的超时持续时间可通过 host.json 项目文件中的 functionTimeout 属性定义。The timeout duration of a function app is defined by the functionTimeout property in the host.json project file. 下表显示两种计划和两种运行时版本的默认值和最大值(以分钟为单位):The following table shows the default and maximum values in minutes for both plans and in both runtime versions:

计划Plan 运行时版本Runtime Version 默认Default 最大值Maximum
消耗Consumption 1.x1.x 55 10 个10
消耗Consumption 2.x2.x 55 10 个10
应用服务App Service 1.x1.x 无限制Unlimited 无限制Unlimited
应用服务App Service 2.x2.x 3030 无限制Unlimited

Note

不管函数应用超时设置如何,230 秒是 HTTP 触发的函数在响应请求时需要的最长时间。Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request. 这起因于 Azure 负载均衡器的默认空闲超时This is because of the default idle timeout of Azure Load Balancer. 对于处理时间较长的情况,考虑使用 Durable Functions 异步模式延迟实际工作并返回即时响应For longer processing times, consider using the Durable Functions async pattern or defer the actual work and return an immediate response.

我采用了哪种托管计划What is my hosting plan

要确定你的函数应用所使用的托管计划,请在 Azure 门户中参阅函数应用的“概览”选项卡中的“应用服务计划/定价层”。To determine the hosting plan used by your function app, see App Service plan / pricing tier in the Overview tab for the function app in the Azure portal. 对于应用服务计划,还指明了定价层。For App Service plans, the pricing tier is also indicated.

在门户中查看缩放计划

还可以使用 Azure CLI 来确定计划,如下所示:You can also use the Azure CLI to determine the plan, as follows:

appServicePlanId=$(az functionapp show --name <my_function_app_name> --resource-group <my_resource_group> --query appServicePlanId --output tsv)
az appservice plan list --query "[?id=='$appServicePlanId'].sku.tier" --output tsv

此命令的输出为 dynamic 时,函数应用采用消耗量计划。When the output from this command is dynamic, your function app is in the Consumption plan. 此命令的输出为 ElasticPremium 时,函数应用采用高级计划。When the output from this command is ElasticPremium, your function app is in the Premium plan. 所有其他值均表示应用服务计划的层。All other values indicate tiers of an App Service plan.

即使启用了 AlwaysOn,各函数的执行超时也由 host.json 项目文件中的 functionTimeout 设置控制。Even with Always On enabled, the execution timeout for individual functions is controlled by the functionTimeout setting in the host.json project file.

存储帐户要求Storage account requirements

在任何计划中,函数应用需要一个支持 Azure Blob、队列、文件和表存储的常规 Azure 存储帐户。On any plan, a function app requires a general Azure Storage account, which supports Azure Blob, Queue, Files, and Table storage. 这是因为 Functions 依赖于 Azure 存储来执行管理触发器和记录函数执行等操作,但某些存储帐户不支持队列和表。This is because Functions rely on Azure Storage for operations such as managing triggers and logging function executions, but some storage accounts do not support queues and tables. 这些帐户包括仅限 Blob 的存储帐户(包括高级存储),会在创建函数应用时从现有的“存储帐户”选项中过滤掉。These accounts, which include blob-only storage accounts (including premium storage), are filtered-out from your existing Storage Account selections when you create a function app.

若要了解有关存储帐户类型的详细信息,请参阅 Azure 存储服务简介To learn more about storage account types, see Introducing the Azure Storage services.

消耗计划的工作原理How the consumption plans work

在消耗计划中,缩放控制器通过根据触发函数的事件数添加额外的 Functions 主机实例来自动缩放 CPU 和内存资源。In the consumption plans, the scale controller automatically scales CPU and memory resources by adding additional instances of the Functions host, based on the number of events that its functions are triggered on. 消耗计划中 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 1 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 are scaled independently.

函数代码文件存储在函数主要存储帐户中的 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.

Note

在消耗量计划中使用 blob 触发器时,处理新的 blob 可能会出现长达 10 分钟的延迟。When you're using a blob trigger on a Consumption plan, there can be up to a 10-minute delay in processing new blobs. 函数应用处于空闲时会发生这种延迟。This delay occurs when a function app has gone idle. 函数应用运行后,就会立即处理 Blob。After the function app is running, blobs are processed immediately. 有关详细信息,请参阅 blob 触发器绑定参考文章For more information, see the blob trigger binding reference article.

运行时缩放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.

缩放单位是 Function App。The unit of scale 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. 实例数最终会缩减为零,此时 Function App 中没有任何函数运行。The number of instances is eventually scaled down to zero when no functions are running within a function app.

用于监视事件和创建实例的扩展控制器

了解缩放行为Understanding scaling behaviors

缩放可根据多种因素而异,可根据选定的触发器和语言以不同的方式缩放。Scaling can vary on a number of factors, and scale differently based on the trigger and language selected. 但是,当今的系统中存在一些缩放特征:However there are a few aspects of scaling that exist in the system today:

  • 单个函数应用最多只能纵向扩展到 200 个实例。A single function app only scales up 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.
  • 对于 HTTP 触发器,将最多每隔 1 秒分配一次新实例。For HTTP triggers, new instances will only be allocated at most once every 1 second.
  • 对于非 HTTP 触发器,将最多每隔 30 秒分配一次新实例。For non-HTTP triggers, new instances will only be allocated at most once every 30 seconds.

不同触发器还可能有不同的缩放限制,如下所述:Different triggers may also have different scaling limits as well as documented below:

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

函数应用的许多方面会影响其缩放,包括主机配置、运行时占用空间和资源效率。There are many aspects of a function app that will impact how well it will scale, 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.

计费模式Billing model

消耗量计划的计费在 Azure Functions 定价页中有详细介绍。Billing for the Consumption plan 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.