Omówienie wersji środowiska uruchomieniowego Azure Functions

Azure Functions obecnie obsługuje kilka wersji hosta środowiska uruchomieniowego. Poniższa tabela zawiera szczegółowe informacje o dostępnych wersjach, ich poziomie pomocy technicznej oraz o tym, kiedy powinny być używane:

Wersja Poziom pomocy technicznej Opis
4.x Ogólna dostępność Zalecana wersja środowiska uruchomieniowego dla funkcji we wszystkich językach. Ta wersja służy do uruchamiania funkcji języka C# na platformie .NET 6.0 i .NET Framework 4.8.
3.x Ogólna dostępność Obsługuje wszystkie języki. Użyj tej wersji, aby uruchamiać funkcje języka C# na platformie .NET Core 3.1 i .NET 5.0.
2.x Ogólna dostępność Obsługiwane w przypadku starszych aplikacji w wersji 2.x. Ta wersja jest w trybie konserwacji z ulepszeniami dostępnymi tylko w nowszych wersjach.
1.x Ogólna dostępność Zalecane tylko w przypadku aplikacji w języku C#, które muszą używać .NET Framework i obsługują tylko programowanie w witrynie Azure Portal, portalu usługi Azure Stack Hub lub lokalnie na komputerach Windows. Ta wersja jest w trybie konserwacji z ulepszeniami dostępnymi tylko w nowszych wersjach.

Ważne

Począwszy od 3 grudnia 2022 r., aplikacje funkcji działające w wersjach 2.x i 3.x środowiska uruchomieniowego Azure Functions nie mogą być już obsługiwane. Przed upływem tego czasu przetestuj, zweryfikuj i przeprowadź migrację aplikacji funkcji do wersji 4.x środowiska uruchomieniowego usługi Functions. Zakończenie obsługi tych wersji środowiska uruchomieniowego jest spowodowane zakończeniem obsługi platformy .NET Core 3.1, która jest wymagana przez te wersje środowiska uruchomieniowego. To wymaganie ma wpływ na wszystkie języki środowiska uruchomieniowego Azure Functions.
Funkcje w wersji 1.x są nadal obsługiwane w przypadku aplikacji funkcji języka C#, które wymagają .NET Framework. Obsługa wersji zapoznawczej jest teraz dostępna w usłudze Functions 4.x, aby uruchamiać funkcje języka C# w .NET Framework 4.8.

W tym artykule opisano niektóre różnice między tymi wersjami, sposób tworzenia poszczególnych wersji oraz sposób zmiany wersji, w której działają funkcje.

Poziomy obsługi

Istnieją dwa poziomy obsługi:

  • Ogólnie dostępne (GA) — w pełni obsługiwane i zatwierdzone do użytku produkcyjnego.
  • Wersja zapoznawcza — nie jest jeszcze obsługiwana, ale oczekuje się, że w przyszłości osiągnie stan ogólnie dostępnej wersji.

Języki

Wszystkie funkcje w aplikacji funkcji muszą mieć ten sam język. Podczas tworzenia aplikacji wybrano język funkcji. Język aplikacji funkcji jest utrzymywany w ustawieniu FUNCTIONS_WORKER_RUNTIME i nie powinien być zmieniany, gdy istnieją funkcje.

Poniższa tabela wskazuje, które języki programowania są obecnie obsługiwane w każdej wersji środowiska uruchomieniowego.

Język 1.x 2.x 3.x 4.x
C# Ogólna dostępność (.NET Framework 4.8) Ogólna dostępność (.NET Core2.1 1) Ogólna dostępność (.NET Core 3.1)
Ogólna dostępność (.NET 5.0)
Ogólna dostępność (.NET 6.0)
Wersja zapoznawcza (.NET Framework 4.8)
JavaScript Ogólna dostępność (Node.js 6) Ogólna dostępność (Node.js 10 & 8) Ogólna dostępność (Node.js 14, 12, & 10) Ogólna dostępność (Node.js 14)
Ogólna dostępność (Node.js 16)
F# Ogólna dostępność (.NET Framework 4.8) Ogólna dostępność (.NET Core2.1 1) Ogólna dostępność (.NET Core 3.1) Ogólna dostępność (.NET 6.0)
Java Nie dotyczy Ogólna dostępność (Java 8) Ogólna dostępność (Java 11 & 8) Ogólna dostępność (Java 11 & 8)
Program PowerShell Nie dotyczy Ogólna dostępność (PowerShell Core 6) Ogólna dostępność (PowerShell 7.0 & Core 6) Ogólna dostępność (PowerShell 7.0)
Wersja zapoznawcza (PowerShell 7.2)
Python Nie dotyczy Ogólna dostępność (Python 3.7 & 3.6) Ogólna dostępność (Python 3.9, 3.8, 3.7, & 3.6) Ogólna dostępność (Python 3.9, 3.8, 3.7)
TypeScript2 Nie dotyczy Ogólna dostępność Ogólna dostępność Ogólna dostępność

