Udostępnij za pośrednictwem

Migrowanie aplikacji w języku C# z modelu wewnątrzprocesowego do izolowanego modelu roboczego

Ważne

Wsparcie dla modelu przetwarzania kończy się 10 listopada 2026 r. Zdecydowanie zalecamy przeprowadzenie migracji aplikacji do izolowanego modelu procesu roboczego, postępując zgodnie z instrukcjami w tym artykule.

Ten artykuł przeprowadzi Cię przez proces bezpiecznej migracji aplikacji funkcji platformy .NET z modelu w procesie do izolowanego modelu pracownika. Aby dowiedzieć się więcej o najważniejszych różnicach między tymi modelami, zobacz porównanie trybu wykonywania.

W tym przewodniku założono, że aplikacja działa w wersji 4.x środowiska uruchomieniowego usługi Functions. Jeśli nie, skorzystaj z poniższych przewodników, aby uaktualnić wersję hosta. Te przewodniki migracji wersji hosta ułatwiają również migrację do izolowanego modelu procesu roboczego podczas pracy z nimi.

Jeśli jest to obsługiwane, ten artykuł korzysta z ASP.NET Core integracji w izolowanym modelu procesu roboczego, co poprawia wydajność i udostępnia znany model programowania, gdy aplikacja korzysta z wyzwalaczy HTTP.

Identyfikowanie aplikacji funkcji do migracji

Użyj następującego skryptu Azure PowerShell, aby wygenerować listę aplikacji funkcji w twojej subskrypcji, które obecnie korzystają z modelu in-process.

Skrypt używa subskrypcji, którą Azure PowerShell jest obecnie skonfigurowany używać. Subskrypcję można zmienić, uruchamiając polecenie Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' i zastępując <YOUR SUBSCRIPTION ID> identyfikatorem subskrypcji, którą chcesz ocenić.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.Runtime -eq 'dotnet')
     {
          $AppInfo.Add($App.Name, $App.Runtime)
     }
}

$AppInfo

Wybierz docelową wersję platformy .NET

W wersji 4.x środowiska uruchomieniowego Functions aplikacja funkcji .NET jest przeznaczona do działania w środowisku .NET 6 lub .NET 8, gdy korzystasz z modelu wewnątrz procesowego.

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 Typ wydania oficjalnej polityki wsparcia .NET Model funkcji przetwarzania1,2
.NET 9 STS (koniec wsparcia 12 maja 2026 r.) Model izolowanego pracownika
.NET 8 LTS (koniec wsparcia 10 listopada 2026 r.) Model izolowanego pracownika
Model w toku2
.NET Framework 4.8 Zobacz zasady Model izolowanego pracownika

1 Model izolowanego procesu roboczego obsługuje wersje platformy .NET (Long Term Support) i Standard Term Support (STS) oraz .NET Framework. Model wewnętrzny obsługuje tylko wydania LTS platformy .NET, kończące się na wersji .NET 8. Aby zapoznać się z pełnym porównaniem funkcji i funkcjonalności między dwoma modelami, zobacz Różnice między procesem procesowym i izolowanym procesem roboczym .NET Azure Functions.

2 Wsparcie dla modelu w toku kończy się 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.

Napiwek

Zalecamy aktualizację do platformy .NET 8 w modelu izolowanej pracy. Zapewnia to szybką ścieżkę migracji do w pełni wydanej wersji z najdłuższym oknem pomocy technicznej platformy .NET.

Ten przewodnik nie przedstawia konkretnych przykładów dla platformy .NET 9. Jeśli musisz kierować się do tej wersji, możesz dostosować przykłady platformy .NET 8.

Przygotowanie do migracji

Przed przeprowadzeniem migracji aplikacji do izolowanego modelu procesu roboczego należy dokładnie przejrzeć zawartość tego przewodnika. Należy również zapoznać się z funkcjami izolowanego modelu roboczego oraz różnicami między dwoma modelami.

