Udostępnij za pomocą

Migrowanie aplikacji z usługi Azure Functions w wersji 3.x do wersji 4.x

Usługa Azure Functions w wersji 4.x jest wysoce zgodna z wersją 3.x. Większość aplikacji powinna bezpiecznie migrować do wersji 4.x bez konieczności wprowadzania znaczących zmian w kodzie. Aby uzyskać więcej informacji na temat wersji środowiska uruchomieniowego usługi Functions, zobacz Omówienie wersji środowiska uruchomieniowego usługi Azure Functions.

Ważne

Od 13 grudnia 2022 r. aplikacje funkcji działające w wersjach 2.x i 3.x środowiska uruchomieniowego usługi Azure Functions nie są już objęte wsparciem doatkowym. Aby uzyskać więcej informacji, zobacz Wycofane wersje.

Ten artykuł przeprowadzi Cię przez proces bezpiecznego migrowania aplikacji funkcji do uruchamiania w wersji 4.x środowiska uruchomieniowego usługi Functions. Ponieważ instrukcje migracji projektu są zależne od języka, pamiętaj, aby wybrać język programowania z selektora w górnej części artykułu.

Identyfikowanie aplikacji funkcji do migracji

Użyj następującego skryptu programu PowerShell, aby wygenerować listę aplikacji funkcji w subskrypcji, które są obecnie przeznaczone dla wersji 2.x lub 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

Wybierz docelową wersję platformy .NET

W wersji 3.x środowiska uruchomieniowego Functions, aplikacja funkcji w języku C# jest przeznaczona dla platformy .NET Core 3.1, korzystając z modelu wewnątrzprocesowego, lub dla platformy .NET 5, korzystając z modelu izolowanego procesu roboczego.

Podczas migracji aplikacji funkcji możesz wybrać docelową wersję platformy .NET. Projekt języka C# można zaktualizować do jednej z następujących wersji platformy .NET obsługiwanych przez usługę Functions w wersji 4.x:

Wersja platformy .NET Oficjalna polityka wsparcia platformy .NET typ wydania Modelprzetwarzania funkcji 1,2
.NET 10 LTS (koniec wsparcia technicznego 14 listopada 2028 r.) Model izolowanego procesu roboczego
.NET 9 STS (koniec wsparcia 10 listopada 2026 r.)3 Model izolowanego procesu roboczego
.NET 8 LTS (koniec wsparcia 10 listopada 2026 r.) Model izolowanego pracownika
Model procesowy2
.NET Framework 4.8 Zobacz zasady Model izolowanego procesu roboczego

1 Model izolowanego procesu roboczego obsługuje wersje platformy .NET (Long Term Support) i Standard Term Support (STS) oraz .NET Framework. Model w trakcie przetwarzania obsługuje tylko wersje LTS .NET, kończące się na .NET 8. Aby zapoznać się z pełnym porównaniem funkcji i funkcjonalności między dwoma podejściami, zobacz Różnice między funkcjami .NET Azure działającymi w ramach procesu a funkcjami działającymi w wydzielonym procesie.

2 Zakończenie wsparcia dla modelu procesu 10 listopada 2026 r. Aby uzyskać więcej informacji, zobacz to ogłoszenie pomocy technicznej. Aby zapewnić ciągłą pełną obsługę, należy przeprowadzić migrację aplikacji do izolowanego modelu procesu roboczego.

3 .NET 9 miało wcześniej oczekiwaną datę zakończenia wsparcia z 12 maja 2026 r. W oknie usługi platformy .NET 9 zespół platformy .NET rozszerzył wsparcie dla wersji STS do 24 miesięcy, począwszy od platformy .NET 9. Aby uzyskać więcej informacji, zobacz wpis w blogu.

Napiwek

Zalecamy zaktualizowanie do platformy .NET 8 na izolowanym modelu procesu roboczego. .NET 8 to w pełni wydana wersja z najdłuższym oknem obsługi z platformy .NET.

