Эту статью опубликовал Бинхэ. Первоначальное название было: «Как написать эту распределенную систему обмена мгновенными сообщениями в своем резюме? Я разобрался с этим за вас!» Эта статья была отредактирована и изменена.

1. Введение

Распределенная система мгновенного обмена сообщениями IM — это, по сути, управление онлайн-чатами и пользователями.

К самому чату основные требования таковы:Отправить текст、картина、документ、голос、видео、Кэш сообщений、Хранение сообщений、Сообщение непрочитано、Читать、отзывать,Автономные сообщения, исторические сообщения, одиночный чат, групповой чат,Синхронизация нескольких терминалов,и другие требования.

Существующие требования к управлению пользователями включают:Добавить друзей、Посмотреть список друзей、удалить друга、Просмотр информации о друзьях、Создать групповой чат、Присоединяйтесь к групповому чату、Просмотр информации об участниках группы、Выйти из группового чата、Изменить псевдоним группы、Пригласить людей в группу、Выгнать кого-нибудь из группы、Закрыть групповой чат、Заполните объявление группы、Изменить групповые заметки и другие потребности, связанные с пользователем, и т. д.

Чтобы лучше понять конструкцию распределенной системы обмена мгновенными сообщениями, я стоял с точки зрения архитектора. После полного понимания требований к системе, бизнес-процессов и технических процессов, я поставил цели программы для системы с глобальной точки зрения и выбрал. Набрать технические решения, выполнить проектирование общей и иерархической архитектуры системы, а также разобраться с интерактивными ссылками для отправки сообщений, одиночных и групповых чатов.Надеюсь, это поможет вам。

2. Цели программы

Прежде чем приступить к выбору технологии и общему проектированию архитектуры, необходимо прояснить одну вещь: независимо от того, какое решение или архитектура будет принято для системы, необходимо четко определить бизнес-цели, технические цели и архитектурные цели решения. , а также в процессе исследований и разработок. Постоянно оценивайте общую производительность системы, выявляйте узкие места системы и постоянно оптимизируйте их.

В целом распределенная система обмена мгновенными сообщениями, которую мы создаем и развиваем, должна соответствовать следующим целям программы.

Конкретно:

• 1）бизнес-цели：Удовлетворение различных сценариев спроса в главе «Проектирование спроса».；
• 2）технические цели：Поддержка неограниченного расширения,Миллионы пользователей одновременно общаются в сети;
• 3）архитектурные цели：Высокий параллелизм、высокая производительность、Высокая доступность、контролируемый、Возможно раннее предупреждение、Масштабируемый,Поддерживает неограниченное расширение.

3. Выбор технологии

С точки зрения выбора технологий, помимо использования базовых фреймворков, таких как SpringBoot, также будут использоваться решения по контейнеризации.

При этом, чтобы максимально снизить технический порог, при выборе технологии всей распределенной системы обмена мгновенными сообщениями в основном используются наиболее популярные на рынке технические платформы и решения.

Конкретный выбор следующий:

• 1）рамки развития：SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo；
• 2）кэш：Redisраспределенныйкэш+Guavaместныйкэш；
• 3）база данных：MySQL、TiDB、HBase；
• 4）шлюз трафика：OpenResty+Lua；
• 5）Бизнес-шлюз：SpringCloud Gateway + Sentinel；
• 6）Структура уровня сохраняемости：MyBatis、Mybatis-Plus；
• 7）Конфигурация сервиса、Регистрация и обнаружение услуг：Nacos；
• 8）информацияпромежуточное программное обеспечение：RocketMQ；
• 9）сетевая связь：Netty；
• 10）документхранилище：Minio；
• 11）бревно Визуализацияуправление：ELK；
• 12）Контейнерное управление：Swarm、Portainer；
• 13）монитор：Prometheus、Grafana；
• 14）внешний интерфейс：Vue；
• 15）Модульное тестирование：Junit；
• 16）Контрольный показатель：JMH；
• 17）стресс-тест：JMeter。

4. Предварительный архитектурный проект

