Azure Functions 运行时版本概述

Azure Functions 当前支持多个版本的运行时主机。 下表详细说明了可用版本、它们的支持级别以及何时应使用它们:

版本 支持级别 说明
4.x GA 对所有语言中的函数建议使用的运行时版本。 使用此版本可在 .NET 6.0、.NET 7.0 和 .NET Framework 4.8 中运行 C# 函数
3.x GA 支持所有语言。 使用此版本在 .NET Core 3.1 和 .NET 5.0 上运行 C# 函数
2.x GA 支持旧版本 2.x 应用。 此版本处于维护模式,仅在更高版本中提供增强功能。
1.x GA 建议仅用于必须使用 .NET Framework 且仅支持在 Azure 门户、Azure Stack Hub 门户或本地 Windows 计算机上开发的 C# 应用。 此版本处于维护模式,仅在更高版本中提供增强功能。

重要

从 2022 年 12 月 3 日开始,我们不再支持在 Azure Functions 运行时的版本 2.x 和 3.x 上运行的函数应用。 请在该时间之前测试、验证函数应用并将其迁移到 Functions 运行时的版本 4.x。 有关详细信息,请参阅从 3.x 迁移到 4.x
之所以不再支持这些运行时版本,是因为不再支持这些更旧的运行时版本所需的 .NET Core 3.1。 此要求会影响所有 Azure Functions 运行时语言。
需要 .NET Framework 的 C# 函数应用仍支持 Functions 版本 1.x。 预览版支持现已在 Functions 4.x 中提供,用于在 .NET Framework 4.8 上运行 C# 函数

本文详细介绍了这些版本之间的一些差异、如何创建每个版本以及如何更改运行函数的版本。

支持级别

有两个级别的支持:

  • 正式发布 (GA) - 完全支持并获得批准在生产中使用。
  • 预览版 - 尚不支持,但将来应达到 GA 状态。

语言

函数应用中的所有函数必须共享相同的语言。 创建应用时,可以在函数应用中选择函数的语言。 函数应用的语言在 FUNCTIONS_WORKER_RUNTIME 设置中维护,并且在存在函数时不应更改。

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

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

1 可以在 .NET Core 2.x 兼容模式下在 .NET Core 3.1 上运行面向运行时版本 2.x 的 .NET 类库应用。 有关详细信息,请参阅 Functions v2.x 注意事项
2 转译为 JavaScript 后支持。

若要更详细地了解受支持的语言版本,请参阅语言特定的开发人员指南文章。
有关语言支持计划更改的信息,请参阅 Azure 路线图

在特定版本上运行

默认情况下,在 Azure 门户中和通过 Azure CLI 创建的函数应用将设置为版本 4.x。 可以根据需要修改此版本。 只能在创建函数应用之后、添加任何函数之前将运行时版本降级为 1.x。 即使应用具有现有函数,也可以迁移到最新版本。 当应用具有现有函数时,请在迁移到更高版本的运行时版本之前注意了解版本之间的任何中断性变更。 以下各部分详细介绍了版本之间的中断性变更,包括特定于语言的中断性变更。

如果没有看到你的编程语言,请从页面顶部选择。

在对运行时的主版本进行更改之前,应首先在新运行时版本上测试现有代码。 可以通过部署到在最新主版本上运行的另一个函数应用来验证应用在升级后是否正常运行。 还可以使用特定于运行时的版本的 Azure Functions Core Tools(包括 Functions 运行时)在本地验证代码。

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

在 Azure 中更改应用版本

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

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

重要

请不要随意更改此应用设置(因为这可能需要更改其他应用设置以及函数代码)。 而是应该在准备好进行主要版本升级时,在 Azure 门户中的函数应用“配置”的“函数运行时设置”选项卡中更改此设置。

若要了解详细信息,请参阅如何针对 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 注意事项

最低扩展版本

从技术上讲,绑定扩展版本与 Functions 运行时版本之间没有关联。 但是,从版本 4.x 开始,Functions 运行时对所有触发器和绑定扩展强制实施了最低版本要求。

如果收到有关包不符合最低版本要求的警告,则应像平常一样将该 NuGet 包更新到最低版本。 可以在链接的配置文件中找到对 Functions v4.x 中使用的扩展的最低版本要求。

对于 C# 脚本,请更新 host.json 中的扩展捆绑包引用,如下所示:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

从技术上讲,扩展捆绑包版本与 Functions 运行时版本之间没有关联。 但是,从版本 4.x 开始,Functions 运行时对扩展捆绑包强制实施了最低版本要求。

如果收到有关扩展捆绑包版本不符合最低版本要求的警告,请更新 host.json 中的现有扩展捆绑包引用,如下所示:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

若要了解有关扩展捆绑包的详细信息,请参阅扩展捆绑包

从 3.x 迁移到 4.x

Azure Functions 版本 4.x 向后高度兼容版本 3.x。 大多数应用应该能够安全地升级到 4.x,而无需对代码进行重大更改。 将 FUNCTIONS_EXTENSION_VERSION 应用设置设为值 ~4 时,会启动升级。 对于在 Windows 上运行的函数应用,还需要将 netFrameworkVersion 站点设置设为面向 .NET 6。

