Поделиться через

Развертывание без простоя для Устойчивых функций

  • Статья

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

Чтобы предотвратить эти сбои, имеется два варианта.

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

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

Стратегия Назначение Плюсы Минусы
Управление версиями Приложения, которые не сталкиваются с частыми критическими изменениями. Простая реализация. Увеличение размера приложения функции в памяти и количества функций.
Дублирование кода.
Проверка состояния по ячейке Система, которая не имеет длительно работающей оркестрации (свыше 24 часов) или часто перекрывающихся оркестраций. Простая база кода.
Не требует дополнительного управления приложениями функций.		 Требуется дополнительная учетная запись хранилища или управление центром задач.
Требуются отрезки времени, когда оркестрация не запущена.
Маршрутизация приложений Система, которая не имеет отрезков времени с незапущенной оркестрацией, например отрезки времени с оркестрацией дольше 24 часов или с часто перекрываемыми оркестрациями. Обрабатывает новые версии систем с постоянно работающими оркестрациями, которые вносят критически важные изменения. Требуется интеллектуальный маршрутизатор приложений.
Максимально допустимое количество приложений функций, разрешенных вашей подпиской. Значение по умолчанию — 100.

В оставшейся части данного документа эти стратегии описаны более подробно.

Примечание

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

Управление версиями

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

Стратегия управления версиями

В данной стратегии необходимо скопировать каждую функцию, а ссылки на другие функции следует обновить. Это можно сделать проще, написав скрипт. Ниже приводится Пример проекта со скриптом миграции.

Примечание

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

Проверка состояния по ячейке

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

Конфигурация приложения функции

Для настройки этого сценария используйте следующую процедуру.

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

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

  3. Для каждой ячейки создайте новый параметр приложения, например DurableManagementStorage. Задайте в качестве значения строку подключения различных учетных записей хранилища. Эти учетные записи хранилища используются расширением Устойчивые функции для надежного выполнения. Используйте отдельную учетную запись хранилища для каждой ячейки. Не отмечайте этот параметр как параметр ячейки развертывания.

  4. В файле host.jsв приложении функции укажите connectionStringName (Durable 2.x) или azureStorageConnectionStringName (Durable 1.x) в качестве имени параметра приложения, созданного на шаге 3.

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

Ячейки развертывания и учетные записи хранилища

Примеры host.js

Приводимые ниже фрагменты JSON являются примерами параметра строки подключения в файле host.js.

Функции 2.0

{
  "version": 2.0,
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub",
      "storageProvider": {
        "connectionStringName": "DurableManagementStorage"
      }
    }
  }
}

Функции 1.x

{
  "durableTask": {
    "azureStorageConnectionStringName": "DurableManagementStorage"
  }
}

Конфигурация конвейера CI/CD

Настройте конвейер CI/CD для развертывания, только если приложение функции не имеет экземпляров оркестрации в работе или ожидании. При использовании Azure Pipelines можно создать функцию, которая проверяет эти условия, как показано в следующем примере:

[FunctionName("StatusCheck")]
public static async Task<IActionResult> StatusCheck(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestMessage req,
    [DurableClient] IDurableOrchestrationClient client,
    ILogger log)
{
    var runtimeStatus = new List<OrchestrationRuntimeStatus>();

    runtimeStatus.Add(OrchestrationRuntimeStatus.Pending);
    runtimeStatus.Add(OrchestrationRuntimeStatus.Running);

    var result = await client.ListInstancesAsync(new OrchestrationStatusQueryCondition() { RuntimeStatus = runtimeStatus }, CancellationToken.None);
    return (ActionResult)new OkObjectResult(new { HasRunning = result.DurableOrchestrationState.Any() });
}

Затем настройте промежуточный шлюз на ожидание, пока оркестрация не выполняется. Дополнительные сведения см. в разделе Реализация управления развертыванием с помощью шлюзов.

Шлюз развертывания

Azure Pipelines проверяет приложение функции на выполнение экземпляров оркестрации до начала развертывания.

Шлюз развертывания (запущен)

Теперь новая версия приложения функции должна развернуться в промежуточной ячейке.

Промежуточная ячейка

Наконец, поменяйте ячейки местами.

Параметры приложения, которые не отмечены как параметры ячейки развертывания, также обмениваются местами, поэтому приложение версии 2 хранит ссылку на учетную запись хранилища А. Так как состояние оркестрации отслеживается в учетной записи хранилища, все взаимодействия, запущенные в приложении версии 2, продолжают работать в новой ячейке без прерывания.

Слот развертывания

Чтобы использовать одну и ту же учетную запись хранилища для обеих ячеек, следует изменить имена центров задач. В этом случае необходимо управлять состоянием ячеек и параметрами HubName приложения. Дополнительные сведения см. в разделе Центры задач в Устойчивых функциях.

Маршрутизация приложений

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

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

  • Развертывание приложения функции.
  • Управление версией Устойчивых функций.
  • Маршрутизация запросов оркестрации в приложения функции.

При первом получении запроса оркестрации маршрутизатор выполняет следующие задачи.

  1. Создает новое приложение функции в Azure.
  2. Развертывает код приложения функции в новом приложении функции в Azure.
  3. Перенаправляет запрос оркестрации в новое приложение.

Маршрутизатор управляет состоянием версии кода приложения, на котором развернуто приложение функции в Azure.

Маршрутизация приложений (первый раз)

Маршрутизатор направляет запросы на развертывание и оркестрацию соответствующему приложению функции на основе версии, отправленной вместе с запросом. В этом случае не учитывается версия с исправлениями.

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

Маршрутизация приложений (без критических изменений)

При развертывании новой версии приложения с критическим изменением можно обновить основную или дополнительную версии. Затем маршрутизатор приложений создает в Azure новое приложение функции, развертывает его и направляет запросы к новой версии этого приложения. На схеме ниже работа оркестраций в версии 1.0.1 приложения продолжает выполняться, но запросы к версии 1.1.0 направляются в новое приложение функции.

Маршрутизация приложений (с критическим изменением)

Маршрутизатор отслеживает состояние оркестраций в версии 1.0.1 и удаляет приложения после завершения всех оркестраций.

Параметры хранилища отслеживания

Каждое приложение функции должно использовать отдельные очереди планирования, возможно, в отдельных учетных записях хранилища. Если требуется запросить все экземпляры оркестрации во всех версиях приложения, можно совместно использовать таблицы экземпляров и журналов в приложениях функции. Можно предоставить общий доступ к таблицам, настроив параметры trackingStoreConnectionStringName и trackingStoreNamePrefix в файле host.json, чтобы они использовали одинаковые значения.

Дополнительные сведения см. в статье Управление экземплярами в Устойчивых функциях в Azure.

Параметры хранилища отслеживания

Дальнейшие действия

Управление версиями Устойчивых функций