根据《开篇 | mPaaS 服务端核心组件体系概述》的介绍，我们已经知道 mPaaS 的 MPS 服务主要提供了专业的移动消息推送方案，可以针对不同的场景提供多种推送类型，满足用户的个性化推送需求，并集成了苹果、华为、小米、OPPO、VIVO、FCM 等多个厂商渠道的推送功能。在提供控制台快速推送能力的同时，MPS 也提供了服务端接入方案，方便用户快速集成移动终端推送功能，与用户保持互动，从而有效地提高用户留存率，提升用户体验。

本文将进一步介绍 MPS 服务端的架构设计和核心业务处理流程，首先看一下 MPS 在mPaaS 中的定位：

通过上图可知 MPS 推送服务为 mPaaS 体系内直接与客户端通讯的核心必备基础组件之一，其基础原理为基于 TCP 长连接通道进行“消息通知”相关业务数据传输。

目前蚂蚁体系内所有 App 均已接入了消息推送服务，并通过历代架构演进、对接统一接入网关、统一使用蚂蚁自研 mmtp 传输协议，形成如今可支持多 App，总量用户量超过十亿，每天推送数十亿消息通知的基础服务。

为满足多种异构客户端，以及其他行业 App 标准管控需求，MPS 同样支持 http2 标准协议，并为支持轻量化部署也依然保留了独立接入网关(mcometgw)，可在根据实际部署场景以及客户端所继承的网络 SDK 选择对应的接入网关。

注 1:Spanner 是蚂蚁集团基于 Nginx 二次开发而来的一个系统。主要承担 SSL 卸载、HTTP、TCP 接入层负载均衡的功能，是蚂蚁集团的流量入口系统之一。通过规范的配置文件部署和自研 Nginx 模块，Spanner 可以支持 LDC 架构下的流量 Zone 间转发、蓝绿发布、容灾切换等功能；

注 2:mcometgw 为 MPS 团队在接入 Spanner 之前的接入网关，同样也是基于Nginx 二次开发，其协议处理只能与 MPS 服务对接，无法与 MGS，MSS 等其他mPaaS 组件对接。

在接入层，除消息通知自身所需的接入网关外，依然需要 mPaaS 移动网关(MGS)配合服务，其主要作用为：客户端通过 RPC 进行设备注册、用户绑定、以及第三方渠道的关系绑定。另外，目前还独立使用了日志网关 MDAP，其主要目的为：按照既定规范采集和上传客户端行为日志埋点，用于监控分析系统进行相关数据分析与报表制作；考虑到日志的优先级与使用频率考虑，以及与主业务链路进行网络隔离方面设计，目前日志依然采用了短连接(http/https)的方式上传，客户端日志上报后，会通过部署在应用服务上的日志采集工具与消息队列投递至数据仓库或其他数据分析系统进行分析、报表制作以及监控报警(相关流程和处理框架非本文重点，可参考 ELK 等设计)。

在此之上所介绍的为蚂蚁的自建渠道，而为了支持国内各大手机产商的管控需求以及支持蚂蚁国际标准接入，MPS 同时也支持了华为、小米、魅族、OPPO、VIVO、FCM 和苹果的 APNS 等渠道推送，并对后端业务系统保持透明，可让业务系统专注于完成业务功能，无需关注终端机型。

接着，我们将介绍下 MPS 服务端的几个核心业务流程。

1

设备建连、注册、绑定用户流程

由 MPS 的基础原理所需，客户端与服务端之间必须要有一条稳定 TCP 物理连接。(注：TCP 连接维持主要通过心跳机制保障，如何保证快速建联，以及如何保持连接的稳定性后续将专门的网络优化相关文章介绍)

因此，所有故事的开头，都是由建立 TCP 连接开始。随 TCP 连接建立之后客户端网络 SDK 即开始上报一些基础信息，如：客户端产品 ID，版本号，操作系统，操作系统版本，机型等等，其目的是为了后端可以做更多的逻辑判断、支持多维度的推送，MPS 会保存一份连接信息至缓存( 注：可根据实际部署环境适配多种类型缓存：Redis、memcache 或者阿里体系内的 OCS、TAIR、Tbase 等等)，此外在接入网关也会保存一份内存数据，为后续全网推送做准备。

对于需要用到第三方推送的终端设备，MPS 客户端 SDK 会根据终端类型注册三方渠道的唯一 ID，随后通过 RPC 一并调用到 MPS 服务端，MPS 则会根据客户端的基础信息生成设备的唯一 ID，并将三方渠道 ID 与 MPS 设备之间的关系持久化至 DB 层( 注：目前主要支持 MySQL 和 OceanBase，为支持亿级用户，持久层必然需要分库、分表 )，至此，原则上 MPS 基于设备维度和基于第三方渠道的消息推送均已可满足。

