Просто любопытно, есть ли у кого-нибудь опыт работы с необработанными исключениями в Service Fabric и каковы передовые методы, связанные с ними. В основном интересует неисправное состояние служб. Восстанавливаются ли службы, если они находятся в неисправном состоянии? Или должна быть глобальная обработка исключений для необработанных исключений, если такая концепция вообще существует в SF. Я не нашел много по этой теме поиском.
Необработанные исключения Service Fabric и рекомендации
Ответы (2)
В моей компании мы создали код для повторного использования в соответствии с рекомендации по использованию ITransaction, которые позволяют нам запускать любой произвольный код и дополнять его соответствующей обработкой исключений и политиками повторных попыток. В этой документации есть руководство о том, как различные типы исключений должны влиять на метод RunAsync, а также как они должны влиять на методы, являющиеся частью удаленной конечной точки.
Как правило, обработка любых исключений, помимо того, что обсуждается в документации, зависит от вас. Что касается меня, я просто позволю исключению всплыть и позволю сервису выйти из строя, если это неожиданное исключение. Ожидаемые исключения всегда следует обрабатывать с помощью соответствующей политики повторных попыток.
person
pixelTitan
schedule
05.09.2019
Ваш вопрос довольно широкий, и ответ меняется в зависимости от типа микросервиса. Для начала, также получив представление об обширности этой темы, стоит взглянуть на мониторинг работоспособности Service Fabric и связанные подразделы. Как видите, существует множество вариантов конфигурации, и по моему опыту (я работаю архитектором Microsoft Azure) не существует универсального решения, универсального для всех. Единственной лучшей практикой является разработка управления исключениями, которое лучше всего подходит для вашего проекта, максимально используя политики работоспособности Fabric.
person
Pino De Francesco
schedule
01.08.2016
Что ж, ошибочное состояние для надежных сервисов (которое я должен был упомянуть) на самом деле не является общим вопросом. Различные сервисы по-разному обрабатывали состояния сбоя. Мне просто любопытно, как надежные службы без сохранения состояния справляются с неисправным состоянием. Похоже, что любые сбои, возникающие во время runasync и вызывающие состояние сбоя, в конечном итоге заставят SF перезапустить службу. Хотя на самом деле об этом мало кто говорит.
- person g.t.w.d; 02.08.2016
@ g.t.w.d Я считаю, что причина, по которой по этой теме очень мало информации, заключается в том, что ее много в двух пересекающихся областях: (1) работоспособность Service Fabric и (2) надежное состояние службы. Они пересекаются, используя System.Fabric.Health в службе, чтобы позволить монитору работоспособности Fabric реагировать на события, инициированные в Fabric управлением состоянием службы.
- person Pino De Francesco; 02.08.2016