Для системы обмена мгновенными сообщениями она охватывает серверные службы обмена мгновенными сообщениями, большие серверные платформы, службы доступа SDK, службы доступа OpenAI и большой интерфейсный интерфейс. Я считаю, что многие друзья могут более или менее использовать обмен мгновенными сообщениями. Схема архитектуры системы примерно такая, как показано на рисунке ниже.

Фактически, этот тип архитектуры также относительно распространен. В этой архитектуре Kong/Openresty/Nginx занимается только балансировкой нагрузки и обратным прокси-сервером. Сотрудники отдела исследований и разработок больше внимания уделяют разработке бизнес-уровня и базового уровня. небольшие часы, такой архитектурный дизайн обычно не вызывает никаких проблем. Однако, как только трафик станет относительно большим и пользователи вызовут интерфейс внутренней платформы для отправки сообщений, SDK обмена мгновенными сообщениями будет синхронно вызывать интерфейс службы обмена мгновенными сообщениями, и возникнут проблемы с производительностью.

Поскольку каждый терминал может установить соединение только с одним экземпляром службы обмена мгновенными сообщениями одновременно, если к одной службе обмена мгновенными сообщениями подключено большое количество пользовательских терминалов, SDK обмена мгновенными сообщениями будет часто и синхронно вызывать интерфейс та же служба обмена мгновенными сообщениями IM. Возникает узкое место в производительности. В настоящее время, когда возникает узкое место в производительности, это не только влияет на службу обмена мгновенными сообщениями IM, но также оказывает определенное влияние на работу внутренней платформы по приему запросов.

5. Оптимизация архитектурного проекта.

Поскольку в архитектурном проекте, показанном на рисунке в предыдущем разделе, есть узкое место в производительности, как мы можем его оптимизировать?

Для этого мы провели оптимизацию на основе предыдущего рисунка. Оптимизированная архитектура показана на рисунке ниже.

Сравнивая эти два рисунка, мы видим, что, исходя из сокрытия деталей технической реализации, мы будем осуществлять внешнюю проверку бизнеса и контроль трафика, а также расширим обязанности Kong/OpenResty/Nginx, чтобы это программное обеспечение имело не только обратный прокси-сервер. Функция балансировки нагрузки также может реализовывать такие функции, как ограничение тока, черные и белые списки, контроль трафика и проверка бизнеса.

Другими словами, в рамках этой архитектурной модели мы полностью раскрываем обязанности по входу во всю распределенную систему обмена мгновенными сообщениями, в полной мере используем возможности высокого параллелизма и высокой пропускной способности Kong/OpenResty/Nginx и пытаемся заблокировать большинство недействительных данных. запросы за пределами всей системы. Например, пользователи пытаются вызывать такие интерфейсы, как отправка сообщений, добавление друзей, добавление групп и т. д. без входа в систему. Это значительно снизит нагрузку бизнеса на серверную платформу.

Помимо реализации таких функций, как ограничение тока, черные и белые списки, контроль трафика и проверка бизнеса в Kong/OpenResty/Nginx, мы также представили кластеры бизнес-шлюзов для реализации ограничения тока, понижения версии, автоматического выключателя, управления потоком, проверки и аутентификации. и т. д. для дальнейшего обеспечения стабильности и безопасности последующих систем.

Чтобы решить проблему, связанную с тем, что большое количество пользовательских терминалов подключено к одному и тому же IMобмену, мгновенными экземпляр службы сообщений,IMобмен мгновенными сообщениямиSDK часто вызывает один и тот же IMобмен мгновенными экземпляр службы сообщенийизвызвано интерфейсомиз Проблемы с производительностью。Мы представили кластер RocketMQ между SDK службы обмена мгновенными сообщениями IM и службой обмена мгновенными сообщениями IM.

Каждый экземпляр службы обмена мгновенными сообщениями IM в кластере службы обмена мгновенными сообщениями IM имеет уникальный идентификатор в кластере, и после запуска каждого экземпляра службы обмена мгновенными сообщениями IM он будет прослушивать только тему, связанную с его собственным идентификатором в RocketMQ. Таким образом, каждая служба обмена мгновенными сообщениями IM будет получать сообщения только в теме, связанной с ее собственным идентификатором, и не будет получать все сообщения.

