Жизненный цикл приложения 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, чтобы ознакомиться с примерами.

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

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