Жизненный цикл приложения Service Fabric

  • Статья

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

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

Важно!

Для работы с Service Fabric доступны две служебные программы CLI. Azure CLI используется для управления ресурсами Azure, включая кластер Service Fabric, размещенный в Azure. Service Fabric CLI используется для непосредственного подключения к кластеру Service Fabric (независимо от того, где он размещается), а также для управления кластером, приложениями и службами.

Роли моделей служб

Роли моделей служб:

  • Разработчик службы. Разрабатывает модульные и универсальные службы, для которых можно переопределить цель и которые можно использовать в различных приложениях одного и того же или разных типов. Например, служба очередей может использоваться для создания приложения для обработки обращений (служба поддержки) или приложения для электронной коммерции (корзины).
  • Разработчик приложения. Создает приложения путем интеграции коллекции служб для обеспечения соответствия определенным конкретным требованиям или сценариям. Например, на веб-сайте электронной коммерции могут интегрироваться интерфейсные службы JSON без отслеживания состояния службы, аукцион с отслеживанием состояния службы и служба очереди с отслеживанием состояния службы для создания аукционного приложения.
  • Администратор приложения. Принимает решения о конфигурации приложения (установка параметров шаблона конфигурации), развертывании (сопоставление с доступными ресурсами) и обеспечении качества обслуживания. Например, администратор приложения принимает решение о языковых настройках приложения, используемых в зависимости от региона (например, английский для США или японский для Японии). Другое развернутое приложение может иметь другие настройки.
  • Оператор. Развертывает приложения с учетом конфигурации приложения и требований, указанных администратором приложения. Например, оператор выделяет и развертывает приложение и обеспечивает его работу в Azure. Операторы должны отслеживать работоспособность и производительность приложений и поддерживать соответствующую физическую инфраструктуру при необходимости.

Разработка

  1. Разработчик службы разрабатывает различные типы служб, используя модель программирования Reliable Actors или Reliable Services.
  2. Разработчик службы декларативно описывает создаваемые типы служб в файле манифеста службы, состоящем из одного или нескольких пакетов кода, конфигурации и данных.
  3. Разработчик приложения затем выполняет построение приложения с использованием различных типов служб.
  4. Разработчик приложения декларативно описывает тип приложения в его манифесте, указывая ссылки на манифесты составляющих служб и соответствующим образом переопределяя и параметризируя различные параметры конфигурации и развертывания составляющих служб.

См. статьи Приступая к работе с Reliable Actors и Начало работы со службами Reliable Services в Service Fabric, чтобы ознакомиться с примерами.

Развернуть

  1. Администратор приложения изменяет приложение определенного типа для конкретного приложения, которое будет развернуто в кластере Service Fabric путем указания соответствующих параметров элемента ApplicationType в манифесте приложения.
  2. Оператор загружает пакет приложения в хранилище образов кластера с помощью метода CopyApplicationPackage или командлета Copy-ServiceFabricApplicationPackage. Пакет приложения содержит манифест приложения и коллекцию пакетов служб. Структура служб выполняет развертывание приложений из пакета приложений, размещенного в хранилище образов, который может представлять собой магазин больших двоичных объектов Azure или системную службу Service Fabric.
  3. Оператор затем выделяет тип приложения в целевом кластере из загруженного пакета приложения с помощью метода ProvisionApplicationAsync, командлета Register-ServiceFabricApplicationType или операции REST Provision an Application.
  4. После подготовки приложения оператор запускает приложение с параметрами, предоставленными администратором приложения с помощью метода CreateApplicationAsync, командлета New-ServiceFabricApplication или операции REST Create Application.
  5. После того как приложение будет развернуто, оператор использует метод CreateServiceAsync, командлет New-ServiceFabricService или операцию REST Create Service для создания экземпляров службы для приложения на основании доступных типов службы.
  6. Теперь приложение работает в кластере Service Fabric.

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

Тест

  1. После развертывания в локальном кластере разработки или в тестовом кластере разработчик службы запускает встроенный сценарий проверки переключения на резервный ресурс с помощью классов FailoverTestScenarioParameters и FailoverTestScenario или командлета Invoke-ServiceFabricFailoverTestScenario. Сценарий тестирования отказа пропускает указанную службу через важные преобразования и отказы, чтобы гарантировать, что она остается доступной и продолжает работать.
  2. Затем разработчик службы запускает встроенный хаотический сценарий тестирования с помощью классов ChaosTestScenarioParameters и ChaosTestScenario или командлета Invoke-ServiceFabricChaosTestScenario. Хаотический сценарий тестирования в случайном порядке вызывает множественные ошибки на уровне узла, пакета кода и реплики в кластере.
  3. Разработчик службытестирует обмен данными между службами , создавая сценарии тестирования для перемещения первичных реплик в кластере.

Дополнительные сведения см. в статье Общие сведения о службе анализа сбоев.

