Управление зависимостями гостевых исполняемых файлов - на основе Service Fabric

Question

Недавно мы решили начать использовать локальную Service Fabric и столкнулись с проблемой «зависимости».

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

Пример, проясняющий ситуацию:

В приведенной ниже таблице услуга B зависит от службы A. Если службаПри обнаружении непредвиденной ошибки и перезапуске служба B перейдет в состояние «ошибка» (о котором не будет сообщено матрице).Это означает, что служба B сообщит о состоянии работоспособности OK, хотя она находится в состоянии ошибки.

Мы думали о решении, заключающемся в следующих строках:

Создание независимой службы, котораяотслеживает события состояния работоспособности всех реплик / разделов / приложений в кластере и содержит все дерево зависимостей.

Когда состояние работоспособности службы изменяется, она перезапускает свои прямые зависимости, что вызывает эффект доминособытия -> перезапускаются до тех пор, пока все поддерево не будет сброшено (как показано ниже в блок-схеме событий -> действия).

Проблема заключается вСобытия HealthReport не отправляются в короткие промежутки времени (это означает, что вся моя система не может работать, и я не буду знать в течение нескольких минут).Я бы отслеживал состояние работоспособности, но мне нужно знать историю (даже если состояние сейчас исправно, это не значит, что раньше оно не было в состоянии ошибки).

Другая проблема заключается в том, что событияможет появиться на любом уровне обслуживания (реплика / раздел), и это потребует от меня агрегирования всех событий.

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

Answer 1

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

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

• Используйте автоматические выключатели для закрытия связи с неисправными службами. В этой метафоре замкнутая цепь образуется между двумя службами, общающимися нормально. Автоматический выключатель контролирует связь. Если он обнаруживает некоторое количество сбойных коммуникаций, он «открывает» цепь, вызывая любые дальнейшие сбой связи немедленно. Затем автоматический выключатель посылает периодические запросы в сбойную службу, чтобы проверить ее работоспособность, и замыкает цепь, как только сбойная служба начинает работать. Это немного сложнее, чем политика повторных попыток, поскольку вы несете ответственность за предотвращение сбоя службы в открытой цепи, а также за принятие решения о том, что является исправным сервисом. Полли также поддерживает автоматические выключатели

• Использование очередей для формирования полностью асинхронной связи между службами. Вместо того, чтобы напрямую связываться со службой B к A, поставьте в очередь исходящие операции для A в службе B. Обработайте очередь в своем собственном потоке - не допускайте сбоев связи с обработчиком очереди. Вы также можете добавить входящую очередь в службу A, чтобы получать сообщения из исходящей очереди службы B, чтобы полностью изолировать обработку сообщений от сети. Это, вероятно, самый длительный, но и самый сложный процесс, так как для него требуется архитектура, отличная от RPC, и вы также должны решить, что делать с сообщениями, которые неоднократно терпят неудачу. Вы можете немедленно повторить неудачные сообщения, отправить их в конец очереди после задержки, отправить их в набор недоставленных писем для ручной обработки или вообще отбросить сообщение. Поскольку вы используете гостевые исполняемые файлы, у вас нет роскоши надежных коллекций, чтобы помочь с этим процессом, поэтому стороннее решение, такое как RabbitMQ, может оказаться полезным, если вы решите пойти по этому пути.