Комментарии 17
Из открытых XMPP-серверов самым продвинутым показался ejabberd, написанный на Erlang. На такой подвиг я был не готов, кроме того.Ещё есть MongooseIM. А ещё у самих Process One можно использовать ejabberd как saas.
Сам по себе протокол старый, и его пришлось бы расширять под свои нужды.А чего такого нету в xmpp, чтобы пришлось его расширять?
Про бекенд, всё же, хотелось бы поподробнее послушать. Какие нагрузки? Где узкое звено? У ejabberd были в своё время проблемы в синхронизации чатов между разными инстансами в кластере. У вас такой проблемы нету? Или один толстый инстанс запущен?
Я сам очень долго не мог понять что делает WAMP и его архитектоуру. WAMP изначально распределения система. Запросы не выполняются на сервере WAMP он просто получает запрос от зарегистрированного слушателя и передаёт на обработку зарегистрированногму воркеру. То есть изначально все направлено на горизонтальное масштабирование. Конечно использовать для чата мне кажется не рациональным так как там вступают другие факторы. Это дополучение и доподтверждение запросов которые прошли во время разъединения и пересоединение слушателя или воркера. Как результат прекрасная работа в тестовый период и пропущенные сообщения и дубли сообщений в реальном приложении. Для таких случаев лучше использовать средства с гарантированной доставкой сообщений ровно один раз. Например mqtt но и другие брокеры подойдут. Например rabbitmq тот же.
Как вариант еще можно посмотреть на engine.io, он тоже нацелен на надежность доставки и масштабирование. Возможно там несколько больше оверхеда по трафику, но зато очень простой в использовании.
upd. Вспомнил, что доводилось использовать engine.io в большей степени для передачи непрерывного потока сообщений. И было важно постоянное подключение, нежели гарантия доставки каждого отдельного сообщения. Бэк получился достаточно простым: nginx распределял подключения с привязкой айпишников по нодам, а между нодами сообщения прокидывались тупо через редис. Все это уже и ранее использовалось в проекте, а мне тогда хотелось хотя бы примерно понять, что будет происходить с нагрузкой после добавления веб-сокетов. В итоге все оказалось в норме и я не стал ничего переделывать. Во многом наверное поэтому engine.io запомнился беспроблемным и приятным в использовании. Сейчас немного почитал про WAMP (спасибо за наводку), и подумал что в случае сложной маршрутизации и при непостоянстве подключения, engine.io похоже так себе решение.
Да. Engine.io это собственно тот же socket.io тол коты качестве транспорта использует Легаси протоколы вместо вебсокеттв. Любые брокеры с гарантированной доставкой сообщений хорошая основа для таких приложений. Ещё из плюс что могу поддерживать миллионы подключенных устройств если они работают на erlang
А чего такого нету в xmpp, чтобы пришлось его расширять?
Хотелось иметь RPC в протоколе.
Про бекенд, всё же, хотелось бы поподробнее послушать.
На бэкенде крутится wamp-роутер. Бизнес-логика чата является wamp-клиентом по отношению к роутеру и крутится с ним в одном процессе. При таком подходе их легко разнести на разные сервера в будущем при разрастании бизнес логики и изменении профиля нагрузки. Сообщения и чаты хранятся в репликасете монги. Для операций типа "создать новый чат", "получить список сообщений с курсорной навигацией" используется RPC подход. Для пользовательских сообщений и различных событий типа "пользователь появился в сети", "пользователь покинул чат" используется PubSub. Механизм с realm используется для разделения на проекты.
У ejabberd были в своё время проблемы в синхронизации чатов между разными инстансами в кластере. У вас такой проблемы нету? Или один толстый инстанс запущен?
Текущая инсталляция состоит из трех небольших инстансов (4 ядра / 8 ГБ). Все wamp-сообщения с кодом EVENT сервер повторяет всем членам кластера. Это позволяет общаться в одном чате пользователям, подключенным к разным серверам. При разрастании кластера до размеров, когда fan-out может стать проблемой, есть возможность шарить списки подписчиков и слать события адресно.
Какие нагрузки?
Сейчас нагрузка небольшая - до 1000 пользователей в онлайне в пике. С такой нагрузкой справляется и один инстанс. Три запущены, как говорится, на всякий случай.
Где узкое звено?
При текущей нагрузке проблем пока не выявлено.
Как решали проблему резкого скачка количества запросов за состоянием чата при массовых обрывах вебсокетов (деплой, перезагрузка балансировщика, etc.) и последующих переподключениях?
Многие из этих вопросов WAMP решает на уровне протокола в частности пересоединение при разрыве сокета. Балансировка ему не ружен так как по сути сервер WAMP это брокер на котором регистрируются исполнители запросов возможно удаленные. Их может быть много и можно регистрировать дополнительные обработчики. То есть WAMP сервер это и есть балансировка. Пожалуй что там неудобно так это управление все этим хозяйством. Проверка доступных воркеров, мониторинг их работы и т.п. Если бы эти вопросы получили свое решение тотWAMP мог стать средой для выполнения микросервмсов но основанной не на идеологии оркестиации а на идеологии хореографии.
Инстансов запущено с запасом, деплоятся они по очереди. Т.е. берем одну машину, останавливаем старую версию приложения, поднимаем новую, и так для всех. При таком подходе одновременно переподключается только 1/N (N - кол-во инстансов) пользователей. Но в любом случае, с нашей нагрузкоймы легко перевариваем одновременный обрыв всех коннектов.
WAMP прекрасен хотя и недостаточно популярен. Я бы хотел чтобы это протокол развивался так как он поддерживает масштабирование и потенц ально может стать средой для разворачивания микросервмсов. Но что касается при мнения в чатах в сравнении с mqtt он как мне кажется с льно проигрывает. На уровне логике то не может гарантировать доставку ровно один раз как это может делать mqtt., Также он менее производителем и сложнее коастеризуется если мы сравним с реализация и mqtt на erlang
Свой самописный чат - прекрасное решение!
Мне во множестве различных проектов приходилось делать чат. Первый раз, когда возникла такая задача, решили заюзать Spika . Сейчас, может быть, этот проект мертв, но тогда был одним из первых, в результатах поиска. Намучились - не то слово, и все равно лагало.
В следующий раз решили использовать Quickblox. Результат получился не лучше.
Много времени тратилось на то, чтобы добавить это в проект, потом тяжело было это поддерживать, и работало, мягко говоря, так себе (переписка с их сапортом велась постоянно).
А потом нам с бекендщиком пришла здравая мысль: а что если сделать свой, очень простой движок для чата на сокетах? Потрачено было не так много времени (меньше месяца, точно) и мы получили простой и надежный, как автомат Калашникова, чат. Добавляется в проект за пару часов, и работает без проблем. Это решение мы потом использовали в десятках следующих проектов и по сей день используем.
То же касается и звонков. Около года назад Twilio очень сильно подняли цены на свои сервисы, и мы благополучно перешли на голое и бесплатное WebRTC, и потом подумали, почему мы не сделали так сразу).
Рассматривался ли Matrix в качестве протокола для чата?
берем спецификацию xmpp, переводим нужное в json, запускаем rabbitMQ с MQTT и гоняем по воркерам пакеты. Довольно безотказная система с кластеризацией и простейшим расширением. В добавок можно STOMP плагин запихнуть и web-mqtt.
Чаты на вебсокетах. Теперь про бэкенд