Azure Functions 托管选项Azure Functions hosting options

在 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 functionality, such as Azure Virtual Network connectivity.

本文详细比较了各种托管计划和基于 Kubernetes 的托管。This article provides a detailed comparison between the various hosting plans, along with Kubernetes-based hosting.

计划概述Overview of plans

下面汇总了适用于 Functions 的三个主要托管计划的优点:The following is a summary of the benefits of the three main hosting plans for Functions:

消耗计划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.
✔ 即使是在负载较高期间也可自动缩放。✔ Scales automatically, even during periods of high load.
高级计划Premium plan 使用预热的工作器根据需要自动缩放,这些工作器在空闲后会毫不延迟地运行应用程序,在更强大的实例上运行,并连接到虚拟网络。Automatically scales based on demand using pre-warmed workers which run applications with no delay after being idle, runs on more powerful instances, and connects to virtual networks.

请考虑下列情况中的 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 a high execution bill, but low GB seconds 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 aren't available on the Consumption plan, such as virtual network connectivity.
专用计划Dedicated plan 在应用服务计划中以定期应用服务计划费率运行你的函数。Run your functions within an App Service plan at regular App Service plan rates.

最适用于不能使用 Durable Functions 的长时间运行的方案。Best for long-running scenarios where Durable Functions can't be used. 对于以下情况,可以考虑使用应用服务计划: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.
✔ 需要可预测的缩放和成本。✔ Predictive scaling and costs are required.

本文中的比较表还包括以下托管选项,这些选项提供了运行函数应用所需的最大限度的控制和隔离。The comparison tables in this article also include the following hosting options, which provide the highest amount of control and isolation in which to run your function apps.

