Куда должен идти автоматический выключатель?
Я разрабатываю новый REST API, и я видел, как в некоторых проектах автоматический выключатель помещается в Controller
. Раньше я помещал его в DAO
.
Первое отличие, которое я могу сказать, заключается в том, что размещение его в том DAO
, что каждая служба, которая использует эту третью сторону, будет открыта в сценарии ошибки. И размещение его в Controller
, ВСЕГДА открыло бы каждый маршрут, который использует эту третью сторону; так что не сразу. Но второй вариант (в Controller
) кажется более простым.
Какие-нибудь рекомендации о том, куда это должно быть?
Ответы
Этот ответ состоит из двух частей. К первой части уже обратился Роберт Харви в своем комментарии:
- Согласно каталогу шаблонов микросервисов Криса Ричардсона, автоматический выключатель должен находиться в прокси для удаленной службы. API Gateway - хорошее место для этого.
- Другой альтернативой является обнаружение на стороне сервера, особенно если стратегия восстановления подразумевает поиск других запущенных экземпляров той же службы.
Но есть вторая часть. Задача автоматического выключателя - быстро выйти из строя, если обнаруживается, что обслуживание недоступно, вместо того, чтобы накапливать шаги, которые впоследствии не удастся, что приведет к большому разочарованию. Таким образом, автоматический выключатель получает полное представление только в том случае, если потребляющая служба готова среагировать на разрыв:
- Возможно, удаленная служба имеет важное значение, и потребляющая служба может решить приостановить работу (то есть внутренний автоматический выключатель).
- Возможно, удаленная служба не является существенной, и потребляющая служба может решить продолжить работу, но в ухудшенном режиме.
- (прерыватели на основе обнаружения службы, вероятно, не откажутся, но найдут другую работающую службу, и потребители этого не заметят).
С общей точки зрения, такой выбор поведения является обязанностью контроллера: контроллер координирует работу между элементами службы и может адаптировать обработку на основе информации о сбое.
Однако, если в вашем случае речь идет только о получении данных из другого места, и если ваша стратегия обработки ошибок всегда одинакова (нет разницы между существенным и несущественным; например, попробуйте использовать кешированное значение, если оно доступно, и не удастся иначе), вы вполне мог решить поставить его в дао имхо.