Ценность Эврика в облачном литейном/PaaS-окружении?

Question

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

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

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

Спасибо,

Лешек

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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