1 Aplikacje biblioteki klas .NET przeznaczone dla środowiska uruchomieniowego w wersji 2.x działają na platformie .NET Core 3.1 w trybie zgodności platformy .NET Core 2.x. Aby dowiedzieć się więcej, zobacz Zagadnienia dotyczące funkcji w wersji 2.x.
2 Obsługiwane przez transpilowanie do języka JavaScript.

Aby uzyskać więcej informacji na temat obsługiwanych wersji językowych, zobacz artykuł przewodnik dla deweloperów specyficzny dla języka.
Aby uzyskać informacje o planowanych zmianach w obsłudze języka, zobacz Harmonogram działania platformy Azure.

Uruchamianie w określonej wersji

Domyślnie aplikacje funkcji utworzone w Azure Portal i za pomocą interfejsu wiersza polecenia platformy Azure są ustawione na wersję 4.x. W razie potrzeby możesz zmodyfikować tę wersję. Możesz obniżyć wersję środowiska uruchomieniowego tylko do wersji 1.x po utworzeniu aplikacji funkcji, ale przed dodaniem dowolnych funkcji. Przejście do nowszej wersji jest dozwolone nawet w przypadku aplikacji, które mają istniejące funkcje. Gdy aplikacja ma istniejące funkcje, należy pamiętać o wszelkich zmianach powodujących niezgodność między wersjami przed przejściem do nowszej wersji środowiska uruchomieniowego. W poniższych sekcjach szczegółowo opisano zmiany między wersjami:

Przed wprowadzeniem zmiany wersji głównej środowiska uruchomieniowego należy najpierw przetestować istniejący kod, wdrażając w innej aplikacji funkcji uruchomionej w najnowszej wersji głównej. Ten test pomaga upewnić się, że działa prawidłowo po uaktualnieniu. Kod można również zweryfikować lokalnie przy użyciu wersji środowiska uruchomieniowego Azure Functions Core Tools, która obejmuje środowisko uruchomieniowe usługi Functions.

Zmiany na starszą lub mniej zaawansowaną 2.x nie są obsługiwane. Jeśli to możliwe, zawsze należy uruchamiać aplikacje w najnowszej obsługiwanej wersji środowiska uruchomieniowego usługi Functions.

Zmiana wersji aplikacji na platformie Azure

Wersja środowiska uruchomieniowego usługi Functions używana przez opublikowane aplikacje na platformie Azure jest określana przez FUNCTIONS_EXTENSION_VERSION ustawienie aplikacji. Obsługiwane są następujące główne wartości wersji środowiska uruchomieniowego:

Wartość Cel środowiska uruchomieniowego
~4 4.x
~3 3.x
~2 2.x
~1 1.x

Ważne

Nie zmieniaj arbitralnie tego ustawienia aplikacji, ponieważ może być wymagane inne ustawienie aplikacji i zmiany kodu funkcji. Zamiast tego należy zmienić to ustawienie na karcie Ustawienia środowiska uruchomieniowego funkcjiw konfiguracji aplikacji funkcji w Azure Portal, gdy wszystko będzie gotowe do uaktualnienia wersji głównej.

Aby dowiedzieć się więcej, zobacz Jak określać docelowe wersje środowiska uruchomieniowego Azure Functions.

Przypinanie do określonej wersji pomocniczej