Mimo że zamiast tego można użyć modelu w procesie, nie zalecamy tego podejścia, jeśli można go uniknąć. Obsługa dla modelu realizowanego procesowo zostanie zakończona 10 listopada 2026 r., dlatego przed tym należy przejść do modelu izolowanego pracownika. Wykonanie tej czynności podczas migracji do wersji 4.x spowoduje zmniejszenie całkowitego nakładu pracy, a izolowany model roboczy zapewni aplikacji dodatkowe korzyści, w tym możliwość łatwiejszego określania przyszłych wersji platformy .NET. Jeśli przechodzisz do izolowanego modelu roboczego, Asystent uaktualniania platformy .NET może również obsługiwać wiele niezbędnych zmian kodu.

Ten przewodnik nie przedstawia konkretnych przykładów dla platformy .NET 10 (wersja zapoznawcza) ani .NET 9. Jeśli musisz kierować jedną z tych wersji, możesz dostosować przykłady platformy .NET 8.

Przygotowanie do migracji

Jeśli jeszcze tego nie zrobiono, zidentyfikuj listę aplikacji, które muszą zostać zmigrowane w bieżącej subskrypcji platformy Azure przy użyciu programu Azure PowerShell.

Przed przeprowadzeniem migracji aplikacji do wersji 4.x środowiska uruchomieniowego usługi Functions należy wykonać następujące zadania:

  1. Sprawdź listę zmian wpływających na kompatybilność między wersjami 3.x a 4.x.
  2. Wykonaj kroki opisane w artykule Migrowanie projektu lokalnego, aby przeprowadzić migrację projektu lokalnego do wersji 4.x.
  3. Po przeprowadzeniu migracji projektu w pełni przetestuj aplikację lokalnie przy użyciu wersji 4.x narzędzi Azure Functions Core Tools.
  4. Uruchom moduł sprawdzania poprawności przed uaktualnieniem w aplikacji hostowanej na platformie Azure i rozwiąż wszelkie zidentyfikowane problemy.
  5. Zaktualizuj aplikację funkcji na platformie Azure do nowej wersji. Jeśli musisz zminimalizować przestoje, rozważ użycie miejsca przejściowego do przetestowania i zweryfikowania migrowanej aplikacji na platformie Azure w nowej wersji środowiska uruchomieniowego. Następnie możesz wdrożyć aplikację do środowiska produkcyjnego przy użyciu zaktualizowanych ustawień wersji. Aby uzyskać więcej informacji, zobacz Aktualizowanie przy użyciu dostępnych zasobów.
  6. Opublikuj zmigrowany projekt w zaktualizowanej aplikacji funkcjonalnej.

Gdy używasz programu Visual Studio do publikowania projektu w wersji 4.x w istniejącej aplikacji funkcji w niższej wersji, podczas wdrażania zostanie wyświetlony monit o zaktualizowanie aplikacji funkcji do wersji 4.x. Ta aktualizacja używa tego samego procesu zdefiniowanego w Update without slots.

Migrowanie projektu lokalnego

Instrukcje uaktualniania są zależne od języka. Jeśli język nie jest widoczny, wybierz go z selektora w górnej części artykułu.

Wybierz kartę zgodną z docelową wersją platformy .NET i żądanym modelem procesów (proces współdzielony lub proces izolowany).

Napiwek

Jeśli przechodzisz do wersji LTS lub STS platformy .NET przy użyciu izolowanego modelu roboczego, asystent uaktualniania platformy .NET może służyć do automatycznego wprowadzania wielu zmian wymienionych w poniższych sekcjach.

Plik projektu

Poniższy przykład to .csproj plik projektu, który używa programu .NET Core 3.1 w wersji 3.x:

<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>

Użyj jednej z następujących procedur, aby zaktualizować ten plik XML do uruchomienia w usłudze Functions w wersji 4.x:

W tych krokach przyjęto założenie lokalnego projektu w języku C#; Jeśli aplikacja zamiast tego używa skryptu języka C# (pliki csx ), przed kontynuowaniem należy przekonwertować go na model projektu .

Następujące zmiany są wymagane w pliku projektu .csproj XML:

  1. Ustaw wartość PropertyGroup. TargetFramework do net8.0.

  2. Ustaw wartość PropertyGroup. AzureFunctionsVersion do v4.

  3. Dodaj następujący OutputType element do elementu PropertyGroup:

    <OutputType>Exe</OutputType>

  4. W pliku ItemGroup. PackageReference lista: zastąp odwołanie do pakietu Microsoft.NET.Sdk.Functions następującymi odwołaniami:

      <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" />

    Zanotuj wszystkie odwołania do innych pakietów w Microsoft.Azure.WebJobs.* przestrzeniach nazw. Te pakiety zostaną zastąpione w późniejszym kroku.

  5. Dodaj następujący nowy element ItemGroup:

    <ItemGroup>
  <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>

