Hystrix как услуга

Question

Основываясь на примерах, найденных в сети, Hystrix Circuit Breaker предполагается использовать в качестве библиотеки-оболочки поверх исходящих вызовов службы.По сути, это означает, что нужно корректировать код и внедрять зависимости для всех существующих проектов.Это может оказаться очень дорогостоящим и рискованным.

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

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

Кто-нибудь реализовывал такое решение?Это вообще возможно?Если нет, то имеет ли смысл использовать Hystrix как часть шлюза API?

Отказ от ответственности: я искал похожие вопросы, но не мог найти ничего похожего.

Answer 1

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

В этом случае у вас будут ложные отрицания, отключающие цепь, когда в действительности она не должна быть отключена.В то же время, скажем, сервис должен был снова стать живым, «Hysterix как сервис» должен каким-то образом дать понять вышестоящему сервису, что ответ может быть доступен.Учитывая все вышесказанное, кажется, что было бы лучше, если бы это была библиотека или коляска, на которую физическая сеть не влияла.