当然，业务对于消推送的诉求，一般是基于业务结果，需要对指定用户推送通知。因此，MPS 必须支持通过用户 ID 路由推送的能力，因而延伸到客户端，就需要有一个用户与设备关系绑定的过程，正如上图中的用户绑定步骤，待流程完成后，MPS 已具备各种维度推送的基本条件，静待业务调用。

2

业务调用、消息推送过程

目前 MPS 主要支持两种调用模式：

业务系统接口调用；

mPaaS控制台页面调用。

一般业务流程已接口调用触发为主，日常验证和群发、广播等流程则可通过控制台来直接操作。对于客户端消息通知内容，一般客户端需要进行严格管控，因此 MPS 提供了推送模板管理的功能，可在 mPaaS 控制台进行操作，例如：配置可一个“支付宝收款#amount#元。”的模板，模板中只有 amount 变量可替换，其他内容均为固定，接口调用时也只需传输 amount 属性。

如此，管理人员可有效的控制和规范推送消息内容。此外，当推送内容需要变更时，只需维护模板，业务系统完全不做任何变动即可按照新的消息内容推送通知。因此，在 MPS 的服务端流程中便多了一个模板渲染的步骤(同步支持语音播报模板，客户端可根据语音类型消息，进行语言替换后播报声音通知)。

在非常多的业务场景中，当业务发生时用户未必在线，也未必有网络。因此，在 MPS 中所有消息均会被持久化。业务发生时，MPS 会尝试做一次推送(第三方渠道推送或自建的TCP 连接推送)。自建渠道中，会通过查询缓存来判断用户的终端是否有 TCP 连接，如果存在则推送，客户端收到推送消息后，会给服务端回执，服务端即可更新消息状态。如果推送失败，或者回执丢失，用户在下一次建立连接时，会重新接受消息通知，同时客户端会进行逻辑去重。

3

多维度广播消息通知推送

客户端 App 运营往往需要进行大规模的营销活动，MPS 全网消息通知，是提醒用户活动开始的，促使用户打开 App 的有效手段。同时，全网通知在很多时候也需要按照特定的规则进行控制范围(如：操作系统类型，机型，版本等)，因此 MPS 也添加了多维度推送的支持。

广播推送主要分：自建渠道和第三方渠道推送两种模式。

自建渠道，在前端触发广播任务时，MPS 封装好推送内容与业务所需规则后，即可由接入网关来遍历内存中的连接列表，并匹配特定维度来推送至客户端(如图中：最左侧流程)。

第三方渠道模式，则需采用循环遍历绑定关系获取三方渠道 ID 来推送，对于亿级用户的 App 而言，快速的遍历所有用户，是对活动最强有力的支持，因此 MPS 依赖了分布式调度任务来确保集群各服务都参与到推送过程中来：分布式任务目前采用 3+1 的方式：

> 第一步：

调度中心日常情况会按照固定的频率(支持 crontab 表达式)来检测是否有待处理的广播任务，为避免重复触发和冗余推送，检测过程是单任务，通过单机检测(如：图中 step1: 随机调度的是 MPS-B 服务器)。

> 第二步：

当 MPS-B 服务器，检测到有待处理广播任务后，开始进行任务分片(分片数=总用户数 % 集群中机器数 % 计划每个任务执行的用户数)，并对每个任务分配任务 ID，并将任务模型返回给分布式调度中心。

> 第三步：

分布式调度任务中心，接收到分片任务列表后，将总任务趋于均衡的分配给集群中每台机器(MPS-A....MPS-N)同时携带任务 ID 和任务模型，各服务器领取到各自任务后，开始根据任务模型中的属性各自处理。

> 第四步：

最终将消息通知挨条调用至第三方渠道，后面的工作则交给产商提供的消息中心与客户端处理。

至此，MPS 消息推送最主要的处理流程基本介绍完毕，只要按照这个逻辑与客户端配合把代码堆起来，系统就可应运而生了。其中，在推送路由过程中适当的加入策略模式、三方渠道推送管理中加入工厂模式等设计，也可以让系统做的更好看。更进一步，系统需要支持 LDC(Logical Data Center) 架构，支持多机房，多可用区(Zone)部署，以满足容灾等稳定性需求，在类似这种部署方式下系统内部调用关系，分布式调度任务控制等逻辑也需要进行适当的调整。

通过本节内容，希望给大家通篇介绍 MPS 的基础架构技术，如果有问题欢迎大家微信后台留言，或登录消息推送具体文档页(http://t.cn/EtnB6Gu)了解更多。