Po wprowadzeniu tych zmian zaktualizowany projekt powinien wyglądać podobnie do następującego przykładu:

<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>

Zmiany pakietu i przestrzeni nazw

Na podstawie modelu, do którego przeprowadzasz migrację, może być konieczne zaktualizowanie lub zmiana pakietów, do których odnosi się aplikacja. Podczas przyjęcia pakietów docelowych musisz zaktualizować przestrzeń nazw instrukcji using oraz niektóre typy, do których się odwołujesz. Możesz zobaczyć wpływ tych zmian przestrzeni nazw na instrukcje using w przykładach szablonu wyzwalacza HTTP w dalszej części tego artykułu.

Jeśli jeszcze tego nie zrobiono, zaktualizuj projekt, aby odwoływać się do najnowszych stabilnych wersji:

W zależności od wyzwalaczy i powiązań używanych przez aplikację może być konieczne odwołanie do innego zestawu pakietów. W poniższej tabeli przedstawiono zamiany niektórych najczęściej używanych rozszerzeń:

Scenariusz Zmiany referencji do pakietu
Wyzwalacz czasomierza Dodaj
Microsoft.Azure.Functions.Worker.Extensions.Timer
Powiązania przechowywania Zamień
Microsoft.Azure.WebJobs.Extensions.Storage
z
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues i
Microsoft.Azure.Functions.Worker.Extensions.Tables
Powiązania obiektu blob Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Powiązania kolejki Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Powiązania tabeli Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Tables
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.Tables
Powiązania Cosmos DB Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.CosmosDB
i/lub
Microsoft.Azure.WebJobs.Extensions.DocumentDB
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Powiązania usługi Service Bus Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.ServiceBus
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Powiązania usługi Event Hubs Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.EventHubs
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Powiązania usługi Event Grid Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.EventGrid
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Wiązania usługi SignalR Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.SignalRService
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Durable Functions Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.DurableTask
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions
(Dostawca magazynu SQL)		 Zamień odwołania na
Microsoft.DurableTask.SqlServer.AzureFunctions
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(Dostawca magazynu Netherite)		 Zamień odwołania na
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Powiązania usługi SendGrid Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.SendGrid
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Powiązania platformy Kafka Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Kafka
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Powiązania RabbitMQ Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
z najnowszą wersją oprogramowania
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Wstrzykiwanie zależności
i konfiguracja uruchamiania		 Usuń odwołania do
Microsoft.Azure.Functions.Extensions
(Model izolowanego procesu roboczego domyślnie udostępnia tę funkcję).

Zobacz Obsługiwane powiązania , aby zapoznać się z pełną listą rozszerzeń, które należy wziąć pod uwagę, i zapoznaj się z dokumentacją każdego rozszerzenia, aby uzyskać pełne instrukcje instalacji dla izolowanego modelu procesów. Pamiętaj, aby zainstalować najnowszą stabilną wersję wszystkich docelowych pakietów.

Napiwek

Wszelkie zmiany w wersjach rozszerzeń w trakcie tego procesu mogą wymagać również zaktualizowania host.json pliku. Pamiętaj, aby zapoznać się z dokumentacją każdego używanego rozszerzenia. Na przykład rozszerzenie usługi Service Bus ma zmiany powodujące niezgodność w strukturze między wersjami 4.x i 5.x. Aby uzyskać więcej informacji, zobacz Powiązania usługi Azure Service Bus dla usługi Azure Functions.

Aplikacja modelu izolowanego pracownika nie powinna odwoływać się do żadnych pakietów w przestrzeniach nazw Microsoft.Azure.WebJobs.* ani Microsoft.Azure.Functions.Extensions. Jeśli masz jakiekolwiek pozostałe odwołania do tych odwołań, należy je usunąć.

Napiwek

