Бөлісу құралы:

Перенос приложений из Функции Azure версии 1.x на версию 4.x

Внимание

Java не поддерживается версией 1.x среды выполнения Функции Azure. Возможно, вы вместо этого хотите перенести приложение Java с версии 3.x на версию 4.x. Если вы переносите приложение-функцию версии 1.x, выберите C# или JavaScript выше.

Внимание

TypeScript не поддерживается версией 1.x среды выполнения Функции Azure. Возможно, вы хотите перенести приложение TypeScript с версии 3.x на версию 4.x. Если вы переносите приложение-функцию версии 1.x, выберите C# или JavaScript выше.

Внимание

PowerShell не поддерживается версией 1.x среды выполнения Функции Azure. Возможно, вы хотите перенести приложение PowerShell с версии 3.x на версию 4.x. Если вы переносите приложение-функцию версии 1.x, выберите C# или JavaScript выше.

Внимание

Python не поддерживается версией 1.x среды выполнения Функции Azure. Возможно, вместо этого вы хотите перенести приложение Python с версии 3.x на версию 4.x. Если вы переносите приложение-функцию версии 1.x, выберите C# или JavaScript выше.

Внимание

Support будет завершен для версии 1.x среды выполнения Функции Azure 14 сентября 2026. Настоятельно рекомендуется перенести приложения в версию 4.x, следуя инструкциям в этой статье.

В этой статье описывается процесс безопасной миграции вашего функционального приложения для запуска в среде выполнения Функций версии 4.x. Так как инструкции по миграции проекта зависят от языка, обязательно выберите язык разработки из селектора в верхней части статьи.

Если вы используете версию 1.x среды выполнения в Azure Stack Hub, сначала ознакомьтесь с Рекомендациями для Azure Stack Hub.

Определение приложений-функций для миграции

Выполните следующий скрипт PowerShell в Azure Cloud Shell, чтобы создать список приложений-функций в подписке, предназначенных для текущей версии 1.x:

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     $AppSettings = Get-AzFunctionAppSetting -Name $App.Name -ResourceGroupName $App.ResourceGroupName
     if ($AppSettings.FUNCTIONS_EXTENSION_VERSION -like '*1*')
     {
          $AppInfo.Add($App.Name, $AppSettings.FUNCTIONS_EXTENSION_VERSION)
     }
}

$AppInfo

Если вы работаете за пределами Cloud Shell, необходимо сначала задать активную подписку:

$Subscription = '<SUBSCRIPTION_ID>' 

Set-AzContext -Subscription $Subscription | Out-Null

В этом примере замените "<SUBSCRIPTION_ID>" идентификатором подписки.

Выбор целевой версии .NET

В версии среды выполнения Functions 1.x ваше приложение на C# предназначено для .NET Framework.

При переносе приложения-функции у вас есть возможность выбрать целевую версию .NET. Проект C# можно обновить до одной из следующих версий .NET, поддерживаемых функциями версии 4.x:

версия .NET .NET официальная политика поддержки тип релиза Модельпроцесса функций 1,2
.NET 10 LTS (окончание поддержки 14 ноября 2028 г.) Изолированная рабочая модель
.NET 9 STS (окончание поддержки 10 ноября 2026 г.)3 Изолированная рабочая модель
.NET 8 LTS (окончание поддержки 10 ноября 2026 г.) Изолированная рабочая модель,
Модель в процессе2
.NET Framework 4.8 См. политику Изолированная рабочая модель

1 Модель изолированного рабочего поддерживает долгосрочные версии поддержки (LTS) и стандартные версии поддержки (STS) .NET, а также .NET Framework. Модель in-process поддерживает только выпуски LTS .NET, заканчивающиеся .NET 8. Для полного сравнения характеристик и функциональности двух моделей см. в разделе Differences between in-process and isolate worker process .NET Функции Azure.

2 Поддержка заканчивается для модели в процессе 10 ноября 2026 года. Дополнительные сведения см. в этом объявлении о поддержке. Для непрерывной поддержки следует перенести приложения в изолированную рабочую модель.

3 Ожидаемая дата окончания поддержки для .NET 9 ранее была 12 мая 2026 года. В течение периода обслуживания .NET 9 группа .NET расширила поддержку версий для длительной поддержки (STS) до 24 месяцев, включая .NET 9. Дополнительные сведения см. в записи блога.

