0. Предисловие
Согласно введению «Введение | Обзор системы основных компонентов сервера mPaaS», мы уже знаем, что служба MPS mPaaS в основном предоставляет профессиональное решение для отправки мобильных сообщений, которое может предоставлять различные типы push-уведомлений для различных сценариев. удовлетворить персонализированные потребности пользователей в push-уведомлениях и интегрировать функцию push-уведомлений нескольких каналов производителей, таких как Apple, Huawei, Xiaomi, OPPO, VIVO, FCM и т. д. Предоставляя возможность быстрого нажатия на консоль, MPS также предоставляет решение для доступа к серверу, которое удобно для пользователей, позволяя быстро интегрировать функцию нажатия мобильного терминала и поддерживать взаимодействие с пользователями, тем самым эффективно повышая коэффициент удержания пользователей и удобство работы с ними.
В этой статье далее будут представлены проектирование архитектуры и основной бизнес-процесс обработки сервера MPS.Во-первых, давайте взглянем на позиционирование MPS в mPaaS:
Из приведенного выше рисунка видно, что служба push-уведомлений MPS является одним из основных основных компонентов системы mPaaS для прямой связи с клиентом.
В настоящее время все приложения в системе Ant подключены к службе push-сообщений, а благодаря эволюции архитектуры прошлых поколений, интеграции единого шлюза доступа и унифицированному использованию протокола передачи mmtp, разработанного Ant, теперь можно поддерживать несколько приложений с общим числом пользователей, превышающим один миллиард. Базовый сервис, который ежедневно отправляет миллиарды уведомлений о сообщениях.
Чтобы удовлетворить различные разнородные клиенты и другие стандартные требования к управлению и контролю приложений, MPS также поддерживает стандартный протокол http2, а также сохраняет независимый шлюз доступа (mcometgw) для поддержки облегченного развертывания, которое можно использовать в соответствии с реальными сценариями развертывания и Выберите соответствующий шлюз доступа для сетевого SDK, унаследованного клиентом.
-
Примечание 1: Spanner — это система, разработанная Ant Group на базе Nginx. Он в основном отвечает за функции разгрузки SSL, балансировки нагрузки уровня доступа HTTP и TCP и является одной из систем ввода трафика Ant Group. Благодаря стандартизированному развертыванию файла конфигурации и модулям Nginx собственной разработки Spanner может поддерживать переадресацию трафика между зонами, сине-зеленую публикацию и переключение аварийного восстановления в архитектуре LDC;
-
Заметка 2:mcometgw — это шлюз доступа команды MPS перед подключением к Spanner.Также основан на вторичной разработке Nginx.Его обработка протокола может быть связана только со службой MPS, и не может быть связана с другими компонентами mPaaS, такими как MGS и МСС.
На уровне доступа, помимо шлюза доступа, необходимого для самого уведомления о сообщении, для взаимодействия с сервисами по-прежнему требуется мобильный шлюз mPaaS (MGS), основные функции которого: клиент выполняет регистрацию устройства, привязку пользователя и третье. сторонние каналы через RPC. Кроме того, лог-шлюз MDAP в настоящее время также используется независимо. Его основной целью является сбор и загрузка скрытых точек журнала поведения клиентов в соответствии с установленными спецификациями, которые используются для системы мониторинга и анализа для анализа связанных данных и создания отчетов; приоритетность и использование журналов Учитывая частоту и схему изоляции сети от основного бизнес-канала, журналы по-прежнему загружаются через короткое соединение (http/https) Очередь доставляется в хранилище данных или другую систему анализа данных для анализа, создания отчетов, мониторинга и оповещения (связанные процессы и структура обработки не являются предметом этой статьи, вы можете обратиться к ELK и другим проектам).
Вышеупомянутый канал представляет собой собственный канал Ant, и для поддержки потребностей в управлении и контроле основных отечественных производителей мобильных телефонов и поддержки международного стандарта доступа Ant MPS также поддерживает Huawei, Xiaomi, Meizu, OPPO, VIVO, FCM. Он передается по таким каналам, как Apple APNS, и является прозрачным для серверной бизнес-системы, позволяя бизнес-системе сосредоточиться на выполнении бизнес-функций, не обращая внимания на модель терминала.
Далее мы введем несколько основных бизнес-процессов на сервере MPS.
1. Подключение устройства, регистрация и процесс привязки пользователя
В соответствии с основным принципом MPS должно быть стабильное физическое соединение TCP между клиентом и сервером. (Примечание: поддержание TCP-соединения в основном гарантируется механизмом сердцебиения, как обеспечить быстрое установление соединения и как поддерживать стабильность соединения будут представлены в специальных статьях, связанных с оптимизацией сети, позже)
Поэтому начало всех историй начинается с установления TCP-соединения. После установления TCP-соединения клиентский сетевой SDK начинает сообщать некоторую базовую информацию, такую как: идентификатор продукта клиента, номер версии, операционная система, версия операционной системы, модель и т. д. Цель состоит в том, чтобы серверная часть могла выполнять больше логики. оценивая и поддерживая многомерную отправку, MPS сохранит копию информации о соединении в кеше (Примечание: различные типы кешей могут быть адаптированы в соответствии с фактической средой развертывания: Redis, memcache или OCS, TAIR, Tbase и т. д. в системы Ali), кроме того, копия данных памяти также сохраняется в шлюзе доступа для подготовки к последующей передаче по всей сети.
Для терминальных устройств, которым необходимо использовать сторонние push-уведомления, клиентский SDK MPS зарегистрирует уникальный идентификатор стороннего канала в соответствии с типом терминала, а затем вместе вызовет сервер MPS через RPC, и MPS сгенерирует уникальный идентификатор. устройства в соответствии с базовой информацией клиента и сохранить связь между трехсторонним идентификатором канала и устройством MPS на уровне БД (Примечание. В настоящее время в основном поддерживаются MySQL и OceanBase. Для поддержки сотен миллионов пользователей, уровень сохраняемости должен нуждаться в подбазе данных и подтаблице.) Пока, в принципе, MPS достаточно отправки сообщений на основе устройств и сторонних каналов.
Конечно, бизнес-требования для принудительной отмены обычно основаны на бизнес-результатах, и уведомления должны быть отправлены назначенным пользователям. Таким образом, MPS должен поддерживать возможность маршрутизации с помощью идентификатора пользователя, поэтому для расширения до клиента требуется процесс привязки отношений между пользователями и устройствами, точно так же, как шаги привязки пользователей на приведенном выше рисунке, после завершения процесса MPS Имеет базовые условия для отправки различных измерений в ожидании бизнес-вызова.
2. Бизнес-вызов и процесс отправки сообщений
MPS в настоящее время в основном поддерживает два режима вызова:
- Вызов интерфейса бизнес-системы;
- Вызов страницы консоли mPaaS.
Общий бизнес-процесс имеет интерфейс, называемый триггером, ежедневная проверка и групповая выдача, трансляция и другие процессы могут напрямую управляться консолью. Для содержания уведомления сообщения клиента общий клиент должен строго контролировать, поэтому MPS обеспечивает функцию управления шаблонами и может работать на консоли MPAAS, например: Конфигурация может быть «Коллекция Alipay # Сумма # юаней». Только переменная Amount в шаблоне может быть заменена, а остальное содержимое фиксировано, а атрибут AMOUNT требуется только при вызове интерфейса.
Таким образом, менеджеры могут эффективно контролировать и стандартизировать содержание push-сообщений. Кроме того, когда необходимо изменить push-контент, вам нужно только сохранить шаблон, и бизнес-система может отправлять push-уведомления в соответствии с новым содержимым сообщения без каких-либо изменений. Поэтому в серверном процессе MPS есть дополнительный этап рендеринга шаблона (синхронно поддерживает шаблоны голосового вещания, а клиент может транслировать звуковое оповещение после замены языка в соответствии с типом голосового сообщения).
Во многих бизнес-сценариях пользователи могут не быть в сети или не иметь сети, когда происходит бизнес. Поэтому все сообщения сохраняются в MPS. Когда происходит бизнес, MPS попытается выполнить push-уведомление (продвижение стороннего канала или самостоятельно созданное push-соединение TCP). В самодельном канале он проверит, есть ли у пользовательского терминала TCP-соединение, запросив кеш.Если он существует, он будет отправлен.После того, как клиент получит push-сообщение, он передаст квитанцию серверу, и сервер может обновить статус сообщения. Если отправка не удалась или квитанция потеряна, пользователь повторно примет уведомление о сообщении при следующем установлении соединения, а клиент выполнит логическую дедупликацию.
3. Многомерное уведомление о широковещательном сообщении
Операторам клиентских приложений часто требуется широкомасштабная маркетинговая кампания, уведомление о сообщениях всей сети MPS, чтобы напомнить о начале активности пользователя, предлагая пользователю эффективные средства открытия приложения. Между тем, всей сети также необходимо знать объем контроля в соответствии с конкретными правилами во многих случаях (таких как: тип операционной системы, модель, версия и т. д.), и поэтому в MPS также добавлена поддержка многомерного push-уведомления.
Основные точки широковещательного толчка:самодельные каналыисторонние каналыНажмите два режима.
-
самодельные каналы, когда внешний интерфейс инициирует широковещательную задачу, после того как MPS инкапсулирует push-контент и правила, необходимые для бизнеса, шлюз доступа может просмотреть список подключений в памяти и сопоставить определенное измерение, чтобы отправить его клиенту (как показано на рисунке: крайний левый процесс).
-
Модель стороннего канала, то необходимо пересечь отношения привязки, чтобы получить трехсторонний идентификатор канала для отправки.Для приложения со 100 миллионами пользователей быстрый обход всех пользователей является наиболее мощной поддержкой действий.Поэтому MPS полагается на задачи распределенного планирования для убедитесь, что все службы в кластере участвуют в процессе отправки: в настоящее время распределенные задачи используют метод 3+1:
первый шаг:
Ежедневная ситуация диспетчерского центра будет определять, есть ли широковещательные задачи, которые должны быть обработаны в соответствии с фиксированной частотой (поддержка выражений crontab). сервер MPS-B).
Шаг 2:
Когда сервер MPS-B обнаруживает, что есть широковещательные задачи для обработки, он начинает сегментировать задачи (количество сегментов = общее количество пользователей % количество машин в кластере % количество пользователей, запланированных для выполнения каждой задачи), и назначает задачи для каждого идентификатора задачи и вернуть модель задачи в распределенный центр планирования.
третий шаг:
Центр задач распределенного планирования после получения сегментированного списка задач распределяет общее количество задач сбалансированным образом на каждую машину (MPS-A....MPS-N) в кластере, одновременно несущем идентификатор задачи и модель задачи. , После получения своих соответствующих задач они начинают обрабатывать их в соответствии с атрибутами в модели задач.
четвертый шаг:
Наконец, уведомление о сообщении вызывается по стороннему каналу одно за другим, а последующая работа передается в центр сообщений и клиент, предоставленный производителем для обработки.
До сих пор в основном был представлен основной поток обработки push-сообщений MPS.Пока код накапливается в сотрудничестве с клиентом в соответствии с этой логикой, система может появиться в соответствии с требованиями времени. Среди них соответствующее добавление режима стратегии в процесс маршрутизации push-уведомлений и добавление режима factory к трехстороннему управлению push-уведомлениями также может улучшить внешний вид системы. Кроме того, система должна поддерживать архитектуру LDC (логический центр обработки данных), поддерживать развертывание в нескольких машинных залах, в зонах с несколькими доступными зонами, чтобы соответствовать требованиям стабильности, таким как аварийное восстановление.Также необходимо настроить логику, такую как управление полетом. соответственно.
Благодаря содержанию этого раздела я надеюсь познакомить всех с инфраструктурной технологией MPS.Если у вас есть какие-либо вопросы, оставьте сообщение в фоновом режиме WeChat или войдите в систему, чтобы нажать конкретную страницу документа (t.cn/EtnB6Gu)выучить больше.
Читать в прошлом
«Начало | Обзор системы основных компонентов сервера mPaaS компании Ant Financial»
«Обзор системы основных компонентов сервера mPaaS компании Ant Financial: мобильный шлюз API MGS»
«Анализ оптимизации конструкции приложения Alipay: экстремальное сжатие размера пакета Android»
Подпишитесь на нашу официальную учетную запись, чтобы ознакомиться с технологией mPaaS из первых рук.
Группа Dingding: номер группы поиска «23124039» через Dingding
С нетерпением жду вашего присоединения ~