在将应用升级到 Functions 运行时版本 4.x 之前,应执行以下任务:

运行升级前验证程序

Azure Functions 提供升级前验证程序,用于帮助识别将函数应用迁移到 4.x 时的潜在问题。 运行升级前验证程序:

  1. Azure 门户中,导航到你的函数应用。

  2. 打开“诊断和解决问题”页。

  3. 在“Function App 诊断”中,开始键入 Functions 4.x Pre-Upgrade Validator,然后从列表中选择它。

  4. 验证完成后,请查看建议并解决应用中的任何问题。 如果需要对应用进行更改,请确保在本地使用 Azure Functions Core Tools v4 或通过使用过渡槽来验证针对 Functions 运行时版本 4.x 的更改。

在不使用槽的情况下迁移

升级到 v4.x 的最简单方法是在 Azure 中将函数应用上的 FUNCTIONS_EXTENSION_VERSION 应用程序设置设为 ~4。 函数应用在 Windows 上运行时,还需要更新 Azure 中的 netFrameworkVersion 站点设置。 必须在带有槽的站点上执行其他过程

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

在 Windows 上运行时,还需要启用运行时版本 4.x 所需的 .NET 6.0。

az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

在这些示例中,请将 <APP_NAME> 替换为函数应用的名称,并将 <RESOURCE_GROUP_NAME> 替换为资源组的名称。

使用槽进行迁移

使用部署槽位是将函数应用从以前的版本迁移到 v4.x 运行时的好方法。 通过使用过渡槽,可以在过渡槽中的新运行时版本上运行应用,并在验证后切换到生产槽。 这些槽还提供一种在升级期间最大程度地缩短停机时间的方法。 如果需要最大程度地缩短停机时间,请按照最短停机时间升级中的步骤操作。

在升级槽中验证应用后,可以将应用和新版本设置切换到生产槽。 此切换需要在生产槽中包含设置 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0。 添加此设置的方式会影响升级所需的停机时间。

标准升级

如果启用了槽的函数应用可以处理一次完整重启的停机时间,那么你可以直接在生产槽中更新 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 设置。 由于直接在生产槽中更改此设置会导致重启,从而影响可用性,因此请考虑在流量减少时执行此更改。 然后,可以从过渡槽中切换升级的版本。

Update-AzFunctionAppSetting PowerShell cmdlet 当前不支持这些槽。 你必须使用 Azure CLI 或 Azure 门户。

  1. 使用以下命令在生产槽中设置 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> 
    

    此命令会导致在生产槽中运行的应用重启。

  2. 同样,使用以下命令在过渡槽中设置 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  3. 使用以下命令更改 FUNCTIONS_EXTENSION_VERSION 并将过渡槽升级到新的运行时版本:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  4. (仅限 Windows)对于在 Windows 上运行的函数应用,请使用以下命令,以便运行时可以在 .NET 6 上运行:

    az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    

    在 Windows 上运行时,Functions 运行时版本 4.x 需要 .NET 6。

  5. 如果代码项目需要任何更新才能在版本 4.x 上运行,请立即将这些更新部署到过渡槽。

  6. 在切换之前,请确认函数应用在升级的过渡环境中正常运行。

  7. 使用以下命令将升级的过渡槽切换到生产槽:

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
    

最短停机时间升级

若要最大程度地缩短生产应用的停机时间,可以将 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 设置从过渡槽切换到生产槽。 然后,可以从预热过渡槽切换到升级的版本。

  1. 使用以下命令在过渡槽中设置 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  2. 使用以下命令将带有新设置的槽切换到生产槽,同时还原过渡槽中的版本设置。

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    

    在切换期间过渡槽可能会出现错误,并且会在暂存时还原运行时版本。 出现这种情况是因为如果在切换期间暂存中仅具有 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0,则会删除暂存中的 FUNCTIONS_EXTENSION_VERSION 设置。 在没有此版本设置的情况下,槽处于错误状态。 在切换后立即更新过渡槽中的版本应该会将槽重新置于良好状态,并且你可以根据需要调用回滚更改。 但是,对于切换的任何回滚,你还需要在切换返回之前直接从生产槽中删除 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0,以免生产槽中出现与过渡槽中相同的错误。 然后,生产设置中的此更改会导致重启。

  3. 使用以下命令在过渡槽中再次设置 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    

    此时,这两个槽都已设置 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0

  4. 使用以下命令更改 FUNCTIONS_EXTENSION_VERSION 并将过渡槽升级到新的运行时版本:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  5. (仅限 Windows)对于在 Windows 上运行的函数应用,请使用以下命令,以便运行时可以在 .NET 6 上运行:

    az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    

    在 Windows 上运行时,Functions 运行时版本 4.x 需要 .NET 6。

  6. 如果代码项目需要任何更新才能在版本 4.x 上运行,请立即将这些更新部署到过渡槽。

  7. 在切换之前,请确认函数应用在升级的过渡环境中正常运行。

  8. 使用以下命令将升级的预热过渡槽切换到生产槽:

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
    

升级本地项目

