Как веб-сокеты поддерживают постоянное соединение и насколько оно стабильно для использования в прямом эфире?
Мне нужен сервер на основе событий, где данные легко передаются клиенту. Как я читал на форумах, серверы на базе веб-сокетов - мой лучший выбор. Пожалуйста, объясните, как это работает, и насколько стабильно его использование на производственных коробках?
1 ответ
Поскольку веб-сокеты настолько новы, я не верю, что многие серверы приложений еще имеют большую поддержку веб-сокетов. Например, Tomcat заявляет следующее: "Tomcat обеспечивает поддержку WebSocket, как определено в RFC 6455. Эта функция еще не завершена, и вам предлагается предоставить обратную связь в форме отчетов об ошибках". Однако вы можете использовать преимущества веб-сокетов, если рассматриваете свою архитектуру немного иначе. Пример приложения, которое будет отправлять изменения котировок акций на основе событий, может работать в следующих логических шагах.
1) Клиентское приложение (веб-приложение или другое приложение включения веб-сокетов) установит соединение веб-сокетов с запрошенным сервером, обслуживающим ресурсы.
2) Сервер будет нести ответственность за получение внешнего (внутреннее событие) и выбор клиентов, которые получат соответствующее сообщение.
3) Затем это сообщение будет отправлено через веб-сокет-соединение клиенту. Веб-сокеты, как определено стандартом, должны позволять этому соединению оставаться открытым, пока клиент находится в сети, и должны доставлять эти данные практически в реальном времени. Более того, он будет предлагать преимущество работы на стандартных портах / протоколах, которые могут быть надежно доставлены через Интернет.
Отсюда видно, что на самом деле существует 4 логических элемента инфраструктуры. 1) Бэкэнд, настроенный для получения событий. Для котировок акций это будет бэкэнд учреждений. 2) Посредник сообщений, который отвечает за логическое связывание событий с соответствующими клиентами. 3) Подключение веб-сокета к клиенту. и 4) сам клиент
Серверная часть: действительно может быть написана во всем, что необходимо для подключения к вашим событиям. Для системы котировок акций это будет какое-то специальное приложение, связанное с поставщиком финансовых услуг.
Для Message Broker я бы посоветовал вам использовать JMS или AMQP для обработки "службы, основанной на событиях". Эти брокеры сообщений хорошо определены и используются во многих корпоративных приложениях. С аппаратной точки зрения они могут работать непосредственно на вашем бэкэнде или отдельно. Более того, они предлагают вам широкий спектр услуг (точка-точка, публикация подписки и т. Д.), Которые вы можете использовать в своем приложении. В качестве альтернативы, если вы хотите создать свою собственную службу обмена сообщениями, вы можете использовать что-то вроде Netty.
Для подключения через веб-сокет вам понадобится служба, которая может легко и надежно подключиться к вашей системе брокера сообщений. Например, Kaazing (Disclaimer и полное раскрытие, которое я работаю для Kaazing) предлагает как корпоративную версию AMQP, так и версию JMS, которая может напрямую подключаться к вашим брокерам сообщений.
Проблемы с клиентом: укажите, поддерживают ли браузеры веб-сокеты и каковы механизмы отката (длинный опрос, ajax). Они действительно зависят от того, какой сервис вы используете для создания подключения к веб-сокету. Хотя существует множество сервисов с открытым исходным кодом, которые предоставляют механизмы отката, Kaazing также предлагает эмулируемое соединение веб-сокетов, которое логически работает больше как веб-сокеты, а не механизмы отката (длинный опрос /ajax), которые были созданы для замены веб-сокетов.
В УСЛОВИЯХ СТАБИЛЬНОСТИ: JMS и AMQP широко используются и стабильны. Существует внушительный список пользователей отрасли, которые уже работают на своих технологиях.
Проверьте этот живой веб-документ архитектуры для более подробной информации