ASEASE 应用服务环境 (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 usage.
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.

本文中的其余表对有关各种功能和行为的计划进行了比较。The remaining tables in this article compare the plans on various features and behaviors. 有关动态托管计划(“消耗”和“高级”)之间的成本比较,请参阅 Azure Functions 定价页For a cost comparison between dynamic hosting plans (Consumption and Premium), see the Azure Functions pricing page. 有关各种专用计划选项的定价,请参阅应用服务定价页For pricing of the various Dedicated plan options, see the App Service pricing page.

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

下表显示了各个托管计划支持的操作系统及其语言运行时支持。The following table shows supported operating system and language runtime support for the hosting plans.

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
专用计划Dedicated 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
ASEASE .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 是唯一受支持的操作系统。1 Linux is the only supported operating system for the Python runtime stack.
2 对于 PowerShell 运行时堆栈,Windows 是唯一受支持的操作系统。2 Windows is the only supported operating system for the PowerShell runtime stack.
3 对于 Docker 容器,Linux 是唯一受支持的操作系统。3 Linux is the only supported operating system for Docker containers.

函数应用超时持续时间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.

缩放Scale

下表对各种托管计划的缩放行为进行了比较。The following table compares the scaling behaviors of the various hosting plans.

向外扩展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 incoming trigger events. 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 when idle, 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.
专用计划Dedicated plan 在专用计划中运行时,函数主机可以连续运行,这意味着冷启动实际上不是问题。When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn’t really an issue.
ASEASE 在专用计划中运行时,函数主机可以连续运行,这意味着冷启动实际上不是问题。When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn’t really an issue.
KubernetesKubernetes 可以根据 KEDA 配置对应用进行配置以避免冷启动。Depending on KEDA configuration, apps can be configured to avoid a cold start. 如果配置为缩放到零,则新事件会遇到冷启动。If configured to scale to zero, then a cold start is experienced for new events.

服务限制Service limits

资源Resource 消耗计划Consumption plan 高级计划Premium plan 专用计划Dedicated plan ASEASE KubernetesKubernetes
默认超时持续时间(分钟)Default timeout duration (min) 55 3030 301301 3030 3030
最大超时持续时间(分钟)Max timeout duration (min) 1010 无限制7unbounded7 无限制2unbounded2 unboundedunbounded unboundedunbounded
最大出站连接数(每个实例)Max outbound connections (per instance) 600 个处于活动状态(总共 1200 个)600 active (1200 total) unboundedunbounded unboundedunbounded unboundedunbounded unboundedunbounded
最大请求大小 (MB)3Max request size (MB)3 100100 100100 100100 100100 取决于群集Depends on cluster
最大查询字符串长度3Max query string length3 40964096 40964096 40964096 40964096 取决于群集Depends on cluster
最大请求 URL 长度3Max request URL length3 81928192 81928192 81928192 81928192 取决于群集Depends on cluster
每个实例的 ACUACU per instance 100100 210-840210-840 100-840100-840 210-2508210-2508 AKS 定价AKS pricing
最大内存(每个实例的 GB 数)Max memory (GB per instance) 1.51.5 3.5-143.5-14 1.75-141.75-14 3.5 - 143.5 - 14 支持任何节点Any node is supported
每个计划的函数应用数Function apps per plan 100100 100100 无限制4unbounded4 unboundedunbounded unboundedunbounded
应用服务计划App Service plans 每个区域 100 个100 per region 每个资源组 100 个100 per resource group 每个资源组 100 个100 per resource group - -
存储5Storage5 5 TB5 TB 250 GB250 GB 50-1000 GB50-1000 GB 1 TB1 TB 不适用n/a
每个应用的自定义域数Custom domains per app 50065006 500500 500500 500500 不适用n/a
自定义域 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 包含无限制的 SNI SSL 连接和 1 个 IP SSL 连接unbounded SNI SSL and 1 IP SSL connections included 不适用n/a

1 默认情况下,应用服务计划中的 Functions 1.x 运行时的超时是无限制的。1 By default, the timeout for the Functions 1.x runtime in an App Service plan is unbounded.
2 需要将应用服务计划设置为 Always On2 Requires the App Service plan be set to Always On. 按标准费率付费。Pay at standard rates.
3 这些限制在主机中设置3 These limits are set in the host.
4 可以托管的函数应用的实际数目取决于应用的活动、计算机实例的大小和相应的资源利用率。4 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.
5 存储限制是同一应用服务计划中所有应用的临时存储中的总内容大小。5 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.
6 当函数应用托管在消耗计划中时,仅支持 CNAME 选项。6 When your function app is hosted in a Consumption plan, only the CNAME option is supported. 对于高级计划应用服务计划中的函数应用,可以使用 CNAME 或 A 记录映射自定义域。For function apps in a Premium plan or an App Service plan, you can map a custom domain using either a CNAME or an A record.
7 保证最长 60 分钟。7 Guaranteed for up to 60 minutes.
8 辅助角色是托管客户应用的角色。8 Workers are roles that host customer apps. 辅助角色有 3 种固定大小:一个 vCPU/3.5 GB RAM;两个 vCPU/7 GB RAM;四个 vCPU/14 GB RAM。Workers are available in three fixed sizes: One vCPU/3.5 GB RAM; Two vCPU/7 GB RAM; Four vCPU/14 GB RAM.

网络功能Networking features

功能Feature 消耗计划Consumption plan 高级计划Premium plan 专用计划Dedicated plan ASEASE KubernetesKubernetes
入站 IP 限制和专用站点访问Inbound IP restrictions and private site access ✅是✅Yes ✅是✅Yes ✅是✅Yes ✅是✅Yes ✅是✅Yes
虚拟网络集成Virtual network integration ❌否❌No ✅是(区域)✅Yes (Regional) ✅是(区域和网关)✅Yes (Regional and Gateway) ✅是✅Yes ✅是✅Yes
虚拟网络触发器(非 HTTP)Virtual network triggers (non-HTTP) ❌否❌No ✅是✅Yes ✅是✅Yes ✅是✅Yes ✅是✅Yes
混合连接(仅限 Windows)Hybrid connections (Windows only) ❌否❌No ✅是✅Yes ✅是✅Yes ✅是✅Yes ✅是✅Yes
出站 IP 限制Outbound IP restrictions ❌否❌No ✅是✅Yes ✅是✅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 the most predictable pricing.
*专用计划*Dedicated plan 应用服务计划中函数应用的费用与其他应用服务资源(例如 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)App Service Environment (ASE) 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 也会产生费用。There's also 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.

后续步骤Next steps