Привет всем, я Бинхэ~~

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

Для управления пользователями,Существующие требования включают в себя：Добавление друзей, просмотр списка, удаление друзей, просмотр информации о друзьях, создание группового чата, присоединение к групповому чату, просмотр информации об участниках группы, @участники группы, выход из группового чата, изменение группового псевдонима, привлечение людей в группу, исключение людей из группу, закрытие групповых чатов, заполнение групповых объявлений, изменение групповых заметок и другие потребности, связанные с пользователем.

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

1. Предисловие

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

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

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

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

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

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

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

• Среда разработки: SpringBoot, SpringCloud, SpringCloud Alibaba, Dubbo.
• Кэш: Перераспределенный кеш + локальный кеш Гуавы.
• База данных: MySQL, TiDB, HBase.
• Шлюз трафика: OpenResty+Lua.
• Бизнес-шлюз: SpringCloud Gateway + Sentinel.
• Структура слоев персистентности: MyBatis, Mybatis-Plus.
• Служить конфигурацию, Служить регистрацию и открытие: Nacos.
• Промежуточное ПО для обмена сообщениями: RocketMQ.
• Сетевые коммуникации: Нетти.
• Хранилище файлов: Minio.
• Управление визуализацией журналов: ELK.
• Контейнерное управление: Swarm, Portainer.
• Мониторинг: Прометей, Графана.
• Фронтенд: Vue.
• Модульное тестирование: Юнит.
• Ориентир: JMH.
• Стресс-тест: JMeter.

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

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

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

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

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

Поскольку архитектурный проект, показанный на рис. 1.1, имеет узкое место в производительности, как мы можем его оптимизировать? С этой целью мы оптимизировали его на основе рисунка 1-1. Оптимизированная архитектура показана на рисунке 1-2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1) Базовые услуги поддержки

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

(2) Контейнеризация

На уровне контейнеризации это будет реализовано через Docker, Swarm и Portainer, а управление контейнеризацией будет осуществляться на основе Swarm и Portainer.

(3) Реализация других основных функций

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

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

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

Здесь мы можем извлечь уроки из идеи многоуровневой архитектуры DDD и разделить код на четыре уровня: уровень отображения, уровень приложения, уровень домена и уровень инфраструктуры. Однако, учитывая особенности распределенной системы обмена мгновенными сообщениями, этого не будет. Строго проектируйте многоуровневое кодирование в соответствии с принципами DDD, как показано на рисунке 1-4.

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

(1) Уровень отображения

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

(2) Прикладной уровень

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

(3) Слой домена

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

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

(4) Уровень инфраструктуры

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

8. Отправьте интерактивную ссылку в сообщении.

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

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

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

(1) Пользователь A вызывает интерфейс внутренней платформы, чтобы отправить сообщение пользователю B, и отправленное сообщение будет содержать идентификатор пользователя B и информацию о терминале.

(2) Внутренняя платформа кэширует сообщение и асинхронно записывает его в библиотеку сообщений.

(3) Внутренняя платформа получает идентификатор службы обмена мгновенными сообщениями IM, подключенной пользователем B, из Redis.

(4) После того как серверная платформа получит идентификатор службы обмена мгновенными сообщениями IM, к которой подключен пользователь B, она отправит сообщение в Тему, соответствующее идентификатору службы обмена мгновенными сообщениями IM, к которой подключен пользователь B, в РакетаMQ.

(5) Служба обмена мгновенными сообщениями IM будет отслеживать сообщения темы в RocketMQ, соответствующие ее собственному идентификатору службы. В это время служба обмена мгновенными сообщениями, подключенная пользователем B, получит сообщение.

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

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

(1) Внутренняя платформа соответствует распределенным условиям и может быть расширена по горизонтали в любое время.

(2) Служба обмена мгновенными сообщениями IM соответствует условиям распределенности и может быть расширена по горизонтали в любое время.

(3) Каждый запущенный экземпляр службы обмена мгновенными сообщениями IM имеет уникальный идентификатор в кластере.

(4) Каждая служба обмена мгновенными сообщениями IM отслеживает только сообщения темы в RocketMQ, соответствующие ее собственному идентификатору.

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

(6) Когда пользователь отправляет сообщение, идентификатор службы обмена мгновенными сообщениями IM будет получен из Redis на основе идентификатора и терминала целевого пользователя, а затем сообщение будет отправлено в тему RocketMQ, соответствующую идентификатору текущего Служба обмена мгновенными сообщениями IM.

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

9. Единая интерактивная ссылка на чат.

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

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

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

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

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

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

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

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