Aby rozwiązać problemy, które aplikacja funkcji mogła napotkać podczas uruchamiania w najnowszej wersji głównej, musisz tymczasowo przypiąć aplikację do określonej wersji pomocniczej. Zapewnia to czas na poprawne uruchomienie aplikacji w najnowszej wersji głównej. Sposób przypinania do wersji pomocniczej różni się między Windows a systemem Linux. Aby dowiedzieć się więcej, zobacz Jak określać docelowe wersje środowiska uruchomieniowego Azure Functions.

Starsze wersje pomocnicze są okresowo usuwane z usługi Functions. Najnowsze informacje o Azure Functions wydaniach, w tym o usunięciu określonych starszych wersji pomocniczych, monitoruj Azure App Service ogłoszenia.

Przypinanie do wersji ~2.0

Aplikacje funkcji platformy .NET działające w wersji 2.x (~2) są automatycznie uaktualniane do uruchamiania na platformie .NET Core 3.1, która jest długoterminową wersją pomocy technicznej platformy .NET Core 3. Uruchamianie funkcji .NET na platformie .NET Core 3.1 umożliwia korzystanie z najnowszych aktualizacji zabezpieczeń i ulepszeń produktów.

Każda przypięta ~2.0 aplikacja funkcji będzie nadal działać na platformie .NET Core 2.2, która nie otrzymuje już zabezpieczeń i innych aktualizacji. Aby dowiedzieć się więcej, zobacz Zagadnienia dotyczące usługi Functions w wersji 2.x.

Minimalne wersje rozszerzeń

Technicznie nie istnieje korelacja między wersjami rozszerzenia powiązania i wersją środowiska uruchomieniowego usługi Functions. Jednak począwszy od wersji 4.x środowisko uruchomieniowe usługi Functions wymusza minimalną wersję dla wszystkich rozszerzeń wyzwalacza i powiązań.

Jeśli zostanie wyświetlone ostrzeżenie o pakiecie, który nie spełnia minimalnej wymaganej wersji, należy zaktualizować ten pakiet NuGet do minimalnej wersji, jak zwykle. Minimalne wymagania dotyczące wersji rozszerzeń używanych w usłudze Functions w wersji 4.x można znaleźć w tym pliku konfiguracji.

W przypadku skryptu języka C# zaktualizuj odwołanie do pakietu rozszerzeń w pliku host.json w następujący sposób:

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

Technicznie nie istnieje korelacja między wersjami pakietu rozszerzeń a wersją środowiska uruchomieniowego usługi Functions. Jednak począwszy od wersji 4.x środowisko uruchomieniowe usługi Functions wymusza minimalną wersję pakietów rozszerzeń.

Jeśli zostanie wyświetlone ostrzeżenie o wersji pakietu rozszerzeń, które nie spełnia minimalnej wymaganej wersji, zaktualizuj istniejące odwołanie do pakietu rozszerzeń w pliku host.json w następujący sposób:

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

Aby dowiedzieć się więcej o pakietach rozszerzeń, zobacz Pakiety rozszerzeń.

Migrowanie z wersji 3.x do wersji 4.x

Azure Functions w wersji 4.x jest wysoce wstecznie zgodny z wersją 3.x. Wiele aplikacji powinno bezpiecznie uaktualnić do wersji 4.x bez znaczących zmian w kodzie. Pamiętaj, aby w pełni przetestować aplikację lokalnie przy użyciu wersji 4.x narzędzi Azure Functions Core Tools lub w miejscu przejściowym przed zmianą wersji głównej w aplikacjach produkcyjnych.

Uaktualnianie istniejącej aplikacji

Podczas lokalnego tworzenia aplikacji funkcji należy uaktualnić zarówno lokalne środowisko projektu, jak i aplikację funkcji działającą na platformie Azure.

Projekt lokalny

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

Aby zaktualizować aplikację biblioteki klas języka C# do platformy .NET 6 i Azure Functions 4.x, zaktualizuj elementy TargetFramework i AzureFunctionsVersion:

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

Należy również upewnić się, że odwołania do pakietów NuGet przez aplikację zostały zaktualizowane do najnowszych wersji. Aby uzyskać więcej informacji, zobacz zmiany powodujące niezgodność . Określone pakiety zależą od tego, czy funkcje działają w procesie, czy poza procesem.

Aby zaktualizować aplikację do wersji Azure Functions 4.x, zaktualizuj lokalną instalację narzędzi Azure Functions Core Tools do wersji 4.x i zaktualizuj pakiet rozszerzeń Azure Functions aplikacji do wersji 2.x lub nowszej. Aby uzyskać więcej informacji, zobacz zmiany powodujące niezgodność .

Uwaga

Node.js 10 i 12 nie są obsługiwane w Azure Functions 4.x.

Uwaga

Program PowerShell 6 nie jest obsługiwany w Azure Functions 4.x.

Uwaga

Język Python 3.6 nie jest obsługiwany w wersji Azure Functions 4.x.

Azure

Moduł sprawdzania poprawności przed uaktualnieniem jest dostępny, aby ułatwić identyfikowanie potencjalnych problemów podczas migrowania aplikacji funkcji do wersji 4.x. Przed przeprowadzeniem migracji istniejącej aplikacji wykonaj następujące kroki, aby uruchomić moduł sprawdzania poprawności:

  1. W Azure Portal przejdź do aplikacji funkcji

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

  3. W obszarze Wyszukaj typowe problemy lub narzędzia wprowadź i wybierz pozycję Moduł sprawdzania poprawności przed uaktualnieniem funkcji 4.x

Po sprawdzeniu, czy można uaktualnić aplikację, możesz rozpocząć proces migracji. Zapoznaj się z podsekcjami poniżej, aby uzyskać instrukcje dotyczące migracji bez miejsc i migracji z miejscami.

Uwaga

Jeśli używasz miejsca do zarządzania migracją, musisz ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS ustawienie aplikacji na "0" w obu miejscach. Dzięki temu zmiany wersji wprowadzone w operacji zamiany miejsca zostaną uwzględnione. Następnie możesz uaktualnić miejsce przejściowe (nieprodukcyjne), a następnie wykonać zamianę.

Aby przeprowadzić migrację aplikacji z wersji 3.x do wersji 4.x, wykonasz:

  • FUNCTIONS_EXTENSION_VERSION Ustaw ustawienie aplikacji na~4
  • Tylko w przypadku aplikacji funkcji Windows włącz platformę .NET 6.0 za pomocą netFrameworkVersion ustawienia
Migracja bez miejsc

Aby wykonać to uaktualnienie bezpośrednio w witrynie bez miejsc, możesz użyć następującego interfejsu wiersza polecenia platformy Azure lub Azure PowerShell polecenia:

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

# For Windows function apps only, also enable .NET 6.0 that is needed by the runtime
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
Migracja z miejscami

Aby wykonać to uaktualnienie przy użyciu miejsc wdrożenia, możesz użyć następujących poleceń interfejsu wiersza polecenia platformy Azure:

Najpierw zaktualizuj miejsce produkcyjne przy użyciu polecenia WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0. Jeśli aplikacja może tolerować ponowne uruchomienie (co ma wpływ na dostępność), zaleca się zaktualizowanie ustawienia bezpośrednio w miejscu produkcyjnym, prawdopodobnie w czasie mniejszego ruchu. Jeśli zamiast tego zdecydujesz się zamienić to ustawienie na miejsce, należy natychmiast zaktualizować miejsce przejściowe po zamianie. Konsekwencją zamiany tylko wtedy, gdy tylko WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 przejściowe jest to, że usunie FUNCTIONS_EXTENSION_VERSION ustawienie w środowisku przejściowym, umieszczając miejsce w złym stanie. Aktualizacja miejsca przejściowego z wersją bezpośrednio po zamianie umożliwia wycofanie zmian w razie potrzeby. Jednak w takiej sytuacji należy nadal przygotować się do bezpośredniej aktualizacji ustawień w środowisku produkcyjnym, aby usunąć WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 je przed zamianą.

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

# OR

# Alternatively get production prepared with WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS via a swap
az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
# The swap actions should be accompanied with a version specification for the slot. You may see errors from staging during the time between these actions.
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>

Po skonfigurowaniu miejsca WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 produkcyjnego można skonfigurować wszystkie inne elementy w miejscu przejściowym, a następnie zamienić:

# Get staging configured with 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>
# Get staging configured with the new extension version
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
# For Windows function apps only, also enable .NET 6.0 that is needed by the runtime
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

# Be sure to confirm that your staging environment is working as expected before swapping.

# Swap to migrate production to the new version
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production

Zmiany powodujące niezgodność między wersjami 3.x i 4.x

Poniżej przedstawiono pewne zmiany, o których należy pamiętać przed uaktualnieniem aplikacji 3.x do wersji 4.x. Aby uzyskać pełną listę, zobacz Azure Functions GitHub problemy z etykietą Zmiana powodująca niezgodność: zatwierdzone. W okresie obowiązywania wersji zapoznawczej oczekuje się większej liczby zmian. Zasubskrybuj App Service ogłoszenia dotyczące aktualizacji.

Środowisko uruchomieniowe

  • serwery proxy Azure Functions nie są już obsługiwane w wersji 4.x. Zaleca się korzystanie z usługi Azure API Management.

  • Rejestrowanie na platformie Azure Storage przy użyciu narzędzia AzureWebJobsDashboard nie jest już obsługiwane w wersji 4.x. Zamiast tego należy użyć Szczegółowe informacje aplikacji. (#1923)

  • Azure Functions 4.x wymusza teraz minimalne wymagania dotyczące wersji rozszerzeń. Uaktualnij do najnowszej wersji rozszerzeń, których dotyczy problem. W przypadku języków non-.NET uaktualnij pakiet do rozszerzenia w wersji 2.x lub nowszej. (#1987)

  • Domyślne i maksymalne limity czasu są teraz wymuszane w wersji 4.x dla aplikacji funkcji działającej w systemie Linux w planie Zużycie. (#1915)

  • Azure Functions 4.x używa Azure.Identity i Azure.Security.KeyVault.Secrets dla dostawcy Key Vault i wycofał się z korzystania z programu Microsoft.Azure.KeyVault. Aby uzyskać więcej informacji na temat konfigurowania ustawień aplikacji funkcji, zobacz opcję Key Vault w repozytoriach wpisów tajnych. (#2048)

  • Aplikacje funkcji, które współużytkują konta magazynu, nie mogą teraz uruchamiać się, gdy ich identyfikatory hostów są takie same. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące identyfikatora hosta. (#2049)

  • Azure Functions 4.x obsługuje aplikacje procesowe i izolowane platformy .NET 6.

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

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

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

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

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

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

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

  • Program PowerShell 6 nie jest obsługiwany w Azure Functions 4.x. (#1999)

  • 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 wersji 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)

Migrowanie z wersji 2.x do 3.x

Azure Functions wersja 3.x jest wysoce zgodna z poprzednimi wersjami do wersji 2.x. Wiele aplikacji może bezpiecznie uaktualnić do wersji 3.x bez żadnych zmian w kodzie. Podczas przechodzenia do wersji 3.x zaleca się uruchamianie rozbudowanych testów przed zmianą wersji głównej w aplikacjach produkcyjnych.

Zmiany powodujące niezgodność między wersjami 2.x i 3.x

Poniżej przedstawiono zmiany specyficzne dla języka, o których należy pamiętać przed uaktualnieniem aplikacji 2.x do wersji 3.x.

Główne różnice między wersjami podczas uruchamiania funkcji biblioteki klas platformy .NET to środowisko uruchomieniowe platformy .NET Core. Usługa Functions w wersji 2.x została zaprojektowana do uruchamiania na platformie .NET Core 2.2 i wersji 3.x jest przeznaczona do uruchamiania na platformie .NET Core 3.1.

Uwaga

Ze względu na problemy z obsługą platformy .NET Core 2.2 aplikacje funkcji przypięte do wersji 2 (~2) są zasadniczo uruchomione na platformie .NET Core 3.1. Aby dowiedzieć się więcej, zobacz Tryb zgodności usługi Functions w wersji 2.x.

  • Powiązania wyjściowe przypisane przez 1.x context.done lub zwracane wartości zachowują się teraz tak samo jak ustawienie w wersji 2.x+ context.bindings.

  • Obiekt wyzwalacza czasomierza jest camelCase zamiast PascalCase

  • Funkcje wyzwalane przez centrum zdarzeń z dataType użyciem pliku binarnego otrzymają tablicę binary zamiast string.

  • Do ładunku żądania HTTP nie można już uzyskać dostępu za pośrednictwem polecenia context.bindingData.req. Nadal można uzyskać do niego dostęp jako parametr wejściowy , context.reqi w pliku context.bindings.

  • Node.js 8 nie jest już obsługiwana i nie będzie wykonywana w funkcjach 3.x.

Migrowanie z wersji 1.x do nowszych wersji

Możesz zdecydować się na migrację istniejącej aplikacji napisanej do korzystania ze środowiska uruchomieniowego w wersji 1.x, aby zamiast tego używać nowszej wersji. Większość zmian, które należy wprowadzić, jest związana ze zmianami w środowisku uruchomieniowym języka, takimi jak zmiany interfejsu API języka C#między .NET Framework 4.8 i .NET Core. Musisz również upewnić się, że kod i biblioteki są zgodne ze wybranym środowiskiem uruchomieniowym języka. Na koniec pamiętaj, aby zanotować wszelkie zmiany w wyzwalaczu, powiązaniach i funkcjach wyróżnionych poniżej. Aby uzyskać najlepsze wyniki migracji, należy utworzyć nową aplikację funkcji w nowej wersji i przełożyć istniejący kod funkcji w wersji 1.x do nowej aplikacji.

Chociaż można przeprowadzić uaktualnienie "w miejscu", ręcznie aktualizując konfigurację aplikacji, przechodząc z wersji 1.x do nowszej, obejmuje pewne zmiany powodujące niezgodność. Na przykład w języku C#obiekt debugowania jest zmieniany z TraceWriter na ILogger. Tworząc nowy projekt w wersji 3.x, zaczynasz od zaktualizowanych funkcji w oparciu o najnowsze szablony w wersji 3.x.

Zmiany w wyzwalaczach i powiązaniach po wersji 1.x

Począwszy od wersji 2.x, należy zainstalować rozszerzenia dla określonych wyzwalaczy i powiązań używanych przez funkcje w aplikacji. Jedynym wyjątkiem dla tych wyzwalaczy HTTP i czasomierza, które nie wymagają rozszerzenia. Aby uzyskać więcej informacji, zobacz Rejestrowanie i instalowanie rozszerzeń powiązań.

Istnieje również kilka zmian w pliku function.json lub atrybutach funkcji między wersjami. Na przykład właściwość Event Hubs path ma teraz eventHubNamewartość . Zobacz istniejącą tabelę powiązań , aby uzyskać linki do dokumentacji dla każdego powiązania.

Zmiany w funkcjach i funkcjach po wersji 1.x

Kilka funkcji zostało usuniętych, zaktualizowanych lub zastąpionych po wersji 1.x. Ta sekcja zawiera szczegółowe informacje o zmianach widocznych w nowszych wersjach po użyciu wersji 1.x.

W wersji 2.x wprowadzono następujące zmiany:

  • Klucze do wywoływania punktów końcowych HTTP są zawsze przechowywane zaszyfrowane w usłudze Azure Blob Storage. W wersji 1.x klucze były domyślnie przechowywane w Azure Files. Podczas uaktualniania aplikacji z wersji 1.x do wersji 2.x istniejące wpisy tajne, które znajdują się w Azure Files są resetowane.

  • Środowisko uruchomieniowe w wersji 2.x nie obejmuje wbudowanej obsługi dostawców elementów webhook. Ta zmiana została wprowadzona w celu zwiększenia wydajności. Nadal można używać wyzwalaczy HTTP jako punktów końcowych dla elementów webhook.

  • Plik konfiguracji hosta (host.json) powinien być pusty lub mieć ciąg "version": "2.0".

  • Aby poprawić monitorowanie, pulpit nawigacyjny zadań WebJobs w portalu, który używał AzureWebJobsDashboard ustawienia, został zastąpiony aplikacja systemu Azure Szczegółowe informacje, który używa APPINSIGHTS_INSTRUMENTATIONKEY ustawienia. Aby uzyskać więcej informacji, zobacz Monitorowanie Azure Functions.

  • Wszystkie funkcje w aplikacji funkcji muszą mieć ten sam język. Podczas tworzenia aplikacji funkcji musisz wybrać stos środowiska uruchomieniowego dla aplikacji. Stos środowiska uruchomieniowego jest określany przez FUNCTIONS_WORKER_RUNTIME wartość w ustawieniach aplikacji. To wymaganie zostało dodane w celu zwiększenia rozmiaru i czasu uruchamiania. Podczas tworzenia aplikacji lokalnie należy również uwzględnić to ustawienie w pliku local.settings.json.

  • Domyślny limit czasu funkcji w planie App Service jest zmieniany na 30 minut. Możesz ręcznie zmienić limit czasu z powrotem na nieograniczony przy użyciu ustawienia functionTimeout w pliku host.json.

  • Ograniczenia współbieżności HTTP są domyślnie implementowane dla funkcji planu Zużycie, z domyślnym 100 współbieżnymi żądaniami na wystąpienie. Można to zmienić w ustawieniu maxConcurrentRequests w pliku host.json.

  • Ze względu na ograniczenia platformy .NET Core obsługa funkcji skryptów języka F# (.fsx plików) została usunięta. Skompilowane funkcje języka F# (.fs) są nadal obsługiwane.

  • Format adresu URL elementów webhook wyzwalacza usługi Event Grid został zmieniony w taki sposób, aby był następujący: https://{app}/runtime/webhooks/{triggerName}.

Wersje aplikacji opracowane lokalnie

Możesz wprowadzić następujące aktualizacje w aplikacjach funkcji, aby lokalnie zmienić wersje docelowe.

wersje środowiska uruchomieniowego Visual Studio

W Visual Studio wybierasz wersję środowiska uruchomieniowego podczas tworzenia projektu. Azure Functions narzędzia dla Visual Studio obsługują trzy główne wersje środowiska uruchomieniowego. Poprawna wersja jest używana podczas debugowania i publikowania na podstawie ustawień projektu. Ustawienia wersji są zdefiniowane w .csproj pliku w następujących właściwościach:

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

Możesz również wybrać net6.0 strukturę docelową lub net48 jako platformę docelową, jeśli używasz funkcji procesu izolowanego platformy .NET. net48 Obsługa programu jest obecnie dostępna w wersji zapoznawczej.

Uwaga

Azure Functions 4.x wymaga, aby Microsoft.NET.Sdk.Functions rozszerzenie było co najmniej 4.0.0.

Aktualizowanie aplikacji 2.x do wersji 3.x w Visual Studio

Możesz otworzyć istniejącą funkcję przeznaczoną dla wersji 2.x i przejść do wersji 3.x, edytując .csproj plik i aktualizując powyższe wartości. Visual Studio automatycznie zarządza wersjami środowiska uruchomieniowego na podstawie metadanych projektu. Jednak istnieje możliwość, jeśli nigdy wcześniej nie utworzono aplikacji 3.x, Visual Studio nie ma jeszcze szablonów i środowiska uruchomieniowego dla wersji 3.x na maszynie. Może to spowodować wystąpienie błędu, takiego jak "brak dostępnego środowiska uruchomieniowego usługi Functions zgodnego z wersją określoną w projekcie". Aby pobrać najnowsze szablony i środowisko uruchomieniowe, zapoznaj się ze środowiskiem tworzenia nowego projektu funkcji. Po wybraniu wersji i szablonu poczekaj, aż Visual Studio ukończyć pobieranie najnowszych szablonów. Po udostępnieniu i wyświetleniu najnowszych szablonów platformy .NET Core 3 można uruchomić i debugować dowolny projekt skonfigurowany dla wersji 3.x.

Ważne

Funkcje w wersji 3.x można opracowywać tylko w Visual Studio, jeśli używasz Visual Studio w wersji 16.4 lub nowszej.

narzędzia VS Code i Azure Functions Core Tools

Azure Functions Core Tools służy do programowania w wierszu polecenia, a także przez rozszerzenie Azure Functions dla Visual Studio Code. Aby programować w wersji 3.x, zainstaluj wersję 3.x narzędzi Core Tools. Programowanie w wersji 2.x wymaga wersji 2.x narzędzi Core Tools itd. Aby uzyskać więcej informacji, zobacz Instalowanie narzędzi Azure Functions Core Tools.

W przypadku Visual Studio Code programowania może być również konieczne zaktualizowanie ustawienia użytkownika, azureFunctions.projectRuntime aby był zgodny z zainstalowaną wersją narzędzi. To ustawienie aktualizuje również szablony i języki używane podczas tworzenia aplikacji funkcji. Aby utworzyć aplikacje w programie ~3 , należy zaktualizować azureFunctions.projectRuntime ustawienie użytkownika na ~3.

Azure Functions extension runtime setting

Aplikacje Maven i Java

Aplikacje Java można migrować z wersji 2.x do wersji 3.x, instalując wersję 3.x podstawowych narzędzi wymaganych do uruchamiania lokalnie. Po sprawdzeniu, czy aplikacja działa prawidłowo lokalnie w wersji 3.x, zaktualizuj plik aplikacji POM.xml , aby zmodyfikować FUNCTIONS_EXTENSION_VERSION ustawienie na ~3, 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>~3</value>
        </property>
    </appSettings>
</configuration>

Powiązania

Począwszy od wersji 2.x, środowisko uruchomieniowe korzysta z nowego modelu rozszerzalności powiązań , który oferuje następujące korzyści:

  • Obsługa rozszerzeń powiązań innych firm.

  • Oddzielenie środowiska uruchomieniowego i powiązań. Ta zmiana umożliwia niezależne przechowywanie wersji i wydawanie rozszerzeń powiązań. Możesz na przykład zdecydować się na uaktualnienie do wersji rozszerzenia, która opiera się na nowszej wersji bazowego zestawu SDK.

  • Lżejsze środowisko wykonawcze, w którym tylko powiązania używane są znane i ładowane przez środowisko uruchomieniowe.

Z wyjątkiem wyzwalaczy HTTP i czasomierza wszystkie powiązania muszą zostać jawnie dodane do projektu aplikacji funkcji lub zarejestrowane w portalu. Aby uzyskać więcej informacji, zobacz Rejestrowanie rozszerzeń powiązań.

W poniższej tabeli przedstawiono powiązania obsługiwane w każdej wersji środowiska uruchomieniowego.

W tej tabeli przedstawiono powiązania obsługiwane w głównych wersjach środowiska uruchomieniowego Azure Functions:

Typ 1.x 2.x i nowsze1 Wyzwalacz Dane wejściowe Dane wyjściowe
Blob Storage
Azure Cosmos DB
Azure SQL (wersja zapoznawcza)
Dapr3
Event Grid
Event Hubs
Elementy webhook PROTOKOŁU HTTP &
IoT Hub
Kafka2
Aplikacje mobilne
Notification Hubs
Queue Storage
RabbitMQ2
SendGrid
Service Bus
SignalR
Table Storage
Czasomierz
Twilio

1 Począwszy od środowiska uruchomieniowego w wersji 2.x, wszystkie powiązania z wyjątkiem protokołu HTTP i czasomierza muszą być zarejestrowane. Zobacz Rejestrowanie rozszerzeń powiązań.

2 Wyzwalacze nie są obsługiwane w planie Zużycie. Wymaga wyzwalaczy opartych na środowisku uruchomieniowym.

3 Obsługiwane tylko w przypadku platformy Kubernetes, IoT Edge i innych trybów hostowanych samodzielnie.

Limit czasu aplikacji funkcji

Limit czasu trwania aplikacji funkcji jest definiowany przez functionTimeout właściwość w pliku projektu host.json . W poniższej tabeli przedstawiono wartości domyślne i maksymalne (w minutach) dla określonych planów:

Planowanie Domyślny Maksimum1
Plan Zużycie 5 10
Plan Premium 302 Nieograniczona liczba
Dedykowany plan 302 Nieograniczona liczba

1 Niezależnie od ustawienia limitu czasu aplikacji funkcji, 230 sekund to maksymalny czas, przez który funkcja wyzwalana przez protokół HTTP może odpowiedzieć na żądanie. Wynika to z domyślnego limitu czasu bezczynności Azure Load Balancer. W przypadku dłuższych czasów przetwarzania rozważ użycie wzorca asynchronicznego Durable Functions lub odroczenie rzeczywistej pracy i zwrócenie natychmiastowej odpowiedzi.
2 Domyślny limit czasu dla wersji 1.x środowiska uruchomieniowego usługi Functions jest nieograniczony.

Następne kroki

Więcej informacji można znaleźć w następujących zasobach: