Как выполнить маршрутизацию между микросервисами с помощью Spring Cloud и Netflix OSS
Во время разработки микросервисов с использованием Spring Cloud мы начали использовать Zuul в качестве прокси-сервера для любого подключения извне к микросервисам и для любого микросервиса, которому необходимо связаться с другим микросервисом.
Через некоторое время мы пришли к выводу, что Zuul был спроектирован как пограничный сервис (только перенаправляющий трафик извне на микросервисы) и не должен использоваться для связи между микросервисами. В особенности то, как Spring Cloud рекомендует использовать eureka для прямого (потенциально сбалансированного по нагрузке) соединения с другим сервисом, заставило нас отказаться от использования Zuul между всем.
Конечно, все работает хорошо, как и ожидалось (как это всегда происходит в Spring Cloud), но мы не знаем, как выполнить определенный сценарий использования с этой настройкой.
При развертывании новой версии микросервиса мы хотели бы иметь сине-зеленое развертывание со старой и новой версией. Однако, не имея Zuul между микросервисами, связь между двумя отдельными сервисами будет продолжать переходить к старой версии, пока она не будет удалена из eureka.
Мы думаем о том, как мы можем достичь этого. На рисунке ниже я нарисовал то, что я думаю, может быть вариантом.
В первой части рисунка Зуул вызывает eureka, чтобы получить реестр для создания маршрутов. Также служба 1 вызывает eureka для получения реестра для маршрутизации к службе 2. Поскольку служба 2 находится в реестре eureka, маршрутизация выполнена успешно.
Во второй части рисунка развернуто обновление службы 2 (службы 2.1). Он также регистрируется с помощью eureka, что делает сервис 1 маршрутизирующим как к сервису 2, так и к сервису 2.1. Это не требуется с синим / зеленым развертыванием.
В третьей части потенциальное решение этой проблемы демонстрируется другим экземпляром eureka, развернутым только для этой цели. Этот экземпляр не распознает одноранговый узел и не будет синхронизироваться с первым экземпляром eureka. В отличие от первого случая, единственной целью этого является содействие сине-зеленому развертыванию. Служба 2.1 регистрируется со вторым экземпляром eureka, а служба 1 изменяет свою конфигурацию так, чтобы получать ее реестр не из первого, а из второго экземпляра eureka.
Главный вопрос, с которым мы сталкиваемся, заключается в том, является ли это жизнеспособным решением. Гибкость маршрута Zuul - большой плюс, которого у нас нет в этом сценарии. Должны ли мы вернуться к маршрутизации каждого вызова между сервисами через Zuul или есть более подходящее другое решение (может быть, конфигурация ленты)? Или второй экземпляр eureka - лучшее решение для этого типа развертываний?
Любая обратная связь будет принята с благодарностью.
С уважением, Андреас
1 ответ
Установив номер версии в метаданных, вы можете легко заставить Svc1 извлекать последнюю версию Svc2, то есть всегда получать экземпляр с последним номером версии. Смотрите эту суть как руководство.