Azure Functions 运行时版本概述

Azure Functions 当前支持三个版本的运行时主机:3.x、2.x 和 1.x。 生产方案支持所有三个版本。

重要

版本 1.x 处于维护模式,仅支持在 Azure 门户、Azure Stack Hub 门户或本地 Windows 计算机上进行开发。 仅在更高版本中提供增强功能。

本文详细介绍了不同版本之间的一些差异、如何创建每个版本,以及如何更改版本。

语言

从版本 2.x 开始,运行时使用语言扩展性模型,并且函数应用中的所有函数必须共享同一语言。 函数应用中的函数语言是在创建应用时选择的,并且在 FUNCTIONS_WORKER_RUNTIME 设置中进行维护。

下表指示每个运行时版本目前支持的编程语言。

语言 1.x 2.x 3.x
C#1 GA (.NET Framework 4.8) GA (.NET Core 2.12) GA (.NET Core 3.1)
GA (.NET 5.0)
JavaScript GA (Node 6) GA(Node 10 和 8) GA(Node 14、12 和 10)
F# GA (.NET Framework 4.8) GA (.NET Core 2.12) GA (.NET Core 3.1)
Java 空值 GA (Java 8) GA(Java 11 和 8)
PowerShell 空值 GA (PowerShell Core 6) GA(PowerShell 7.0 和 Core 6)
Python 不适用 GA(Python 3.7 和 3.6) GA(Python 3.8、3.7 和 3.6)
预览版 (Python 3.9)
TypeScript 不适用 GA3 GA3

1 提供 Azure Functions 的试验版本,以便你使用 .NET 6.0 预览版。 若要了解详细信息,请参阅 Azure Functions v4 早期预览版 页面。 2 可以在 .NET Core 2.x 兼容模式下在 .NET Core 3.1 上运行面向运行时版本 2.x 的 .NET 类库应用。 有关详细信息,请参阅 Functions v2.x 注意事项
3 转译为 JavaScript 后支持。

若要更详细地了解受支持的语言版本,请参阅语言特定的开发人员指南文章。

在特定版本上运行

默认情况下,在 Azure 门户中和通过 Azure CLI 创建的函数应用将设置为版本 3.x。 你可以根据需要修改此版本。 只能在创建函数应用之后、添加任何函数之前将运行时版本降级为 1.x。 即使应用有现有函数,也可以在 2.x 和 3.x 之间迁移。 将具有现有函数的应用从 2.x 迁移到 3.x 之前,请注意 2.x 和 3.x 之间的任何中断性变更

在对运行时的主版本进行更改之前,应首先通过部署到另一个在最新的主版本上运行的函数应用来测试现有代码。 此测试有助于确保它在升级后正常运行。

不支持从 v3.x 降级到 v2.x。 如果可能,应始终在支持的最新版 Functions 运行时上运行应用。

在 Azure 中更改应用版本

Azure 中的已发布应用使用的 Functions 运行时版本由 FUNCTIONS_EXTENSION_VERSION 应用程序设置指定。 支持以下主要运行时版本值:

Value 运行时目标
~3 3.x
~2 2.x
~1 1.x

重要

请不要随意更改此设置,因为这可能需要更改其他应用设置以及函数代码。

若要了解详细信息,请参阅如何针对 Azure Functions 运行时版本

固定到特定的次要版本

若要解决函数应用在最新的主版本上运行遇到的问题,必须将应用固定到特定的次要版本。 这样可让你有时间在最新的主版本上正确运行应用。 对于 Windows 和 Linux,固定到次要版本的方式有所不同。 若要了解详细信息,请参阅如何针对 Azure Functions 运行时版本

系统会定期从 Functions 中删除旧的次要版本。 有关 Azure Functions 版本的最新消息,包括删除较旧的特定次要版本,请关注 Azure 应用服务公告

固定到版本 ~2.0

在版本 2.x (~2) 上运行的 .NET 函数应用会自动升级以在 .NET Core 3.1(这是 .NET Core 3 的长期支持版本)上运行。 通过在 .NET Core 3.1 上运行 .NET 函数,可利用最新的安全更新和产品增强功能。

任何固定到 ~2.0 的函数应用都将继续在 .NET Core 2.2(不再接收安全性更新和其他更新)上运行。 有关详细信息,请参阅 Functions v2.x 注意事项

从 2.x 迁移到 3.x

Azure Functions 版本 3.x 向后高度兼容版本 2.x。 许多应用应该能够安全地升级到 3.x,无需更改任何代码。 虽然建议迁移到 3.x,但在生产应用的主版本中进行更改之前,务必运行大量测试。

2.x 和 3.x 之间的中断性变更

下面是在将 2.x 应用升级到 3.x 之前要注意的变更。

