Обнаружение служб и балансировка нагрузки

Я пытаюсь понять, в каком сценарии я должен выбрать реестр служб для балансировки нагрузки.

По моему мнению, оба решения покрывают одну и ту же функциональность.

Например, если мы рассматриваем consul.io как список функций, мы имеем:

  • Обнаружение служб
  • Проверка работоспособности
  • Ключ/хранилище значений
  • Multi Datacenter

Если балансировщик нагрузки, например Amazon ELB, имеет:

  • настраивается для приема трафика только с вашего балансира нагрузки
  • принимать трафик, используя следующие протоколы: HTTP, HTTPS (защищенный HTTP), TCP и SSL (защищенный TCP)
  • распространяет запросы на экземпляры EC2 в нескольких зонах доступности
  • Количество подключений масштабируется с количеством одновременных запросов, получаемых балансировщиком нагрузки.
  • настроить проверки работоспособности, которые использует балансировка эластичной нагрузки для мониторинга работоспособности экземпляров EC2, зарегистрированных с помощью балансировщика нагрузки, чтобы он мог отправлять запросы только в здоровые экземпляры.
  • Вы можете использовать сквозное шифрование трафика в тех сетях, где используются безопасные (HTTPS/SSL) соединения
  • [EC2-VPC] Вы можете создать балансировщик нагрузки, ориентированный на Интернет, который обрабатывает запросы клиентов через Интернет и перенаправляет их в ваши экземпляры EC2 или внутренний балансировщик нагрузки, который принимает запросы от клиентов в вашем VPC и направляет их в экземпляры EC2 в ваших частных подсетях. Балансиры нагрузки в EC2-Classic всегда обращены к Интернету.
  • [EC2-Classic] Балансиры нагрузки для EC2-Classic поддерживают адреса IPv4 и IPv6. Балансиры нагрузки для VPC не поддерживают адреса IPv6.
  • Вы можете контролировать свой балансировщик нагрузки с помощью показателей CloudWatch, журналов доступа и AWS CloudTrail.
  • Вы можете связать свой балансировщик нагрузки, ориентированный на Интернет, с вашим доменным именем.
  • и др.

Итак, в этом сценарии я не понимаю, почему я бы выбрал что-то вроде consul.io или netflix eureka над Amazon ELB для обнаружения службы.

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

Ответы

Ответ 1

Вы должны подумать об этом как балансировку нагрузки на стороне клиента, а также о балансировке нагрузки.

Балансиры нагрузки на стороне клиента включают Baker Street (http://bakerstreet.io); SmartStack (http://nerds.airbnb.com/smartstack-service-discovery-cloud/); или Consul HA Proxy (https://hashicorp.com/blog/haproxy-with-consul.html).

LBs на стороне клиента используют компонент обнаружения службы (Baker Street использует механизм обнаружения публичных пабов/вспомогательных служб, SmartStack использует ZooKeeper, Consul HA Proxy использует Consul) как часть их реализации, но они обеспечивают проверку работоспособности/завершение которые вы, вероятно, ищете.

Ответ 2

У компонента Service Discovery обычно есть компонент уведомления. Это не балансировка нагрузки, хотя некоторые из них могут это сделать. Он может уведомлять зарегистрированных клиентов об изменениях, например, о снижении нагрузки.

Клиент может запросить обнаружение/реестр службы, чтобы запустить балансировщик нагрузки. Принимая во внимание, что балансировщик нагрузки не имеет никакого отношения к клиенту при его отсутствии.

Ответ 3

AWS ELB и Eureka отличаются во многих аспектах:

Edge Services и сервисы среднего уровня
AWS ELB - это решение для балансировки нагрузки для краевых служб, работающих с веб-трафиком конечного пользователя. Эврика заполняет потребность в балансировке нагрузки среднего уровня.
Сервер среднего уровня относится к серверу приложений, который находится между пользовательской машиной и сервером базы данных, на котором выполняется обработка. Сервер среднего уровня выполняет бизнес-логику.
Хотя теоретически вы можете разместить свои сервисы среднего уровня позади AWS ELB, в EC2 Classic вы выставляете их во внешний мир и тем самым теряете всю полезность групп безопасности AWS.

Выделенная балансировка нагрузки на стороне клиента
AWS ELB также представляет собой традиционное решение для балансировки нагрузки на основе прокси-сервера, тогда как с Eureka это отличается тем, что балансировка нагрузки происходит на уровне экземпляра/сервера/хоста циклически. Экземпляры клиента знают всю информацию о том, с какими серверами они должны разговаривать.
Если вы ищете липкий сеанс пользователя (все запросы от пользователя во время сеанса отправляются на тот же экземпляр), на основе балансировки нагрузки, который предлагает AWS, Eureka не предлагает решение из коробки.

Отключение балансировки нагрузки
Другим важным аспектом, который отличает балансировку нагрузки на основе прокси-сервера от балансировки нагрузки с использованием Eureka, является то, что ваше приложение может быть устойчивым к отключению балансировщика нагрузки, поскольку информация о доступных серверах кэшируется клиентом Eureka.
Это требует небольшого объема памяти, но покупает лучшую отказоустойчивость. Клиент Eureka получает всю информацию реестра сразу и в последующих запросах на сервер Eureka, он получает только дельта, то есть изменения в информации реестра, а не всю информацию реестра. Кроме того, серверы Eureka могут работать в режиме кластера, где каждый партнер не зависит от производительности других одноранговых узлов.

Масштаб и удобство
Кроме того, представьте себе, что 1000s микросервисов работают, и каждый из них имеет несколько экземпляров. Вам понадобится 1000 ELB, по одному для каждого из микросервисов, или что-то вроде HAProxy, который сидит за ELB, чтобы принимать решения уровня 7 на основе имени хоста и т.д., А затем перенаправлять трафик на подмножество экземпляров. В то время как с Eureka вы играете только с именем приложения, которое намного менее сложно.

Ответ 4

Вы также должны прочитать о EUREKA

Amazon ELB предоставляет экземпляры EC2 для ваших запросов на обслуживание на основе балансировщика нагрузки, а IP-адреса экземпляров EC2 несовместимы, поэтому вы также можете использовать EUREKA, которая выполняет ту же работу, но основана на балансировке нагрузки служб и клиентской нагрузки в котором клиент приложения для каждого региона имеет реестр. Вы можете прочитать больше об этом здесь: https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance