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

在 Azure 中创建函数应用时,必须为应用选择托管计划。When you create a function app in Azure, you must choose a hosting plan for your app. 有三个基本托管计划可用于 Azure Functions:消耗计划高级计划专用(应用服务)计划There are three basic hosting plans available for Azure Functions: Consumption plan, Premium plan, and Dedicated (App Service) plan. Windows 虚拟机上的所有托管计划均已正式发布 (GA)。All hosting plans are generally available (GA) on Windows virtual machines.

选择的托管计划决定了以下行为:The hosting plan you choose dictates the following behaviors:

  • 函数应用的缩放方式。How your function app is scaled.
  • 每个函数应用实例可用的资源。The resources available to each function app instance.
  • 对 Azure 虚拟网络连接等高级功能的支持。Support for advanced features, such as Azure Virtual Network connectivity.

消耗计划和高级计划都是在代码运行时自动添加计算能力。Both Consumption and Premium plans automatically add compute power when your code is running. 应用在需要处理负载时会横向扩展,在代码停止运行时会缩小。Your app is scaled out when needed to handle load, and scaled in when code stops running. 此外,对于消耗计划,无需提前支付空闲 VM 或预留容量的费用。For the Consumption plan, you also don't have to pay for idle VMs or reserve capacity in advance.

高级计划提供了额外的功能,例如高级计算实例、使实例始终保持预热状态的功能,以及 VNet 连接。Premium plan provides additional features, such as premium compute instances, the ability to keep instances warm indefinitely, and VNet connectivity.

选择应用服务计划可以利用你管理的专用基础结构。App Service plan allows you to take advantage of dedicated infrastructure, which you manage. 函数应用不会基于事件进行缩放,这意味着,它永远不会缩小到零。Your function app doesn't scale based on events, which means it never scales in to zero. (要求启用 Always On。)(Requires that Always on is enabled.)

有关各种托管计划(包括基于 Kubernetes 的托管)之间的详细比较,请参阅托管计划比较部分For a detailed comparison between the various hosting plans (including Kubernetes-based hosting), see the Hosting plans comparison section.

消耗计划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. 使用情况将基于函数应用内的所有函数聚合生成。Usage 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

可将同一区域中的函数应用分配到同一个消耗计划。Function apps in the same region can be assigned to the same Consumption plan. 在同一个消耗计划中运行多个应用不会产生负面影响。There's no downside or impact to having multiple apps running in the same Consumption plan. 将多个应用分配到同一个消耗计划不会影响每个应用的复原能力、可伸缩性或可靠性。Assigning multiple apps to the same Consumption plan has no impact on resilience, scalability, or reliability of each app.

若要详细了解在消耗计划中运行时如何估算成本,请参阅了解消耗计划成本To learn more about how to estimate costs when running in a Consumption plan, see Understanding Consumption plan costs.

高级计划Premium plan

就像消耗计划一样,使用高级计划时,会根据传入事件数添加和删除 Azure Functions 主机实例。When you're using the Premium plan, instances of the Azure Functions host are added and removed based on the number of incoming events just like the Consumption plan. 高级计划支持以下功能:Premium plan supports the following features:

  • 永久预热实例以避免任何冷启动Perpetually warm instances to avoid any cold start
  • VNet 连接VNet connectivity
  • 无限制的执行持续时间(保证 60 分钟)Unlimited execution duration (60 minutes guaranteed)
  • 高级实例大小(单核心、双核心和四核心实例)Premium instance sizes (one core, two core, and four core instances)
  • 更可预测的定价More predictable pricing
  • 具有多个函数应用的计划的高密度应用分配High-density app allocation for plans with multiple function apps

若要了解如何在高级计划中创建函数应用,请参阅 Azure Functions 高级计划To learn how you can create a function app in a Premium plan, see Azure Functions Premium plan.

