Поскольку мы не используем Stomp для нашего сервера websocket, spring не предлагает структуру брокера сообщений. Мое видение состоит в том, чтобы использовать паб / подписку Spring для обмена сообщениями с хранилищем сообщений Redis для разработчиков и перенести брокер сообщений с Redis на SQS + Dynamo для версии prod.
Как я исключаю (поскольку ios и Android не готовы поставить клиент Stomp на передний план из-за отсутствия поддержки) Stomp, библиотека spring websocket также не включает функцию pub / sub.
Пример нашего бизнес-кейса:
Каждый подключенный сеанс веб-сокета будет инициировать запрос к другому микросервису (который является клиентом веб-сокета Java) для получения данных. Мое видение состоит в том, чтобы соединить эти два сервиса через архитектуру pub / sub с Redis.
- Мобильный клиент отправляет -> «Привет, мой счет оплачен?» через веб-сокет.
- Сервер WebSocket получает это сообщение и передает его клиентской службе WebSocket через redis pub / sub.
- Поскольку сервер websocket и клиент Websocket подключаются через Redi pub / sub. Они могут обмениваться сообщениями.
- Клиент Websocket будет подключен к системе агентов-людей через сокет и передаст «Привет, мой счет оплачен?».
- Ответ («Да, платно») будет снова опубликован на сервере websocket.
- Сервер Websocket отправит его обратно определенному пользователю.
По коммерческим причинам мы хотели бы сохранить 2 сервиса для этого варианта использования. Клиент Websocket может подключаться к системе агента клиента и не связан с нашей бизнес-логикой. Наши мобильные приложения будут взаимодействовать с нашим собственным сервером websocket. Это дает нам возможность добавлять дополнительные настройки и независимо от конкретного поставщика.
Вот мой способ обхода
- Используйте spring-websocket без топания для создания сервера Websocket.
- Используйте Spring-Integration для создания архитектуры обмена сообщениями.
- Каждый сеанс веб-сокета привязан к каналу интеграции Spring и отправляет ответ в конкретное место назначения.
- Создайте очередь запросов / ответов Redis для каждого соединения.
- Канал интеграции Spring подписывается в очередь Redis.
Поскольку наша инфраструктура не поддерживает Rabbit MQ, очередь Redis будет заменена SQS в продукте.
Вопрос: Можем ли мы создать каналы весенней интеграции во время выполнения и привязать их к определенной службе или очереди? Мысленный процесс состоит в том, чтобы предлагать один канал для каждого сеанса веб-сокета и удалять канал по окончании сеанса.
Есть ли лучшее альтернативное решение, доступное в Spring интеграции или Spring Messaging для выполнения этого варианта использования?
