Как проложить маршрут между микросервисами, используя Spring Cloud & Netflix OSS

Во время разработки микросервисов с использованием Spring Cloud мы начали использовать Zuul в качестве прокси-сервера для любого подключения извне к микросервисам и для любого микросервиса, нуждающегося в контакте с другим микросервисом.

Через некоторое время мы сделали вывод о том, что Zuul был разработан как краевое обслуживание (только проксирование трафика извне в микросервисы) и не должно использоваться для обмена межмикросервисами. Тем более, что Cloud рекомендует использовать eureka для прямого (потенциально нагруженного сбалансированного) соединения с другой службой, заставило нас идти против того, чтобы Zuul находился между всеми.

Конечно, все работает прекрасно, как и ожидалось (как это всегда бывает с Spring Cloud), но мы не знаем, как выполнить определенный прецедент с этой настройкой.

При развертывании новой версии микросервиса мы хотели бы иметь сине-зеленое развертывание со старой и новой версиями. Однако, не имея Zuul между микросервисами, связь между двумя отдельными службами будет продолжать идти до старой версии, пока она не будет удалена из eureka.

Мы думаем о том, как мы можем достичь этого. На рисунке ниже я нарисовал, что, по-моему, может быть вариантом.

В первой части рисунка Зуул называет эврика, чтобы получить реестр для создания маршрутов. Также служба 1 вызывает eureka, чтобы получить реестр для маршрутизации на услугу 2. Поскольку служба 2 находится в реестре eureka, маршрутизация выполняется успешно.

Во второй части изображения развернуто обновление службы 2 (сервис 2.1). Он регистрируется также с eureka, что делает сервис 1 теперь маршрутизируемым как на сервис 2, так и на сервис 2.1. Это не требуется при развертывании синего/зеленого.

В третьей части потенциальное решение этой проблемы демонстрируется с помощью другого экземпляра эврики, который развертывается именно для этой цели. Этот экземпляр не известен и не синхронизируется с первым экземпляром eureka. В отличие от первого экземпляра, это единственная цель - облегчить развертывание синего и зеленого. Service 2.1 регистрирует второй экземпляр eureka, а сервис 1 его конфигурацию изменяет, чтобы извлечь его реестр не из первого, а из второго экземпляра eureka.

Главный вопрос, с которым мы сталкиваемся, - это жизнеспособное решение. Наличие гибкости Zuul для маршрута - большой плюс, которого у нас нет в этом сценарии. Должны ли мы вернуться к маршрутизации каждого вызова службы на обслуживание через Zuul или же вам подходит другое решение (возможно, какая-то ленточная конфигурация)? Или второй экземпляр eureka - лучшее решение для такого типа развертываний?

Ответы

Ответ 1

Установив номер версии в метаданных, вы можете легко сделать свой Svc1 выборкой последней версии Svc2, т.е. всегда получая экземпляр с последним номером версии. См. этот смысл в качестве руководства.