【Перевод】Стратегия балансировки нагрузки Consul

Consul— это бесплатный инструмент с открытым исходным кодом, который обеспечивает обнаружение служб, проверку работоспособности, балансировку нагрузки и глобально распределенное хранилище ключей и значений. Кроме того, он предоставляет набор базовых элементов для построения рабочих процессов и инструментов бизнес-процессов. В микросервисной архитектуре приложения обычно работают по нескольким IP-адресам и привязываются к разным портам. Обнаружение служб помогает найти эти различные службы независимо от того, где они расположены.

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

Используйте консуль напрямую

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

Рассмотрим следующий файл конфигурации, который включает IP-адрес серверной службы:

services: 
  backend: 10.2.5.391

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

services: 
  backend: backend.service.consul

как"www.hashicorp.com" - это веб-адрес, как и "backend.service.consul". Здесь TLD или суффикс домена настраивается, но по умолчанию.Consul. Любые запросы, заканчивающиеся этим TLD, будут разрешены в консул. здесь.serviceПространство имен рассказывает консулу искать сервис (не узел машины),. backendимя службы для поиска. Запросы к «backend.service.consul» разрешаются в набор IP-адресов, например «www.hashicorp.com"разрешается в набор IP-адресов. Однако для Consul это разрешение происходит на уровне обнаружения службы и интегрирует механизм проверки работоспособности.

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

преимущество:

• Отсутствие зависимости от внешних инструментов или процессов
• Никакие другие службы не используются для мониторинга или обслуживания
• По умолчанию очень доступны
• максимально близко к реальному времени
• DNS прост в использовании с минимальными усилиями
• Проверки работоспособности распределены, а нагрузка на кластер минимальна.

недостаток:

• Единая точка отказа — несмотря на то, что Consul по умолчанию высокодоступен, этот режим не обеспечивает аварийное переключение, если Consul недоступен или недоступен.
• Требовать прямого использования HTTP API в приложении или выполнить DNS-запрос, предполагая порт, или выполнить два DNS-запроса, чтобы найти адрес и порт.
• Применение сильного соединения консула

Fabio

Fabio— это инструмент с открытым исходным кодом, который предоставляет быстрые, современные маршрутизаторы HTTP(s) и TCP с нулевой конфигурацией и балансировкой нагрузки для сервисов, управляемых Consul. Пользователи подписываются на услуги Consul, предоставляют проверки работоспособности, и Fabio автоматически направляет к ним трафик. Никакой дополнительной настройки не требуется.

Пользователь регистрируется на сервисе, используяurlprefix-тег в начале, например:

urlprefix-/my-service

В этом примере, когда к Fabio делается запрос на /my-service, Fabio автоматически направляет трафик в службу работоспособности в кластере. Fabio также поддерживает более продвинутыеконфигурация маршрутизации.

преимущество:

• Широкая интеграция с Consul
• Больше контроля над балансировкой нагрузки, чем методы DNS
• Сильная поддержка сообщества и более 4000 звезд GitHub
• Поддержка TCP-прокси
• Ведение журнала доступа и множество других похвальныхФункции
• Интегрированное хранилище HashiCorp
• Дополнительный веб-интерфейс для визуализации маршрута
• Очень подробная документация с открытым исходным кодом

недостаток:

• Требуются дополнительные службы для запуска и мониторинга
• Тесно связаны с тегами Consul и Consul

Nginx/HAProxy with Consul Template

Другой способ загрузки баланса консула - использовать сторонний инструмент, такой какNginxилиHAProxy) для балансировки трафика и использования инструментов с открытым исходным кодом, таких какConsul Template) для управления конфигурацией. В этом режиме Consul Template динамически управляет конфигурационным файлом nginx.conf или haproxy.conf, который определяет список балансировщиков нагрузки и сервисов. Этот список создан по шаблону, и Consul Template работает как служба для поддержания шаблонов в актуальном состоянии. Consul Template имеет постоянное подключение к кластеру Consul, и при изменении пула сервисов Consul Template записывает новый файл конфигурации и сигнализирует процессу Nginx или HAProxy перезагрузить его конфигурацию. Вот пример шаблона Nginx Consul Template:

upstream myapp {
{{ range service "myapp" }}
  server {{ .Address }}:{{ .Port }}
{{ end }}
}

В этом примере Consul Template будет отслеживать все сервисы с именем «myapp». Если какое-либо из их состояний изменится, Consul Template создаст новый файл конфигурации и даст указание процессу Nginx перезагрузить. Приведенный выше шаблон отображается в nginx.conf следующим образом:

upstream myapp {
  server 10.2.5.60:13845
  server 10.6.96.234:45033
  server 10.10.20.123:18677
}

