Azure Functions 运行时版本概述Azure Functions runtime versions overview

Azure Functions 当前支持三个版本的运行时主机:1.x、2.x 和 3.x。Azure Functions currently supports three versions of the runtime host: 1.x, 2.x, and 3.x. 生产方案支持所有三个版本。All three versions are supported for production scenarios.


版本 1.x 处于维护模式,仅支持在 Azure 门户或本地 Windows 计算机上进行开发。Version 1.x is in maintenance mode and only supports development in the Azure portal or locally on Windows computers. 仅在更高版本中提供增强功能。Enhancements are provided only in later versions.

本文详细介绍了不同版本之间的一些差异、如何创建每个版本,以及如何更改版本。This article details some of the differences between the various versions, how you can create each version, and how to change versions.


从版本 2.x 开始,运行时使用语言扩展性模型,并且函数应用中的所有函数必须共享同一语言。Starting with version 2.x, the runtime uses a language extensibility model, and all functions in a function app must share the same language. 函数应用中的函数语言是在创建应用时选择的,并且在 FUNCTIONS_WORKER_RUNTIME 设置中进行维护。The language of functions in a function app is chosen when creating the app and is maintained in the FUNCTIONS_WORKER_RUNTIME setting.

下表指示每个运行时版本目前支持的编程语言。The following table indicates which programming languages are currently supported in each runtime version.

语言Language 1.x1.x 2.x2.x 3.x3.x
C#C# GA (.NET Framework 4.7)GA (.NET Framework 4.7) GA (.NET Core 2.2)GA (.NET Core 2.2) GA (.NET Core 3.1)GA (.NET Core 3.1)
JavaScriptJavaScript GA (Node 6)GA (Node 6) GA(Node 10 和 8)GA (Node 10 & 8) GA(Node 12 和 11)GA (Node 12 & 11)
F#F# GA (.NET Framework 4.7)GA (.NET Framework 4.7) GA (.NET Core 2.2)GA (.NET Core 2.2) GA (.NET Core 3.1)GA (.NET Core 3.1)
JavaJava 空值N/A GA (Java 8)GA (Java 8) GA(Java 111 和 8)GA (Java 111 & 8)
PowerShellPowerShell 空值N/A GA (PowerShell Core 6)GA (PowerShell Core 6) GA(PowerShell 7 和 Core 6)GA (PowerShell 7 & Core 6)
TypeScriptTypeScript 不适用N/A 正式版2GA2 正式版2GA2

1 语言版本支持目前处于预览阶段。1 Language version support is currently in preview.
2 转译为 JavaScript 后支持。2 Supported through transpiling to JavaScript.

有关详细信息,请参阅支持的语言For more information, see Supported languages.

在特定版本上运行Run on a specific version

默认情况下,在 Azure 门户中和通过 Azure CLI 创建的函数应用将设置为版本 3.x。By default, function apps created in the Azure portal and by the Azure CLI are set to version 3.x. 你可以根据需要修改此版本。You can modify this version as needed. 只能在创建函数应用之后、添加任何函数之前将运行时版本更改为 1.x。You can only change the runtime version to 1.x after you create your function app but before you add any functions. 即使应用具有函数,也允许在 2.x 和 3.x 之间迁移,但仍建议先在新应用中进行测试。Moving between 2.x and 3.x is allowed even with apps that have functions, but it is still recommended to test in a new app first.

从 1.x 迁移到更高版本Migrating from 1.x to later versions

可以选择迁移所编写的现有应用,以使用 1.x 版运行时,而不使用较新版本。You may choose to migrate an existing app written to use the version 1.x runtime to instead use a newer version. 需要做出的大多数更改与语言运行时的更改相关,例如,.NET Framework 4.7 与 .NET Core 之间的 C# API 更改。Most of the changes you need to make are related to changes in the language runtime, such as C# API changes between .NET Framework 4.7 and .NET Core. 还需要确保代码和库与所选的语言运行时兼容。You'll also need to make sure your code and libraries are compatible with the language runtime you choose. 最后,请务必注意触发器、绑定和以下突出显示功能中的任何更改。Finally, be sure to note any changes in trigger, bindings, and features highlighted below. 为获得最佳迁移结果,应当在新版本中创建一个新的函数应用,并将现有的 1.x 版函数代码移植到新应用。For the best migration results, you should create a new function app in a new version and port your existing version 1.x function code to the new app.

尽管可以通过手动更新应用配置来执行“就地”升级,但从 1.x 转变到更高版本包括了一些中断性变更。While it's possible to do an "in-place" upgrade by manually updating the app configuration, going from 1.x to a higher version includes some breaking changes. 例如,在 C# 中,调试对象从 TraceWriter 更改为 ILoggerFor example, in C#, the debugging object is changed from TraceWriter to ILogger. 创建新的 3.x 版项目后,可以基于最新的 3.x 版模板,从更新的函数着手进行开发。By creating a new version 3.x project, you start off with updated functions based on the latest version 3.x templates.

