Ценность Eureka в среде Cloud Foundry/PaaS?

Мы работаем над собственным облачным приложением, которое будет развернуто в Cloud Foundry, и после первоначального «давайте использовать все преимущества Netflix» мы начали задаваться вопросом, оправдывает ли совпадение с CF использование компонентов Netflix.

Особенно в случае с Eureka, мы планировали использовать его для обнаружения сервисов, но очень похожие возможности предоставляются из коробки CF и маршрутами. Чего бы нам не хватило, так это регистрации сервисов во время выполнения (что в случае архитектуры, которая не часто меняется, не является большой проблемой и на самом деле будет статической картой маршрута serviceID -> CF) и сердцебиения (на уровне приложений, поскольку Я предполагаю, что на уровне контейнера CF следит за тем, чтобы все было в порядке).

Итак, теперь мне интересно - как вы используете его в своих приложениях (приложениях из реальной жизни) при использовании CF? Каковы преимущества сохранения его в архитектуре?

Спасибо,

Лешек

PS. Интересно отметить, что если eureka хранит простую карту маршрута serviceID -> CF, то, если я прав, значение Zuul также снижается (поскольку LB будет доставляться CF, а gorouter — очень хороший вариант).


netflix-eureka cloud-foundry spring-cloud
person Lech Migdal    schedule 12.04.2016    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Eureka использует идентификаторы приложений для обнаружения служб, которые существуют только в контексте дизайна вашего приложения. Маршрутизация Cloud Foundry использует URL-адреса для адресации, что вводит зависимость вашего кода от базовой инфраструктуры.

Если мне нужно получить доступ к account-service, я бы хотел запросить его по этому имени. URL-адрес для этой службы будет отличаться в зависимости от того, провожу ли я тестирование на своем локальном компьютере, запускаю развернутый экземпляр QA или работаю в рабочей среде. Я не хочу, чтобы мое приложение знало, где оно работает и какие URL-адреса соответствуют какой среде. В любом случае, вполне вероятно, что эти URL-адреса могут меняться со временем.

Если я использую Eureka, то я просто прошу account-service, и проблемы, связанные со средой, абстрагируются от моего приложения.

