Во-первых, ваша диаграмма предполагает, что балансировщик нагрузки действует как (TCP) прокси , что не всегда так.Часто используется прямая маршрутизация (или прямая обратная связь с сервером), или выполняется NAT назначения.В обоих случаях соединение между внутренним сервером и клиентом является прямым.Так что в данном случае это, по сути, TCP-квитирование, которое распределяется между внутренними серверами.Для получения дополнительной информации см. Следующее:
Очевидно, что существуют прокси TCP (один HAProxy), в которомВ случае, если прокси-сервер управляет обеими сторонами соединения, поэтому ваше приложение должно быть в состоянии идентифицировать клиента по входящему IP / порту (который может быть от прокси, а не от клиента).Прокси будет обрабатывать получение сообщений обратно клиенту.
В любом случае, все сводится к проектированию приложений, так как я бы предположил, что хитрый бит имеет общее хранилище сеансов (какую-то базу данных или хранилище значений key =>, такое как Redis), так что когда вашСервер приложений говорит: «Мне нужно отправить сообщение Фрэнку», он может определить, к какому внутреннему серверу Фрэнк подключен (из БД), и дать сигнал этому серверу отправить ему сообщение.Вы уменьшаете проблему соединений (от одного и того же клиента), перемещающихся по разным внутренним серверам, имея постоянные соединения (все балансировщики нагрузки могут это делать) или используя что-то внутренне постоянное, например, веб-сокет.
Это, вероятно, чрезмерное упрощение, так как у меня нет опыта работы с программным обеспечением для чата.Очевидно, что сами серверы БД могут быть распределены по нескольким машинам для обеспечения отказоустойчивости и распределения нагрузки.