Aby przeprowadzić migrację aplikacji:

  1. Przeprowadź migrację projektu lokalnego do izolowanego modelu procesu roboczego, wykonując kroki opisane w artykule Migrowanie projektu lokalnego.
  2. Po przeprowadzeniu migracji projektu w pełni przetestuj aplikację lokalnie przy użyciu wersji 4.x narzędzi Azure Functions Core Tools.
  3. Zaktualizuj aplikację funkcji na platformie Azure do modelu izolowanego.

Migrowanie projektu lokalnego

W sekcji opisano różne zmiany, które należy wprowadzić w projekcie lokalnym, aby przenieść go do izolowanego modelu procesu roboczego. Niektóre kroki zmieniają się w oparciu o docelową wersję platformy .NET. Użyj zakładek, aby wybrać instrukcje pasujące do żądanej wersji.

Napiwek

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

Najpierw przekonwertuj plik projektu i zaktualizuj zależności. Kiedy to robisz, zobaczysz błędy kompilacji dla projektu. W kolejnych krokach wprowadzisz odpowiednie zmiany, aby usunąć te błędy.

Plik projektu

Poniższy przykład to plik projektu csproj , który używa platformy .NET 8 w wersji 4.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </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 izolowanym modelu procesu roboczego:

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 Microsoft.NET.Sdk.Functions do pakietu 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>

Zmiana struktury docelowej projektu może również wymagać zmian w częściach łańcucha narzędzi poza kodem projektu. Na przykład w programie VS Code może być konieczne zaktualizowanie azureFunctions.deploySubpath ustawienia rozszerzenia za pomocą ustawień użytkownika lub pliku .vscode/settings.json projektu. Sprawdź, czy nie ma zależności od wersji platformy, które mogą istnieć poza kodem projektu, na przykład w ramach kroków budowania lub potoku CI/CD.

Odwołania do pakietu

Podczas migracji do izolowanego modelu roboczego należy zmienić pakiety odwołań aplikacji.

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 w odwołaniach do pakietów
Wyzwalacz czasomierza Dodaj
Microsoft.Azure.Functions.Worker.Extensions.Timer
Powiązania przechowywania Zastąp
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ą
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Powiązania kolejki Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Powiązania tabel Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Tables
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Tables
Powiązania usługi Cosmos DB Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.CosmosDB
i/lub
Microsoft.Azure.WebJobs.Extensions.DocumentDB
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Powiązania z usługą Service Bus Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.ServiceBus
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Powiązania usługi Event Hubs Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.EventHubs
z najnowszą wersją
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
Powiązania usługi SignalR Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.SignalRService
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Trwałe funkcje Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.DurableTask
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Trwałe funkcje
(Dostawca magazynu SQL)		 Zamień odwołania na
Microsoft.DurableTask.SqlServer.AzureFunctions
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Trwałe funkcje
(Dostawca magazynu Netherite)		 Zamień odwołania na
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Powiązania usługi SendGrid Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.SendGrid
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Powiązania platformy Kafka Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Kafka
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Powiązania/interfejsy RabbitMQ Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
z najnowszą wersją
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 niekompatybilne zmiany w strukturze między wersjami 4.x i 5.x. Aby uzyskać więcej szczegółowych informacji, zobacz Powiązania usługi Azure Service Bus dla usługi Azure Functions.

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

Napiwek

Aplikacja może również zależeć od typów zestawu Azure SDK w ramach wyzwalaczy i powiązań lub jako zależności autonomicznej. Należy skorzystać z tej okazji, aby je również zaktualizować. Najnowsze wersje rozszerzeń Functions współdziałają z najnowszymi wersjami Azure SDK dla platformy .NET, prawie wszystkich pakietów, które mają postać Azure.*.

plik Program.cs

Podczas migracji do uruchomienia w izolowanym procesie roboczym należy dodać plik Program.cs do projektu z następującą zawartością:

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, powinieneś stosować FrameworkReference w 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 jako część HostBuilder, mają podobne 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.

