Сервер веб-сокетов высокой доступности

Я хочу узнать, как лучше всего настроить сервер WebSockets в инфраструктуре микросервисов высокой доступности (.NET Core).

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

Это лучший способ настроить его или есть лучший способ? Моя главная забота — высокая доступность, но я также хочу иметь возможность горизонтального масштабирования.

Кроме того, если сообщение необходимо передать клиенту браузера, следует ли мне использовать какую-то надежную очередь сообщений, чтобы быть уверенным, что все экземпляры сервера WebSockets знают о сообщении, если они владеют подключением к этому клиенту браузера? Альтернатива, о которой я думал для этого, заключается в том, что если серверы каким-то образом не имеют состояния, а информация о соединении хранится где-то еще (кластер Redis?), то мне не нужно будет уведомлять все экземпляры, потому что ни один из них не будет «владеть» соединением с тот клиент? Это возможно?

Спасибо за любую помощь :)

Крис


person ChrisBellew    schedule 22.12.2016    source источник


Ответы (1)


Ваш дизайн звучит хорошо. С помощью haproxy вы можете ограничить количество подключений клиентов к любому экземпляру, что является огромной проблемой для веб-сокетов. Я бы использовал подход без сохранения состояния и обрабатывал ошибки с помощью кода. Когда клиент обнаруживает сбой, просто повторно подключитесь к любому экземпляру. Храните все постоянные данные в каком-то глобальном хранилище. В зависимости от варианта использования, как вы упомянули, Redis будет работать отлично.

В качестве примечания, Websockets поддерживает открытые постоянные соединения, и в зависимости от объема вам может понадобиться пул экземпляров haproxy. Рекомендовал бы по крайней мере два в качестве отправной точки для доступности.

person thun    schedule 04.01.2017
comment
Отлично. Спасибо за это - person ChrisBellew; 05.01.2017