Как справиться с отступлением Hystrix в Zuul?

Question

Я новичок в микро-сервисах, поэтому, пожалуйста, помогите мне в этом вопросе,

Я работаю над простым проектом микро-сервисов с весенней загрузкой, zuul, hystrix и eureka. Один из сервисов вызывает данные из другого сервиса. Но когда служба не работает, ответ равен 500, поэтому для получения ожидаемого результата необходимо отправить запрос еще раз.

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

Заранее спасибо.

Answer 1

Во-первых, для недоступной услуги, вероятно, больше подойдет http-код 503.

Тогда Zuul - это шлюз API, а не служба me sh. Я думаю, что вы смешиваете обе концепции здесь.

Цель шлюза API состоит в том, чтобы принимать трафик c извне вашей сети и распространять его внутри ... и таким образом абстрагировать его сложность (на самом деле это распределенная фасад / маршрутизатор). Пример: zuul, spring cloud gateway

Служба me sh действует как посредник между микросервисами и обеспечивает такие аспекты связи, как автоматические c попытки, автоматический выключатель, отслеживание, ведение журнала.

Пример Istio, Linkerd

Но вы можете go без обслуживания меня sh для реализации этой задачи. Микросервис вызывающей стороны может защитить себя, реализовав таймаут, повторные попытки и автоматические выключатели, встроив мощную библиотеку, такую ​​как resilience4j. (Hystrix на самом деле в конце своей жизни)

Эта библиотека предоставит вам API, позволяющий вам обернуть связь с внешним (другими микросервисами) через специальный прокси, который будет обрабатывать повторные попытки и / или автоматические выключатели для вас. Вы должны посмотреть: https://github.com/resilience4j/resilience4