1.x 之后版本中触发器和绑定的更改Changes in triggers and bindings after version 1.x

从版本 2.x 开始,必须为应用中的函数所用的特定触发器和绑定安装扩展。Starting with version 2.x, you must install the extensions for specific triggers and bindings used by the functions in your app. 唯一的例外是 HTTP 和计时器触发器,它们不需要扩展。The only exception for this HTTP and timer triggers, which don't require an extension. 有关详细信息,请参阅注册和安装绑定扩展For more information, see Register and install binding extensions.

此外,在不同的版本中,函数的 function.json 或属性存在几处更改。There are also a few changes in the function.json or attributes of the function between versions. 例如,事件中心的 path 属性现在为 eventHubNameFor example, the Event Hub path property is now eventHubName. 请参阅现有绑定表,以获取每个绑定的文档链接。See the existing binding table for links to documentation for each binding.

1.x 之后版本中特性和功能的更改Changes in features and functionality after version 1.x

在版本 1.x 后删除、更新或替换了几个特性。A few features were removed, updated, or replaced after version 1.x. 本部分详细介绍了在使用版本 1.x 后,更高版本中会出现的更改。This section details the changes you see in later versions after having used version 1.x.

在版本 2.x 中做出了以下更改:In version 2.x, the following changes were made:

  • 用于调用 HTTP 终结点的密钥始终以加密方式存储在 Azure Blob 存储中。Keys for calling HTTP endpoints are always stored encrypted in Azure Blob storage. 在版本 1.x 中,密钥将默认存储在 Azure 文件存储中。In version 1.x, keys were stored in Azure File storage by default. 将应用从版本 1.x 升级到版本 2.x 时,会重置文件存储中的现有机密。When upgrading an app from version 1.x to version 2.x, existing secrets that are in file storage are reset.

  • 2.x 版运行时不包含对 Webhook 提供程序的内置支持。The version 2.x runtime doesn't include built-in support for webhook providers. 做出此项更改的目的是提高性能。This change was made to improve performance. 仍可以使用 HTTP 触发器作为 Webhook 的终结点。You can still use HTTP triggers as endpoints for webhooks.

  • 主机配置文件 (host.json) 应该为空或包含字符串 "version": "2.0"The host configuration file (host.json) should be empty or have the string "version": "2.0".

  • 为了改进监视功能,门户中使用 AzureWebJobsDashboard 设置的 WebJobs 仪表板已替换为使用 APPINSIGHTS_INSTRUMENTATIONKEY 设置的 Azure Application Insights。To improve monitoring, the WebJobs dashboard in the portal, which used the AzureWebJobsDashboard setting is replaced with Azure Application Insights, which uses the APPINSIGHTS_INSTRUMENTATIONKEY setting. 有关详细信息,请参阅监视 Azure FunctionsFor more information, see Monitor Azure Functions.

  • 函数应用中的所有函数必须共享相同的语言。All functions in a function app must share the same language. 创建函数应用时,必须选择该应用的运行时堆栈。When you create a function app, you must choose a runtime stack for the app. 运行时堆栈由应用程序设置中的 FUNCTIONS_WORKER_RUNTIME 值指定。The runtime stack is specified by the FUNCTIONS_WORKER_RUNTIME value in application settings. 增加此项要求的目的是减少占用空间和启动时间。This requirement was added to improve footprint and startup time. 进行本地开发时,还必须在 local.settings.json 文件中包含此设置。When developing locally, you must also include this setting in the local.settings.json file.

  • 应用服务计划中函数的默认超时已更改为 30 分钟。The default timeout for functions in an App Service plan is changed to 30 minutes. 可以使用 host.json 中的 functionTimeout 设置,将超时手动改回到无限。You can manually change the timeout back to unlimited by using the functionTimeout setting in host.json.

  • 默认情况下,将对消耗计划函数实施 HTTP 并发性限制,每个实例的并发请求数默认为 100。HTTP concurrency throttles are implemented by default for Consumption plan functions, with a default of 100 concurrent requests per instance. 可以在 host.json 文件中的 maxConcurrentRequests 设置内更改此值。You can change this in the maxConcurrentRequests setting in the host.json file.

  • 由于 .NET Core 的限制,已删除对 F# 脚本 (.fsx) 函数的支持。Because of .NET Core limitations, support for F# script (.fsx) functions has been removed. 编译的 F# 函数 (.fs) 仍受支持。Compiled F# functions (.fs) are still supported.

  • 事件网格触发器 Webhook 的 URL 格式已更改为 https://{app}/runtime/webhooks/{triggerName}The URL format of Event Grid trigger webhooks has been changed to https://{app}/runtime/webhooks/{triggerName}.

