你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
重要
截至 2022 年 12 月 13 日,Azure Functions运行时版本 2.x 和 3.x 上运行的函数应用已终止扩展支持。 有关详细信息,请参阅停用的版本。
Azure Functions 版本 4.x 高度向后兼容于版本 3.x。 大多数应用应该能够安全地迁移到 4.x,而无需对代码进行重大更改。 有关 Functions 运行时版本的详细信息,请参阅 Azure Functions 运行时版本概述。
重要
在 2026 年 9 月 30 日之后,在 Linux 上运行的使用消耗计划中的函数应用将停止运行这些生命周期结束的 v3 运行时。 为了避免服务中断, 请将应用迁移到 v4 运行时。
在消耗计划中托管 Linux 上的函数应用的选项将于 2028 年 9 月 30 日停用。 Linux 消费计划未获取任何新功能或 语言版本。 消耗计划中Windows上运行的应用当前不受影响。 在停用日期之前,将应用迁移到 Flex Consumption 计划。
本文将指导你完成安全迁移函数应用以在 Functions 运行时版本 4.x 上运行的过程。 由于项目迁移说明依赖于语言,因此请确保从文章顶部的选择器中选择开发语言。
确定要迁移的函数应用
使用以下 PowerShell 脚本,在订阅中生成当前面向版本 2.x 或 3.x 的函数应用的列表:
$Subscription = '<YOUR SUBSCRIPTION ID>'
Set-AzContext -Subscription $Subscription | Out-Null
$FunctionApps = Get-AzFunctionApp
$AppInfo = @{}
foreach ($App in $FunctionApps)
{
if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*3*')
{
$AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
}
}
$AppInfo
选择目标.NET版本
在 Functions 运行时版本 3.x 上,你的 C# 函数应用程序可以使用进程内模型面向 .NET Core 3.1,或使用独立进程模型面向 .NET 5。
迁移函数应用时,有机会选择.NET的目标版本。 可以将 C# 项目更新为 Functions 版本 4.x 支持的以下.NET版本之一:
| .NET版本 | .NET官方支持策略发布类型 | 函数处理模型1,2 |
|---|---|---|
| .NET 10 | LTS (终止支持 2028 年 11 月 14 日) | 独立工作模型 |
| .NET 9 | STS (终止支持 2026 年 11 月 10 日)3 | 独立工作模型 |
| .NET 8 | LTS(2026 年 11 月 10 日终止支持) |
独立工作模型, 进程内模型2 |
| .NET Framework 4.8 | 查看策略 | 独立工作模型 |
1隔离工作者模型支持长期支持(LTS)和标准支持(STS)的 .NET 版本以及 .NET Framework。 进程模型仅支持 .NET 的 LTS 版本,以 8 .NET 结尾。 有关两个模型之间的完整特性和功能比较,请参阅进程与隔离工作进程之间的差异.NET Azure Functions。
2 对进程内模型的支持将于 2026 年 11 月 10 日结束。 有关详细信息,请参阅此支持公告。 为了继续获得完全支持,推荐将您的应用程序迁移到隔离工作者模型。
3 .NET 9 之前预计于 2026 年 5 月 12 日终止支持日期。 在.NET 9 服务时段,.NET团队将 STS 版本的支持扩展到 24 个月,从 .NET 9 开始。 有关详细信息,请参阅 博客文章。
提示
我们建议将 .NET 更新到隔离的工作进程模型上。 .NET 8 是支持时长最长的正式发布版本。
虽然可以选择改用进程内模型,但如果可以避免此方法,我们不建议使用此方法。 对进程内模型的支持将于 2026 年 11 月 10 日结束,因此需要在此之前迁移到隔离的辅助角色模型。 在迁移到版本 4.x 时,这样做将减少所需的总工作量,而独立工作者模型将为应用提供额外的好处,包括能够更轻松地针对未来版本的 .NET。 如果要迁移到隔离工作者模型,.NET Upgrade Assistant还可以为你处理许多必要的代码更改。
本指南未提供.NET 10(预览版)或.NET 9 的特定示例。 如果您需要面向其中一个版本,可以调整.NET 8 的例子。
准备迁移
如果尚未迁移,请使用 Azure PowerShell 标识需要在当前Azure订阅中迁移的应用列表。
在将应用迁移到 Functions 运行时版本 4.x 之前,应执行以下任务:
- 查看 3.x 与 4.x 之间的中断性变更列表。
- 完成迁移本地项目中的步骤,将本地项目迁移到版本 4.x。
- 迁移项目后,使用 Azure Functions Core Tools 4.x 版本在本地测试应用。
- 对托管在 Azure 中的应用运行预升级验证程序,并解决任何已识别的问题。
- 将Azure中的函数应用更新为新版本。 如果需要最大程度地减少停机时间,请考虑使用 暂存槽 在 Azure 的迁移应用上测试并验证运行在新版本中的情况。 然后,您可以将应用程序与更新的版本设置一起部署到生产环境。 有关详细信息,请参阅使用槽进行更新。
- 将迁移的项目发布到更新的函数应用。
使用Visual Studio将版本 4.x 项目发布到较低版本的现有函数应用时,系统会提示在部署期间让Visual Studio将函数应用更新为版本 4.x。 此更新使用不使用槽进行更新中定义的相同过程。
迁移本地项目
升级指令依赖于语言。 如果没有看到你使用的语言,请通过文章顶部的选择器选择它。
选择与目标版本的.NET和所需进程模型(进程内或独立工作进程)匹配的选项卡。
提示
如果要使用独立辅助角色模型迁移到 LTS 或 STS 版本的 .NET,可以使用 .NET 升级助手自动执行以下部分中提到的许多更改。
项目文件
以下示例是 .csproj 项目文件,该文件在版本 3.x 上使用 .NET Core 3.1:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.13" />
</ItemGroup>
<ItemGroup>
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
</Project>
使用以下过程之一将此 XML 文件更新为在 Functions 版本 4.x 中运行:
这些步骤假定本地 C# 项目;如果应用改用 C# 脚本 (.csx 文件),则应在继续作之前 转换为项目模型 。
.csproj XML 项目文件中需要以下更改:
设置
PropertyGroup的值。TargetFramework的值设置为net8.0。设置
PropertyGroup的值。AzureFunctionsVersion的值设置为v4。将以下
OutputType元素添加到PropertyGroup:<OutputType>Exe</OutputType>在
ItemGroup.PackageReference列表,将包引用替换为以下引用Microsoft.NET.Sdk.Functions:<FrameworkReference Include="Microsoft.AspNetCore.App" /> <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" /> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />记下对
Microsoft.Azure.WebJobs.*命名空间中其他包的任何引用。 在后面的步骤中,你将会替换这些包。添加以下新的
ItemGroup:<ItemGroup> <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/> </ItemGroup>
进行这些更改后,更新的项目应如以下示例所示:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
<RootNamespace>My.Namespace</RootNamespace>
<OutputType>Exe</OutputType>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
<!-- Other packages may also be in this list -->
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
<ItemGroup>
<Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>
</Project>
包和命名空间更改
根据要迁移到的模型,可能需要更新或更改应用程序引用的包。 采用目标包时,需要更新 using 语句的命名空间以及引用的一些类型。 可以在本文之后的usingHTTP 触发器模板示例中查看这些命名空间更改对语句的影响。
如果尚未更新,请更新项目以引用以下项的最新稳定版本:
根据应用使用的触发器和绑定,你的应用可能需要引用一组不同的包。 下表显示了一些最常用的扩展的替代项:
| 场景 | 对包引用的更改 |
|---|---|
| 定时触发器 | 添加 Microsoft.Azure.Functions.Worker.Extensions.Timer |
| 存储绑定 | 将Microsoft.Azure.WebJobs.Extensions.Storage替换为 Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues 和 Microsoft.Azure.Functions.Worker.Extensions.Tables |
| Blob 绑定 | 把对Microsoft.Azure.WebJobs.Extensions.Storage.Blobs的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs |
| 队列绑定 | 把对Microsoft.Azure.WebJobs.Extensions.Storage.Queues的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues |
| 表绑定 | 把对Microsoft.Azure.WebJobs.Extensions.Tables的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.Tables |
| Cosmos DB 绑定 | 把对Microsoft.Azure.WebJobs.Extensions.CosmosDB和/或 Microsoft.Azure.WebJobs.Extensions.DocumentDB的引用替换为最新版本的 Microsoft.Azure。Functions.Worker.Extensions.CosmosDB |
| 服务总线绑定 | 把对Microsoft.Azure.WebJobs.Extensions.ServiceBus的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.ServiceBus |
| 事件中心绑定 | 把对Microsoft.Azure.WebJobs.Extensions.EventHubs的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.EventHubs |
| 事件网格绑定 | 把对Microsoft.Azure.WebJobs.Extensions.EventGrid的引用替换为最新版本的 Microsoft.Azure。Functions.Worker.Extensions.EventGrid |
| SignalR 服务绑定 | 把对Microsoft.Azure.WebJobs.Extensions.SignalRService的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.SignalRService |
| Durable Functions(持久函数) | 把对Microsoft.Azure.WebJobs.Extensions.DurableTask的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.DurableTask |
| Durable Functions(持久函数) (SQL 存储提供程序) |
把对Microsoft.DurableTask.SqlServer.AzureFunctions的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer |
| Durable Functions(持久函数) (Netherite 存储提供程序) |
把对Microsoft.Azure.DurableTask.Netherite.AzureFunctions的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite |
| SendGrid 绑定 | 把对Microsoft.Azure.WebJobs.Extensions.SendGrid的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.SendGrid |
| Kafka 绑定 | 把对Microsoft.Azure.WebJobs.Extensions.Kafka的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.Kafka |
| RabbitMQ 绑定 | 把对Microsoft.Azure.WebJobs.Extensions.RabbitMQ的引用替换为最新版本的 Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ |
| 依赖项注入 和启动配置 |
移除对以下项的引用Microsoft.Azure.Functions.Extensions(独立工作器模型默认提供此功能。) |
有关要考虑的扩展的完整列表,请参阅受支持的绑定;有关独立进程模型的完整安装说明,请参阅每个扩展的文档。 必须安装任何目标包的最新稳定版本。
提示
在此过程中对扩展版本所做的任何更改可能还要求你更新 host.json 文件。 请务必阅读所使用的每个扩展的文档。
例如,服务总线 扩展在版本 4.x 和 5.x 之间的结构上发生了重大更改。 有关详细信息,请参阅 Azure Functions 的 Azure 服务总线 绑定。
隔离的工作模型应用程序不应引用 Microsoft.Azure.WebJobs.* 命名空间或 Microsoft.Azure.Functions.Extensions 中的任何包。 如果有对这些内容的任何剩余引用,应将其删除。
提示
你的应用还可能依赖于Azure SDK类型,无论是作为触发器和绑定的一部分,还是作为独立的依赖项。 还应利用此机会更新这些内容。 Functions 扩展的最新版本适用于适用于 .NET 的最新 Azure SDK 版本,几乎所有的包都采用形式 Azure.*。
Program.cs 文件
迁移项目以在独立工作进程中运行时,必须将以下 program.cs 文件添加到项目:
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
var host = new HostBuilder()
.ConfigureFunctionsWebApplication()
.ConfigureServices(services => {
services.AddApplicationInsightsTelemetryWorkerService();
services.ConfigureFunctionsApplicationInsights();
})
.Build();
host.Run();
此示例包括 ASP.NET Core 集成,以提高性能,并在应用使用 HTTP 触发器时提供熟悉的编程模型。 如果不打算使用 HTTP 触发器,则可以将对 ConfigureFunctionsWebApplication 的调用替换为对 ConfigureFunctionsWorkerDefaults 的调用。 如果这样做,可以从项目文件中删除对 Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore 的引用。 但是,为了获得最佳性能,即使对于具有其他触发器类型的函数,您也应该将 FrameworkReference 保持在 ASP.NET Core 上。
Program.cs文件将替换具有FunctionsStartup属性的任何文件,该文件通常是Startup.cs文件。 在 FunctionsStartup 代码将引用 IFunctionsHostBuilder.Services 的位置,可以改为在 Program.cs 中 .ConfigureServices() 的 HostBuilder 方法中添加语句。 若要详细了解如何使用 Program.cs,请参阅独立辅助角色模型指南中的 启动和配置 。
前面所述的默认 Program.cs 示例包括 Application Insights 的设置。 在 Program.cs 中,还必须配置任何应该应用于项目中代码的日志的日志筛选。 在隔离的工作器模型中, host.json 文件仅控制 Functions 主机运行时发出的事件。 如果未在 Program.cs中配置筛选规则,则可能会看到遥测中各种类别的日志级别存在差异。
尽管可以将自定义配置源注册为 HostBuilder 中的一部分,但这些源同样仅适用于项目中的代码。 平台还需要触发器和绑定配置,这应该通过 应用设置、密钥保管库 引用或 App 配置 引用功能提供。
将所有内容从任何现有 FunctionsStartup 文件移动到 Program.cs 文件后,可以删除 FunctionsStartup 该属性及其应用到的类。
local.settings.json 文件
只有在本地运行时才使用 local.settings.json 文件。 有关信息,请参阅本地设置文件。
迁移到版本 4.x 时,请确保 local.settings.json 文件至少包含以下元素:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
}
}
注意
从进程内运行迁移到在独立工作进程中运行时,需要将FUNCTIONS_WORKER_RUNTIME值更改为 "dotnet-isolated"。
host.json 文件
无需对 host.json 文件进行更改。 但是,如果此文件中的 Application Insights 配置来自进程内模型项目,则可能需要在 Program.cs 文件中进行其他更改。
host.json 文件仅控制来自 Functions 主机运行时环境的日志记录,在隔离工作者模型中,其中一些日志是由你的应用程序直接生成的,因而给予你更多的控制权。 有关如何筛选这些日志的详细信息,请参阅在独立辅助角色模型中管理日志级别。
类名更改
在版本之间,一些关键类的名称发生了更改。 这些更改是.NET API 的更改或进程内进程与独立工作进程之间的差异的结果。 下表列出了函数使用的在迁移时可能会更改的关键 .NET 类:
| .NET Core 3.1 | .NET 5 | .NET 8 |
|---|---|---|
FunctionName(属性) |
Function(属性) |
Function(属性) |
ILogger |
ILogger |
ILogger、ILogger<T> |
HttpRequest |
HttpRequestData |
HttpRequestData、HttpRequest(使用 ASP.NET Core 集成) |
IActionResult |
HttpResponseData |
HttpResponseData、IActionResult(使用 ASP.NET Core 集成) |
FunctionsStartup(属性) |
使用Program.cs替代 |
使用Program.cs替代 |
绑定中也可能存在类名差异。 有关详细信息,请参阅特定绑定的参考文章。
其他代码更改
本部分重点介绍在迁移过程中要考虑的其他代码更改。 所有应用程序都不需要这些更改,但你应该评估是否与方案相关。 请务必检查 3.x 和 4.x 之间的重大变更,以了解可能需要对项目进行的其他更改。
JSON 序列化
默认情况下,独立辅助角色模型使用 System.Text.Json 进行 JSON 序列化。 若要自定义序列化程序选项或切换到 JSON.NET(Newtonsoft.Json),请参阅 Customizing JSON 序列化。
Application Insights 日志级别和筛选
日志可以从 Functions 主机运行时和项目中的代码发送到 Application Insights。 host.json 允许你为主机日志记录配置规则,但若要控制来自代码的日志,需要将筛选规则配置为Program.cs的一部分。 有关如何筛选这些日志的详细信息,请参阅在独立辅助角色模型中管理日志级别。
HTTP 触发器模板
在 HTTP 触发的函数中可以看到进程内和隔离工作进程之间的差异。 版本 3.x(进程内)的 HTTP 触发器模板如以下示例所示:
using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;
namespace Company.Function
{
public static class HttpTriggerCSharp
{
[FunctionName("HttpTriggerCSharp")]
public static async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post", Route = null)] HttpRequest req,
ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
string name = req.Query["name"];
string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
dynamic data = JsonConvert.DeserializeObject(requestBody);
name = name ?? data?.name;
string responseMessage = string.IsNullOrEmpty(name)
? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
: $"Hello, {name}. This HTTP triggered function executed successfully.";
return new OkObjectResult(responseMessage);
}
}
}
迁移后的版本的 HTTP 触发器模板如以下示例所示:
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;
namespace Company.Function
{
public class HttpTriggerCSharp
{
private readonly ILogger<HttpTriggerCSharp> _logger;
public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
{
_logger = logger;
}
[Function("HttpTriggerCSharp")]
public IActionResult Run(
[HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
{
_logger.LogInformation("C# HTTP trigger function processed a request.");
return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
}
}
}
将项目更新为 Azure Functions 4.x:
将 Azure Functions Core Tools 本地安装更新到版本 4.x。
将应用的 Azure Functions 扩展捆绑包更新为 2.x 或更高版本。 有关详细信息,请参阅重大更改。
如果需要,请切换到 4.x 版本支持的其中一个 Java 版本。
更新应用的
POM.xml文件以将FUNCTIONS_EXTENSION_VERSION设置修改为~4,如以下示例所示:<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>~4</value> </property> </appSettings> </configuration>
- 如果需要,请迁移到版本 4.x 支持的 Node.js 版本之一。
- 请借此机会升级到 PowerShell 7.2(建议)。 有关详细信息,请参阅 PowerShell 版本。
- 如果您使用的是 Python 3.6,请升级到受支持的版本之一。
运行升级前验证程序
Azure Functions提供升级前验证程序,帮助你确定将函数应用迁移到 4.x 时的潜在问题。 运行升级前验证程序:
在 Azure 门户中,转到你的函数应用。
打开“诊断和解决问题”页。
在“函数应用诊断”中键入 ,然后从列表中选择它
Functions 4.x Pre-Upgrade Validator。验证完成后,请查看建议并解决应用中的任何问题。 如果需要对应用进行更改,请确保对更改进行验证,可以使用 Azure Functions Core Tools v4 在本地运行版本 4.x 的 Functions 运行时,或者使用暂存槽进行验证。
在 Azure 中更新函数应用
在发布迁移的项目之前,需要在 Azure 中将函数应用主机的运行时更新为版本 4.x。 Functions 主机使用的运行时版本由 FUNCTIONS_EXTENSION_VERSION 应用程序设置控制,但在某些情况下,还必须更新其他设置。 代码更改和应用程序设置更改都需要重启函数应用。
最简单的方法是在不使用槽的情况下进行更新,然后重新发布应用项目。 也可以在使用槽的情况下进行更新,以最大程度地减少应用中的停机时间并简化回滚。
在不使用槽的情况下进行更新
更新到 v4.x 的最简单方法是将 Azure 中函数应用上的 FUNCTIONS_EXTENSION_VERSION 应用程序设置设置为 ~4。 在带有槽的站点上,必须遵循不同的过程。
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
还必须设置另一个设置,Windows和 Linux 之间存在差异。
在 Windows 上运行时,还需要启用运行时版本 4.x 所需的 .NET 8.0。
az functionapp config set --net-framework-version v8.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 是Windows上运行的任何语言的函数应用所必需的。
在本例中,请将 <APP_NAME> 替换为函数应用的名称,并将 <RESOURCE_GROUP_NAME> 替换为资源组的名称。
现可重新发布已迁移为在版本 4.x 上运行的应用项目。
使用槽进行更新
使用部署槽是将函数应用从旧版本更新到 v4.x 运行时的好办法。 通过使用过渡槽,可以在过渡槽中的新运行时版本上运行应用,并在验证后切换到生产槽。 这些槽还提供了在更新期间最大程度地缩短停机时间的方法。 如果需要最大程度地缩短停机时间,请按照最短停机时间更新中的步骤操作。
在更新槽中验证应用后,可以将应用和新版本设置切换到生产槽中。 这种交换需要在生产槽中设置 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0。 添加此设置的方式会影响更新所需的停机时间。
标准更新
如果启用了槽的函数应用能够处理整个重启过程造成的停机时间,则你可以直接在生产槽中更新 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 设置。 由于直接在生产槽中更改此设置会导致重启,从而影响可用性,因此请考虑在流量减少时执行此更改。 然后,可以从过渡槽切换到更新后的版本。
Update-AzFunctionAppSetting PowerShell cmdlet 当前不支持插槽。 必须使用Azure CLI或Azure门户。
使用以下命令在生产槽中设置
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>在本例中,请将
<APP_NAME>替换为函数应用的名称,并将<RESOURCE_GROUP_NAME>替换为资源组的名称。 此命令会导致在生产槽中运行的应用重启。同时,使用以下命令在过渡槽中设置
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>使用以下命令修改
FUNCTIONS_EXTENSION_VERSION并将暂存槽位更新到新的运行时版本:az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>Functions 运行时版本 4.x 需要在 Windows 上使用 .NET 6。 在 Linux 上,.NET应用还必须更新为 .NET 6。 使用以下命令,使运行时可以在 .NET 6 上运行:
在 Windows 上运行时,还需要启用运行时版本 4.x 所需的 .NET 8.0。
az functionapp config set --net-framework-version v8.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>.NET 6 是Windows上运行的任何语言的函数应用所必需的。
在本例中,请将
<APP_NAME>替换为函数应用的名称,并将<RESOURCE_GROUP_NAME>替换为资源组的名称。如果代码项目需要任何更新才能在版本 4.x 上运行,请立即将这些更新部署到过渡槽。
在切换之前,请确认函数应用在更新的过渡环境中正常运行。
使用以下命令将更新的过渡槽切换到生产槽:
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
最短停机时间更新
若要最大程度地缩短生产应用的停机时间,可以将 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 设置从预备环境切换到生产环境。 然后,可以从预热的过渡槽切换到更新后的版本。
使用以下命令在过渡槽中设置
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>使用以下命令将具有新设置的部署槽切换到生产环境,同时恢复暂存槽中的版本设置。
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,以防暂存槽中出现的错误同样出现在生产槽中。 然后,生产设置中的此更改会导致重启。同样,请使用以下命令在过渡槽中设置
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。使用以下命令修改
FUNCTIONS_EXTENSION_VERSION并将暂存槽位更新到新的运行时版本:az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>Functions 运行时版本 4.x 需要在 Windows 中使用 .NET 6。 在 Linux 上,.NET应用还必须更新为 .NET 6。 使用以下命令,使运行时可以在 .NET 6 上运行:
在 Windows 上运行时,还需要启用运行时版本 4.x 所需的 .NET 8.0。
az functionapp config set --net-framework-version v8.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>.NET 6 是Windows上运行的任何语言的函数应用所必需的。
在本例中,请将
<APP_NAME>替换为函数应用的名称,并将<RESOURCE_GROUP_NAME>替换为资源组的名称。如果代码项目需要任何更新才能在版本 4.x 上运行,请立即将这些更新部署到过渡槽。
在切换之前,请确认函数应用在更新的过渡环境中正常运行。
使用以下命令将更新后的预热过渡槽切换到生产:
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
3.x 和 4.x 之间的中断性变更
以下是在将 3.x 应用升级到 4.x 之前需要注意的关键性重大变更,其中包括与语言相关的重大变更。 有关完整列表,请参阅标记为重大更改:已批准的 Azure Functions GitHub 上的问题。
如果没有看到你的编程语言,请从页面顶部选择。
运行时
Azure Functions代理是Azure Functions运行时版本 1.x 到 3.x 版本中的一项功能。 版本 4.x 不支持此功能。 有关详细信息,请参阅使用 Azure Functions 的无服务器 REST API。
4.x 中不再支持使用 AzureWebJobsDashboard登录到Azure 存储。 应改用 Application Insights。 (#1923)
Azure Functions 4.x 现在对扩展强制实施 最低版本要求。 更新到受影响扩展的最新版本。 对于非.NET语言,更新到扩展捆绑包版本 2.x 或更高版本。 (#1987)
现在,对于消耗计划中运行于 Linux 上的函数应用,将会强制实施 4.x 中的默认超时和最大超时。 (#1915)
Azure Functions 4.x 对 密钥保管库 提供程序使用
Azure.Identity和Azure.Security.KeyVault.Secrets,并且已弃用 Microsoft.Azure.KeyVault。 有关如何配置函数应用设置的详细信息,请参阅 Manage 密钥存储中的密钥保管库选项。 (#2048)现在,如果共享存储帐户的多个函数应用具有相同的主机 ID,则这些应用将无法启动。 有关详细信息,请参阅主机 ID 注意事项。 (#2049)
Azure Functions 4.x 支持较新版本的 .NET。 请参阅 Azure Functions 中支持的语言以获取完整的版本列表。
InvalidHostServicesException现为灾难性错误。 (#2045)EnableEnhancedScopes默认为启用状态。 (#1954)移除作为注册服务的
HttpClient。 (#1911)
- 已更新默认线程计数。 不是线程安全的函数或内存使用率较高的函数可能会受到影响。 (#1962)