Совет

Если приложение не зависит от библиотеки или API, доступной только для .NET Framework, рекомендуется обновить до .NET 8 в изолированной рабочей модели. Многие приложения на версии 1.x ориентируются только на .NET Framework, потому что это был единственный доступный вариант в момент их создания. Дополнительные возможности доступны для более поздних версий .NET, и если ваше приложение не вынуждено оставаться на .NET Framework из-за зависимости, следует нацелиться на более новую версию. .NET 8 — это полностью выпущенная версия с самым длинным окном поддержки из .NET.

Хотя можно выбрать модель внутри процесса, это не рекомендуется, если это возможно избежать. Поддержка будет завершена для модели в процессе 10 ноября 2026 года, поэтому перед этим вам потребуется перейти к изолированной рабочей модели. Это при миграции на версию 4.x уменьшит общие затраты усилий, а изолированная рабочая модель даст вашему приложению дополнительные преимущества, включая возможность более легко ориентироваться на будущие версии .NET. При переходе на модель изолированного рабочего процесса, .NET Upgrade Assistant также может выполнить многие необходимые изменения в коде.

В этом руководстве нет конкретных примеров для .NET 10 (предварительная версия) или .NET 9. Если вам нужно ориентироваться на одну из этих версий, можно адаптировать примеры .NET 8.

Подготовка к переносу

Если вы еще не сделали этого, определите список приложений, которые необходимо перенести в текущей подписке Azure с помощью Azure PowerShell.

Прежде чем перенести приложение в среду выполнения функций версии 4.x, выполните следующие задачи:

  1. Просмотрите список изменений поведения после версии 1.x. Миграция с версии 1.x на версию 4.x также может повлиять на привязки.
  2. Выполните действия, описанные в разделе "Миграция локального проекта", чтобы перенести локальный проект в версию 4.x.
  3. После переноса проекта полностью протестируйте приложение локально с помощью версии 4.x Функции Azure Core Tools.
  4. Обновите функциональное приложение в Azure до новой версии. Если необходимо свести к минимуму время простоя, рассмотрите возможность использования промежуточного слота для тестирования и проверки мигрированного приложения в Azure в новой версии среды выполнения. Затем можно развернуть приложение с обновленными параметрами версии в рабочем слоте. Для получения дополнительной информации см. раздел Обновление с помощью слотов.
  5. Опубликуйте перенесенный проект в обновленном приложении-функции.

При использовании Visual Studio для публикации проекта версии 4.x в существующем приложении-функции в более низкой версии вам будет предложено разрешить Visual Studio обновить приложение-функцию до версии 4.x во время развертывания. Это обновление использует тот же процесс, определенный в Обновлении без слотов.

Перенос локального проекта

В следующих разделах описаны обновления, которые необходимо внести в файлы проекта C#, чтобы иметь возможность выполняться в одной из поддерживаемых версий .NET в функциях версии 4.x. Отображаемые обновления являются общими для большинства проектов. Код проекта может требовать обновления, не упомянутые в этой статье, особенно при использовании пользовательских пакетов NuGet.

Перенос приложения-функции C# с версии 1.x на версию 4.x среды выполнения функций требует внесения изменений в код проекта. Многие из этих изменений являются результатом изменений на языке C# и .NET API.

Выберите вкладку, соответствующую целевой версии .NET, и нужную модель процесса (внутрипроцессный или изолированный рабочий процесс).

Совет

При переходе на версию LTS или STS .NET с помощью изолированной рабочей модели .NET помощник по обновлению можно использовать для автоматического внесения многих изменений, упомянутых в следующих разделах.

файл проекта

Следующий пример — файл проекта .csproj, работающий на версии 1.x.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v1</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Используйте одну из следующих процедур, чтобы обновить этот XML-файл для запуска в Функциях версии 4.x:

Эти шаги предполагают локальный проект C#. Если ваше приложение вместо этого использует скрипты C# (.csx файлы), вам следует преобразовать приложение в модель проекта перед продолжением.