person Corby Page    schedule 17.04.2016
comment
Ну, это верно, если мы предполагаем, что URL-адреса жестко закодированы, но что, если мы используем службу конфигурации (которую, я надеюсь, большинство людей в любом случае используют в настоящее время) для хранения информации о serviceID -> сопоставление маршрутов облачного литейного производства? Отображение будет другим для локальной машины, для QA и для PROD (отличается профилем Spring) и будет абстрагироваться от моего приложения. Если я прав, этот подход даст мне именно то, что Eureka дает в CF, но исключит один компонент (Eureka Server) плюс клиентские библиотеки Eureka из каждой службы. Итак, чистая победа с моей точки зрения...? :) - person Lech Migdal; 18.04.2016
comment
Это, безусловно, жизнеспособный подход, но он требует, чтобы вы поддерживали маршруты в двух местах и ​​синхронизировали их. Вам нужно будет определить маршрут, связанный с cf (например, в manifest.yml), а затем определить соответствующий маршрут в config-server. Если что-то меняется, нужно исправлять в обоих местах. В более крупных развертываниях лучше избегать подобных неавтоматизированных задач синхронизации. Но если это работает для вас в вашей среде, это здорово! - person Corby Page; 18.04.2016
comment
Хорошая точка зрения. Так что теперь мне интересно - если у нас уже есть Redis в архитектуре, то такое сопоставление serviceID -> route можно было бы сохранить в Redis. Преимущества - никаких дополнительных компонентов, при всей ценности Эврики, если я прав? - person Lech Migdal; 18.04.2016
comment
С функциональной точки зрения это возможно. Тем не менее, Eureka специально создана для обнаружения сервисов, поэтому вы получаете готовые функции, которые вам придется создавать самостоятельно в пользовательской настройке Redis. Поддержка RestTemplate, многоязычные клиенты, выделенный пользовательский интерфейс, поддержка ленты и т. д. Благодаря Spring Cloud Services вы также получаете поддержку OAuth2 для безопасного развертывания и высокой доступности в следующей версии. Компромисс между развертыванием новой части инфраструктуры и необходимостью обновления пользовательской настройки Redis, чтобы не отставать от новых функций Eureka, которые вам нужны. - person Corby Page; 19.04.2016
comment
Спасибо, это имеет смысл. Я думаю, что мы будем тестировать вариант сервисного реестра с кластером redis, так как это уже ключевой элемент нашей архитектуры, и я все еще борюсь с Eureka :) Теперь я думаю о ленте - какова ценность, которую вы видите в ее использовании с CF ? С одним маршрутом для каждой службы и LB, выполненным на уровне маршрутизатора CF, балансировка нагрузки на стороне клиента кажется довольно сложной? :) (если не используется маршрутизатор CF) - person Lech Migdal; 21.04.2016
comment
Да, я предпочитаю не использовать балансировку нагрузки на стороне клиента, когда доступна маршрутизация CF. Я просто привел пример функциональности обнаружения сервисов в Eureka, которая не была бы доступна в собственном решении. - person Corby Page; 21.04.2016
comment
Небольшое обновление (через месяц) - мы все равно остановились на Эврике, по причинам, которые вы упомянули - в какой-то момент я устал настраивать маршруты в слишком многих местах (включая Зуул) ;-) Опять - спасибо за помощь! - person Lech Migdal; 01.06.2016
comment
В случае, если это еще не было обнаружено — я не могу найти его здесь — вы можете настроить клиент Eureka для объявления IP: порта вместо маршрута HTTP. Таким образом, например. Используя Ribbon, вы можете запускать балансировку нагрузки для отдельных экземпляров. Имейте в виду, однако, что ваш экземпляр CF должен позволять экземплярам приложений связываться друг с другом, минуя маршрутизатор CF. - person C-Otto; 13.01.2017

arrow_upward
3
arrow_downward

С облачным литейным производством мы также чувствовали, что использование eureka может быть излишним. но Мы сделали одну вещь для экстернализации и токенизации имен службы. Первоначально нам нужна была служба конфигураций Spring для управления конфигурацией, но мы чувствовали, что ее также можно использовать в качестве центрального источника карт URL-адресов службы. (необходимо было написать специальный код для загрузки из центрального источника данных).

Мы создали службу конфигурации Spring с настраиваемым хранилищем данных, которое содержит множество вещей, таких как пароли, URL-адреса службы и т. д. Используя чашки, мы подключаемся к службе конфигурации Spring, а шаблон конфигурации содержит набор токенов, которые затем преобразуются в URL-адреса службы на лету. .

Первоначально нам нужна служба конфигураций Spring для управления конфигурацией, но мы чувствовали, что ее можно использовать в качестве центрального источника URL-адреса службы (для загрузки из источника данных необходимо было написать собственный код).

В Cloud Foundry нет IP-адресов и портов, поэтому нет необходимости отслеживать проверку работоспособности отдельного экземпляра для балансировки нагрузки. CF делает это внутренне довольно хорошо из коробки. Итак, все, что вам нужно, — это центральный источник данных, чтобы сопоставить нам имя host.domain с ключами/токенами. например. membership.v1=https://membership-1-0-2.

Но если вы хотите, чтобы одна транзакция, затрагивающая CF, могла вызывать службу, размещенную в нескольких центрах обработки данных, вам понадобится eureka или consul.io, чтобы преодолеть это. Кластеры CF не охватывают центры обработки данных.

person Sameer Tandon    schedule 23.05.2017
comment
Одно короткое обновление, когда я наткнулся на ваш ответ: youtu.be/DLjtm-v9DOM показывает новую функцию. CloudFoundry, чтобы он мог работать в нескольких центрах обработки данных, используя CPI, интерфейс облачного провайдера. - person Bernd; 28.06.2018