Zmiany podpisu funkcji

Niektóre kluczowe typy zmieniają się między modelem procesu a izolowanym modelem roboczym. Wiele z nich odnosi się do atrybutów, parametrów i zwracanych typów tworzących sygnaturę funkcji. Dla każdej funkcji należy wprowadzić zmiany w następujących celach:

  • Atrybut funkcji, który również ustawia nazwę funkcji
  • Jak funkcja uzyskuje element ILogger/ILogger<T>
  • Wyzwalanie i wiązanie atrybutów i parametrów

W pozostałej części tej sekcji przedstawiono poszczególne kroki.

Atrybuty funkcji

Atrybut Function w izolowanym modelu procesu roboczego zastępuje atrybut FunctionName. Nowy atrybut ma ten sam podpis, a jedyną różnicą jest nazwa. Można więc po prostu wykonać zamianę tekstu w całym projekcie.

Rejestrowanie danych

W modelu przetwarzania można dołączyć opcjonalny ILogger parametr funkcji lub użyć iniekcji zależności, aby uzyskać element ILogger<T>. Jeśli aplikacja już używała wstrzykiwania zależności, te same mechanizmy działają w izolowanym modelu roboczym.

Jednak w przypadku wszystkich funkcji, które opierały się na parametrze ILogger metody, należy wprowadzić zmianę. Zalecamy użycie wstrzykiwania zależności do uzyskania elementu ILogger<T>. Wykonaj następujące kroki, aby przeprowadzić migrację mechanizmu rejestrowania funkcji:

  1. W klasie funkcji dodaj private readonly ILogger<MyFunction> _logger; właściwość, zastępując MyFunction nazwą swojej klasy funkcji.

  2. Utwórz konstruktor dla klasy funkcji, który przyjmuje ILogger<T> parametr jako parametr:

    public MyFunction(ILogger<MyFunction> logger) {
    _logger = logger;
}

    Zastąp oba wystąpienia MyFunction w poprzednim fragmencie kodu nazwą klasy funkcji.

  3. W przypadku operacji rejestrowania w kodzie funkcji zastąp odwołania do parametru ILogger parametrem _logger.

  4. ILogger Usuń parametr z sygnatury funkcji.

Aby dowiedzieć się więcej, zobacz Rejestrowanie w modelu izolowanego procesu roboczego.

Wyzwalanie i wiązanie zmian