(1) Пользователь вызывает интерфейс внутренней платформы, чтобы отправить сообщение группе.

(2) Внутренняя платформа кэширует сообщение и асинхронно записывает его в библиотеку сообщений.

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

(4) Группируйте пользователей в соответствии с идентификатором службы и группируйте пользователей с одинаковым идентификатором службы в одну логическую группу для облегчения последующих push-сообщений и записывайте список пользователей, которые не находятся в сети.

(5) Циклически отправлять сообщения в тему в RocketMQ, соответствующую каждому идентификатору службы.

(6) Широковещательная обработка идентификаторов непрочитанных сообщений пользователей, не находящихся в сети.

(7) Служба обмена мгновенными сообщениями IM будет отслеживать тему, соответствующую ее собственному идентификатору службы, и в любое время будет получать сообщения, передаваемые в свою собственную службу.

(8) После того, как служба обмена мгновенными сообщениями получит сообщение, если пользователь отключен или пользователь не в сети, передача сообщения пользователю не удастся, или соединение, установленное между пользователем и службой обмена мгновенными сообщениями, не найдено. , и сообщение не будет отправлено пользователю.

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

Хорошо, после всего этого вы понимаете, как спроектировать хорошо масштабируемую распределенную систему обмена мгновенными сообщениями? Спешите взять блокнот, чтобы записать полученные знания и включить их в свое резюме!

11. Как написать описание резюме

В большинстве резюме будет описание проектачасть,То есть от вас требуется писать о проектах, в которых вы участвовали.,Для конкретного проекта,Как правило, вы можете начать сОписание проекта, используемая технология и ваши обязанности в проекте.Представлен в трех аспектах。

Описание проекта

распределенныйIMобмен мгновенными сообщениямисистема — это полностью независимо разработанный распределенный IMобмен. мгновенными сообщениямиплатформа,Back-end в проектировании и реализации архитектуры Служитьобщее включение：Большая серверная платформа, серверная служба обмена мгновенными сообщениями, SDK для обмена мгновенными сообщениями, служба доступа к большой модели OpenAI: ПК, H5 и небольшие программы。

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

Используемая технология

Часть выбора технологии деталей

Должностные обязанности

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

2. Отвечает за общее проектирование архитектуры передачи сообщений и написание основного кода.

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

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

5. Отвечает за проектирование и реализацию распределенного расширения крупных серверных платформ и служб обмена мгновенными сообщениями.

6. Отвечает за универсальный дизайн и реализацию SDK больших моделей OpenAI.

7. Отвечает за написание основного кода и технические исследования.

8. Организовать выпуск версии проекта и просмотреть код другого персонала отдела.

9. Всесторонне отслеживать общий ход проекта и контролировать риски проекта. За этот период неоднократно преодолевались трудности и болевые точки распределенной системы мгновенного обмена сообщениями IM.

Некоторые технические моменты заключаются в следующем:

1. Используйте высокопроизводительные сценарии OpenResty+Lua в качестве шлюза трафика распределенной системы обмена мгновенными сообщениями, обеспечивая балансировку нагрузки, несколько стратегий ограничения тока и защиты от очистки, включая: стратегии защиты от очистки, основанные на условном механизме ограничения тока, Оркестровка на основе токенов. Стратегия защиты от перехвата и стратегия защиты от перехвата основаны на механизме черного и белого списка, а данные в локальном и распределенном кеше могут быть считаны непосредственно на шлюзе трафика для проверки. проверка не удалась, результат будет возвращен напрямую, что действительно обеспечивает предварительное тестирование, предотвращающее попадание недействительного трафика на большую серверную платформу.

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

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

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

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

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

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

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

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

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

10. Независимо спроектирован и разработан SDK для подключения нескольких крупных моделей OpenAI. Благодаря внедрению SDK для больших моделей OpenAI система может подключаться к крупным моделям OpenAI, таким как ChatGPT, ChatGLM и т. д., посредством простой настройки.

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

12. Напишите в конце

Распределенную систему обмена мгновенными сообщениями можно использовать не только в реальных сценариях чата, но также можно подключить к различным сценариям отправки реальных сообщений. Для разработки и реализации этих реальных проектов, помимо распределенной системы обмена мгновенными сообщениями IM, у Glacier's Knowledge Planet также есть пять других проектов, таких как распределенная система флэш-продаж Sekill, рукописный RPC, простая система торговых центров и т. д. Требования , планы, архитектура, реализация и т. д. — все это взято из реальных бизнес-сценариев в Интернете, что позволяет вам по-настоящему изучить планы внедрения бизнеса и технологий крупных интернет-компаний и эффективно превратить их в свои собственные резервы знаний.