Как правильно организовать проксирование вебсокетов со сторонних сервисов?
Есть необходимость получать сигналы от нескольких бирж и рассылать уведомления пользователям по их сигналам.
На сайте также необходимо показывать эти данные.
Я хочу сделать такую систему:
1. Сервис проксирования вебсокета, который будет подключаться ко всем нужным вебсокетам и через rabbitmq рассылать сообщения в соответствующие каналы
2. Консюмеры, которые, соответственно, будут подписываться на эти каналы и делать то, что нужно. В том числе и отправлять эти сигналы на сайт. Т.е. сервис рассылки уведомлений, сервис обновления данных в базе, сервис трансляции этих сигналов подписчикам вебсокета на сайте, и.т.д.
Все ли ок в этой схеме и какие у нее слабые места?
Если я правильно понял и речь о биржах криптовалютных (так как у бирж из фондового рынка не вебсокеты), у каждой биржи свой формат подключения websocket (к примеру для многих хватает чистого php ratchet а для некоторых нужно Thruway WAMP). У каждой биржи свои заморочки, лимиты на количество подписок на подключение, косяки с подвисшим каналом (соединение есть данные не идут) и т.п.
Настоятельно рекомендую физически разнести по процессам сбор сырых данных и их обработку.
Готового websocket посредника для бирж я не знаю, есть потуги у ccxt но слабые, плюс реализация там ну очень грузит процессор, по 1 валютной паре на подключение так же не добавляет радости (если захочешь подключить сразу сотню пар биржи, ей это может не понравиться).
Если говорить про задачу перераспределения событий, но так она не на столько сложная чтобы можно было ожидать что то готовое.
Ваша схема вполне жизнеспособна. Консьюмеры очереди rabbitmq могут потреблять одну и туже очередь, в несколько потоков, т. е. Система масштабируется горизонтально. Основной вопрос будет с шардированием и клиентских сокетов, что бы направить эвенты от ваших консьюмеров до ваших клиентов. В зависимости от ожидаемой нагрузки стоит ввести ещё один транспортный слой в вашу схему - транспорт до клиента
