MobPush推送实现解析

一、MobPush概述
MobPush是MOB继一系列公共SDK之后推出的一款专注推送服务的免费SDK。可以帮助开发者更快、更方便集成实现推送功能。推送可以大幅度提升用户活跃度，有效唤醒沉睡用户。
目前MobPush可支持IOS 、Android两大平台APP集成，提供Rest API 方便开发者灵活发送推送消息，并且提供完整的可视化数据和强大管理后台。在推送形式上已经完全支持基本的通知栏消息、透传消息、本地消息的推送，并且可设置定时下发推送功能；在考虑精准推送上，MobPush支持不同程度的推送范围发送---Registration ID 、别名、标签、地理位置以及精细化的用户分群方式。

二、推送模式解析
MobPush整体使用MobPush自有通道+厂商通道的方式，厂商通道包括IOS的APNs，Android的厂商通道包括华为、小米、魅族三个通道；MobPush自有通道是自定义的一套基于UDP的更为简单的二进制网络通信协议。

以上是MobPush整体的流程， IOS的通知栏消息全部是基于APNs首先下发的，但是如果APNs发送失败，我们会再尝试使用自有消息通道进行消息下发，然后再由客户端处理为本地通知的方式到达通知栏，这样可以保证更高的消息到达能力；Android的通知消息如果对接了厂商通道，则优先会经过厂商系统级别的通道发送，并且如果厂商通道失败，会采用离线的方式保留，待客户端下次上线之后采用MobPush通道下发；所有的透传消息都是需要经过MobPush自有通道下发的。

为什么会考虑使用UDP协议？
有很多推送协议也是采用MQTT 或 XMPP 或 其他基于TCP 的方案，MQTT有QoS功能，实现了重发次数以及相关策略，但是比较复杂、可自定义程度比较低；XMPP基于xml协议，属于文本协议范畴，协议对比比较复杂且太冗余，不太适合推送系统。
MobPush定位为广大开发者提供稳定、实时的推送服务，需要能够承受极大的网络负担压力，会连接大量的客户端，并且要积极保障可快速响应；对于推送服务来说消息内容却更多是短消息内容，并非短文，大多类似于短信长度的提醒、通知、营销内容，可以控制在UDP数据包长度内，不需要进行分包处理，Internet上的标准MTU（最大传输单元）值为576字节，网络层IP需要占据20，UDP首部占用8个，所以只需要控制下发内容长度在576-20-8 =548字节即可；对于PUSH 来说，对数据的到达顺序性要求比较低，不像IM这种交互需要保障消息的顺序。
基于以上原因，UDP更加适合MobPush的协议选型了，当然在MobPush也并不是完全放弃如MQTT的Qos机制，这个会在业务代码中处理而不是靠网络协议来补偿，MobPush在对应的设置条件下可保障消息有一次的到达。MobPush在消息安全上也有所考虑，会在下发消息经过压缩、AES加密处理，而加密的AES KEY是动态生成。

既然是做推送sdk的，为什么还需要对接厂商通道呢？
其实这个也是和APP的保活有及大的关系，当前Android的保活、互拉及其困难，但是绝对重要。一般的保活方式包括：利用系统Service机制、设置进程优先级的方式、利用系统广播、使用AlarmManager、进程间相互拉起、利用Native进程等等，但是现在android的对这些机制都有了对应策略，很难发挥相对大的作用。诚然在华为、小米、魅族各系统中已经有厂商自己的推送链接服务，厂商自己的推送服务肯定是不会被杀死的，所以在考虑推送服务的时候，利用好厂商自有通道，可以很好的保障消息的准确到达，并且有的机型可以很好唤醒APP。

说到推送的长连接不得不说到另外一个问题：端口老化的问题，因为IP资源的有限以及路由器端口数量有限导致这一问题，具体关于NAT本文不分析。MobPush依靠心跳的机制来维护客户端、路由器、基站、服务端的关系，以此对抗NAT老化问题，以确保UDP链接的套接字保活。MobPush的心跳包体只有一个字节长度，能够很大的节省Client的流量，而且对于心跳时间也可以调整。

三、服务整体架构

整体采用微服务架构，各层之间逻辑清晰，能很好的做到水平扩展和服务拆分以及负载。
控制层：主要为数据入口，主要负责数据安全加解密、流控；
业务服务：和控制层dubbo交互，处理业务逻辑，可以根据实际情况做到业务降级和压力分流；
基础服务：主要包含一些数据统计、定时任务的处理：如定时推送业务、推送中心，还有最重要的为MobPush通道提供支持的UDP服务，这些服务当前也是设计为分布式服务，可以很好的进行水平扩展；
存储层：根据不同数据的重要性、实时性、量级分别输入到不同存储空间，并且根据重要数据归档日志。
在系统中，根据业务规则，使用kafka作为消息队列将业务解耦，缩短业务处理流程，将复杂的处理逻辑分层简化，异步处理，提升业务响应时间。