Aplikacja może również zależeć od typów Azure SDK w ramach wyzwalaczy i powiązań bądź jako zależność autonomiczna. Należy skorzystać z tej okazji, aby je również zaktualizować. Najnowsze wersje rozszerzeń usługi Functions współdziałają z najnowszymi wersjami zestawu Azure SDK dla platformy .NET, prawie wszystkich pakietów, dla których jest formularz Azure.*.

plik Program.cs

Podczas migracji do uruchomienia w izolowanym procesie roboczym należy dodać następujący plik program.cs do projektu:

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();

Ten przykład obejmuje integrację ASP.NET Core w celu zwiększenia wydajności i udostępnienia znanego modelu programowania, gdy aplikacja używa wyzwalaczy HTTP. Jeśli nie zamierzasz używać wyzwalaczy HTTP, możesz zastąpić wywołanie ConfigureFunctionsWebApplication wywołaniem metody ConfigureFunctionsWorkerDefaults. Jeśli to zrobisz, możesz usunąć odwołanie z Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore pliku projektu. Jednak aby uzyskać najlepszą wydajność, nawet w przypadku funkcji z innymi typami wyzwalaczy, należy utrzymywać FrameworkReference przy ASP.NET Core.

Plik Program.cs zastępuje dowolny plik, który ma FunctionsStartup atrybut , który jest zazwyczaj plikiem Startup.cs . W miejscach, w których FunctionsStartup kod mógłby się odwoływać do IFunctionsHostBuilder.Services, można zamiast tego dodać instrukcje do .ConfigureServices() metody HostBuilder w Program.cs. Aby dowiedzieć się więcej na temat pracy z Program.cs, zobacz Start-up and configuration (Uruchamianie i konfiguracja ) w przewodniku po izolowanym modelu procesu roboczego.

Domyślne przykłady Program.cs opisane wcześniej obejmują konfigurację usługi Application Insights. W Program.cs należy również skonfigurować filtrowanie dzienników, które ma dotyczyć dzienników pochodzących z kodu w projekcie. W modelu izolowanego procesu roboczego plik host.json kontroluje tylko zdarzenia emitowane przez środowisko uruchomieniowe hosta usługi Functions. Jeśli nie skonfigurujesz reguł filtrowania w Program.cs, mogą wystąpić różnice w poziomach dziennika dostępnych dla różnych kategorii w twojej telemetrii.

Chociaż można zarejestrować niestandardowe źródła konfiguracji w ramach HostBuilderprogramu , mają one podobnie zastosowanie tylko do kodu w projekcie. Platforma potrzebuje również konfiguracji wyzwalaczy i powiązań, które powinny być udostępniane poprzez ustawienia aplikacji, odwołania do usługi Key Vault lub funkcje odwołań do usługi App Configuration.

Po przeniesieniu wszystkich elementów z dowolnego istniejącego FunctionsStartup do pliku Program.cs można usunąć atrybut i klasę FunctionsStartup , do której został zastosowany.

plik local.settings.json

Plik local.settings.json jest używany tylko w przypadku uruchamiania lokalnego. Aby uzyskać informacje, zobacz Plik ustawień lokalnych.

Podczas migracji do wersji 4.x upewnij się, że plik local.settings.json zawiera co najmniej następujące elementy:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

Uwaga

Podczas migracji z uruchamiania w procesie wewnętrznym do uruchamiania w wyizolowanym procesie pracownika, należy zmienić wartość FUNCTIONS_WORKER_RUNTIME na "dotnet-isolated".

plik host.json

Do pliku host.json nie są wymagane żadne zmiany. Jednak jeśli konfiguracja usługi Application Insights w tym pliku pochodzi z projektu modelu przetwarzania, możesz chcieć wprowadzić inne zmiany w pliku Program.cs. Plik host.json steruje tylko rejestrowaniem ze środowiska uruchomieniowego hosta usługi Functions, a w modelu izolowanego procesu roboczego niektóre z tych dzienników pochodzą bezpośrednio z aplikacji, co zapewnia większą kontrolę. Aby uzyskać szczegółowe informacje na temat filtrowania tych dzienników, zobacz Zarządzanie poziomami dzienników w izolowanym modelu procesu roboczego.

Zmiany nazwy klasy

