Все зависит.Давайте рассмотрим ваши варианты, предполагая, что ваш биржевой маклер, ваш чат и ваша книга заказов построены как отдельные серверы / микро-сервисы.
Один WebSocket для каждого сервера
Вы можете иметь каждый серверзапуск собственного сервера WebSocket, потоковая передача событий, относящихся к этому серверу.
Pros
Это простой подход.Каждый сервер независим.
Минусы
Плохо масштабируется.Количество открытых TCP-соединений будет стоить дороже, так как число одновременных пользователей увеличивается.Повышенная сложность, когда вам необходимо реплицировать серверы для обеспечения избыточности, поскольку все реплики должны транслировать одни и те же события.Вы также должны создать свой собственный запасной вариант для восстановления устаревших данных клиента из-за потери соединения WebSocket.Необходимо создать обработчики событий на клиенте для каждого типа события.Возможно, потребуется добавить обработку версий, чтобы предотвратить скачки данных, если исходные данные извлекаются по HTTP, а события отправляются по отдельному соединению WebSocket.
Публикация / подписка потоковых событий
Существует много публикаций /доступные решения для подписки, такие как Pusher , PubNub или SocketCluster .Идея часто заключается в том, что ваши серверы публикуют события в теме / теме очереди сообщений, которые прослушиваются серверами WebSocket, которые перенаправляют события подключенным клиентам.
Pros
Весы легче.Сервер должен отправить только одно сообщение, а вы можете добавить больше серверов WebSocket по мере увеличения числа одновременно работающих пользователей.
Минусы
Скорее всего, вам все равно придется обрабатывать восстановление после событийпотерян во время отключения.Тем не менее может потребоваться управление версиями для обработки данных гонок.И все же нужно написать обработчики для каждого типа события.
Шлюз API реального времени
Эта часть более бесстыдна, так как охватывает Resgate , проект с открытым исходным кодом I 'Я был вовлечен в себя.Но это также относится к таким решениям, как Firebase .Под термином «API-шлюз в реальном времени» я имею в виду API-шлюз , который не только обрабатывает HTTP-запросы, но и работает в двух направлениях через WebSocket.
С веб-клиентами вас редко интересуетсобытия - вы заинтересованы в изменении состояния.События - это просто способ описать изменения.Получая данные через шлюз, он может отслеживать, какие ресурсы интересуют клиента в настоящее время. Затем он будет поддерживать клиента в актуальном состоянии в течение всего времени использования данных.
Плюсы
Хорошо масштабируется.Клиент не требует специального кода для обработки событий, так как система обновляет данные клиента для вас.Обрабатывает восстановление из потерянных соединений.Нет данных гонок.С ним легко работать.
Минусы
В основном для клиентских веб-сайтов (использующих React, Vue, Angular и т. Д.), Поскольку он плохо работает с сайтами с серверными страницами.Сложнее применять к уже существующим HTTP API.