高级计划按照在实例中分配的核心秒数和内存收费,而不是按照执行情况和消耗的内存收费。Instead of billing per execution and memory consumed, billing for the Premium plan is based on the number of core seconds and memory allocated across instances. 高级计划不收取执行费用。There is no execution charge with the Premium plan. 每个计划必须始终至少分配一个实例。At least one instance must be allocated at all times per plan. 这样,无论函数是活动的还是空闲的,每个活动计划的月成本都是最低的。This results in a minimum monthly cost per active plan, regardless if the function is active or idle. 请记住,高级计划中的所有函数应用会共享已分配的实例。Keep in mind that all function apps in a Premium plan share allocated instances.

请考虑下列情况中的 Azure Functions 高级计划:Consider the Azure Functions Premium plan in the following situations:

  • 函数应用持续或几乎持续运行。Your function apps run continuously, or nearly continuously.
  • 你的消耗计划具有大量的小型执行操作,具有较高的执行费用但较低的 GB 秒费用。You have a high number of small executions and have a high execution bill but low GB second bill in the Consumption plan.
  • 你需要的 CPU 或内存选项超出消耗计划提供的选项。You need more CPU or memory options than what is provided by the Consumption plan.
  • 你的代码所需的运行时间超过消耗计划允许的最长执行时间Your code needs to run longer than the maximum execution time allowed on the Consumption plan.
  • 你需要只有高级计划才会提供的功能,例如虚拟网络连接。You require features that are only available on a Premium plan, such as virtual network connectivity.

专用(应用服务)计划Dedicated (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).

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

  • 具有已运行其他应用服务实例的、未充分利用的现成 VM。You have existing, underutilized VMs that are already running other App Service instances.
  • 需要提供用于运行函数的自定义映像。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 实例手动进行横向扩展。Using an App Service plan, you can manually scale out by adding more VM instances. 你也可以启用自动缩放,但自动缩放将慢于高级计划的弹性缩放。You can also enable autoscale, though autoscale will be slower than the elastic scale of the Premium plan. 有关详细信息,请参阅手动或自动缩放实例计数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.

应用服务环境 (ASE) 中运行可以让你完全隔离函数,并利用比应用服务计划更多的实例。Running in an App Service Environment (ASE) lets you fully isolate your functions and take advantage of higher number of instances than an App Service Plan.

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 the different runtime versions:

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

备注

不管函数应用超时设置如何,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.

即使启用了 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.

确定现有应用程序的托管计划Determine the hosting plan of an existing application

要确定你的函数应用所使用的托管计划,请在 Azure 门户中参阅函数应用的“概览”选项卡中的“应用服务计划” 。To determine the hosting plan used by your function app, see App Service plan in the Overview tab for the function app in the Azure portal. 若要查看定价层,请选择“应用服务计划”的名称,然后从左侧窗格中选择“属性” 。To see the pricing tier, select the name of the App Service Plan , and then select Properties from the left pane.

在门户中查看缩放计划

还可以使用 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 different tiers of an App Service plan.

存储帐户要求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. 这是因为 Azure Functions 依赖 Azure 存储来执行管理触发器和记录函数执行之类的操作,但某些存储帐户不支持队列和表。This is because Azure Functions relies on Azure Storage for operations such as managing triggers and logging function executions, but some storage accounts don't support queues and tables. 这些帐户包括仅限 blob 的存储帐户(包括高级存储)和使用区域冗余存储空间复制的常规用途存储帐户,已在创建函数应用时将从现有的“存储帐户”选项中过滤掉。These accounts, which include blob-only storage accounts (including premium storage) and general-purpose storage accounts with zone-redundant storage replication, are filtered-out from your existing Storage Account selections when you create a function app.

触发器和绑定也可以使用函数应用使用的相同存储帐户来存储应用程序数据。The same storage account used by your function app can also be used by your triggers and bindings to store your application data. 但是,对于存储密集型操作,应使用单独的存储帐户。However, for storage-intensive operations, you should use a separate storage account.

多个函数应用可以共享同一存储帐户,不会导致任何问题。It's possible for multiple function apps to share the same storage account without any issues. (一个很好的例子是,当你使用 Azure 存储模拟器在本地环境中开发多个应用时,它的作用类似于一个存储帐户。)(A good example of this is when you develop multiple apps in your local environment using the Azure Storage Emulator, which acts like one storage account.)

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

