Как лучше построить архитектуру серверной части на Erlang (Cowboy) для обмена через WebSocket с мобильными клиентами?

Question

[Вадим Курочкин]

Добрый день.

Есть потребность в высокопроизводительном WebSocket-сервере, который держит соединение с мобильным клиентом и снабжает по запросу клиента его какими-либо данными.
В качестве такого сервера был выбран Cowboy на Erlang (варианты?).
Клиент делает запрос на получение некоторых данных. Данные собираются какое-то время (5..30 сек) затем отправляются клиенту.

Как лучше построить архитектуру серверной части с возможностями Erlang?
Cowboy принимает запрос от мобильного клиента и:

1. Кладет его в некую очередь на обработку (таблицу БД, например). Какой-нибудь worker забирает из очереди задачу, собирает данные и обновляет задачу в очереди.
Далее данные отправляются клиенту.

2. Обходясь без воркера, Cowboy создает трэд под запрос и сам выполняет работу воркера по занимающему определенное время сбору нужных данных, а потом отдает данные клиенту.

Что скажете?

Answer 1

[Сергей]

Т.е. ваш клиент общается с Cowboy по одному из протоколов (Websocket, http, long-pooling ) ?

По сути вы привели один и тот же способ --- передать управление кому то.
Только в первом случае в пуле у вас ограниченное кол-во воркеров, а во втором неограниченное.

Да и что мешает обработать запрос непосредственно в хендлере ?
Хендлер также может принимать любые сообщения, и генерировать любые сообщения т.е. можно реализовать любую логику, такую же какую вы реализуете на get_server или руками loop() -> receive ... end.

Comments

[Вадим Курочкин]

Да, по WebSocket. Хорошо, спасибо, смотрю в сторону обработки в хендлере.

Answer 2

[_ _]

Можете faye использовать. faye.jcoglan.com
Для него есть готовые клиентские библиотеки под мобилки, например вот https://github.com/m1entus/MZFayeClient, под андроид тоже видел.
Использую его в ipad-приложении, полет нормальный.

Comments

[Сергей]

Да это обычный push-сервер. Человеку нужна логика посложнее чем принял-отправил.

[_ _]

Вы в своем уме? Какой push-сервер? Или вы писатель, а не читатель?

Answer 3

[Алексей Павлов]

Если у вас очень большая нагрузка (или планируется очень большая нагрузка), и один сервер не справляется, то тогда вариант с отдельными воркерами будет более гибким. (Вы даже сможете делать воркеров на разных языках.)
Если у вас всем занимается один сервер, то лучше использовать только сам Эрланг - он прекрасно держит висящее пассивное соединение. Как данные появятся (их возвратит колбек), так они сразу уйдут клиенту, а пока данные готовятся, то ресурсы на поддержание коннекта практически не расходуются.
Плюс, насчёт нескольких серверов - Эрланг сам умеет работать на нескольких серверах, так что второй вариант выглядит предпочтительнее. Но первый - гибче. Больше гибкости для последующего развития сервиса.

Хм. Перечитал ваш вопрос. Воркер у вас только на обработку данных. А Эрланг будет в любом случае держать соединение. Получается, в первом варианте профит будет в случае, если в качестве воркера будет использоваться не-Эрланг, который будет (значительно) быстрее обрабатывать эту специфическую задачу (ежели у вас задача сложно обрабатывается на самом эрланге).

Comments

[Вадим Курочкин]

И в п. 1 и в п. 2 будет запрашиваться внешний сервис, который и будет отвечать сходу, без последующих опросов на предмет выполнения. Как я понимаю, все же лучше будет задействовать сам Erlang, если на удержание соединения ресурсов надо мало. В этом случае уходят воркер и база с заданиями.

Answer 4

[Maxim Sokhatsky]

Создание высокопроизводительного WebSocket Erlang релея сопровождается следующим списком задач, которые необходимо будет решить архитектору:

1. Форматирование сообщений: JSON, BERT, MessagePack
2. XHR Fallback при отсутствии вебсокетов
3. Обеспечение подписок между WebSocket процессами через PubSub для чата
4. Обеспечение клиентского PING и обеспечение рекконектов
5. Развитая поддержка текстового UTF-8 и бинарного формата

Веб-сервер cowboy не предоставляет ничего из этого списка. Для 2) есть библиотека bullet но она не всех устроит, ее придется дорабатывать пользователям, если они захотят stateful WebSocket соединение. Это означает, что cowboy является низкоуровневым веб-сервером и для реализации этих жизненно необходимых механизмов вам придется воспользоваться более высокоуровневыми библиотеками, веб-фреймворками, которые берут всю эту рутину прикладного уровня на себя.