Niektóre klasy kluczy zmieniły nazwy między wersjami. Te zmiany są wynikiem zmian w interfejsach API platformy .NET lub różnic między procesem wewnętrznym a izolowanym procesem roboczym. W poniższej tabeli przedstawiono kluczowe klasy platformy .NET używane przez funkcje, które mogą ulec zmianie podczas migracji:

.NET Core 3.1 .NET 5 .NET 8
FunctionName (atrybut) Function (atrybut) Function (atrybut)
ILogger ILogger ILogger, ILogger<T>
HttpRequest HttpRequestData HttpRequestData, HttpRequest (przy użyciu integracji z platformą ASP.NET Core)
IActionResult HttpResponseData HttpResponseData, IActionResult (przy użyciu integracji z platformą ASP.NET Core)
FunctionsStartup (atrybut) Zamiast tego używa Program.cs Zamiast tego używa Program.cs

Mogą również występować różnice nazw klas w wiązaniach. Aby uzyskać więcej informacji, zobacz artykuły referencyjne dotyczące określonych powiązań.

Inne zmiany kodu

W tej sekcji wyróżniono inne zmiany kodu, które należy wziąć pod uwagę podczas pracy z migracją. Te zmiany nie są wymagane przez wszystkie aplikacje, ale należy ocenić, czy istnieją odpowiednie dla Twoich scenariuszy. Pamiętaj, aby sprawdzić zmiany powodujące niekompatybilność między wersjami 3.x i 4.x oraz inne zmiany, które mogą być konieczne do wprowadzenia w projekcie.

Serializacja JSON

Domyślnie izolowany model procesu roboczego używa System.Text.Json do serializacji JSON. Aby dostosować opcje serializatora lub przełączyć się na JSON.NET (Newtonsoft.Json), zobacz Dostosowywanie serializacji JSON.

Poziomy dzienników i filtrowanie usługi Application Insights

Dzienniki można wysyłać do usługi Application Insights zarówno ze środowiska uruchomieniowego hosta usługi Functions, jak i kodu w projekcie. host.jsonumożliwia konfigurowanie reguł rejestrowania hostów, ale w celu kontrolowania dzienników pochodzących z kodu należy skonfigurować reguły filtrowania w ramach Program.cs. Aby uzyskać szczegółowe informacje na temat filtrowania tych dzienników, zobacz Zarządzanie poziomami dzienników w izolowanym modelu procesu roboczego.

Szablon wyzwalacza HTTP

Różnice między procesem wewnętrznym a izolowanym procesem roboczym można zobaczyć w funkcjach wyzwalanych przez protokół HTTP. Szablon wyzwalacza HTTP dla wersji 3.x (w procesie) wygląda następująco:

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);
        }
    }
}

Szablon wyzwalacza HTTP dla zmigrowanej wersji wygląda następująco:

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"]}!");
        }
    }
}

Aby zaktualizować projekt do usługi Azure Functions 4.x:

  1. Zaktualizuj lokalną instalację narzędzi Azure Functions Core Tools do wersji 4.x.

  2. Zaktualizuj pakiet rozszerzeń usługi Azure Functions aplikacji do wersji 2.x lub nowszej. Aby uzyskać więcej informacji, zobacz Zmiany powodujące niezgodność.

  1. W razie potrzeby przejdź do jednej z wersji java obsługiwanych w wersji 4.x.

  2. Zaktualizuj plik aplikacji POM.xml, aby zmodyfikować FUNCTIONS_EXTENSION_VERSION ustawienie na ~4, tak jak w poniższym przykładzie:

    <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>
  1. W razie potrzeby przejdź do jednej z wersji Node.js obsługiwanych w wersji 4.x.
  1. Skorzystaj z tej okazji, aby przeprowadzić uaktualnienie do programu PowerShell 7.2, co jest zalecane. Aby uzyskać więcej informacji, zobacz Wersje programu PowerShell.
  1. Jeśli używasz języka Python 3.6, przejdź do jednej z obsługiwanych wersji.

Uruchamianie modułu sprawdzania poprawności przed uaktualnieniem