Po zmianie odwołań do pakietu w poprzednim kroku wprowadzono błędy wyzwalaczy i powiązań, które można teraz naprawić:

  1. Usuń wszystkie using Microsoft.Azure.WebJobs; deklaracje.

  2. Dodaj instrukcję using Microsoft.Azure.Functions.Worker; .

  3. Dla każdego atrybutu powiązania zmień nazwę atrybutu zgodnie z opisem w dokumentacji referencyjnej, którą można znaleźć w indeksie Obsługiwane powiązania . Ogólnie rzecz biorąc, nazwy atrybutów zmieniają się w następujący sposób:

    • Wyzwalacze zwykle pozostają nazwane w taki sam sposób. Na przykład QueueTrigger to nazwa atrybutu dla obu modeli.
    • Powiązania wejściowe zwykle wymagają dodania Input do nazwy. Jeśli na przykład użyto atrybutu powiązania wejściowego CosmosDB w modelu przetwarzania, atrybut będzie teraz .CosmosDBInput
    • Powiązania wyjściowe zwykle wymagają Output dodania do ich nazwy. Jeśli na przykład użyto atrybutu powiązania wyjściowego Queue w modelu przetwarzania, ten atrybut będzie teraz .QueueOutput

  4. Zaktualizuj parametry atrybutu, aby odzwierciedlały izolowane wersje modelu procesu roboczego, jak określono w dokumentacji referencyjnej powiązania.

    Na przykład w modelu przetwarzania danych wiązanie wyjściowe obiektu blob jest reprezentowane przez [Blob(...)] atrybut zawierający Access właściwość. W modelu izolowanego procesu roboczego atrybut wyjściowy obiektu blob to [BlobOutput(...)]. Powiązanie nie wymaga Access już właściwości, aby można było usunąć ten parametr. Więc [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] stałby się .[BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")]

  5. Przenieś powiązania wyjściowe z listy parametrów funkcji. Jeśli masz tylko jedno powiązanie wyjściowe, możesz zastosować je do zwracanego typu funkcji. Jeśli masz wiele danych wyjściowych, utwórz nową klasę z właściwościami dla poszczególnych danych wyjściowych i zastosuj atrybuty do tych właściwości. Aby dowiedzieć się więcej, zobacz Wiele powiązań wyjściowych.

  6. Zapoznaj się z dokumentacją referencyjną każdego powiązania, aby dowiedzieć się, do jakich typów można je przypisać. W niektórych przypadkach może być konieczne zmianę typu. W przypadku powiązań wyjściowych, jeśli wersja modelu w procesie używa elementu IAsyncCollector<T>, można zastąpić to powiązaniem do tablicy typu docelowego: T[]. Można również rozważyć zastąpienie powiązania wyjściowego obiektem klienta reprezentującym tę usługę, jako typ powiązania dla powiązania wejściowego, jeśli jest dostępne, lub samodzielnie wstrzykując klienta.

  7. Jeśli funkcja zawiera IBinder parametr, usuń go. Zastąp funkcjonalność obiektem klienta reprezentującym usługę, jako typ powiązania dla powiązania wejściowego, jeśli jest to możliwe, lub poprzez własnoręczne wstrzyknięcie klienta.

  8. Zaktualizuj kod funkcji, aby pracować z dowolnymi nowymi typami.

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 z uruchamiania procesu w procesie wyizolowanego procesu roboczego należy zmienić FUNCTIONS_WORKER_RUNTIME wartość na dotnet-isolated. Upewnij się, że plik local.settings.json zawiera co najmniej następujące elementy:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

Wartość, dla AzureWebJobsStorage której masz wartość, może być inna. Nie musisz zmieniać jej wartości w ramach migracji.

plik host.json

Do pliku host.json nie są wymagane żadne zmiany. Jeśli jednak konfiguracja usługi Application Insights znajduje się w tym pliku z projektu modelu przetwarzania, możesz wprowadzić dodatkowe zmiany w pliku Program.cs . Plik host.json steruje rejestrowaniem tylko 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.

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.

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 logów i filtrowanie w 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.

Przykładowe migracje funkcji

Przykład wyzwalacza HTTP

Wyzwalacz HTTP dla modelu przetwarzania może wyglądać podobnie do następującego przykładu:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Wyzwalacz HTTP dla zmigrowanej wersji może wyglądać podobnie do następującego przykładu:

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

Zaktualizuj swoją aplikację funkcji w Azure

Aktualizacja aplikacji funkcji do izolowanego modelu obejmuje dwie zmiany, które należy wykonać razem, ponieważ w przypadku ukończenia tylko jednej z nich aplikacja jest w stanie błędu. Obie te zmiany powodują również ponowne uruchomienie procesu aplikacji. Z tych powodów należy przeprowadzić aktualizację przy użyciu miejsca przejściowego. Miejsca przejściowe pomagają zminimalizować przestoje aplikacji i umożliwić testowanie i weryfikowanie zmigrowanego kodu przy użyciu zaktualizowanej konfiguracji na platformie Azure. Następnie możesz wdrożyć w pełni zmigrowany aplikację do miejsca produkcyjnego za pomocą operacji zamiany.

Ważne

Gdy wdrożony ładunek aplikacji nie jest zgodny ze skonfigurowanym środowiskiem uruchomieniowym, jest w stanie błędu. Podczas procesu migracji aplikacja jest umieszczana w tym stanie, najlepiej tylko tymczasowo. Miejsca wdrożenia pomagają ograniczyć efekt tego działania, ponieważ błąd zostanie naprawiony w środowisku przejściowym (nieprodukcyjnym), zanim zmiany zostaną zastosowane w postaci jednej aktualizacji w środowisku produkcyjnym. Sloty również chronią przed wszelkimi błędami i umożliwiają wykrywanie innych problemów przed dotarciem do produkcji.

W trakcie tego procesu mogą nadal występować błędy w logach pochodzących z slotu przygotowawczego (nieprodukcyjnego). To jest spodziewane, choć powinny ustąpić w miarę realizacji kolejnych kroków. Przed wykonaniem operacji zamiany slotów należy potwierdzić, że te błędy przestaną się pojawiać i że aplikacja działa zgodnie z oczekiwaniami.

Wykonaj następujące kroki, aby wykorzystać sloty wdrożeniowe, aby zaktualizować aplikację funkcjonalną do modelu izolowanego procesu roboczego.

  1. Utwórz miejsce wdrożenia, jeśli jeszcze tego nie zrobiono. Możesz również zapoznać się z procesem zamiany slotów i upewnić się, że jesteś w stanie wprowadzać aktualizacje do istniejącej aplikacji z minimalnymi zakłóceniami.

  2. Zmień konfigurację miejsca przeznaczonego na etapy przejściowe (nieprodukcyjnego), aby używać izolowanego modelu procesu roboczego, ustawiając FUNCTIONS_WORKER_RUNTIME jako ustawienie aplikacji na dotnet-isolated. FUNCTIONS_WORKER_RUNTIME nie powinno być oznaczone jako ustawienie gniazda.

    Jeśli jako część aktualizacji celem jest inna wersja platformy .NET, należy również zmienić konfigurację stosu. Aby to zrobić, zapoznaj się z Aktualizowaniem konfiguracji stosu. Możesz użyć tych samych instrukcji dotyczących wszelkich przyszłych aktualizacji wersji platformy .NET.

    Jeśli masz jakiekolwiek zautomatyzowane procesy tworzenia infrastruktury, takie jak potok CI/CD, upewnij się, że automatyzacje są również aktualizowane, aby ustawić FUNCTIONS_WORKER_RUNTIME na dotnet-isolated i wybrać prawidłową wersję platformy .NET.

  3. Opublikuj zmigrowany projekt na wersję przejściową (nieprodukcyjną) swojej aplikacji funkcji.

    Jeśli używasz programu Visual Studio do publikowania izolowanego projektu modelu procesu roboczego w istniejącej aplikacji lub miejscu używającym modelu przetwarzania, może on również wykonać poprzedni krok w tym samym czasie. Jeśli poprzedni krok nie został ukończony, program Visual Studio wyświetli monit o zaktualizowanie aplikacji funkcji podczas wdrażania. Program Visual Studio przedstawia to jako jedną operację, ale nadal są to dwie oddzielne operacje. Możesz nadal widzieć błędy w swoich dziennikach z slotu przejściowego (nieprodukcyjnego) w stanie przejściowym.

  4. Upewnij się, że aplikacja działa zgodnie z oczekiwaniami w miejscu przejściowym (nieprodukcyjnym).

  5. Wykonaj operację zamiany miejsca , aby zastosować zmiany wprowadzone w miejscu przejściowym (nieprodukcyjnym) do miejsca produkcyjnego. Zamiana slotów odbywa się jako pojedyncza aktualizacja, która pozwala uniknąć wprowadzenia tymczasowego stanu błędu w środowisku produkcyjnym.

  6. Upewnij się, że aplikacja działa zgodnie z oczekiwaniami w środowisku produkcyjnym.

Po wykonaniu tych kroków migracja zostanie ukończona, a aplikacja zostanie uruchomiona w modelu izolowanym. Gratulacje! Powtórz kroki opisane w tym przewodniku w razie potrzeby dla innych aplikacji, które wymagają migracji.

Następny krok

Dowiedz się więcej o izolowanym modelu procesu roboczego