Javascript

  • 通过 context.done 或返回值分配的输出绑定现在与在 context.bindings 中进行设置具有相同的行为。

  • 计时器触发器对象采用 camelCase 而非 PascalCase

  • dataType 为 binary 的事件中心触发函数将收到 binary 数组而非 string 数组。

  • 无法再通过 context.bindingData.req 访问 HTTP 请求有效负载。 仍然可以在 context.bindings 中以输入参数 context.req 的形式对其进行访问。

  • Node.js 8 不再受支持,并且在 3.x 函数中不会执行。

.NET Core

运行 .NET 类库函数时,版本之间的主要区别在于 .NET Core 运行时。 Functions 版本 2.x 专门用于在 .NET Core 2.2 上运行,版本 3.x 专门用于在 .NET Core 3.1 上运行。

备注

由于 .NET Core 2.2 的支持问题,固定到版本 2 (~2) 的函数应用实质上是在 .NET Core 3.1 上运行。 有关详细信息,请参阅 Functions v2.x 兼容性模式

从 1.x 迁移到更高版本

可以选择迁移所编写的现有应用,以使用 1.x 版运行时,而不使用较新版本。 需要做出的大多数更改与语言运行时的更改相关,例如,.NET Framework 4.8 与 .NET Core 之间的 C# API 更改。 还需要确保代码和库与所选的语言运行时兼容。 最后,请务必注意触发器、绑定和以下突出显示功能中的任何更改。 为获得最佳迁移结果,应当在新版本中创建一个新的函数应用,并将现有的 1.x 版函数代码移植到新应用。

尽管可以通过手动更新应用配置来执行“就地”升级,但从 1.x 转变到更高版本包括了一些中断性变更。 例如,在 C# 中,调试对象从 TraceWriter 更改为 ILogger。 创建新的 3.x 版项目后,可以基于最新的 3.x 版模板,从更新的函数着手进行开发。

1.x 之后版本中触发器和绑定的更改

从版本 2.x 开始,必须为应用中的函数所用的特定触发器和绑定安装扩展。 唯一的例外是 HTTP 和计时器触发器,它们不需要扩展。 有关详细信息,请参阅注册和安装绑定扩展

此外,在不同的版本中,函数的 function.json 或属性存在几处更改。 例如,事件中心的 path 属性现在为 eventHubName。 请参阅现有绑定表,以获取每个绑定的文档链接。

1.x 之后版本中特性和功能的更改

在版本 1.x 后删除、更新或替换了几个特性。 本部分详细介绍了在使用版本 1.x 后,更高版本中会出现的更改。

在版本 2.x 中做出了以下更改:

  • 用于调用 HTTP 终结点的密钥始终以加密方式存储在 Azure Blob 存储中。 在版本 1.x 中,密钥将默认存储在 Azure 文件存储中。 将应用从版本 1.x 升级到版本 2.x 时,会重置文件存储中的现有机密。

  • 2.x 版运行时不包含对 Webhook 提供程序的内置支持。 做出此项更改的目的是提高性能。 仍可以使用 HTTP 触发器作为 Webhook 的终结点。

  • 主机配置文件 (host.json) 应该为空或包含字符串 "version": "2.0"

  • 为了改进监视功能,门户中使用 AzureWebJobsDashboard 设置的 WebJobs 仪表板已替换为使用 APPINSIGHTS_INSTRUMENTATIONKEY 设置的 Azure Application Insights。 有关详细信息,请参阅监视 Azure Functions

  • 函数应用中的所有函数必须共享相同的语言。 创建函数应用时,必须选择该应用的运行时堆栈。 运行时堆栈由应用程序设置中的 FUNCTIONS_WORKER_RUNTIME 值指定。 增加此项要求的目的是减少占用空间和启动时间。 进行本地开发时,还必须在 local.settings.json 文件中包含此设置。

  • 应用服务计划中函数的默认超时已更改为 30 分钟。 可以使用 host.json 中的 functionTimeout 设置,将超时手动改回到无限。

  • 默认情况下,将对消耗计划函数实施 HTTP 并发性限制,每个实例的并发请求数默认为 100。 可以在 host.json 文件中的 maxConcurrentRequests 设置内更改此值。

  • 由于 .NET Core 的限制,已删除对 F# 脚本 (.fsx) 函数的支持。 编译的 F# 函数 (.fs) 仍受支持。

  • 事件网格触发器 Webhook 的 URL 格式已更改为 https://{app}/runtime/webhooks/{triggerName}

本地开发的应用程序版本

你可以对函数应用进行以下更新以在本地更改目标版本。

Visual Studio 运行时版本

在 Visual Studio 中,可在创建项目时选择运行时版本。 用于 Visual Studio 的 Azure Functions 工具支持这三个主要运行时版本。 基于项目设置进行调试和发布时,将使用正确的版本。 版本设置在 .csproj 文件中的以下属性内定义:

3.x 版
<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>

备注

Azure Functions 3.x 和 .NET 要求 Microsoft.NET.Sdk.Functions 扩展至少为 3.0.0

版本 2.x
<TargetFramework>netcoreapp2.1</TargetFramework>
<AzureFunctionsVersion>v2</AzureFunctionsVersion>
版本 1.x
<TargetFramework>net472</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>
在 Visual Studio 中将 2.x 应用更新到 3.x

你可以打开面向 2.x 的现有函数,并通过编辑 .csproj 文件并更新上述值来迁移到 3.x。 Visual Studio 将基于项目元数据自动管理运行时版本。 但是,如果你之前从未创建过 3.x 应用,则 Visual Studio 在你的计算机上可能尚无适用于 3.x 的模板和运行时。 这可能会出现错误,例如“没有与项目中指定的版本匹配的可用函数运行时” 若要提取最新的模板和运行时,请完成体验来创建新的函数项目。 到达版本和模板选择屏幕后,请等待 Visual Studio 完成最新模板提取。 最新的 .NET Core 3 模板可用并显示后,就可以运行和调试为版本 3.x 配置的任何项目。

重要

只有使用 Visual Studio 版本 16.4 或更高版本时,才能在 Visual Studio 中开发 3.x 版函数。

VS Code 和 Azure Functions Core Tools

Azure Functions Core Tools 可用于命令行开发,另外,还可供用于 Visual Studio Code 的 Azure Functions 扩展使用。 若要针对版本 3.x 进行开发,请安装 Core Tools 版本 3.x。 版本 2.x 开发需要 Core Tools 版本 2.x,依此类推。 有关详细信息,请参阅安装 Azure Functions Core Tools

对于 Visual Studio Code 开发,可能还需要更新 azureFunctions.projectRuntime 的用户设置,使之与已安装工具的版本匹配。 此设置还会更新创建函数应用期间使用的模板和语言。 若要在 ~3 中创建应用,请将 azureFunctions.projectRuntime 用户设置更新为 ~3

Azure Functions 扩展运行时设置

Maven 和 Java 应用

通过安装在本地运行所需的 Core Tools 3.x 版本,可以将 Java 应用从版本 2.x 迁移到 3.x。 验证你的应用在 3.x 版中本地运行并正常工作后,更新应用的 POM.xml 文件来将 FUNCTIONS_EXTENSION_VERSION 设置修改为 ~3,如以下示例中所示:

<configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~3</value>
        </property>
    </appSettings>
</configuration>

绑定

从版本 2.x 开始,运行时使用新的绑定扩展性模型,该模型具有以下优势:

  • 支持第三方绑定扩展。

  • 运行时和绑定分离。 此项更改允许对绑定扩展进行版本控制和单独发布操作。 例如,可以选择升级到依赖于基础 SDK 的较新版本的扩展版本。

  • 更轻便的执行环境,其中运行时仅知道和加载正在使用的绑定。

除 HTTP 和计时器触发器外,其他所有绑定必须显式添加到函数应用项目,或者在门户中注册。 有关详细信息,请参阅注册绑定扩展

下表显示了每个运行时版本支持的绑定。

下表显示了 Azure Functions 运行时的主版本支持的绑定:

类型 1.x 2.x 及更高版本1 触发器 输入 输出
Blob 存储
Azure Cosmos DB
Dapr3
事件网格
事件中心
HTTP 和 Webhook
IoT 中心
Kafka2
移动应用
通知中心
队列存储
RabbitMQ2
SendGrid
服务总线
SignalR
表存储
计时器

1 从版本 2.x 运行时开始,除了 HTTP 和 Timer 以外,所有绑定都必须注册。 请参阅注册绑定扩展

2 消耗计划中不支持触发器。 需要运行时驱动的触发器

3 仅支持 Kubernetes、IoT Edge 和其他自托管模式。

函数应用超时持续时间

函数应用的超时持续时间通过 host.json 项目文件中的 functionTimeout 属性进行定义。 下表显示了两种计划和不同运行时版本的默认值和最大值(以分钟为单位):

计划 运行时版本 默认 最大值
消耗 1.x 5 10
消耗 2.x 5 10
消耗 3.x 5 10
高级 1.x 无限制 无限制
高级 2.x 30 无限制
高级 3.x 30 无限制
应用服务 1.x 无限制 无限制
应用服务 2.x 30 无限制
应用服务 3.x 30 无限制

备注

不管函数应用超时设置如何,230 秒是 HTTP 触发的函数在响应请求时需要的最长时间。 这起因于 Azure 负载均衡器的默认空闲超时。 对于处理时间较长的情况,考虑使用 Durable Functions 异步模式延迟实际工作并返回即时响应

后续步骤

有关详细信息,请参阅以下资源: