Архитектура серверного приложения чата?
Я рассматриваю две альтернативы серверной архитектуре чат-приложения:
- Сервер на комнату: пользователи подключаются к одному серверу, который напрямую пересылает сообщения и другие события. База данных используется для настойчивости.
- Плюсы: сообщения доставляются быстрее, эффективнее, задействовано меньше серверов.
- Сервер на пользователя: каждый пользователь подключается к серверу, который пересылает сообщения и другие события через брокера сообщений (то есть Redis) на другие серверы, которые пересылают эти события пользователям. Опять же, база данных используется для настойчивости.
- Плюсы: простая архитектура, пользователи подключаются к одному серверу, надежнее.
Примечание: термин «сервер» относится не к физическому компьютеру, а к конкретному адресу / порту.
Какие еще плюсы и минусы существуют у каждой модели? Какую модель я бы использовал в каких ситуациях? Есть ли другие возможные серверные архитектуры?
В случае, если это актуально: приложение ориентировано на комнаты с двумя пользователями (то есть прямой обмен сообщениями) с меньшим акцентом на группы или очень большие комнаты.
Если это не та сеть Stack Exchange, о которой стоит спросить, дайте мне знать, и я могу переместить вопрос. Спасибо!
Ответы 2
Вот что я хочу отметить для вас:
- Создавая приложение для обмена сообщениями, я предполагаю, что вы будете использовать Websocket для отправки и получения сообщений, это означает, что вам понадобится липкий сеанс, что также означает, что пользователи, вероятно, будут подключаться к одному серверу каждый раз, когда они используют приложение.
- Вам определенно понадобится брокер сообщений. Потому что без него было бы очень больно заставить все ваши серверы общаться друг с другом. Redis - хороший выбор здесь, вы также можете использовать его для кеширования пользовательского сеанса (быстрее, чем db), но все же нужно сохранять в db, хотя
- Идея о том, что у каждого пользователя / комнаты есть свой «сервер» (адрес / порт), довольно странная. зачем вам это? С моей точки зрения, это довольно сложно. Вам нужно будет: направлять пользователей / комнаты на их выделенный порт, как узнать их выделенный порт, как иметь несколько адресов для каждого сервера? ...
... с возможностью подключения к нескольким серверам), которые пересылают сообщения напрямую другим пользователям, вместо того, чтобы проходить через удаленные узлы через Redis. Надеюсь, это проясняет ситуацию.
Использование Redis проще и надежнее для взаимодействия ваших серверов друг с другом. Без Redis вам нужно было бы: отслеживать, какие сообщения должны отправляться на какой сервер, поддерживать множественные соединения между серверами, обрабатывать ошибки, когда один из серверов умирает, тормозит или просто отвечает, выяснять, как добавить или удалить серверы ...
Я просто хочу прояснить, что серверы напрямую не общаются друг с другом, но все равно будут использовать Redis. В моем комментарии, когда я сказал «каждый из них, возможно, подключается к нескольким серверам», я имел в виду каждого пользователя, а не сервер. Идея состоит в том, чтобы создать более прямую связь между пользователями, вместо того, чтобы их контент проходил через несколько серверов (включая Redis).
Честно согласен; иметь один шлюз на пользователя проще и, вероятно, более масштабируемо. Архитектура, используемая в больших чат-приложениях, не может быть слишком неправильной.
Я не понимаю, почему вы пытаетесь создать разные адреса и порты для каждой комнаты (или того, что вы называете сервером).
Это может работать, например, как шаблон издатель / подписчик. На одном сервере и одном адресе создайте канал, который пользователи (при одиночном или групповом разговоре) могут его слушать. Затем, если пользователь публикует сообщение на этом канале, вы можете отправить его всем подписчикам.
Также существуют разные способы обработки сохраняемости сообщений, например, сначала вставка их в базу данных, а затем их публикация в каналах. Но, как заметил @Khang, нужен брокер. Ваш брокер может самостоятельно обрабатывать сохранение сообщений или просто отправлять сообщения с одного сервера на другой. (Например, Нац)
Другое дело, если вы хотите увеличить масштаб, ваши сообщения должны иметь возможность перемещаться по вашей распределенной сети, как в ситуациях, когда подписчик канала подключен к другому серверу; какой брокер, которого вы выберете, может вам в этом помочь.
Но возвращаясь к плюсам и минусам, оба решения, о которых вы говорили, могут привести к тому, что вы откроете слишком много портов на слишком большом количестве адресов (если я правильно понимаю), что не кажется нормальным, потому что вы можете исчерпать их, пока один порт может обрабатывать все, что вам нужно. Также в настоящее время я не знаю, как вы собираетесь это реализовать. И он может не делать ничего быстрее, чем другие архитектуры.
Извините, что не уточнил. Это не похоже на то, что для каждого пользователя есть адрес / порт, но адрес / порт назначается каждому пользователю (с несколькими общими портами). В этой модели для обеспечения масштабируемости клиенты могут быть подключены к разным серверам, которые должны ретранслировать сообщения. Доступен ли брокер распределенных сообщений? (т.е. тот, который отправляет опубликованные сообщения только подписавшимся узлам)
Я думаю, что Redis тоже это делает (еще не пробовал), но я полностью уверен, что NATS очень хорошо поддерживает эту функцию.
Да, я использую WebSockets для подключения пользователей к чат-серверам. Я согласен с тем, что Redis нужен, по крайней мере, для некоторых вещей, но в моей голове споры о том, должны ли сообщения проходить через Redis. Я сделаю свой вопрос немного яснее; многие пользователи будут подключены к одному и тому же адресу / порту, но каждому будет назначен один (через балансировщик нагрузки). Стандартный вариант, по-видимому, заключается в том, что пользователи подключаются к одному серверу, который обрабатывает все, от отправки сообщений до обновлений профиля. Другая модель, о которой я думаю, состоит в том, чтобы каждая комната была выделена серверу, а затем пользователи подключались к этим комнатам (каждая точка ...