Обзор жизненного цикла служб Reliable Services

Когда вы думаете о жизненном цикле служб Azure Service Fabric Reliable Services, основы жизненного цикла являются наиболее важными. Как правило, жизненный цикл включает в себя следующее:

• Во время запуска:
  • Службы создаются.
  • Службы имеют возможность создавать и возвращать нулевое или большее количество слушателей.
  • Открываются все возвращенные прослушиватели, тем самым позволяя обмен данными со службой.
  • Вызывается метод RunAsync службы, позволяющий службе выполнять длительные задачи или фоновую работу.
• Во время выключения:
  • Маркер отмены, переданный RunAsync, отменен, и прослушиватели закрыты.
  • После закрытия прослушивателей сам объект службы будет уничтожен.

Существуют подробные сведения о точном порядке этих событий. Порядок событий может немного изменяться в зависимости от того, является ли надежная служба бессостоянием или с состоянием. Кроме того, для служб с отслеживанием состояния необходимо иметь дело с основным сценарием переключения. Во время этой последовательности роль Primary передаётся другой реплике (или возвращается) без прерывания работы службы. Наконец, мы должны подумать об ошибках или условиях сбоя.

Запуск бесстатусной службы

Жизненный цикл бессостояной службы прост. Ниже приведен порядок событий:

1. Служба создается.
2. StatelessService.CreateServiceInstanceListeners() вызывается и открываются все возвращенные прослушиватели. ICommunicationListener.OpenAsync() вызывается для каждого прослушивателя.
3. Затем, параллельно, две вещи происходят -
   • Вызывается метод службы StatelessService.RunAsync() .
   • Если он присутствует, вызывается метод службы StatelessService.OnOpenAsync(). Этот вызов является необычным переопределением, но он доступен. Задачи инициализации расширенной службы можно запустить в настоящее время.

Завершение работы службы без отслеживания состояния

Для завершения работы бесточного сервиса используется тот же шаблон, только в обратном порядке.

1. Все открытые прослушиватели закрыты. ICommunicationListener.CloseAsync() вызывается для каждого прослушивателя.
2. Маркер отмены, передаваемый в RunAsync() отмену, отменен. Проверка свойства маркера IsCancellationRequested отмены возвращает значение true, и если он вызывается, метод маркера ThrowIfCancellationRequested создает исключение OperationCanceledException. Service Fabric ожидает завершения RunAsync().
3. После завершения RunAsync() вызывается метод StatelessService.OnCloseAsync() службы, если он присутствует. OnCloseAsync вызывается при корректном завершении работы экземпляра службы без отслеживания состояния. Это может произойти при обновлении кода службы, перемещении экземпляра службы из-за балансировки нагрузки или обнаружении временного сбоя. В редких случаях можно переопределить StatelessService.OnCloseAsync(), но это может быть использовано для безопасного закрытия ресурсов, остановки фоновой обработки, завершения сохранения внешнего состояния или закрытия существующих подключений.
4. После завершения StatelessService.OnCloseAsync() объект службы уничтожается.

Запуск stateful-сервиса

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

1. Служба создается.

2. StatefulServiceBase.OnOpenAsync() вызывается. Этот вызов обычно не переопределяется в службе.

3. вызывается StatefulServiceBase.CreateServiceReplicaListeners().

   • Если служба является основной службой, открываются все возвращенные прослушиватели. ICommunicationListener.OpenAsync() вызывается для каждого прослушивателя.
   • Если служба является вторичной службой, открываются только те слушатели, которые помечены как ListenOnSecondary = true. Наличие прослушивателей, открытых на вторичных файлах, менее распространено.

4. Затем параллельно:

   • Если служба в настоящее время является первичной, вызывается метод службы StatefulServiceBase.RunAsync() .
   • StatefulServiceBase.OnChangeRoleAsync() вызывается. Этот вызов обычно не переопределяется в службе.

   Примечание.

   Для новой вторичной реплики StatefulServiceBase.OnChangeRoleAsync() вызывается дважды. Сначала после шага 2, когда он становится бездействующей вторичной системой, а затем во время шага 4, когда он становится активной вторичной системой. Дополнительные сведения о жизненном цикле реплики и экземпляра см. в статье "Реплика и жизненный цикл экземпляра".

Завершение работы службы с отслеживанием состояния

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

1. Все открытые прослушиватели закрыты. ICommunicationListener.CloseAsync() вызывается для каждого слушателя.

2. Вызывается метод StatefulServiceBase.OnCloseAsync(). Этот вызов является необычным переопределением, но доступен.

3. Маркер отмены, переданный в RunAsync(), отменен. Проверка свойства IsCancellationRequested маркера отмены возвращает значение true, и при вызове метод ThrowIfCancellationRequested маркера генерирует исключение OperationCanceledException. Service Fabric ожидает завершения RunAsync().

   Примечание.

   Необходимо дождаться завершения RunAsync , только если эта реплика является первичной репликой.

