一、MobPush概述MobPush是MOB继一系列公共SDK之后推出的一款专注于推送服务的免费SDK。可以帮助开发者更快更方便的集成实现推送功能。推送可以大大增加用户活跃度，有效唤醒沉睡的用户。目前MobPush可以支持IOS和Android平台的APP集成，提供RestAPI方便开发者灵活发送推送消息，提供完整的可视化数据和强大的管理后台。在推送形式上，已经全面支持基础通知栏消息、透传消息、本地消息的推送，并且可以设置定时发送推送功能；在精准推送方面，MobPush支持不同级别的推送范围发送——注册ID、别名、标签、地理位置、精细化的用户分组方式。2.推送模式分析MobPush采用MobPush自有渠道+厂商渠道为一体。厂商渠道包括IOSAPNs，安卓厂商渠道包括华为、小米、魅族。MobPush自带的通道是基于UDP自定义设置的，是一种更简单的二进制网络通信协议。以上就是MobPush的整体流程。IOS通知栏的消息都是先基于APNs发送的。但是，如果APNs发送失败，我们会尝试使用自己的消息通道发送消息，然后客户端会作为本地通知处理。到达通知栏的方式，可以保证更高的消息可达性；如果Android通知消息接入厂商通道，则优先通过厂商系统级通道发送，如果厂商通道失效，则保留离线。客户端下次上线后，通过MobPush通道进行投递；所有透传消息都需要通过MobPush自带的通道进行传递。为什么会考虑使用UDP协议？许多推送协议也使用MQTT或XMPP或其他基于TCP的解决方案。MQTT有QoS功能，实现了重传次数和相关策略，但是比较复杂，可定制性差；XMPP基于xml协议，属于文本协议范畴，协议比较比较复杂，过于冗余，不适合推送系统。MobPush定位于为广大开发者提供稳定、实时的推送服务。需要能够承受巨大的网络负载压力，连接大量客户端，主动保证快速响应；对于推送服务，消息内容更为重要。短信的内容，不是短文本，多类似短信长度的提醒、通知、营销等内容，可以控制在UDP数据包长度内，无需分包处理。网上标准的MTU（MaximumTransmissionUnit）值是576个字符Section，网络层IP需要占用20个，UDPheader占用8个，所以只需要控制下发内容的长度在576-20即可-8=548字节；对于PUSH来说，对于数据到达的顺序要求比较低，不像IM的交互需要保证消息的顺序。基于以上原因，UDP更适合作为MobPush的协议选择。当然，MobPush并没有完全放弃MQTT等Qos机制。这将在业务代码中处理，而不是由网络协议补偿。MobPush在相应的设置条件下可以保证消息一次到达。MobPush也考虑了消息的安全性，会对传递的消息进行压缩和AES加密，加密后的AESKEY是动态生成的。既然是推送SDK，为什么还要对接厂商通道呢？其实这和app的keep-alive也有很大关系。目前Android的保活和互拉难度极大，但绝对重要。一般的保活方式有：使用系统Service机制，设置进程优先级，使用系统广播，使用AlarmManager，进程间相互拉起，使用Native进程等，但是现在Android对这些机制都有相应的策略，就是难以发挥比较大的作用。确实，华为、小米、魅族的系统中都有厂商自己的推送链接服务，厂商自己的推送服务肯定不会被杀掉。所以在考虑推送服务的时候，利用好厂商自己的渠道，可以很轻松的保证消息的准确到达，部分机型可以很好的唤醒APP。说到推送长连接，不得不说到另一个问题：端口老化的问题，这是IP资源有限，路由器端口数量有限导致的。本文不具体分析NAT。MobPush依靠心跳机制来维护客户端、路由器、基站、服务器之间的关系，以对抗NAT老化问题，保证UDP连接的套接字保持存活。MobPush的心跳包体只有一个字节长，可以大大节省客户端的流量，心跳时间也可以调整。3、服务整体架构整体采用微服务架构，各层之间逻辑清晰，可以很好的实现水平扩展、服务拆分和负载。控制层：主要是数据录入，主要负责数据安全加解密，流量控制；业务服务：与控制层dubbo交互，处理业务逻辑，可根据实际情况实现业务降级和压力分流；基础服务：主要包括一些数据统计和定时任务的处理：比如定时推送服务，推送中心，最重要的是支持MobPush通道的UDP服务。这些服务目前设计为分布式服务，可以很好地横向扩展；存储层：根据不同数据的重要性、实时性、量级，输入到不同的存储空间，日志按照重要数据进行归档。在系统中，根据业务规则，采用Kafka作为消息队列，实现业务解耦，缩短业务处理流程，简化复杂的处理逻辑分层、异步处理，提高业务响应时间。
