(Исходный контент Ma Honeycomb Technology, общедоступный идентификатор: mfwtech)

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

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

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

1. Дизайнерские идеи и общая архитектура

Мы объединяем различные бизнес-сценарии B2C, C2B и C2C для разработки и внедрения служб обмена мгновенными сообщениями, таких как личные сообщения, консультации пользователей и отзывы пользователей в мобильном терминале Mafengwo. и другие функции.

В настоящее время службы, задействованные в IM, следующие:

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

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

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

2. Технический принцип и процесс реализации

2.1 Общий канал данных

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

2.1.1 Основной принцип взаимодействия канала передачи данных

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

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

2.1.2 Принцип реализации клиентского канала данных

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

2.2 Подписка на сообщения и их распространение

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

2.2.1 Подписка на новости

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

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

2.2.2 Распространение сообщений

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

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

2.3 Рисунок списка сообщений сеанса

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

2.3.1 Структура сообщения, отображаемого в списке

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

2.3.2 Тип сообщения и принцип управления макетом дисплея

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

2.3.3 Процесс отрисовки пользовательского интерфейса для одновременной отправки и получения сообщений

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

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

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

3. Детальная оптимизация и опыт прохождения ям

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

3.1 Дедупликация сообщений

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

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

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

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

3.2 Локализованный толчок

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

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

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

3.3 Механизм аварийного переподключения канала данных

Текущий канал передачи данных реализуется через HTTP-опрос длинных ссылок (Polling). Влияние на опрос в различных бизнес-сценариях показано на следующем рисунке:

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

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

На практике были обнаружены следующие проблемы:

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

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

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

3.4 Уникальный идентификатор сеанса

3.4.1 Для чего введен идентификатор строки сообщения?

Строка сообщения используется для представления отношения чата разговора.Разные строки сообщения представляют разговор разных объектов.На уровне БД необходима таблица для хранения этого отношения uid + object_id + busi_type = идентификатор строки сообщения.

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

Найдите идентификатор продавца, получите источник консультации и назначьте экономку
Найти существующую строку сообщения
Определите статус клиентской страницы, решите, следует ли отправить push-уведомление, и отправьте напоминание о сообщении

При таком подходе есть две проблемы:

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

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

3.4.2 Когда создавать строку сообщений

При входе на страницу сеанса для отправки сообщения проверьте, есть ли соответствующая строка сообщения в БД.Если ее нет, в качестве идентификатора строки сообщения используется идентификатор сообщения, и он повторно используется, если он существует.
При входе в сеанс проверьте, есть ли соответствующая строка сообщения в БД в соответствии с идентификатором пользователя, идентификатором типа бизнеса и т. д. Если соответствующей строки сообщения нет, создайте строку сообщения и повторно используйте ее, если она существует.

3.4.3 Цель введения строки сообщения

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

4. Перспективы и ближайшая оптимизация

4.1 Реализация канала данных обновлена до Websocket

WebSocket — это протокол для полнодуплексной связи по одному TCP-соединению. WebSocket упрощает обмен данными между клиентом и сервером, позволяя серверу активно передавать данные клиенту. В API WebSocket браузеру и серверу нужно выполнить только одно рукопожатие, и между ними может быть создано постоянное соединение, и может выполняться двусторонняя передача данных.

По сравнению с текущим механизмом реализации опроса HTTP Websocket имеет следующие преимущества:

меньше затрат на контроль. Заголовки пакетов, используемые для управления протоколом, относительно малы при обмене данными между сервером и клиентом после создания соединения. Без расширений для контента «сервер-клиент» этот заголовок имеет размер всего от 2 до 10 байт (в зависимости от длины пакета); для контента «клиент-сервер» этот заголовок требует дополнительной 4-байтовой маски. По сравнению с HTTP-запросом, каждый раз передающим полный заголовок, накладные расходы значительно сокращаются.
больше в реальном времени. Поскольку протокол является полнодуплексным, сервер может активно отправлять данные клиенту в любое время. По сравнению с HTTP, который должен ждать, пока клиент инициирует запрос для ответа сервера, задержка значительно меньше; даже по сравнению с длительным опросом, таким как Comet, он может доставлять данные больше раз за короткий период времени.
оставаться на связи. В отличие от HTTP, Websocket необходимо сначала создать соединение, что делает его протоколом с отслеживанием состояния, и некоторая информация о состоянии может быть опущена при последующей связи. И HTTP-запросам может потребоваться нести информацию о состоянии (например, аутентификацию и т. д.) в каждом запросе.
лучшая бинарная поддержка. Websocket определяет бинарные фреймы, которые упрощают обработку бинарного контента, чем HTTP.
расширение поддержки. Websocket определяет расширения, пользователи могут расширять протокол и реализовывать некоторые пользовательские подпротоколы, например, некоторые браузеры поддерживают сжатие и т. д.
Лучший эффект сжатия. По сравнению со сжатием HTTP, при надлежащей поддержке расширений Websocket может продолжать использовать контекст предыдущего контента и может значительно улучшить степень сжатия при передаче аналогичных данных.

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

Реализация HTTP-опроса будет заменена в ближайшем будущем для дальнейшей оптимизации эффективности канала данных.

4.2 Расширение бизнес-функций

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

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

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

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

(Исходное содержание Ma Honeycomb Technology)