Обновление

  1. Разработчик службы обновляет составляющие службы экземпляра приложения или устраняет ошибки кода и предоставляет новую версию манифеста служб.
  2. Разработчик приложения переопределяет и параметризует настройки конфигурации и развертывания и предоставляет новую версию манифеста приложения. Разработчик приложения затем включает новые версии манифестов служб в приложение и собирает новую версию приложения этого же типа в обновленном пакете приложения.
  3. Администратор приложения включает новую версию типа приложения в целевое приложение, обновляя соответствующие параметры.
  4. Оператор загружает обновленный пакет приложения в хранилище образов кластера с помощью метода CopyApplicationPackage или командлета Copy-ServiceFabricApplicationPackage. Пакет приложения содержит манифест приложения и коллекцию пакетов служб.
  5. Оператор предоставляет новую версию приложения для целевого кластера с помощью метода ProvisionApplicationAsync, командлета Register-ServiceFabricApplicationType или операции REST Provision an Application.
  6. Оператор обновляет целевое приложение до новой версии, используя метод UpgradeApplicationAsync, командлет Start-ServiceFabricApplicationUpgrade или операцию REST Upgrade an Application.
  7. Оператор проверяет ход обновления с помощью метода GetApplicationUpgradeProgressAsync, командлета Get-ServiceFabricApplicationUpgrade или операции REST Get Application Upgrade Progress.
  8. При необходимости оператор изменяет и повторно применяет параметры текущего обновления приложения с помощью метода UpdateApplicationUpgradeAsync, командлета Update-ServiceFabricApplicationUpgrade или операции REST Update Application Upgrade.
  9. При необходимости оператор применяет откат текущего обновления приложения с помощью метода RollbackApplicationUpgradeAsync, командлета Start-ServiceFabricApplicationRollback или операции RESTRollback Application Upgrade.
  10. Структура службы обновляет целевое приложение, запущенное в кластере приложения без потери доступности служб, которые входят в его состав.

См. руководство по обновлению приложений Service Fabric с помощью Visual Studio, чтобы ознакомиться с примерами.

Техническое обслуживание

  1. Для обновлений и исправлений операционной системы структура служб взаимодействует с инфраструктурой Azure таким образом, чтобы обеспечивать гарантированную доступность всех приложений в кластере.
  2. Для обновлений и исправлений в платформе Service Fabric обновление самой Service Fabric выполняется без потери доступности любых приложений, запущенных в кластере.
  3. Администратор приложения утверждает добавление или удаление узлов в кластере после выполнения анализа архивных данных об использовании мощностей и прогнозируемой потребности в мощностях в будущем.
  4. Оператор добавляет и удаляет узлы, указанные администратором приложения.
  5. При добавлении новых или удалении существующих узлов из кластера структура службы автоматически балансирует нагрузку запущенных приложений на всех узлах в кластере, чтобы достичь оптимальной производительности.

Удалить

  1. Оператор может удалить определенный экземпляр запущенной службы в кластере без удаления всего приложения с помощью метода DeleteServiceAsync, командлета Remove-ServiceFabricService или операции REST Delete Service.
  2. Оператор может также удалить экземпляр приложения и все его службы с помощью метода DeleteApplicationAsync, командлета Remove-ServiceFabricApplication или операции REST Delete Application.
  3. После того как приложения и службы будут остановлены, оператор может отменить выделение мощностей для этого типа приложений с помощью метода UnprovisionApplicationAsync, командлета Unregister-ServiceFabricApplicationType или операции REST Unprovision an Application. При отмене подготовки мощностей для определенного типа приложения пакет приложения не удаляется из хранилища образов; необходимо удалить его вручную.
  4. Оператор удаляет пакет приложений из ImageStore с помощью метода RemoveApplicationPackage или командлета Remove-ServiceFabricApplicationPackage.

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

Сохранение дискового пространства в хранилище образов кластера

ImageStoreService сохраняет скопированные и подготовленные пакеты, что может привести к накоплению файлов. Накопление файлов может привести к тому, что ImageStoreService (fabric:/System/ImageStoreService) заполнит диск, и может увеличить время сборки для реплик ImageStoreService.

Чтобы избежать накопления файлов, используйте следующую последовательность подготовки:

  1. Скопируйте пакет в ImageStore и воспользуйтесь параметром сжатия.

  2. Подготовьте пакет.

  3. Удалите пакет в хранилище образов.

  4. Обновите приложение или кластер.

  5. Отмените подготовку старой версии.

Шаги 3 и 5 в описанной выше процедуре предотвращают накопление файлов в хранилище образов.

Настройка автоматической очистки

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

PowerShell:

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML:

<Section Name="Management">
  <Parameter Name="CleanupApplicationPackageOnProvisionSuccess" Value="True" />
</Section>

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

<Section Name="Management">
  <Parameter Name="CleanupUnusedApplicationTypes" Value="true" />
  <Parameter Name="PeriodicCleanupUnusedApplicationTypes" Value="true" />     
  <Parameter Name="TriggerAppTypeCleanupOnProvisionSuccess" Value="true" />
  <Parameter Name="MaxUnusedAppTypeVersionsToKeep" Value="3" />
</Section>

Очистка файлов и данных на узлах

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

Чтобы полностью удалить двоичные файлы приложения, необходимо отменить регистрацию типа приложения.

Рекомендации для снижения нагрузки на диск:

  1. Remove-ServiceFabricApplicationPackage удаляет пакет из временного расположения отправки.
  2. Unregister-ServiceFabricApplicationType освобождает дисковое пространство путем удаления файлы типов приложения из службы хранилища образов и всех узлов. Диспетчер удаления по умолчанию выполняется каждый час.
  3. CleanupUnusedApplicationTypes автоматически очищает старые неиспользуемые версии приложений. 
    {
  "name": "Management",
  "parameters": [
    {
      "name": "CleanupUnusedApplicationTypes",
      "value": true
    },
    {
      "name": "MaxUnusedAppTypeVersionsToKeep",
      "value": "3"
    }
  ]
}
  4. Remove-ServiceFabricClusterPackage удаляет старые неиспользуемые двоичные файлы установки среды выполнения.

Примечание

Разрабатывается функция, которая разрешит Service Fabric удалять папки приложений после эвакуации приложения с узла.

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

Дополнительные сведения о разработке и тестировании приложений Service Fabric и служб, а также об управлении ими см. в следующих разделах.