При входе пользователя в систему будет установлено длительное соединение со службой обмена мгновенными сообщениями IM, в качестве ключа будут использоваться идентификатор пользователя и терминал, а в качестве значения будет использоваться идентификатор службы обмена мгновенными сообщениями IM. , который будет храниться в распределенном кеше. При этом идентификатор пользователя и терминала будут использоваться в качестве ключа, а длинное соединение, установленное пользовательским терминалом и службой обмена мгновенными сообщениями IM, будет использоваться в качестве значения, которое будет храниться в локальной памяти IM. служба мгновенных сообщений.

Когда пользователь вызывает интерфейс внутренней платформы для отправки сообщения, будет передан идентификатор целевого пользователя, а терминальное устройство, на котором пользователь входит в систему, будет указано в SDK обмена мгновенными сообщениями. Сообщение в конечном итоге будет отправлено. отправляться в RocketMQ через SDK для обмена мгновенными сообщениями.

В это время SDK обмена мгновенными сообщениями IM получит идентификатор службы обмена мгновенными сообщениями, подключенной к целевому пользователю, из распределенного кэша на основе идентификатора целевого пользователя и терминала, и отправит сообщение в тему, связанную с этим идентификатором. В это время служба обмена мгновенными сообщениями IM, которая устанавливает длинное соединение с целевым пользователем, получит сообщение в RocketMQ, а затем получит длинное соединение, установленное с пользовательским терминалом, из локального кэша на основе идентификатора пользователя и терминала и отправит сообщение это пользователю на основе этой длинной информации о соединении.

Кроме того, в реальной реализации, чтобы предотвратить одновременное подключение большого количества пользователей только к одному экземпляру службы в кластере службы обмена мгновенными сообщениями IM, операции хеширования и по модулю будут выполняться на IP-адресе, отпечатке браузера, мобильном телефоне. телефонное устройство и т. д., к которому подключается пользователь, чтобы максимально равномерно распределить их по каждому экземпляру службы в кластере.

Итак, вопрос в том, есть ли возможности для дальнейшей оптимизации этого архитектурного решения?

6. Проектирование архитектуры контейнеризации

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

Как видите, мы дополнительно оптимизировали архитектуру распределенной системы обмена мгновенными сообщениями и внедрили контейнерную архитектуру. На основе исходной архитектуры мы внесли следующие улучшения и оптимизации.

1) Базовые услуги поддержки:базовая поддержка Служитьбудет основываться на различныхпромежуточное программное обеспечение、Служба хранения данных、а такжемонитор Служитьвыполнить,Включает: базу данных MySQL, базу данных TiDB, HBase, кэш Redis, очередь сообщений RocketMQ, мониторинг Prometheus и управление контейнерами Portainer, а также другие базовые реализации промежуточного программного обеспечения.,Базовые услуги поддержки повлияют на всю распределеннуюIMобмен мгновенными Система сообщений предоставляет самые основные данные, передачу инфекции、Такие услуги, как мониторинг и управление контейнерами.

2) Контейнеризация:На уровне контейнеризации,Будет реализовано через Docker, Swarm и Portainer.,в,Контейнеризация будет управляться на основе Swarm и Portainer.

3) Реализация других основных функций:В дополнение к вышеописанной многоуровневой архитектуре,Для построения распределенной системы мгновенных сообщений.,Также рассмотрите исключениямонитор、Регистрация и обнаружение услуг、Визуализация、Деградация сервиса и скрытые данные、Ограничение сервисного тока、Аварийное восстановление услуги、Планирование мощности, расширение и сокращение, полноканальное стресс-тестирование и т. д.

7. Проектирование многоуровневой бизнес-архитектуры DDD

В распределенной системе обмена мгновенными сообщениями, будь то большая серверная платформа или служба обмена мгновенными сообщениями, мы примем многоуровневую бизнес-архитектуру для кода бизнес-уровня.

Здесь мы можем извлечь уроки из идеи многоуровневой архитектуры DDD и разделить код на четыре уровня: уровень отображения, уровень приложения, уровень домена и уровень инфраструктуры.