В XML-файле проекта CSPROJ требуются следующие изменения:

  1. Задайте значение PropertyGroup. TargetFramework изменено на net8.0.

  2. Задайте значение PropertyGroup. AzureFunctionsVersion изменено на v4.

  3. Добавьте следующий OutputType элемент в :PropertyGroup

    <OutputType>Exe</OutputType>

  4. ItemGroup в.список PackageReference замените ссылку на пакет Майкрософт.NET.Sdk.Functions следующими ссылками:

      <FrameworkReference Include="Microsoft.AspNetCore.App" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
  <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
  <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />

    Запишите ссылки на другие пакеты в пространствах имен Майкрософт.Azure.WebJobs.*. Вы замените эти пакеты на следующем шаге.

  5. Добавьте новый элемент ItemGroup:

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

После внесения этих изменений обновленный проект должен выглядеть следующим образом:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

Изменения в структуре пакета и пространстве имен

На основе модели, в которую выполняется миграция, может потребоваться обновить или изменить пакеты, на которые ссылается приложение. При внедрении целевых пакетов необходимо обновить пространство имен инструкций using и некоторые типы, на которые вы ссылаетесь. Вы можете увидеть влияние этих изменений пространства имен на инструкции в примерах HTTP-триггера, представленных далее в статье.

Если вы еще не сделали этого, обновите проект, чтобы ссылаться на последние стабильные версии:

В зависимости от триггеров и привязок, которые использует приложение, может потребоваться ссылаться на другой набор пакетов. В следующей таблице показаны замены некоторых наиболее часто используемых расширений:

Сценарий Изменения ссылок на пакеты
Триггер таймера Добавить
Майкрософт.Azure. Functions.Worker.Extensions.Timer
Привязки для хранилища Заменить
Microsoft.Azure.WebJobs.Extensions.Storage
на
Майкрософт.Azure. Functions.Worker.Extensions.Storage.Blobs
Майкрософт.Azure.Functions.Worker.Extensions.Storage.Queues и
Майкрософт.Azure.Functions.Worker.Extensions.Tables
Привязки больших двоичных объектов Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.Storage.Blobs
Привязки очередей Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
с последней версией
Майкрософт.Azure.Functions.Worker.Extensions.Storage.Queues
Привязки таблиц Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.Tables
с последней версией
Майкрософт.Azure.Functions.Worker.Extensions.Tables
Привязки Cosmos DB Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.CosmosDB
и (или)
Microsoft.Azure.WebJobs.Extensions.DocumentDB
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.CosmosDB
привязки для служебная шина Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.ServiceBus
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.ServiceBus
Привязки к Центрам событий Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.EventHubs
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.EventHubs
Привязки сетки событий Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.EventGrid
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.EventGrid
привязки службы SignalR Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.SignalRService
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.SignalRService
Функции Durable Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.DurableTask
с последней версией
Майкрософт.Azure.Functions.Worker.Extensions.DurableTask
Устойчивые функции
(поставщик хранилища SQL)		 Замена ссылок на
Microsoft.DurableTask.SqlServer.AzureFunctions
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.DurableTask.SqlServer
Устойчивые функции
(поставщик хранилища Netherite)		 Замена ссылок на
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.DurableTask.Netherite
Привязки SendGrid Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.SendGrid
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.SendGrid
Привязки Kafka Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.Kafka
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.Kafka
Привязки RabbitMQ Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.RabbitMQ
Внедрение зависимостей
и конфигурация запуска		 Удаление ссылок на
Microsoft.Azure.Functions.Extensions
(Изолированная рабочая модель предоставляет эту функцию по умолчанию.)

Ознакомьтесь с поддерживаемыми привязками для полного списка расширений, которые следует рассмотреть, и ознакомьтесь с документацией по каждому расширению, чтобы получить полные инструкции по установке для изолированной модели процесса. Не забудьте установить последнюю стабильную версию всех целевых пакетов.

Совет

Любые изменения версий расширений во время этого процесса могут потребовать обновления host.json файла. Обязательно ознакомьтесь с документацией по каждому используемому расширению. Например, расширение служебная шина имеет критические изменения в структуре между версиями 4.x и 5.x. Дополнительные сведения см. в привязках Служебная шина Azure для Функции Azure.

Приложение изолированной рабочей модели не должно ссылаться на пакеты в пространствах имен Майкрософт.Azure.WebJobs.* или Майкрософт.Azure.Functions.Extensions. Если у вас есть оставшиеся ссылки на них, их следует удалить.

Совет

Ваше приложение также может зависеть от типов Azure SDK, в составе триггеров и привязок или как автономной зависимости. Вы должны воспользоваться этой возможностью, чтобы также их обновить. Последние версии расширений Функций работают с последними версиями Azure SDK для .NET, и почти все пакеты для него представлены в форме Azure.*.

