一、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作为音讯队列将业务解耦，缩短业务解决流程，将简单的解决逻辑分层简化，异步解决，晋升业务响应工夫。