Однако, учитывая особенности распределенной системы обмена мгновенными сообщениями IM, многоуровневое кодирование не будет проектироваться строго в соответствии с принципами DDD, как показано на рисунке ниже.

Видно, что распределенная система обмена мгновенными сообщениями будет опираться на конструктивные идеи DDD, но не будет полностью соответствовать DDD.

1) Уровень отображения:Уровень представления,Также называется слоем пользовательского интерфейса.,Это верхний уровень дизайна DDD.,Предоставление API-интерфейса внешним сторонам,Получить запрос клиента,Параметры анализа,Возвращать данные результата,и обрабатывать исключения.

2) Прикладной уровень:Прикладной уровень,Также называется прикладным уровнем.,Уровень приложений в основном обрабатывает бизнес-сценарии, которые подвержены изменениям.,Может выполняться соответствующая обработка связанных событий, планирование и другие операции агрегирования.

3) Уровень домена:Слой домена,Также называется слоем домена.,Можно сказать, что уровень предметной области является сутью проектирования DDD.,Он абстрагирует относительно неизмененные части бизнес-системы и инкапсулирует их в модель предметной области. При проектировании распределенной системы мгновенных сообщений.,Уровень предметной области в принципе не зависит от других слоев.,Это также не зависит от уровня инфраструктуры.,Вот отличие от дизайна DDD.

4) Уровень инфраструктуры:уровень инфраструктуры,Также называется уровнем инфраструктуры.,Уровень инфраструктуры будет предоставлять общие базовые возможности другим уровням.,В распределенной системе обмена мгновенными сообщениями.,включая Понятнокэш、Общие инструменты、информация、Механизм сохранения системы и т. д.

8. Общая ссылка для взаимодействия с мгновенными сообщениями.

В распределенной системе обмена мгновенными сообщениями IM мы игнорируем некоторые другие детали и фокусируемся на интерактивной логике отправки сообщений. Независимо от того, является ли это одиночным или групповым чатом, сообщения в конечном итоге необходимо доставлять на терминал пользователя через службу обмена мгновенными сообщениями IM. Процесс отправки сообщений в это время показан на рисунке ниже.

Вы можете увидеть:Пользователи распределеныIMобмен мгновенными система сообщений отправляет информацию,Будь то одиночный чат или групповой чат,Последнее сообщение будет отправлено на терминальное устройство, на котором пользователь входит в систему. Предположим, что пользователь A в это время отправляет сообщение пользователю B.,Или пользователь А и пользователь Б находятся в одной группе,Пользователь А отправляет сообщение группе,пользовательBперениматьинформация Основной процесс заключается в следующем。

Конкретно:

• 1）пользовательAвызовназадтерминальная платформаизинтерфейс дляпользовательBотправлятьинформация,иотправлятьизинформациясерединабудет иметьпользовательBизIDи информация о терминале；
• 2）Бэкэнд-платформа будет Кэш сообщенийвставать,и будетинформация Асинхронная записьинформация Библиотека；
• 3）Бэкэнд-платформа отRedisсерединаполучатьпользовательBсоединятьизIMобмен мгновенными сообщениями СлужитьизID；
• 4）назадтерминальная платформаполучатьприезжатьпользовательBсоединятьизIMобмен мгновенными После ввода идентификатора сервиса он подключится к IMобмену пользователя B в RocketMQ. мгновенными сообщениями СлужитьIDпереписыватьсяизTopicотправлятьинформация；
• 5）IMобмен мгновенными Служба сообщений будет отслеживать сообщения темы в RocketMQ, соответствующие ее собственному идентификатору службы. В это время IMобмен. мгновенными сообщениями Служитьвстречаперениматьприезжатьинформация；
• 6）IMобмен мгновенными После получения сообщения служба сообщений получит пользователя B и IMобмен из кэша на основе идентификатора пользователя B и информации о терминале. мгновенными сообщениями Служить Учреждатьизсоединять,и通过这个соединять КпользовательBтолкатьинформация。

Для реализации процесса отправки сообщений, как указано выше, должны быть выполнены следующие условия:

• 1）Серверная платформа соответствует распределенным условиям,Может быть расширен горизонтально в любое время;
• 2）IMобмен мгновенными сообщениями Служить满足распределенный条件,Может быть расширен горизонтально в любое время;
• 3）каждыйзапускатьизIMобмен мгновенными экземпляры службы сообщений имеют уникальный идентификатор в кластере;
• 4）каждыйIMобмен мгновенными сообщениями Служить,Они следят только за собойIDпереписыватьсяизRocketMQсерединаTopicизинформация；
• 5）пользователь Войти в распределеннуюIMобмен мгновенными система сообщений будет работать с IMобменом мгновенными Служба сообщений устанавливает длинное соединение, кэширует длинное соединение на основе идентификатора пользователя и терминала, на котором оно расположено, и кэширует подключенные IMобмены на основе идентификатора пользователя и терминала, на котором он расположен. мгновенными Идентификатор службы сообщений кэшируется в Redis;
• 6）пользовательотправлятьинформациячас,встреча根据目标пользовательизIDи терминал отRedisсерединаполучатьIMобмен мгновенными идентификатор службы сообщений, который, в свою очередь, предоставляет текущий IMобмен мгновенными сообщениями СлужитьизIDпереписыватьсяизRocketMQизTopicотправлятьинформация；
• 7）переписыватьсяизIMобмен мгновенными сообщениями Служитьслушай иперениматьприезжатьRocketMQинформацияназад,Информация о подключении пользователя будет получена из кэша на основе идентификатора целевого пользователя и терминала.,к целипользовательтолкатьинформация。

9. Интерактивная ссылка на единый чат для обмена мгновенными сообщениями

Единый чат означает, что в распределенной системе обмена мгновенными сообщениями один пользователь напрямую общается с другим пользователем, что представляет собой чат один на один. В этом сценарии весьма вероятно, что среди двух пользователей, общающихся в одиночку, один пользователь не находится в сети.

Например:пользовательAДаватьпользовательBотправлятьинформациячас,Пользователь Б может быть не в сети.

На данный момент нам нужно сохранить сообщение, отправленное пользователем А пользователю Б.

Фактически, в реализованной нами распределенной системе обмена мгновенными сообщениями записи сообщений будут храниться независимо от того, находится ли пользователь Б в сети или нет. Когда пользователь Б входит в систему, сообщение синхронизируется с пользователем Б, как показано на рисунке ниже.

Как видите, когда пользователь А отправляет сообщение пользователю Б:

• 1）еслипользовательBонлайн,Вы можете следитьотправлятьинформацияизинтерактивное направление ссылкипользовательBотправлятьинформация Понятно；
• 2）еслипользовательBНетонлайн,в это времяне мочьпользовательBнормальныйтолкатьинформация。когдапользовательBВойти в распределеннуюIMобмен мгновенными сообщениямисистеманазад,Будет вызван интерфейс серверной платформы для извлечения всех непрочитанных сообщений.,и пройтипользовательBонлайннаправление процессапользовательBтолкатьинформация。

10. Интерактивная ссылка на групповой чат в мгновенных сообщениях

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

В настоящее время при отправке сообщения мы можем узнать всех онлайн-пользователей в группе через идентификатор группы и мгновенно отправить сообщение онлайн-пользователям.

Те пользователи, которые не в сети, будут обрабатываться как отдельные пользователи чата, которые не находятся в сети, как показано на рисунке ниже.

Видно, что процесс интерактивного связывания группового чата выглядит следующим образом:

• 1）пользовательвызовназадтерминальная платформаизинтерфейс для群组отправлятьинформация；
• 2）Бэкэнд-платформа будет Кэш сообщенийи Асинхронная записьинформация Библиотека；
• 3）Потому что это для группыотправлятьинформация,В группе несколько пользователей,в это времяначнется сRedisсерединаполучать所有пользовательсоединятьизIMобмен мгновенными список идентификаторов службы сообщений;
• 4）вернопользовательв соответствии с СлужитьIDГруппа,Группируйте пользователей с одинаковым идентификатором службы в одну логическую группу.,Удобно для последующих push-сообщений,И будет записан список пользователей, которые не онлайн;
• 5）круговое направлениекаждый СлужитьIDпереписыватьсяизRocketMQсерединаизTopicотправлятьинформация；
• 6）Трансляция не обработанаонлайнпользовательизнепрочитанныйинформацияID；
• 7）IMобмен мгновенными сообщениями Служитьвстреча监听自身СлужитьIDпереписыватьсяизTopic,встреча随часперениматьтолкатьприезжать自身Служитьизинформация；
• 8）когдаIMобмен мгновенными После того как служба сообщений получит сообщение, если пользователь отключится или не будет в сети, отправка сообщения пользователю не удастся, или пользователь и IMобмен не смогут быть запрошены. мгновенными сообщениями Служить Учреждатьизсоединять,就Нетвстреча Кпользовательтолкатьинформация；
• 9）когдапользователь Войти в распределеннуюIMобмен мгновенными сообщениямисистеманазад,Исторические (автономные) сообщения будут извлекаться с серверной платформы.,и через онлайн-процесс пользователя,Кпользовательтолкатьинформация；

хорошо,см. здесь,Вы понимаете, как создать высокомасштабируемуюизраспределенныйIMобмен мгновенными сообщениямисистема Понятно?？（Эта статья была опубликована одновременно в：http://www.52im.net/thread-4564-1-1.html）

11. Соответствующая информация

[1] Краткое обсуждение архитектуры системы IM.

[2] Кратко опишите подводные камни разработки мобильного IM: проект архитектуры, протокол связи и клиент.

[3] Набор практики проектирования архитектуры мобильного обмена мгновенными сообщениями для массового онлайн-пользователя (включая подробные изображения и тексты).

[4] Оригинальная теоретическая схема архитектуры распределенной системы обмена мгновенными сообщениями (IM).

[5] Как обеспечить эффективность и производительность в режиме реального времени при отправке крупномасштабных групповых сообщений в мобильном обмене мгновенными сообщениями?

[6] Набор технической информации об архитектуре IM для сотен миллионов пользователей (Часть 1): общая архитектура, разделение услуг и т. д.

[7] Набор технической информации по архитектуре ИМ для сотен миллионов пользователей (Часть 2): надежность, упорядоченность, слабая оптимизация сети и т.д.

[8] От новичка до эксперта: Как спроектировать распределенную систему обмена мгновенными сообщениями с миллиардами сообщений.

[9] Раскрыта архитектура IM-архитектуры Enterprise WeChat: модель сообщений, десятки тысяч людей, уведомления о прочтении, отзыв сообщений и т. д.

[10] Обмен технологиями Rongyun: всестороннее раскрытие надежного механизма доставки миллиардов мгновенных сообщений.

[11] Совместное использование технологий Alibaba IM (3): Архитектурная эволюция системы обмена мгновенными сообщениями Xianyu на миллиардном уровне.

[12] На основе практики: краткое изложение технических ключевых моментов небольшой системы обмена мгновенными сообщениями с одним миллионом сообщений.

[13] Изучите IM из исходного кода (10): Создайте высокопроизводительный кластер IM на основе Netty (включая технические идеи + исходный код).

[14] Архитектурная практика и размышления о комплексной системе обмена сообщениями TPS IM уровня 100 000.

[15] Путь к технической практике самостоятельной разработки системы IM обслуживания клиентов от 0 до 1.

[16] Проектирование архитектуры и практика чата для массовых пользователей.

[17] Самая популярная статья о Netty для начинающих в истории: базовое введение, построение среды и практическая практика.

[18] Начало работы: наиболее тщательный анализ принципов высокой производительности и архитектуры платформы Netty на данный момент.

[19] Написано для начинающих: методы обучения и передовые стратегии для высокопроизводительной Java-инфраструктуры NIO Netty.

[20] Шаг за шагом научите вас, как использовать Netty для реализации механизма пульса и механизма отключения и повторного подключения программ сетевой связи.

[21] Начало работы с самым мощным Java NIO в истории: если вы боитесь, что начнете и бросите, прочтите эту статью!