Usługa Azure Functions udostępnia moduł sprawdzania poprawności przed uaktualnieniem, który pomaga zidentyfikować potencjalne problemy podczas migracji aplikacji funkcji do wersji 4.x. Aby uruchomić moduł sprawdzania poprawności przed uaktualnieniem:

  1. W portalu Azure przejdź do aplikacji funkcyjnej.

  2. Otwórz stronę Diagnozowanie i rozwiązywanie problemów.

  3. W Diagnostyce aplikacji funkcji zacznij wpisywać Functions 4.x Pre-Upgrade Validator, a następnie wybierz ją z listy.

  4. Po zakończeniu walidacji przejrzyj zalecenia i rozwiąż wszelkie problemy w aplikacji. Jeśli musisz wprowadzić zmiany w aplikacji, sprawdź poprawność zmian w wersji 4.x środowiska uruchomieniowego Functions lokalnie przy użyciu narzędzi Azure Functions Core Tools w wersji 4, lub korzystając z miejsca przejściowego.

Zaktualizuj swoją aplikację funkcji na platformie Azure

Przed opublikowaniem zmigrowanego projektu należy zaktualizować środowisko uruchomieniowe hosta aplikacji funkcji na platformie Azure do wersji 4.x. Wersja środowiska uruchomieniowego używana przez hosta usługi Functions jest kontrolowana przez FUNCTIONS_EXTENSION_VERSION ustawienie aplikacji, ale w niektórych przypadkach należy również zaktualizować inne ustawienia. Zmiany kodu i zmiany ustawień aplikacji wymagają ponownego uruchomienia aplikacji funkcji.

Najprostszym sposobem jest zaktualizowanie aplikacji bez slotów i ponowne opublikowanie projektu aplikacji. Możesz również zminimalizować przestój w aplikacji i uprościć wycofywanie, aktualizując przy użyciu slotów.

Aktualizacja bez przedziałów

Najprostszym sposobem aktualizacji do wersji 4.x jest skonfigurowanie ustawienia aplikacji FUNCTIONS_EXTENSION_VERSION na ~4 w aplikacji funkcji na platformie Azure. Musisz wykonać inną procedurę w miejscu z gniazdami.

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

Należy również ustawić inne ustawienie, które różni się między systemami Windows i Linux.

W systemie Windows należy również włączyć platformę .NET 8.0, która jest wymagana przez wersję 4.x środowiska uruchomieniowego.

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

Platforma .NET 6 jest wymagana w przypadku aplikacji funkcji w dowolnym języku uruchomionym w systemie Windows.

W tym przykładzie zastąp <APP_NAME> nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów.

Teraz możesz ponownie opublikować projekt aplikacji, który został zmigrowany do uruchomienia w wersji 4.x.

Aktualizowanie przy użyciu slotów

Użycie gniazd wdrożeniowych to dobry sposób na aktualizację aplikacji funkcji do wersji środowiska uruchomieniowego 4.x z wcześniejszej wersji. Korzystając z trybu przejściowego, możesz uruchomić swoją aplikację w nowej wersji środowiska uruchomieniowego i przełączyć się do środowiska produkcyjnego po weryfikacji. Sloty również zapewniają sposób na zminimalizowanie przestojów podczas aktualizacji. Jeśli musisz zminimalizować przestój, wykonaj kroki opisane w temacie Minimalna aktualizacja przestoju.

Po zweryfikowaniu aplikacji w zaktualizowanym slocie, możesz zamienić aplikację i ustawienia nowej wersji na środowisko produkcyjne. Ta zamiana wymaga ustawienia WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w slocie produkcyjnym. Sposób dodawania tego ustawienia wpływa na ilość przestojów wymaganych do aktualizacji.

Standardowa aktualizacja

Jeśli aplikacja funkcji z włączoną obsługą miejsca może obsługiwać przestój pełnego ponownego uruchamiania, możesz zaktualizować WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS ustawienie bezpośrednio w miejscu produkcyjnym. Ponieważ zmiana tego ustawienia bezpośrednio w miejscu produkcyjnym powoduje ponowne uruchomienie, które ma wpływ na dostępność, rozważ wykonanie tej zmiany w czasie ograniczonego ruchu. Następnie możesz zamienić zaktualizowaną wersję ze slotu przejściowego.

