Какова концептуальная разница между инструментами Service Discovery и Load Balancers, которые проверяют здоровье node?

Недавно несколько популярных инструментов поиска услуг стали популярными / "mainstream", и Im задается вопросом, в каких случаях первичного использования их следует использовать вместо традиционных балансировщиков нагрузки.

С LB вы кластерируете узел узлов за балансиром, а затем клиенты делают запросы к балансировщику, который затем (обычно) обходит все запросы на всех узлах кластера.

С обнаружением службы (Consul, ZK и т.д.), вы позволяете централизованному "консенсусному" сервису определять, какие узлы для конкретного сервиса здоровы, а ваше приложение подключается к узлам, которые служба считает здоровыми. Таким образом, пока обнаружение сервисов и балансировка нагрузки представляют собой две отдельные концепции, обнаружение служб дает вам балансировку нагрузки как удобный побочный эффект.

Но, если балансировщик нагрузки (скажем HAProxy или nginx) имеет встроенные в него мониторинг и проверки работоспособности, то вы в значительной степени получаете обнаружение службы как побочный эффект балансировки нагрузки! Если мой LB не хочет пересылать запрос на нездоровый node в своем кластере, то это функционально эквивалентно консенсусному серверу, сообщающему моему приложению, чтобы он не подключался к неутешительному node.

Таким образом, инструменты для обнаружения услуг выглядят как "6-в-одном, полдюжины в другом", эквивалентные балансировщикам нагрузки. Я что-то упустил? Если у кого-то была архитектура приложения, полностью основанная на сбалансированных по нагрузке микросервисах, каково преимущество (или нет) перехода на модель обнаружения на основе сервисов?

3 ответа

Балансирам нагрузки обычно требуются конечные точки ресурсов, которые он балансирует нагрузку на трафик. С ростом микросервисов и приложений на основе контейнеров, созданные во время выполнения динамические контейнеры (контейнеры докеров) являются эфемерными и не имеют статических конечных точек. Эти конечные точки контейнеров являются эфемерными, и они меняются по мере их выселения и создаются для масштабирования или по другим причинам. Инструменты обнаружения сервисов, такие как Consul, используются для хранения информации о конечных точках динамически создаваемых контейнеров (контейнеров докеров). Такие инструменты, как консул-регистратор, работающий на контейнерах, регистрирует конечные точки контейнера в инструментах обнаружения сервисов, таких как консул. Такие инструменты, как Consul-template, будут прослушивать изменения конечных точек контейнера в консуле и обновлять балансировщик нагрузки (nginx) для отправки трафика. Таким образом, обе службы Discovery Tools, такие как инструменты Consul и Load Balancing, такие как Nginx, сосуществуют для обеспечения обнаружения службы времени выполнения и возможности балансировки нагрузки соответственно.

Последующие действия: каковы преимущества эфемерных узлов (те, которые приходят и уходят, живут и умирают) против "постоянных" узлов, таких как традиционные виртуальные машины?

[DDG]: все, что приходит мне на ум: эфемерные узлы, такие как контейнеры докеров, подходят для служб без состояния, таких как API и т.д. (Существует тяга к постоянным контейнерам с использованием внешних томов - драйверы томов и т.д.)

  • Скорость: Скручивание или уничтожение эфемерных контейнеров (контейнеров докеров с изображения) занимает менее 500 миллисекунд, в отличие от минут при стоянии традиционных виртуальных машин

  • Эластичная инфраструктура: в век облака мы хотим масштабироваться и в соответствии с потребностями пользователей, что подразумевает наличие контейнеров с эфемерным характером (возможно, для IP-адресов и т.д.). Подумайте о маркерной кампании на неделю, для которой мы ожидаем увеличение трафика TPS на 200%, быстро масштабируемся с помощью контейнеров, а затем публикуем кампанию, уничтожаем ее.

  • Использование ресурсов: Центр данных или Cloud теперь представляют собой один большой компьютер (вычислительный кластер), а контейнеры упаковывают вычислительный кластер для максимального использования ресурсов и во время слабого спроса разрушают инфраструктуру для более низкого использования ресурсов/ресурсов.

Многое из этого возможно из-за потери связи с эфемерными контейнерами и обнаружения времени выполнения с использованием инструмента обнаружения сервисов, такого как консул. Традиционные виртуальные машины и жесткое связывание IP-адресов могут заглушить эту возможность.


Обратите внимание, что эти два варианта не обязательно являются взаимоисключающими. Возможно, например, что вы все равно можете перенаправлять клиентов на балансировщик нагрузки (который мог бы выполнять другие роли, такие как дросселирование), но иметь балансировщик нагрузки, используя реестр служб для поиска экземпляров.

Также стоит отметить, что обнаружение службы позволяет балансировку нагрузки на стороне клиента, то есть клиент может вызвать услугу напрямую без дополнительного перехода через балансировщик нагрузки. Я понимаю, что это была одна из причин того, что Netflix разработала Eureka, чтобы избежать звонков между службами, которые должны были выйти и вернуться через внешний ELB, за которые им пришлось бы платить. Балансировка нагрузки на стороне клиента также обеспечивает средство, позволяющее клиенту влиять на решение балансировки нагрузки на основе собственной перспективы доступности услуг.


Если вы посмотрите на инструменты с совершенно другой точки зрения, а именно на ITSM/ITIL, балансировка нагрузки станет "именно такой", тогда как обнаружение сервисов является частью постоянного обновления CMDB, а также всех ваших услуг и их взаимосвязи, для лучшей видимости воздействия, в случае простоя и обзора областей, которые могут потребоваться дополнять, в случае приложений с высокой степенью готовности.

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

licensed under cc by-sa 3.0 with attribution.