Работа с Spring Boot Clustered Websockets на Amazon Beanstalk

Question

У меня есть приложение с использованием Spring Framework/Spring Boot/Spring Messaging/Websockets и я собираюсь развернуть его на Elastic Beanstalk. Вы можете думать о применении в качестве приложения чата (это на самом деле имеет функции чата)

Сценарий

Ниже приведен пример сценария:

Client A <-> Server A 
Client B <-> Server B 
Client C <-> Server B 

Теперь, если Client A посылает сообщение, используя весенний обмен сообщениями, если я отправлю это сообщение всем подключенным клиентам, только Client A увидит его, потому что только Client A подключен к Server A, а также, если Client B делает, только Clients B and C увидит это, а не Client A.

Так что это оставляет мне проблему с какими вариантами у меня есть.

Возможные решения

Если возможно, я хотел бы использовать службы Amazon, как я уже в своей облачной платформе.

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

Кто-нибудь знает о хорошем решении этой проблемы? Я могу настроить сервер для обработки всех веб-сокетов, но это не оптимально.

Заранее благодарен!

Answer 1

Я успешно делаю почти то, что вы описываете.

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

То, как я столкнулся с кластером, - это создание подсистемы, где я могу отправлять сообщения другим узлам.

Поэтому, когда я хочу отправить сообщение веб-сокета из узла AI, отправьте сообщение с веб-сокетом с этого узла (оно отправит всем зарегистрированным клиентам), а затем отправит сообщение другим узлам, чтобы они могли отправлять всем их клиентов.

Обмен сообщениями «внутри кластера» осуществляется с помощью SNS + SQS. При запуске каждый узел создает очередь (идентифицируется с помощью экземпляра instanceid), регистрирует эту очередь в теме (все узлы используют одну и ту же тему), а затем запускает прослушиватель для новых сообщений в этой очереди. Этот слушатель использует длительный опрос. Amazon добавила поддержку «длинного опроса» в своих очередях некоторое время назад, она была недоступна вначале. Что подразумевается, так это то, что клиенты могут заблокировать до 20 секунд ожидания сообщения, как только будет получено сообщение, это сообщение будет обработано, поэтому ваша латентность будет очень низкой. Когда я хочу отправить сообщение сообщение в тему, и сообщение будет перенаправлено во все очереди, зарегистрированные в этом разделе. Затем я также создал фильтрацию в прослушивателе, чтобы разрешить сообщение отправлять только «другим» клиентам (т. Е. Не отправлять это мне самому).

Я вижу, что вы упомянули о RabbitMQ ... Слабость моего подхода заключается в том, что он не поддерживает богатство, которое возможно, если вы используете брокер сообщений, поддерживающий протокол сообщений STOMP.Это означает, что вам не нужно беспокоиться о кластеризации вообще, вы просто отправляете брокеру и обрабатываете тяжелую работу. Думаю, для меня это будет моим следующим шагом, если мне когда-нибудь понадобится более богатое решение.

Если кто-то может построить клиент STOMP, поддерживаемый SQS, это было бы благом для создания сообщения веб-сокета весной в AWS.