Маршрутизация к тому же экземпляру контейнера Backend, который обслуживал начальный запрос - PullRequest
0 голосов
/ 17 октября 2018

У нас есть мультисервисная архитектура, состоящая из внешнего интерфейса HAProxy (при необходимости мы можем изменить его на другой прокси-сервер), базу данных mongodb и несколько экземпляров внутреннего приложения, работающего под Docker Swarm.

Однажды начальныйзапрос направляется в экземпляр (контейнер) серверного приложения, и мы хотим, чтобы все будущие запросы от мобильных клиентов направлялись в один и тот же экземпляр.Бэкэнд-приложение использует TCP-сокеты для связи с VoIP PBX.

В идеале мы хотели бы контролировать количество экземпляров серверного приложения, используя ключ replicas в файле docker-compose.Однако, если контейнер умер и был воссоздан, мы бы потребовали, чтобы мобильные клиенты продолжили маршрутизацию в тот же контейнер.Причина в том, что каждый контейнер содержит информацию о состоянии.

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

1 Ответ

0 голосов
/ 17 октября 2018

HAproxy имеет то, что вам нужно. Эта статья объясняет все.

В заключение статьи вы можете выбрать одно из двух решений: Привязка IP-источника к серверу и Постоянство уровня приложения .Последнее решение сильнее / лучше, чем первое, но для него требуются файлы cookie.

Вот дополнительные сведения из статьи:

Привязка IP-источника к серверу

Простой способ поддерживать сходство между пользователем и сервером - использовать IP-адрес пользователя: это называется исходным IP-соответствием.Есть много проблем, связанных с этим, и я не буду подробно их описывать (TODO ++: другая статья, которую нужно написать).Единственное, что вам нужно знать, это то, что привязка IP-адреса источника - это самый последний метод, который нужно использовать, когда вы хотите «привязать» пользователя к серверу.Что ж, это правда, что это решит нашу проблему до тех пор, пока пользователь использует один IP-адрес или он никогда не изменит свой IP-адрес во время сеанса.

Постоянство прикладного уровня

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

В чем разница между постоянством и сродством

Сродство: это когда мы используем информацию из уровня ниже уровня приложения для поддержки запроса клиента к одному серверу

Постоянство: это когда мы используем информацию прикладного уровня для привязки клиента к одному серверу

липкий сеанс: липкий сеанс - это сеанс, поддерживаемый постоянством

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

Используя постоянство, мы имеем в виду, что мы на 100% уверены, что пользователь будет перенаправленна один сервер.Используя affinity, мы имеем в виду, что пользователь может быть перенаправлен на тот же сервер…

Настройка Affinity в балансировщике нагрузки HAProxy / Aloha

В приведенной ниже конфигурации показано, как это сделатьсходство в HAProxy, основанное на информации об IP-адресе клиента:

frontend ft_web
  bind 0.0.0.0:80
  default_backend bk_web
backend bk_web
  balance source
  hash-type consistent # optional
  server s1 192.168.10.11:80 check
  server s2 192.168.10.21:80 check

Настройка cookie-файлов сеанса с помощью балансировщика нагрузки В приведенной ниже конфигурации показано, как настроить балансировщик нагрузки HAProxy / Aloha для внедрения cookie-файла вклиентский браузер:

frontend ft_web
  bind 0.0.0.0:80
  default_backend bk_web
backend bk_web
  balance roundrobin
  cookie SERVERID insert indirect nocache
  server s1 192.168.10.11:80 check cookie s1
  server s2 192.168.10.21:80 check cookie s2
...