Следует отметить, что в этом режиме ни Nginx, ни HAProxy не знают о существовании Consul, они просто читают свою конфигурацию, как если бы значения были жестко запрограммированы оператором или инструментом управления конфигурацией.

преимущество:

• Обработка приложений, работающих на портах, отличных от портов по умолчанию, без дополнительных запросов API.
• Nginx и Haproxy - это через онлайн-инструмент тестирования
• Команды уже могут иметь опыт или существующую инфраструктуру для этих инструментов
• Если Consul отключается, все еще сохраняется запись о последнем известном исправном состоянии службы.
• Шаблон Consul также работает сVaultИнтеграция, что делает его идеальным решением, если файл конфигурации содержит конфиденциальные данные, такие как закрытые ключи TLS или общие пароли.

недостаток:

• Для управления и мониторинга требуются два дополнительных сервиса — Nginx/HAProxy и Consul Template.
• Поскольку блокирующие запросы, неэффективный шаблон может вызвать огромное давление на консуль кластера
• Проблемы, связанные с реализацией парадигмы «Один контейнер — один сервис»
• Кластер «летающая свинья» (кластер с сервисами, переключающимися между работоспособными и неработоспособными, или кластер с большим количеством последовательных быстрых отмен) может привести к нестабильной конфигурации Nginx/HAproxy.

Nginx with Custom Module

Недавно я начал пытаться удалить Consul Template, но сохранить проверенную временем гибкость и привычность Nginx. В обществе есть несколько очень интересных и инновационных практик, а именно:

• Dynamic Nginx Upstreams for Consul via lua-nginx-module by Zachary Schneider
• Nginx upsync module
• Nginx Pro DNS resolution
• ngx_http_set_backend which inspired binding Nginx modules in C to Consul in Golang

В конечном счете, эти подходы либо включают слишком много движущихся частей, либо включают расширенную функциональность, выходящую за рамки базового обнаружения служб Consul. Поэтому я написалngx_http_consul_backend_module, для каждого запроса, направленного к nginx, динамически выбирается апстрим.

Это выглядит так:

http {
  server {
    listen       80;
    server_name  example.com;

    location /my-service {
      consul $backend service-name;
      proxy_pass http://$backend;
    }
  }
}

Для каждого запроса ключевое слово consul сообщает Nginx делегату пользовательскому модулю и выбирает случайные серверные службы работоспособности, а также проксирует запросы к серверной службе. Конечно, есть области для улучшения, но проверка концепции показывает, что нет промежуточного инструмента, который также может быть подключен напрямую к Nginx и Consul.

преимущество:

• Обработка приложений, работающих на портах, отличных от портов по умолчанию, без дополнительных запросов API.
• Никаких внешних инструментов — просто запустите Nginx и укажите прямо на Consul
• Используйте HTTP/2, устаревшие запросы и т. д., предоставляемые официальной клиентской библиотекой Consul SDK.

недостаток:

• Nginx необходимо скомпилировать из исходного кода для установки пользовательских модулей.
• Запросы на каждую задний конец, Call Consul (каждый запрос требует разрешения RTT и Consul запроса)
• Необходимо знать знание пользовательского модуля NGINX для выполнения задачи.
• Для закрытых ключей TLS или общих секретов нельзя использовать сVaultинтегрированный
• Модуль был тщательно протестирован онлайн (еще нет)

HAProxy 1.8

HAProxy 1.8(Текущий релиз-кандидат на момент написания этой статьи) Добавляет встроенные возможности для обнаружения служб через DNS без использования сторонних инструментов или модулей. HAProxy некоторое время имел встроенное решение DNS, ноHAProxy 1.8 предлагает решение для портов с записями SRV и поддержкой EDNS., делая его идеальным спариванием с консулом.

преимущество:

• Никаких внешних инструментов — просто запустите HAProxy и укажите прямо на Consul
• Изящно обрабатывает перезагрузку, TTL и т. д.
• Также поддерживает обнаружение сервисов Kubernetes и Docker Swarm.

недостаток:

• Требуется HAProxy
• Меньшая гибкость для сценариев отказа, чем у шаблона Consul.

в заключении

Для приложений, использующих Consul, существует множество стратегий и методов балансировки нагрузки. В этом посте подробно описаны некоторые из наиболее распространенных технологий, и мы надеемся, что он вдохновит вас на новые захватывающие способы интеграции стандартных инструментов балансировки нагрузки и Consul. Независимо от того, используете ли вы Consul напрямую, восполняете пробел с помощью шаблонов Consul, компилируете свою собственную версию Nginx или пробуете версию-кандидат HAProxy 1.8, мы с нетерпением ждем возможности услышать, как вы можете сбалансировать нагрузку своих приложений микросервисов.

Оригинальная ссылка:Woohoo. Hashi Corp.com/blog/load - нет...