Привязки центров уведомлений и мобильных приложений поддерживаются только в версии 1.x среды выполнения. При обновлении до версии 4.x среды выполнения необходимо удалить эти привязки в пользу работы с этими службами непосредственно с помощью пакетов SDK.

файл Program.cs

В большинстве случаев миграция требует добавления в проект следующего program.cs файла:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

Этот пример включает интеграцию ASP.NET Core для повышения производительности и предоставления знакомой модели программирования при использовании триггеров HTTP в приложении. Если вы не планируете использовать триггеры HTTP, можно заменить вызов ConfigureFunctionsWebApplication вызовом ConfigureFunctionsWorkerDefaults. При этом можно удалить ссылку на Майкрософт.Azure.Functions.Worker.Extensions.Http.AspNetCore из файла проекта. Однако для оптимальной производительности даже для функций с другими типами триггеров следует сохранить FrameworkReference для ASP.NET Core.

Файл Program.cs заменяет любой файл с FunctionsStartup атрибутом, который обычно является файлом Startup.cs. В местах, где ваш код FunctionsStartup будет ссылаться на IFunctionsHostBuilder.Services, можно вместо этого добавить инструкции в метод .ConfigureServices() класса HostBuilder в вашем файле Program.cs. Дополнительные сведения о работе с Program.cs см. в руководстве по запуску и настройке в изолированной рабочей модели.

Примеры Program.cs по умолчанию включают настройку Application Insights. В Program.cs необходимо также настроить фильтрацию журналов, которая должна применяться к журналам, поступающим из кода в проекте. В изолированной рабочей модели файл host.json управляет событиями, создаваемыми средой выполнения узла функций. Если правила фильтрации не настроены в Program.cs, могут возникнуть различия в уровнях журнала, присутствующих для различных категорий телеметрии.

Хотя вы можете зарегистрировать пользовательские источники конфигурации в рамках HostBuilder, они аналогично применяются только к коду в вашем проекте. Платформа также нуждается в настройке триггера и привязки, и это должно быть указано через функции настройки приложения, ссылки на Key Vault или ссылки на App Configuration.

После того как вы переместите все из любых существующих FunctionsStartup в файл Program.cs, можно удалить атрибут FunctionsStartup и класс, к которому он был применён.

файл host.json

Параметры в файле host.json применяются на уровне приложения-функции как локально, так и в Azure. В версии 1.x файл host.json пуст или содержит некоторые параметры, которые применяются ко всем функциям в приложении-функции. Дополнительные сведения см. в Host.json версии 1. Если ваш файл host.json имеет значения параметров, просмотрите формат host.json версии 2 на предмет любых изменений.

Чтобы запуститься в версии 4.x, необходимо добавить "version": "2.0" в файл host.json. Также следует добавить logging в конфигурацию, как показано в следующих примерах:

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    }
}

Файл host.json управляет ведением журнала только из среды выполнения узла Функций и в изолированной рабочей модели некоторые из этих журналов приходят непосредственно из приложения, что дает вам больше контроля. Дополнительные сведения об фильтрации этих журналов см. в статье "Управление уровнями журналов в изолированной рабочей модели ".

local.settings.json файл

Файл local.settings.json используется только при локальном запуске. Дополнительные сведения см. в файле локальных параметров. В версии 1.x файл local.settings.json имеет только два обязательных значения:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "AzureWebJobsDashboard": "AzureWebJobsStorageConnectionStringValue"
    }
}

При переходе на версию 4.x убедитесь, что файл local.settings.json содержит по крайней мере следующие элементы:

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

Примечание.

При переходе от выполнения процесса к выполнению в изолированном рабочем процессе необходимо изменить FUNCTIONS_WORKER_RUNTIME значение на "dotnet-isolated".

Изменения имени класса

Некоторые классы ключей изменили имена между версиями 1.x и версией 4.x. Эти изменения являются следствием изменений в API .NET или различий между внутрипроцессным и изолированным рабочими процессами. В следующей таблице указывается ключ .NET классов, используемых функциями, которые могут измениться при миграции:

Версия 1.x .NET 8
FunctionName (атрибут) Function (атрибут)
TraceWriter ILogger<T>, ILogger
HttpRequestMessage HttpRequestData, HttpRequest (с помощью интеграции ASP.NET Core)
HttpResponseMessage , (с использованием интеграции ASP.NET Core)

В привязках также могут быть различия имен классов. Для получения дополнительной информации см. справочные статьи по конкретным привязкам.

Другие изменения кода

В этом разделе рассматриваются другие изменения кода, которые следует учитывать при работе с миграцией. Эти изменения не требуются для всех приложений, но следует оценить, имеют ли они отношение к вашим сценариям. Не забудьте ознакомиться с изменениями поведения после версии 1.x, чтобы узнать о возможных корректировках, которые может потребоваться внести в ваш проект.

Сериализация JSON

По умолчанию изолированная рабочая модель использует System.Text.Json для сериализации JSON. Чтобы настроить параметры сериализатора или переключиться на JSON.NET (Newtonsoft.Json), см. статью Customization JSON serialization.

Уровни логов Application Insights и фильтрация

Журналы можно отправлять в Application Insights как из среды выполнения функции, так и из кода в проекте. host.json позволяет настраивать правила ведения журнала хоста, но для управления журналами, поступающими из вашего кода, необходимо настроить правила фильтрации в рамках Program.cs. Дополнительные сведения об фильтрации этих журналов см. в статье "Управление уровнями журналов в изолированной рабочей модели ".

Шаблон триггера HTTP

Большинство изменений кода между версией 1.x и версией 4.x можно увидеть в триггерных функциях HTTP. Шаблон триггера HTTP для версии 1.x выглядит следующим образом:

using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static async Task<HttpResponseMessage> 
            Run([HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post", 
            Route = null)]HttpRequestMessage req, TraceWriter log)
        {
            log.Info("C# HTTP trigger function processed a request.");

            // parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            if (name == null)
            {
                // Get request body
                dynamic data = await req.Content.ReadAsAsync<object>();
                name = data?.name;
            }

            return name == null
                ? req.CreateResponse(HttpStatusCode.BadRequest, 
                    "Please pass a name on the query string or in the request body")
                : req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
        }
    }
}

В версии 4.x шаблон триггера HTTP выглядит следующим образом:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

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

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

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

Чтобы обновить проект до Функции Azure 4.x:

  1. Обновите локальную установку Функции Azure Core Tools до версии 4.x.

  2. Перейдите к одной из версий Node.js, поддерживаемых в версии 4.x.

  3. Добавьте элементы version и extensionBundle в host.json, чтобы он выглядел следующим образом:

    {
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[3.3.0, 4.0.0)"
    }
}

    Элемент extensionBundle требуется, так как после версии 1.x привязки сохраняются как внешние пакеты. Дополнительные сведения см. в разделе "Пакеты расширений".

  4. Обновите файл local.settings.json таким образом, чтобы он содержит по крайней мере следующие элементы:

    {
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "node"
    }
}

    Параметр AzureWebJobsStorage может быть эмулятором хранилища Azurite или фактической учетной записью хранения Azure. Дополнительные сведения см. в эмуляторе локального хранилища.

Обновите ваше функциональное приложение в Azure

Перед публикацией перенесенного проекта необходимо обновить среду выполнения узла приложения-функции в Azure до версии 4.x. Версия среды выполнения, используемая узлом функций, управляется FUNCTIONS_EXTENSION_VERSION параметром приложения, но в некоторых случаях другие параметры также должны быть обновлены. Изменения кода и изменения параметров приложения требуют перезапуска приложения-функции.

Наиболее простой способ — обновить без слотов, а затем повторно опубликовать проект приложения. Вы также можете свести к минимуму время простоя в приложении и упростить откат, обновляя через слоты.

Обновление без слотов

Самый простой способ обновиться до версии 4.x — установить параметр приложения FUNCTIONS_EXTENSION_VERSION в значение ~4 в приложении-функции в Azure. На сайте со слотами необходимо выполнить другую процедуру.

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

Необходимо также задать другой параметр, который отличается от Windows и Linux.

При работе с Windows также необходимо включить .NET 8.0, которая требуется в среде выполнения версии 4.x.

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

.NET 6 требуется для приложений-функций на любом языке, работающем на Windows.

В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов.

Теперь вы можете повторно опубликовать проект приложения, перенесенный для запуска в версии 4.x.

Обновить с использованием слотов