Polecenie Update-AzFunctionAppSetting cmdlet programu PowerShell nie obsługuje obecnie miejsc. Musisz użyć interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal.

  1. Użyj następującego polecenia, aby ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w slocie produkcyjnym.

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

    W tym przykładzie zastąp <APP_NAME> nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów. To polecenie powoduje ponowne uruchomienie aplikacji w miejscu produkcyjnym.

  2. Użyj następującego polecenia, aby również ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS w miejscu przejściowym:

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

  3. Użyj następującego polecenia, aby zmienić FUNCTIONS_EXTENSION_VERSION i zaktualizować miejsce przejściowe do nowej wersji środowiska uruchomieniowego:

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

  4. Wersja 4.x środowiska uruchomieniowego usługi Functions wymaga platformy .NET 6 w systemie Windows. W systemie Linux aplikacje platformy .NET muszą również zostać zaktualizowane do platformy .NET 6. Użyj następującego polecenia, aby środowisko uruchomieniowe było uruchamiane na platformie .NET 6:

    W systemie Windows należy również włączyć platformę .NET 8.0, która jest wymagana przez wersję 4.x środowiska uruchomieniowego.

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

    Platforma .NET 6 jest wymagana w przypadku aplikacji funkcji w dowolnym języku uruchomionym w systemie Windows.

    W tym przykładzie zastąp <APP_NAME> nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów.

  5. Jeśli projekt kodu wymaga aktualizacji do uruchomienia w wersji 4.x, wdróż te aktualizacje w miejscu przejściowym teraz.

  6. Przed przełączeniem upewnij się, że aplikacja funkcji działa poprawnie w zaktualizowanym środowisku przejściowym.

  7. Użyj następującego polecenia, aby przenieść aktualizowane gniazdo przejściowe do produkcji:

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

Aktualizacja minimalizująca przestoje

Aby zminimalizować przestój w aplikacji produkcyjnej, możesz przenieść ustawienia z slotu przejściowego do produkcji. Następnie można wprowadzić zaktualizowaną wersję z wstępnie przygotowanej strefy etapowej.

  1. Użyj następującego polecenia, aby ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w miejscu przejściowym:

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

  2. Użyj następujących poleceń, aby zamienić slot na nowe ustawienie w trybie produkcyjnym, a jednocześnie przywrócić ustawienie wersji w slocie przejściowym.

    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>

    Błędy z lokalnego środowiska testowego mogą wystąpić w czasie między zamianą a przywróceniem wersji środowiska uruchomieniowego dla lokalnego środowiska. Ten błąd może wystąpić, ponieważ gdy WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 występuje tylko w środowisku przejściowym podczas zamiany, usuwane jest ustawienie FUNCTIONS_EXTENSION_VERSION w tym środowisku. Bez ustawienia wersji, twoje gniazdo jest w złym stanie. Aktualizacja wersji w slocie tymczasowym bezpośrednio po zamianie powinna przywrócić slot do właściwego stanu, a w razie potrzeby możesz cofnąć swoje zmiany. Jednak każde wycofanie zamiany wymaga również bezpośredniego usunięcia WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 z środowiska produkcyjnego przed przywróceniem zamiany, aby zapobiec wystąpieniu tych samych błędów, które pojawiły się w środowisku przejściowym. Ta zmiana ustawienia produkcyjnego spowoduje ponowne uruchomienie.

  3. Użyj następującego polecenia, aby ponownie ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w miejscu przejściowym:

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

    W tym momencie oba gniazda mają ustawione WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0.

  4. Użyj następującego polecenia, aby zmienić FUNCTIONS_EXTENSION_VERSION i zaktualizować miejsce przejściowe do nowej wersji środowiska uruchomieniowego:

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

  5. Wersja 4.x środowiska uruchomieniowego usługi Functions wymaga platformy .NET 6 w systemie Windows. W systemie Linux aplikacje platformy .NET muszą również zostać zaktualizowane do platformy .NET 6. Użyj następującego polecenia, aby środowisko uruchomieniowe było uruchamiane na platformie .NET 6:

    W systemie Windows należy również włączyć platformę .NET 8.0, która jest wymagana przez wersję 4.x środowiska uruchomieniowego.

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

    Platforma .NET 6 jest wymagana w przypadku aplikacji funkcji w dowolnym języku uruchomionym w systemie Windows.

    W tym przykładzie zastąp <APP_NAME> nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów.

  6. Jeśli projekt kodu wymaga aktualizacji do uruchomienia w wersji 4.x, wdróż te aktualizacje w miejscu przejściowym teraz.

  7. Przed przełączeniem upewnij się, że aplikacja funkcji działa poprawnie w zaktualizowanym środowisku przejściowym.

  8. Użyj następującego polecenia, aby przełączyć zaktualizowaną i wstępnie podgrzaną szczelinę przejściową na środowisko produkcyjne.

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