区域中数据驻留In Region Data Residency

当需要将所有客户数据保留在单个区域内时,与函数应用关联的存储帐户必须是具有区域内冗余的存储帐户。When necessary for all customer data to remain within a single region, the storage account associated with the function app must be one with in region redundancy. 区域内冗余存储帐户还需要与 Azure Durable Functions 一起使用,以实现持久功能。An in-region redundant storage account would also need to be used with Azure Durable Functions for Durable Functions.

其他由平台管理的客户数据只有托管在内部负载均衡器应用服务环境(简称 ILB ASE)中时才会存储在该区域内。Other platform-managed customer data will only be stored within the region when hosting in an Internal Load Balancer App Service Environment (or ILB ASE). 有关详细信息,可参阅 ASE 区域冗余Details can be found in ASE zone redundancy.

消耗计划和高级计划的工作原理How the Consumption and Premium plans work

在消耗计划和高级计划中,Azure Functions 基础结构通过根据触发函数的事件数添加额外的 Functions 主机实例来缩放 CPU 和内存资源。In the Consumption and Premium plans, the Azure Functions infrastructure 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 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 are scaled independently. 在高级计划中,计划大小将决定该实例上该计划中所有应用的可用内存和 CPU。In the Premium plan, your plan size will determine 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 that must be loaded 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 Always on 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 个实例。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 秒分配一次新实例。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.
  • 对于服务总线触发器,请使用资源的 管理 权限,以实现最有效的缩放。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 number of instances an app scales out to. 最常见的情况是下游组件(如数据库)的吞吐量有限。This is most common for cases where a downstream component like a database has limited throughput. 默认情况下,消耗计划函数将横向扩展到最多 200 个实例,高级计划函数将横向扩展到最多 100 个实例。By default, consumption plan functions will 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 设置为 0 或 null,或介于 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 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.

若要详细了解如何在 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.

托管计划比较Hosting plans comparison

以下比较表显示了可帮助你选择 Azure Functions 应用托管计划的所有重要方面:The following comparison table shows all important aspects to help the decision of Azure Functions App hosting plan choice:

计划摘要Plan summary

