Как выполнять маршрутизацию между микросервисами с помощью Spring Cloud и Netflix OSS

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

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

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

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

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

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

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

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

введите описание изображения здесь

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

Любая обратная связь будет принята с благодарностью.

С уважением, Андреас


person Andreas Evers    schedule 09.07.2015    source источник
comment
Сказочный вопрос и схемы. Вы правы, зуул предназначен как пограничный шлюз. Это то, над чем мы работаем. Netflix использует Asgaard и AWS Auto Scale Groups для развертывания. Моя первая мысль - запустить новую версию, но OUT_OF_SERVICE в eureka, а затем одновременно отметить старую версию OUT_OF_SERVICE и новую как UP. Установить статус можно с помощью Spring Cloud Bus. Ожидайте больше последующих сообщений здесь.   -  person spencergibb    schedule 10.07.2015
comment
Разве мы не можем поиграть с метаданными экземпляра? Их можно динамически изменять с сервера Eureka после регистрации службы (см. github.com / Netflix / eureka / wiki / Eureka-REST-operations - обновить метаданные). Затем мы могли бы создать экземпляры ленточного фильтра, полученные от Eureka, на основе этой информации.   -  person Bertrand Renuart    schedule 16.07.2015


Ответы (1)


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

person lawal    schedule 17.07.2015
comment
Спасибо! Это помогло мне решить еще несколько проблем со стеком Netflix в целом. Кое-где нет документации. Подобные гисты очень помогают. - person Ryan J. McDonough; 02.08.2015
comment
Я не хочу разрушать чары, но мне кажется, что это серьезный взлом. Как мы собираемся вернуться к предыдущей версии, если что-то пошло не так? - person Cengiz Can; 04.02.2016