Przełomowe zmiany między 3.x i 4.x

Poniżej przedstawiono kluczowe zmiany disruptywne, o których należy pamiętać przed uaktualnieniem aplikacji 3.x do wersji 4.x, w tym zmiany specyficzne dla języka. Aby uzyskać pełną listę, zobacz kwestie Azure Functions na GitHubie oznaczone etykietą Zmiana powodująca niezgodność: zatwierdzona.

Jeśli język programowania nie jest widoczny, wybierz go w górnej części strony.

Środowisko uruchomieniowe

  • Serwery proxy usługi Azure Functions były funkcją w wersjach od 1.x do 3.x środowiska uruchomieniowego usługi Azure Functions. Ta funkcja nie jest obsługiwana w wersji 4.x. Aby uzyskać więcej informacji, zobacz Bezserwerowe interfejsy API REST korzystające z usługi Azure Functions.

  • Rejestrowanie w usłudze Azure Storage przy użyciu narzędzia AzureWebJobsDashboard nie jest już obsługiwane w wersji 4.x. Zamiast tego należy użyć usługi Application Insights. (#1923)

  • Usługa Azure Functions 4.x wymusza teraz minimalne wymagania dotyczące wersji rozszerzeń. Zaktualizuj do najnowszej wersji rozszerzeń, których dotyczy problem. W przypadku języków innych niż .NET, zaktualizuj pakiet rozszerzeń do wersji 2.x lub nowszej. (#1987)

  • Domyślne i maksymalne limity czasu są teraz egzekwowane w wersji 4.x dla aplikacji funkcjonalnych działających na systemie Linux w Planie Konsumpcji. (#1915)

  • Usługa Azure Functions 4.x używa Azure.Identity i Azure.Security.KeyVault.Secrets dla dostawcy usługi Key Vault i wycofała korzystanie z usługi Microsoft.Azure.KeyVault. Aby uzyskać więcej informacji na temat konfigurowania ustawień aplikacji funkcji, zobacz opcję Key Vault w temacie Zarządzanie magazynem kluczy. (#2048)

  • Uruchomienie aplikacji funkcjonalnych, które współdzielą konta magazynu, jest teraz niemożliwe, gdy ich identyfikatory hostów są takie same. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące identyfikatora hosta. (#2049)

  • Usługa Azure Functions 4.x obsługuje nowsze wersje platformy .NET. Aby uzyskać pełną listę wersji, zobacz Obsługiwane języki w usłudze Azure Functions .

  • InvalidHostServicesException jest teraz błędem krytycznym. (#2045)

  • EnableEnhancedScopes jest domyślnie włączona. (#1954)

  • Usuń HttpClient jako zarejestrowaną usługę. (#1911)

  • Użyj modułu ładującego z jedną klasą w języku Java 11. (#1997)

  • Zatrzymaj ładowanie plików jar procesu roboczego w środowisku Java 8. (#1991)

  • Node.js w wersji 10 i 12 nie są obsługiwane w usłudze Azure Functions 4.x. (#1999)

  • Serializacja danych wyjściowych w aplikacjach Node.js została zaktualizowana w celu rozwiązania poprzednich niespójności. (#2007)

  • Zaktualizowano domyślną liczbę wątków. Mogą mieć to wpływ na funkcje, które nie są bezpieczne wątkowo lub mają duże użycie pamięci. (#1962)

  • Język Python 3.6 nie jest obsługiwany w usłudze Azure Functions 4.x. (#1999)

  • Transfer pamięci udostępnionej jest domyślnie włączony. (#1973)

  • Zaktualizowano domyślną liczbę wątków. Mogą mieć to wpływ na funkcje, które nie są bezpieczne wątkowo lub mają duże użycie pamięci. (#1962)

Następne kroki

Dowiedz się więcej o wersjach usługi Functions

  • Last updated on