4. После завершения StatefulServiceBase.RunAsync() объект службы удаляется.

Переключения основной службы с отслеживанием состояния

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

Для основной, которая демотирована

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

1. Все открытые прослушиватели закрыты. ICommunicationListener.CloseAsync() вызывается для каждого слушателя.
2. Маркер отмены, передаваемый в RunAsync(), был отменен. Проверка свойства маркера IsCancellationRequested отмены возвращает значение true, и если он вызывается, метод маркера ThrowIfCancellationRequested создает исключение OperationCanceledException. Service Fabric ожидает завершения RunAsync().
3. Прослушиватели, помеченные как ListenOnSecondary = true, открываются.
4. Вызывается служба StatefulServiceBase.OnChangeRoleAsync() . Этот вызов обычно не переопределяется в службе.

Для вторичного, который продвигается

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

1. ICommunicationListener.CloseAsync() вызывается для всех открытых прослушивателей (отмечено значением ListenOnSecondary = true).
2. Открываются все прослушиватели связи. ICommunicationListener.OpenAsync() вызывается для каждого слушателя.
3. Затем параллельно:
   • Вызывается метод службы StatefulServiceBase.RunAsync() .
   • StatefulServiceBase.OnChangeRoleAsync() вызывается. Этот вызов обычно не переопределяется в службе.

Распространенные проблемы при завершении работы службы с отслеживанием состояния и первичной понижении

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

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

Так как службы работают с отслеживанием состояния, скорее всего, они используют надежные коллекции. В Service Fabric при понижении основного состояния одна из первых вещей, которая происходит, заключается в том, что доступ на запись к базовому состоянию отзывается. Это приводит к второму набору проблем, которые могут повлиять на жизненный цикл службы. Коллекции возвращают исключения в зависимости от времени и условий, таких как перемещение или завершение работы реплики. Эти исключения должны обрабатываться правильно. Исключения, создаваемые Service Fabric, попадают в постоянные (FabricException) и временные (FabricTransientException) категории. Постоянные исключения должны быть зарегистрированы и вызываются, а временные исключения могут быть повторены на основе какой-то логики повторных попыток.

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

Заметки о жизненном цикле службы

• Метод RunAsync() и CreateServiceReplicaListeners/CreateServiceInstanceListeners вызовы являются необязательными. Служба может иметь один из них, оба или ни один из них. Например, если служба выполняет всю свою работу в ответ на вызовы пользователей, нет необходимости в реализации RunAsync(). Необходимы только прослушиватели связи и связанный с ними код. Аналогичным образом создание и возврат прослушивателей связи является необязательным, так как служба может выполнять только фоновую работу и может реализовать RunAsync().
• Он действителен для успешного завершения RunAsync() службы и возврата из нее. Завершение не является признаком сбоя. Завершение RunAsync() указывает на то, что фоновая работа службы завершена. Для надежных служб с отслеживанием состояния RunAsync() вызывается снова, если реплика понижена с первичной до вторичной, а затем повышена обратно до первичной.
• Если служба завершает работу в RunAsync(), выбросив неожиданное исключение, это представляет собой сбой. Объект службы завершает работу и сообщается об ошибке работоспособности.
• Хотя нет ограничения времени на возврат из этих методов, вы сразу же потеряете возможность записи в Надежные коллекции и, следовательно, не сможете завершить любую реальную работу. Мы рекомендуем как можно быстрее вернуться после получения запроса на отмену. Если служба не отвечает на эти вызовы API в разумный период времени, Service Fabric может принудительно завершить службу. Обычно это происходит только во время обновления приложения или при удалении службы. Это время ожидания составляет 15 минут по умолчанию.
• Сбои в OnCloseAsync() пути приводят к вызову OnAbort(), что является последней возможностью для службы предпринять усилия по очистке и освобождению всех ресурсов, которыми они воспользовались. Обычно это вызывается при обнаружении постоянной ошибки на узле или когда Service Fabric не может надежно управлять жизненным циклом экземпляра службы из-за внутренних сбоев.
• OnChangeRoleAsync() вызывается при изменении роли реплики сохраняющего состояния службы, например, на первичную или вторичную. Первичным репликам присваивается статус записи (им разрешено создавать и записывать в Надежные коллекции). Вторичные реплики получают состояние чтения (могут читаться только из существующих надежных коллекций). Большая часть работы в сервисе с сохранением состояния выполняется на первичной реплике. Вторичные реплики могут выполнять проверки в режиме только для чтения, создавать отчеты, выполнять интеллектуальный анализ данных или другие задачи, доступные только для чтения.

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

• Общие сведения о надежных службах
• Быстрый старт надежных служб
• Реплики и экземпляры