升级指令依赖于语言。 如果没有看到你使用的语言,请在文章顶部通过切换器将其选中。

若要将 C# 类库项目更新为 .NET 6 和 Azure Functions 4.x,请执行以下操作:

  1. Azure Functions Core Tools 的本地安装更新到版本 4。

  2. 按如下所示更新 TargetFrameworkAzureFunctionsVersion

    <TargetFramework>net6.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    
  3. 将应用引用的 NuGet 包更新到最新版本。 有关详细信息,请参阅中断性变更
    特定包取决于函数是在进程内运行还是在进程外运行。

若要将项目更新到 Azure Functions 4.x,请执行以下操作:

  1. Azure Functions Core Tools 的本地安装更新到版本 4.x。

  2. 将应用的 Azure Functions 扩展捆绑包更新到 2.x 或更高版本。 有关详细信息,请参阅中断性变更

  1. 如果使用的是 Node.js 版本 10 或 12,请移动到受支持的版本之一。
  1. 如果使用的是 PowerShell Core 6,请移动到受支持的版本之一。
  1. 如果使用的是 Python 3.6,请移动到受支持的版本之一。

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

以下是在将 3.x 应用升级到 4.x 之前需要注意的关键中断性变更,其中包括特定于语言的中断性变更。 如需完整列表,请参阅标有中断性变更:已批准的 Azure Functions GitHub 问题。 预计在预览期间会有更多变更。 订阅应用服务公告以获取更新。

如果没有看到你的编程语言,请从页面顶部选择。

运行时

  • 4\.x 不再支持 Azure Functions 代理。 建议使用 Azure API Management

  • 4\.x 不再支持使用 AzureWebJobsDashboard 登录到 Azure 存储。 应改用 Application Insights。 (#1923)

  • Azure Functions 4.x 现在强制实施对扩展的最低版本要求。 升级到受影响的扩展的最新版本。 对于非 .NET 语言,请升级到扩展包版本 2.x 或更高版本。 (#1987)

  • 现在,对于消耗计划中运行于 Linux 上的函数应用,4.x 中强制实施了默认超时和最大超时。 (#1915)

  • Azure Functions 4.x 为 Key Vault 提供程序使用 Azure.IdentityAzure.Security.KeyVault.Secrets,已经弃用了 Microsoft.Azure.KeyVault。 有关如何配置函数应用设置的详细信息,请参阅机密存储库中的 Key Vault 选项。 (#2048)

  • 现在,如果共享存储帐户的多个函数应用具有相同的主机 ID,则这些应用将无法启动。 有关详细信息,请参阅主机 ID 注意事项。 (#2049)

  • Azure Functions 4.x 支持 .NET 6 进程内和独立应用。

  • InvalidHostServicesException 现为灾难性错误。 (#2045)

  • EnableEnhancedScopes 默认为启用状态。 (#1954)

  • HttpClient 作为注册的服务删除。 (#1911)

  • 在 Java 11 中使用单一类加载程序。 (#1997)

  • 在 Java 8 中停止加载辅助进程 jar。 (#1991)

  • Azure Functions 4.x 不支持 Node.js 版本 10 和 12。 (#1999)

  • 更新了 Node.js 应用中的输出序列化,以解决以前的不一致问题。 (#2007)

  • Azure Functions 4.x 不支持 PowerShell 6。 (#1999)

  • 已更新默认线程计数。 不是线程安全的函数或内存使用率较高的函数可能会受到影响。 (#1962)

  • Azure Functions 4.x 不支持 Python 3.6。 (#1999)

  • 默认启用共享内存传输。 (#1973)

  • 已更新默认线程计数。 不是线程安全的函数或内存使用率较高的函数可能会受到影响。 (#1962)

从 2.x 迁移到 3.x

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

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

以下是在将 2.x 应用升级到 3.x 之前需要注意的特定于语言的更改。 如果没有看到你的编程语言,请从页面顶部选择。

运行 .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 context.done 或返回值分配的输出绑定现在与在 2.x+ context.bindings 中进行设置具有相同的行为。

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

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

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

  • Node.js 8 不再受支持,并且不会在 3.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 时,会重置 Azure 文件存储中的现有机密。

  • 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 文件中的以下属性内定义:

<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

如果使用 .NET 独立进程功能,也可以选择 net6.0net7.0net48 作为目标框架。 对 net7.0net48 的支持目前处于预览阶段。

注意

Azure Functions 4.x 要求 Microsoft.NET.Sdk.Functions 扩展至少为 4.0.0

在 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
Azure SQL(预览版)
Dapr3
事件网格
事件中心
HTTP 和 Webhook
IoT 中心
Kafka2
移动应用
通知中心
队列存储
RabbitMQ2
SendGrid
服务总线
SignalR
表存储
计时器

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

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

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

函数应用超时持续时间

函数应用的超时持续时间通过 functionTimeout 项目文件中的 functionTimeout 属性进行定义。 下表显示特定计划的默认值和最大值(以分钟为单位):

计划 默认 Maximum1
消耗计划 5 10
高级计划 302 无限制
专用计划 302 无限制

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

后续步骤

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