消耗计划Consumption plan 在函数运行时自动缩放,你只需为计算资源付费。Scale automatically and only pay for compute resources when your functions are running. 在消耗计划中,会根据传入事件数动态添加和删除 Functions 主机的实例。On the Consumption plan, instances of the Functions host are dynamically added and removed based on the number of incoming events.
✔ 默认托管计划。✔ Default hosting plan.
✔ 仅当函数运行时才产生费用。✔ Pay only when your functions are running.
✔ 即使是在负载较高期间也可自动横向扩展。✔ scale-out automatically, even during periods of high load.
高级计划Premium plan 在根据需求自动缩放时,将使用预热的工作器在空闲后立即运行应用程序,在功能更强大的实例上运行,并连接到 VNET。While automatically scaling based on demand, use pre-warmed workers to run applications with no delay after being idle, run on more powerful instances, and connect to VNETs. 除了应用服务计划的所有功能之外,还请考虑下列情况中的 Azure Functions 高级计划:Consider the Azure Functions Premium plan in the following situations, in addition to all features of the App Service plan:
✔ 你的函数应用持续地运行,或者近乎持续地运行。✔ Your function apps run continuously, or nearly continuously.
✔ 你的消耗计划具有大量的小型执行操作,具有较高的执行费用但较低的 GB 秒费用。✔ You have a high number of small executions and have a high execution bill but low GB second bill in the Consumption plan.
✔ 你需要的 CPU 或内存选项超出消耗计划提供的选项。✔ You need more CPU or memory options than what is provided by the Consumption plan.
✔ 你的代码所需的运行时间超过消耗计划允许的最长执行时间。✔ Your code needs to run longer than the maximum execution time allowed on the Consumption plan.
✔ 你需要只有高级计划才会提供的功能,例如虚拟网络连接。✔ You require features that are only available on a Premium plan, such as virtual network connectivity.
专用计划 1Dedicated plan1 在应用服务计划中以定期应用服务计划费率运行你的函数。Run your functions within an App Service plan at regular App Service plan rates. 非常适合长时间运行的操作,以及需要更具预测性的缩放和成本的情况。Good fit for long running operations, as well as when more predictive scaling and costs are required. 对于以下情况,可以考虑使用应用服务计划:Consider an App Service plan in the following situations:
✔ 具有已运行其他应用服务实例的、未充分利用的现成 VM。✔ You have existing, underutilized VMs that are already running other App Service instances.
✔ 需要提供用于运行函数的自定义映像。✔ You want to provide a custom image on which to run your functions.
ASE 1ASE1 应用服务环境 (ASE) 是一项应用服务功能,可提供完全隔离和专用的环境,以便高度安全地运行应用服务应用。App Service Environment (ASE) is an App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale. ASE 适用于有以下要求的应用程序工作负荷:ASEs are appropriate for application workloads that require:
✔ 极高的缩放性。✔ Very high scale.
✔完全计算隔离和安全的网络访问。✔ Full compute isolation and secure network access.
✔ 高内存利用率。✔ High memory utilization.
KubernetesKubernetes Kubernetes 提供了一个在 Kubernetes 平台之上运行的完全隔离的专用环境。Kubernetes provides a fully isolated and dedicated environment running on top of the Kubernetes platform. Kubernetes 适用于有以下要求的应用程序工作负荷:Kubernetes is appropriate for application workloads that require:
✔ 自定义硬件要求。✔ Custom hardware requirements.
✔ 隔离和安全的网络访问。✔ Isolation and secure network access.
✔ 能够在混合或多云环境中运行。✔ Ability to run in hybrid or multi-cloud environment.
✔ 与现有的 Kubernetes 应用程序和服务一起运行。✔ Run alongside existing Kubernetes applications and services.

1 有关各种应用服务计划选项的特定限制,请参阅应用服务计划限制1 For specific limits for the various App Service plan options, see the App Service plan limits.

操作系统/运行时Operating system/runtime

Linux1Linux1
仅限代码Code-only
Windows2Windows2
仅限代码Code-only
Linux1、3Linux1,3
Docker 容器Docker container
消耗计划Consumption plan .NET Core.NET Core
Node.jsNode.js
JavaJava
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
不支持No support
高级计划Premium plan .NET Core.NET Core
Node.jsNode.js
JavaJava
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
专用计划 4Dedicated plan4 .NET Core.NET Core
Node.jsNode.js
JavaJava
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
ASE 4ASE4 .NET Core.NET Core
Node.jsNode.js
JavaJava
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
.NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core
KubernetesKubernetes 不适用n/a 不适用n/a .NET Core.NET Core
Node.jsNode.js
JavaJava
PowerShell CorePowerShell Core

1对于 Python 运行时堆栈,Linux 是唯一受支持的操作系统。1Linux is the only supported operating system for the Python runtime stack.
2 对于 PowerShell 运行时堆栈,Windows 是唯一受支持的操作系统。2Windows is the only supported operating system for the PowerShell runtime stack.
3对于 Docker 容器,Linux 是唯一受支持的操作系统。3Linux is the only supported operating system for Docker containers. 4 有关各种应用服务计划选项的特定限制,请参阅应用服务计划限制4 For specific limits for the various App Service plan options, see the App Service plan limits.

缩放Scale

向外扩展Scale out 最大实例数Max # instances
消耗计划Consumption plan 事件驱动型。Event driven. 即使是在负载较高期间也可自动扩展。Scale out automatically, even during periods of high load. Azure Functions 基础结构可根据触发函数的事件数添加额外的 Functions 主机实例,因此可以缩放 CPU 和内存资源。Azure Functions infrastructure 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. 200200
高级计划Premium plan 事件驱动型。Event driven. 即使是在负载较高期间也可自动扩展。Scale out automatically, even during periods of high load. Azure Functions 基础结构可根据触发函数的事件数添加额外的 Functions 主机实例,因此可以缩放 CPU 和内存资源。Azure Functions infrastructure 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. 100100
专用计划 1Dedicated plan1 手动/自动缩放Manual/autoscale 10-2010-20
ASE 1ASE1 手动/自动缩放Manual/autoscale 100100
KubernetesKubernetes 对使用 KEDA 的 Kubernetes 群集进行事件驱动型自动缩放。Event-driven autoscale for Kubernetes clusters using KEDA. 因群集而异。    Varies by cluster.  

1 有关各种应用服务计划选项的特定限制,请参阅应用服务计划限制1 For specific limits for the various App Service plan options, see the App Service plan limits.

冷启动行为Cold start behavior

消耗 计划Consumption plan 如果空闲一段时间,应用数可能会缩减为零,这意味着某些请求在启动时可能会产生额外的延迟。Apps may scale to zero if idle for a period of time, meaning some requests may have additional latency at startup. 消耗计划有一些可缩短冷启动时间的优化措施,包括从已经运行函数主机和语言进程的预热占位符函数中进行拉取。The consumption plan does have some optimizations to help decrease cold start time, including pulling from pre-warmed placeholder functions that already have the function host and language processes running.
高级计划Premium plan 永久预热实例以避免任何冷启动。Perpetually warm instances to avoid any cold start.
专用计划 1Dedicated plan1 在专用计划中运行时,函数主机可以连续运行,这意味着冷启动实际上不是问题。When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn’t really an issue.
ASE 1ASE1 在专用计划中运行时,函数主机可以连续运行,这意味着冷启动实际上不是问题。When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn’t really an issue.
KubernetesKubernetes 依赖于 KEDA 配置。Depends on KEDA configuration. 可将应用配置为始终运行且绝不会冷启动,也可以将应用配置为缩减为零,这将导致在出现新事件时进行冷启动。Apps can be configured to always run and never have cold start, or configured to scale to zero, which results in cold start on new events.

1 有关各种应用服务计划选项的特定限制,请参阅应用服务计划限制1 For specific limits for the various App Service plan options, see the App Service plan limits.

服务限制Service limits

资源Resource 消耗计划Consumption plan 高级计划Premium plan 应用服务计划1App Service plan1
向外扩展Scale out 事件驱动Event driven 事件驱动Event driven 手动/自动缩放Manual/autoscale
最大实例数Max instances 200200 100100 10-2010-20
默认超时持续时间(分钟)Default timeout duration (min) 55 3030 302302
最大超时持续时间(分钟)Max timeout duration (min) 10 个10 无限8unbounded8 不受限制3unbounded3
最大出站连接数(每个实例)Max outbound connections (per instance) 600 个处于活动状态(总共 1200 个)600 active (1200 total) unboundedunbounded unboundedunbounded
最大请求大小 (MB)4Max request size (MB)4 100100 100100 100100
最大查询字符串长度4Max query string length4 40964096 40964096 40964096
最大请求 URL 长度4Max request URL length4 81928192 81928192 81928192
每个实例的 ACUACU per instance 100100 210-840210-840 100-840100-840
最大内存(每个实例的 GB 数)Max memory (GB per instance) 1.51.5 3.5-143.5-14 1.75-141.75-14
每个计划的函数应用数Function apps per plan 100100 100100 不受限制5unbounded5
应用服务计划App Service plans 每个区域 100 个100 per region 每个资源组 100 个100 per resource group 每个资源组 100 个100 per resource group
存储6Storage6 1 GB1 GB 250 GB250 GB 50-1000 GB50-1000 GB
每个应用的自定义域数Custom domains per app 50075007 500500 500500
自定义域 SSL 支持Custom domain SSL support 包含无限制的 SNI SSL 连接unbounded SNI SSL connection included 包含无限制的 SNI SSL 连接和 1 个 IP SSL 连接unbounded SNI SSL and 1 IP SSL connections included 包含无限制的 SNI SSL 连接和 1 个 IP SSL 连接unbounded SNI SSL and 1 IP SSL connections included

1 有关各种应用服务计划选项的特定限制,请参阅应用服务计划限制1 For specific limits for the various App Service plan options, see the App Service plan limits.
2 默认情况下,应用服务计划中的 Functions 1.x 运行时的超时是无限制的。2 By default, the timeout for the Functions 1.x runtime in an App Service plan is unbounded.
3 需要将应用服务计划设置为 Always On3 Requires the App Service plan be set to Always On. 按标准费率付费。Pay at standard rates.
4 这些限制在主机中设置4 These limits are set in the host.
5 可以托管的函数应用的实际数目取决于应用的活动、计算机实例的大小和相应的资源利用率。5 The actual number of function apps that you can host depends on the activity of the apps, the size of the machine instances, and the corresponding resource utilization.
6 存储限制是同一应用服务计划中所有应用的临时存储中的总内容大小。6 The storage limit is the total content size in temporary storage across all apps in the same App Service plan. 消耗计划使用 Azure 文件存储作为临时存储。Consumption plan uses Azure Files for temporary storage.
7 当函数应用托管在消耗计划中时,仅支持 CNAME 选项。7 When your function app is hosted in a Consumption plan, only the CNAME option is supported. 对于应用服务计划中的函数应用,可以使用 CNAME 或 A 记录映射自定义域。For function apps in an App Service plan, you can map a custom domain using either a CNAME or an A record. 8 保证最长 60 分钟。8 Guaranteed for up to 60 minutes.

网络功能Networking features

功能Feature 消耗计划Consumption plan 专用计划Dedicated plan ASEASE KubernetesKubernetes
入站 IP 限制和专用站点访问Inbound IP restrictions and private site access ✅是✅Yes ✅是✅Yes ✅是✅Yes ✅是✅Yes
虚拟网络集成Virtual network integration ❌否❌No ✅是(区域)✅Yes (Regional) ✅是✅Yes ✅是✅Yes
虚拟网络触发器(非 HTTP)Virtual network triggers (non-HTTP) ❌否❌No ✅是✅Yes ✅是✅Yes ✅是✅Yes
混合连接(仅限 Windows)Hybrid connections (Windows only) ❌否❌No ✅是✅Yes ✅是✅Yes ✅是✅Yes
出站 IP 限制Outbound IP restrictions ❌否❌No ✅是✅Yes ✅是✅Yes ✅是✅Yes

计费Billing

消耗计划Consumption plan 只需为函数运行时间付费。Pay only for the time your functions run. 账单将基于执行数量、执行时间和所用内存。Billing is based on number of executions, execution time, and memory used.
高级计划Premium plan 高级计划基于在必需实例和预热实例中使用的核心秒数和内存。Premium plan is based on the number of core seconds and memory used across needed and pre-warmed instances. 每个计划必须至少有一个实例始终处于预热状态。At least one instance per plan must be kept warm at all times. 此计划提供更可预测的定价。This plan provides more predictable pricing.
专用计划 1Dedicated plan1 应用服务计划中函数应用的费用与其他应用服务资源(例如 Web 应用)的费用相同。You pay the same for function apps in an App Service Plan as you would for other App Service resources, like web apps.
ASE 1ASE1 ASE 每月会产生统一的基础结构使用费,该费率不会随 ASE 的大小变化而改变。there's a flat monthly rate for an ASE that pays for the infrastructure and doesn't change with the size of the ASE. 此外,每个应用服务计划 vCPU 也会产生费用。In addition, there's a cost per App Service plan vCPU. ASE 中托管的所有应用都在“隔离”定价 SKU 中。All apps hosted in an ASE are in the Isolated pricing SKU.
KubernetesKubernetes 只需支付 Kubernetes 群集的费用;Functions 无额外费用。You pay only the costs of your Kubernetes cluster; no additional billing for Functions. 函数应用作为应用程序工作负荷在群集之上运行,就像普通应用一样。Your function app runs as an application workload on top of your cluster, just like a regular app.

1 有关各种应用服务计划选项的特定限制,请参阅应用服务计划限制1 For specific limits for the various App Service plan options, see the App Service plan limits.

后续步骤Next steps