Использование слотов развертывания — это хороший способ обновить функциональное приложение до исполняющей среды версии 4.x с предыдущей версии. С помощью промежуточного слота можно запустить приложение в новой версии среды выполнения в промежуточном слоте и перейти в рабочую среду после проверки. Слоты также позволяют свести к минимуму время простоя во время обновления. Если необходимо свести к минимуму время простоя, выполните действия, описанные в разделе "Минимальное время простоя".

После проверки приложения в обновленном слоте вы можете переместить приложение и настройки новой версии в рабочую среду. Для этого переключения требуется установить параметр WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в рабочем слоте. Добавление этого параметра влияет на время простоя, необходимое для обновления.

Стандартное обновление

Если для приложения-функции с поддержкой слотов допустимо время простоя, необходимое для полного перезапуска, можно обновить параметр WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS непосредственно в рабочем слоте. Так как изменение этого параметра непосредственно в рабочем слоте приводит к перезапуску, влияющему на доступность, рекомендуется выполнять это изменение в период пониженного трафика. Затем вы можете задействовать обновленную версию, переместив ее в промежуточный слот.

Командлет PowerShell Update-AzFunctionAppSetting в настоящее время не поддерживает слоты. Необходимо использовать Azure CLI или портал Azure.

  1. Используйте следующую команду, чтобы задать WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в рабочем слоте:

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

    В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов. Эта команда приводит к перезапуску приложения, запущенного в рабочем слоте.

  2. Используйте следующую команду, чтобы также задать WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS в промежуточном слоте:

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

  3. Используйте следующую команду, чтобы изменить FUNCTIONS_EXTENSION_VERSION и обновить промежуточный слот до новой версии среды выполнения:

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

  4. Для среды выполнения функций версии 4.x требуется .NET 6 в Windows. В Linux приложения .NET также должны обновляться до .NET 6. Используйте следующую команду, чтобы среда выполнения была запущена в .NET 6:

    При работе с Windows также необходимо включить .NET 8.0, которая требуется в среде выполнения версии 4.x.

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

    .NET 6 требуется для приложений-функций на любом языке, работающем на Windows.

    В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов.

  5. Если в проекте кода необходимы обновления, чтобы он работал на версии 4.x, разверните эти обновления в промежуточной стадии сейчас.

  6. Убедитесь, что приложение-функция работает правильно в обновленной промежуточной среде перед переключением.

  7. Используйте следующую команду, чтобы переключить обновленный промежуточный слот на рабочую среду:

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

Минимальное обновление простоя

Чтобы свести к минимуму время простоя в рабочем приложении, можно переключить параметр WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS из промежуточного слота в рабочую среду. После этого можно переключить обновленную версию из предварительно созданного промежуточного слота.

  1. Используйте следующую команду, чтобы задать WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в промежуточном слоте:

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

  2. Используйте следующие команды, чтобы переключить слот с новым параметром в рабочую среду и одновременно восстановить параметр версии в промежуточном слоте.

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

    В период между переключением и восстановлением версии среды выполнения вы можете увидеть ошибки в промежуточном слоте. Эта ошибка может произойти, потому что наличие WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 только в промежуточном режиме во время обмена приводит к удалению параметра FUNCTIONS_EXTENSION_VERSION в промежуточном режиме. Без параметра версии слот находится в плохом состоянии. Обновление версии в промежуточном слоте сразу после переключения должно вернуть слот обратно в стабильное состояние, и можно инициировать процесс отмены изменений, если это необходимо. Однако для любого отката переключения также необходимо непосредственно удалить WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 из рабочей среды перед обратным переключением, чтобы предотвратить те же ошибки в продакшене, которые были замечены на стадии промежуточного тестирования. Это изменение в рабочем параметре приведет к перезапуску.

  3. Используйте следующую команду, чтобы вновь настроить WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в слоте подготовки:

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

    На этом этапе в обоих слотах установлено WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0.

  4. Используйте следующую команду, чтобы изменить FUNCTIONS_EXTENSION_VERSION и обновить промежуточный слот до новой версии среды выполнения:

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

  5. Для среды выполнения функций версии 4.x требуется .NET 6 в Windows. В Linux приложения .NET также должны обновляться до .NET 6. Используйте следующую команду, чтобы среда выполнения была запущена в .NET 6:

    При работе с Windows также необходимо включить .NET 8.0, которая требуется в среде выполнения версии 4.x.

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

    .NET 6 требуется для приложений-функций на любом языке, работающем на Windows.

    В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов.

  6. Если в проекте кода необходимы обновления, чтобы он работал на версии 4.x, разверните эти обновления в промежуточной стадии сейчас.

  7. Убедитесь, что приложение-функция работает правильно в обновленной промежуточной среде перед переключением.

  8. Используйте следующую команду, чтобы переключить обновленный и предварительно подготовленный слот подготовки на продакшн.

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