从 2.x 迁移到 3.xMigrating from 2.x to 3.x

Azure Functions 版本 3.x 向后高度兼容版本 2.x。Azure Functions version 3.x is highly backwards compatible to version 2.x. 许多应用应该能够安全地升级到 3.x,无需更改任何代码。Many apps should be able to safely upgrade to 3.x without any code changes. 虽然建议迁移到 3.x,但在生产应用的主版本中进行更改之前,务必运行大量测试。While moving to 3.x is encouraged, be sure to run extensive tests before changing the major version in production apps.

2.x 和 3.x 之间的中断性变更Breaking changes between 2.x and 3.x

下面是在将 2.x 应用升级到 3.x 之前要注意的变更。The following are the changes to be aware of before upgrading a 2.x app to 3.x.


  • 通过 context.done 或返回值分配的输出绑定现在与在 context.bindings 中进行设置具有相同的行为。Output bindings assigned through context.done or return values now behave the same as setting in context.bindings.

  • 计时器触发器对象采用 camelCase 而非 PascalCaseTimer trigger object is camelCase instead of PascalCase

  • dataType 为 binary 的事件中心触发函数将收到 binary 数组而非 string 数组。Event Hub triggered functions with dataType binary will receive an array of binary instead of string.

  • 无法再通过 context.bindingData.req 访问 HTTP 请求有效负载。The HTTP request payload can no longer be accessed via context.bindingData.req. 仍然可以在 context.bindings 中以输入参数 context.req 的形式对其进行访问。It can still be accessed as an input parameter, context.req, and in context.bindings.

  • Node.js 8 不再受支持,并且在 3.x 函数中不会执行。Node.js 8 is no longer supported and will not execute in 3.x functions.


在 Azure 中更改应用版本Changing version of apps in Azure

Azure 中的已发布应用使用的 Functions 运行时版本由 FUNCTIONS_EXTENSION_VERSION 应用程序设置指定。The version of the Functions runtime used by published apps in Azure is dictated by the FUNCTIONS_EXTENSION_VERSION application setting. 支持以下主要运行时版本值:The following major runtime version values are supported:

ValueValue 运行时目标Runtime target
~3 3.x3.x
~2 2.x2.x
~1 1.x1.x


请不要随意更改此设置,因为这可能需要更改其他应用设置以及函数代码。Don't arbitrarily change this setting, because other app setting changes and changes to your function code may be required.

本地开发的应用程序版本Locally developed application versions

你可以对函数应用进行以下更新以在本地更改目标版本。You can make the following updates to function apps to locally change the targeted versions.

Visual Studio 运行时版本Visual Studio runtime versions

在 Visual Studio 中,可在创建项目时选择运行时版本。In Visual Studio, you select the runtime version when you create a project. 用于 Visual Studio 的 Azure Functions 工具支持这三个主要运行时版本。Azure Functions tools for Visual Studio supports the three major runtime versions. 基于项目设置进行调试和发布时,将使用正确的版本。The correct version is used when debugging and publishing based on project settings. 版本设置在 .csproj 文件中的以下属性内定义:The version settings are defined in the .csproj file in the following properties:

版本 1.xVersion 1.x
版本 2.xVersion 2.x
3.x 版Version 3.x


Azure Functions 3.x 和 .NET 要求 Microsoft.NET.Sdk.Functions 扩展至少为 3.0.0Azure Functions 3.x and .NET requires the Microsoft.NET.Sdk.Functions extension be at least 3.0.0.

在 Visual Studio 中将 2.x 应用更新到 3.xUpdating 2.x apps to 3.x in Visual Studio

你可以打开面向 2.x 的现有函数,并通过编辑 .csproj 文件并更新上述值来迁移到 3.x。You can open an existing function targeting 2.x and move to 3.x by editing the .csproj file and updating the values above. Visual Studio 将基于项目元数据自动管理运行时版本。Visual Studio manages runtime versions automatically for you based on project metadata. 但是,如果你之前从未创建过 3.x 应用,则 Visual Studio 在你的计算机上可能尚无适用于 3.x 的模板和运行时。However, it's possible if you have never created a 3.x app before that Visual Studio doesn't yet have the templates and runtime for 3.x on your machine. 这可能会出现错误,例如“没有与项目中指定的版本匹配的可用函数运行时”This may present itself with an error like "no Functions runtime available that matches the version specified in the project." 若要提取最新的模板和运行时,请完成体验来创建新的函数项目。To fetch the latest templates and runtime, go through the experience to create a new function project. 到达版本和模板选择屏幕后,请等待 Visual Studio 完成最新模板提取。When you get to the version and template select screen, wait for Visual Studio to complete fetching the latest templates. 在最新的 .NET Core 3 模板可用并显示后,你应该能够运行和调试为版本 3.x 配置的任何项目。Once the latest .NET Core 3 templates are available and displayed you should be able to run and debug any project configured for version 3.x.


