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

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

ИМ 1.0 — Ранняя стадия

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

IM 1.0 разработан с использованием PHP и реализует базовый доступ к обслуживанию пользователей/клиентов, отправку и получение сообщений, а также функции управления списками консультаций IM. Когда пользователь консультируется, он будет назначен службе поддержки клиентов с помощью равномерно распределенной стратегии, и отношения между пользователем и службой поддержки будут записаны. Когда пользователь/клиент отправляет сообщение, оно доставляется в очередь блокировки Redis другой стороны путем вызова модуля пересылки сообщений. Чтобы получить сообщение, модуль опроса сообщений вызывается через длинное соединение HTTP.При наличии сообщения он немедленно возвращается, а если сообщения нет, он блокируется на определенный период времени и возвращается.Цель блокировки здесь, чтобы уменьшить интервал опроса. Модель отправки и получения сообщений показана на следующем рисунке:

Оптимизация модуля опроса сообщений

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

Чтобы решить эту проблему, мы оптимизировали модуль опроса сообщений, используя фреймворк OpenResty и используя сопрограммы Lua для оптимизации долгосрочного монтирования php-fmp. Сопрограмма Lua будет решать, следует ли перехватывать сетевой запрос, помечая запрос, перенаправленный Nginx.В случае перехвата операция блокировки будет передана сопрограмме Lua для обработки, а php-fmp будет выпущен вовремя, чтобы уменьшить потребление производительность сервера. Оптимизированный поток обработки показан на следующем рисунке:

IM 2.0 — Этап настройки требований

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

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

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

IM 3.0 — служба, разделенная на фазы

Объем бизнеса постоянно накапливается, и по мере увеличения модулей код IM-системы быстро разбухает. Из-за отсутствия унифицированной спецификации кода, недостаточной ответственности за единый интерфейс и множества взаимосвязей между модулями изменение одного требования, вероятно, повлияет на другие модули, что приведет к высоким затратам на разработку и сопровождение новых требований.

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

Обслуживание клиентов: Предоставлять различные способы повышения эффективности обслуживания клиентов и удобства пользователей, такие как управление группой, управление членами, услуги по проверке качества и т. д., чтобы улучшить работу и уровень управления группы обслуживания клиентов, через службы распределения, передачи услуг сделать пользователей более эффективными в приеме Гибкий и эффективный, поддержка автоматического ответа, часто задаваемые вопросы, службы базы знаний и т. д., чтобы повысить эффективность ответа на запросы в службу поддержки и т. д.
Сервис пользователя: анализируйте поведение пользователей, создавайте рекомендации по интересам и пользовательские портреты для пользователей, а также подсчитывайте удовлетворенность пользователей обслуживанием клиентов продавцов Mafengwo.
IМ сервис: поддержка режима одиночного чата и группового чата, предоставление уведомлений о сообщениях в режиме реального времени, автономная отправка сообщений, исторический роуминг сообщений, список контактов, загрузка и хранение файлов, обнаружение контроля риска содержимого сообщений и т. д.
служба данных: Собирая исходную запись консультации пользователя, следует ли консультироваться с заказом, есть ли прием службы поддержки клиентов, информация о консультации пользователя и времени ответа службы поддержки клиентов и т. д., определяют индикаторы данных, выполняют автономный расчет данных посредством анализа данных и, наконец, предоставляют статистические данные внешних данных. Основная информация индикатора включает 30 секунд, скорость ответа за 1 минуту, количество запросов, количество неответов, среднее время ответа, продажи консультаций, коэффициент конверсии консультаций, коэффициент конверсии рекомендаций, давление при приеме с разделением времени, дежурный статус, обслуживание рейтинг и др.

Поток статуса пользователя

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

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

Рефакторинг служб обмена мгновенными сообщениями

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

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

Среди них наиболее важные уровни Proxy и Exchange предоставляют следующие услуги:

1. правила маршрутизации, такие как ip-hash, опрос, минимальное количество подключений и т. д., хешируют клиентов к разным экземплярам ChannelManager с помощью правил.

2. Управление клиентским доступом, информация о подключении после доступа будет синхронизирована с модулем DispatchTable, что удобно для Dispatcher.

3.Протокол связи между ChannelManager и клиентом, включая запрос клиента на установление соединения, отключение и повторное подключение, активное отключение, пульсацию, уведомление, отправку и получение сообщений, QoS сообщений и т. д.

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

При отправке сообщения будет логика, такая как создание строки сообщения и назначение помощника. Эти логики в настоящее время реализованы в PHP. Служба обмена мгновенными сообщениями должна знать результат выполнения PHP. Один из способов — использовать Go для повторной реализации, а другой способ — вызвать PHP через интерфейс REST для return , что приведет к слишком большому сетевому взаимодействию между службой обмена мгновенными сообщениями и бизнесом PHP, что повлияет на производительность.
При пересылке сообщений несколько экземпляров ChannelManager должны взаимодействовать друг с другом. Например, пользователь A на ChannelManager1 отправляет сообщение в службу поддержки клиентов B на ChannelManager2. Если между экземплярами нет механизма связи, сообщение не может быть перенаправлено. Когда экземпляр ChannelManager необходимо расширить, новый экземпляр должен установить связь с другими существующими экземплярами, что усложняет расширение системы.
Если клиент не поддерживает протокол WebSocket, циклический перебор длинных соединений HTTP в качестве решения для перехода на более раннюю версию можно использовать только для получения сообщений, а сообщения необходимо обрабатывать через короткие соединения. Другие сценарии не требуют пересылки сообщений и используются только для передачи сообщений в ChannelManager, которые можно отправлять напрямую через WebSocket.

Измененный процесс вызова службы обмена мгновенными сообщениями

Процесс инициализации строки сообщения и назначения обслуживания клиентов завершается бизнесом PHP. Когда требуется пересылка сообщений, бизнес PHP вызывает интерфейс отправки сообщений службы Dispatcher.Служба Dispatcher извлекает экземпляр ChannelManager, где находится получатель, с помощью общих данных Dispatcher Table, отправляет сообщение экземпляру через RPC, а ChannelManager отправляет сообщение через WebSocket клиенту. Процесс вызова службы обмена мгновенными сообщениями показан на следующем рисунке:

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

При проектировании уровня Exchange необходимо учитывать 3 вопроса:

1. Мультитерминальная синхронизация сообщений

Теперь в число клиентов входят браузер ПК, клиент Windows, H5, iOS/Android.Если пользователь заходит на несколько терминалов, при приходе сообщения нужно узнать все соединения этого пользователя.При отключении терминала пользователя нужно чтобы найти это соединение.

Как упоминалось выше, информация о подключении хранится в модуле DispatcherTable, поэтому модуль DispatcherTable должен иметь возможность быстро получать информацию о подключении на основе информации о пользователе. Дизайн модуля DispatcherTable использует хранилище хэшей Redis.После того, как клиент устанавливает соединение с ChannelManager, метаданные, которые необходимо синхронизировать, — это uid (информация о пользователе), uniquefield (уникальное значение, уникальное значение, соответствующее соединению). , wsid (идентификатор соединения), clientip (ip клиента), serverip (ip сервера), channel (канал), соответствующая структура примерно такая:

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

2. Синхронизация онлайн-статуса пользователя

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

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

3. Сообщение не теряется и не повторяется

Во избежание потери сообщения, для тех, кто использует метод опроса длинного соединения, мы при инициации запроса приведем идентификатор прочитанного сообщения клиента, а сервер рассчитает сообщение о разнице и вернет его; если используется метод WebSocket , сервер после отправки сообщения клиенту будет ждать ACK от клиента.Если у клиента нет ACK, сервер попытается отправить его несколько раз.

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

Поток сообщений для службы обмена мгновенными сообщениями

Как упоминалось выше, служба обмена мгновенными сообщениями должна поддерживать несколько терминалов, и в то же время она разделена на сторону пользователя и сторону продавца с точки зрения ролей, чтобы позволить уведомлениям и сообщениям динамически выводить дифференцированный контент в соответствии с доменное имя, терминал и роль, вводится метод DDD (Domain Driven Design) для обработки сообщений, процесс обработки показан на следующем рисунке:

Резюме и перспективы

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

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

Автор статьи: команда IM R&D платформы сотовой электронной коммерции Ma.

(Исходное содержание Ma Honeycomb Technology, пожалуйста, укажите источник и сохраните изображение QR-кода в конце статьи при перепечатке, спасибо за сотрудничество.)