Изменения поведения после версии 1.x

В этом разделе подробно описаны изменения, внесенные после версии 1.x в поведении триггера и привязки, а также в основных функциях и поведении функций.

Изменения в триггерах и привязках

Начиная с версии 2.x, вам потребуется устанавливать расширения для конкретных триггеров и привязок, которые используются функциями вашего приложения. Единственное исключение — триггеры HTTP и таймера, для которых не требуется расширение. Для получения дополнительной информации см. Зарегистрируйте и установите расширения привязки.

Также при смене версий были внесены некоторые изменения в function.json или атрибуты функций. Например, свойство path для концентраторов событий теперь имеет атрибут eventHubName. Для получения ссылок на документацию для каждой привязки см. таблицу существующих привязок.

Изменения в функциях и возможностях

Некоторые функции были удалены, обновлены или заменены после версии 1.x. В этом разделе подробно описаны изменения, которые вы увидите в более поздних версиях после использования версии 1.x.

В версии 2.x внесены следующие изменения.

  • Ключи для вызова конечных точек HTTP всегда хранятся зашифрованными в хранилище Azure Blob. В версии 1.x ключи хранятся в Файлы Azure по умолчанию. При переносе приложения с версии 1.x на версию 2.x существующие секреты, которые находятся в Файлы Azure, сбрасываются.

  • Среда выполнения версии 2.x не имеет встроенной поддержки вебхуков. Это изменение внесено для повышения производительности. Вы по-прежнему можете использовать HTTP триггеры в качестве конечных точек для веб-перехватчиков.

  • Чтобы улучшить мониторинг, панель WebJobs на портале, которая использовала параметр AzureWebJobsDashboard, заменена инструментом приложение Azure Insights, который использует параметр APPINSIGHTS_INSTRUMENTATIONKEY. Дополнительные сведения см. в разделе Monitor Функции Azure.

  • Все функции в рамках одного приложения должны использовать один язык. При создании приложения-функции необходимо выбрать для приложения стек среды выполнения. В параметрах приложения стек среды выполнения определяется значением FUNCTIONS_WORKER_RUNTIME. Это требование добавлено для уменьшения занимаемого места и ускорения запуска. При локальной разработке также необходимо включить этот параметр в файл local.settings.json.

  • По умолчанию для функций в плане службы приложений устанавливается время ожидания 30 минут. Вы можете вручную снять это ограничение, изменив параметр functionTimeout в файле host.json.

  • Регулирование параллельной обработки HTTP по умолчанию применяется для функций плана потребления, по умолчанию допуская не более 100 одновременных запросов на один экземпляр. Это поведение можно изменить в параметре maxConcurrentRequests файла host.json.

  • Из-за ограничений .NET Core поддержка функций скрипта F# (.fsx файлов) была удалена. Скомпилированные функции F# (.fs) по-прежнему поддерживаются.

  • Для веб-перехватчиков триггера Event Grid формат URL-адреса изменен в соответствии со следующим шаблоном: https://{app}/runtime/webhooks/{triggerName}.

  • Имена некоторых предварительно определенных пользовательских метрик были изменены после версии 1.x. Duration был заменен на MaxDurationMs, MinDurationMsи AvgDurationMs. Success Rate также был переименован в Success Rate.

Рекомендации по Azure Stack Hub

App Service в Azure Stack Hub не поддерживает версию 4.x Функции Azure. При планировании миграции с версии 1.x в Azure Stack Hub можно выбрать один из следующих вариантов:

  • Миграция на версию 4.x, размещенную в общедоступном облаке Функции Azure с помощью инструкций в этой статье. Вместо обновления существующего приложения вы создадите новое приложение с помощью версии 4.x, а затем развернете измененный проект в нем.
  • Перейдите на WebJobs, размещенные на плане службы приложений в Azure Stack Hub.

Следующие шаги

Дополнительные сведения о версиях функций

  • Last updated on