AWS ELB против Service Registry
В архитектуре микросервисов не рекомендуется жестко кодировать URL-адреса служб в коде или в конфигурациях, поскольку это может измениться. Для этого мы используем шаблон обнаружения сервисов. Но того же можно добиться с помощью AWS ELB. После того, как я зарегистрирую свои сервисы в ELB и если я жестко закодирую его URL-адрес, изменение IP-адреса сервиса не произойдет, поскольку URL-адрес ELB останется прежним.
Итак, в чем разница между жесткое кодирование URL-адреса AWS ELB в конфигурации кода и использованием инструменты реестра служб, такие как Eureka, Istio?
Ответы 2
Реестр служб, такой как Eureka, является примером обнаружения служб на стороне клиента. AWS ELB представляет собой обнаружение сервисов на стороне сервера.
Пожалуйста, пройдите - https://microservices.io/patterns/service-registry.html для более глубокого погружения.
Я вижу два основных отличия в обнаружении сервисов с помощью таких инструментов, как Eureka, Istio или AWS ELB.
Используя AWS ELB, вы являетесь своего рода зависимым, облачным поставщиком или поставщиком облачных услуг. Теперь ваше развертывание связано с облачным сервисом. Теперь, в будущем, если вам придется сменить облако (скажем, вы по какой-то причине хотите перейти на Azure), то миграция потребует дополнительных усилий, так как вам нужно будет настроить часть couter для обнаружения облачных сервисов в новом облаке. Но в случае прямого использования Eureka или istio вам просто нужно развернуть свои артефакты и соответствующую конфигурацию на новой облачной платформе.
Второе отличие заключается в том, как внутренний клиент может обнаруживать целевые службы.
Есть два шаблона для обнаружения сервисов:
Эврика, Istio - это Обнаружение службы на стороне клиента Клиент обращается напрямую к реестру служб и получает полный адрес (хост и порт) вызываемой службы. Итак, в конце концов, клиент знает хост и порт службы, а клиент - это тот, кто делает последний запрос к целевой службе, поэтому это называется обнаружением на стороне клиента.
AWS ELB Обнаружение служб на стороне сервера Клиент обращается к балансировщику нагрузки (или маршрутизатору). Маршрутизатор внутренне обнаруживает адрес службы через реестр служб, а затем выполняет дальнейший вызов целевой службы.
Главное отличие -
- Клиент никогда не узнает адрес целевой службы, или клиенту никогда не нужно знать детали целевой службы.
- Клиентский код становится проще, поскольку ему не нужно заниматься обнаружением сервисов.