只有使用 Visual Studio 版本 16.4 或更高版本时,才能在 Visual Studio 中开发 3.x 版函数。Version 3.x functions can only be developed in Visual Studio if using Visual Studio version 16.4 or newer.

VS Code 和 Azure Functions Core ToolsVS Code and Azure Functions Core Tools

Azure Functions Core Tools 可用于命令行开发,另外,还可供适用于 Visual Studio Code 的 Azure Functions 扩展使用。Azure Functions Core Tools is used for command line development and also by the Azure Functions extension for Visual Studio Code. 若要针对版本 3.x 进行开发,请安装 Core Tools 版本 3.x。To develop against version 3.x, install version 3.x of the Core Tools. 版本 2.x 开发需要 Core Tools 版本 2.x,依此类推。Version 2.x development requires version 2.x of the Core Tools, and so on. 有关详细信息,请参阅安装 Azure Functions Core ToolsFor more information, see Install the Azure Functions Core Tools.

对于 Visual Studio Code 开发,可能还需要更新 azureFunctions.projectRuntime 的用户设置,使之与已安装工具的版本匹配。For Visual Studio Code development, you may also need to update the user setting for the azureFunctions.projectRuntime to match the version of the tools installed. 此设置还会更新创建函数应用期间使用的模板和语言。This setting also updates the templates and languages used during function app creation. 若要在 ~3 中创建应用,请将 azureFunctions.projectRuntime 用户设置更新为 ~3To create apps in ~3 you would update the azureFunctions.projectRuntime user setting to ~3.

Azure Functions 扩展运行时设置

Maven 和 Java 应用Maven and Java apps

通过安装在本地运行所需的 Core Tools 3.x 版本,可以将 Java 应用从版本 2.x 迁移到 3.x。You can migrate Java apps from version 2.x to 3.x by installing the 3.x version of the core tools required to run locally. 验证你的应用在 3.x 版中本地运行并正常工作后,更新应用的 POM.xml 文件来将 FUNCTIONS_EXTENSION_VERSION 设置修改为 ~3,如以下示例中所示:After verifying that your app works correctly running locally on version 3.x, update the app's POM.xml file to modify the FUNCTIONS_EXTENSION_VERSION setting to ~3, as in the following example:



从版本 2.x 开始,运行时使用新的绑定扩展性模型,该模型具有以下优势:Starting with version 2.x, the runtime uses a new binding extensibility model that offers these advantages:

  • 支持第三方绑定扩展。Support for third-party binding extensions.

  • 运行时和绑定分离。Decoupling of runtime and bindings. 此项更改允许对绑定扩展进行版本控制和单独发布操作。This change allows binding extensions to be versioned and released independently. 例如,可以选择升级到依赖于基础 SDK 的较新版本的扩展版本。You can, for example, opt to upgrade to a version of an extension that relies on a newer version of an underlying SDK.

  • 更轻便的执行环境,其中运行时仅知道和加载正在使用的绑定。A lighter execution environment, where only the bindings in use are known and loaded by the runtime.

除 HTTP 和计时器触发器外,其他所有绑定必须显式添加到函数应用项目,或者在门户中注册。With the exception of HTTP and timer triggers, all bindings must be explicitly added to the function app project, or registered in the portal. 有关详细信息,请参阅注册绑定扩展For more information, see Register binding extensions.

下表显示了每个运行时版本支持的绑定。The following table shows which bindings are supported in each runtime version.

下表显示了 Azure Functions 运行时的主版本支持的绑定:This table shows the bindings that are supported in the major versions of the Azure Functions runtime:

类型Type 1.x1.x 2.x 及更高版本12.x and higher1 触发器Trigger 输入Input 输出Output
Blob 存储Blob storage
Cosmos DBCosmos DB
事件网格Event Grid
事件中心Event Hubs
HTTP 和 WebhookHTTP & webhooks
IoT 中心IoT Hub
移动应用Mobile Apps
通知中心Notification Hubs
队列存储Queue storage
服务总线Service Bus
表存储Table storage

1 从版本 2.x 运行时开始,除了 HTTP 和 Timer 以外,所有绑定都必须注册。1 Starting with the version 2.x runtime, all bindings except HTTP and Timer must be registered. 请参阅注册绑定扩展See Register binding extensions.

2 消耗计划中不支持触发器。2 Triggers aren't supported in the Consumption plan. 需要运行时驱动的触发器Requires runtime-driven triggers.

3 仅支持 Kubernetes、IoT Edge 和其他自托管模式。3 Supported only in Kubernetes, IoT Edge, and other self-hosted modes only.

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

后续步骤Next steps

有关详细信息,请参阅以下资源:For more information, see the following resources: