MobPush推送实现解析
从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作为消息队列将业务解耦,缩短业务处理流程,将复杂的处理逻辑分层简化,异步处理,提升业务响应时间。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
SpringBoot分布式 - SpringCloud
一:介绍 Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中涉及的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。 微服务(Microservices Architecture)是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。 Spring Cloud 中文文档 https://springcloud.cc/spring-cloud-dalston.html Spring Cloud 官方文档 http://projects.spring.io/spring-cloud/#quick-start SpringCloud 教程PDF下载:https://download.csdn.net/download/yueshutong123/10501017 二:入门 在IDEA新建空白工程 1....
- 下一篇
低延迟音视频传输技术在直播领域的应用
本文来自陌陌视频流媒体技术负责人吴涛在WebRTCon 2018上的分享,他详解了陌陌从传统直播过渡到1对1到多人互动模式的演进,架构的优化保证了用户体验与业务需求。另外,文末为WebRTCon 2018最后一波PPT分享,点击阅读原文下载。 文 / 吴涛 整理 / LiveVideoStack 概览 我有幸曾在互联网、安防监控、广电音视频传输三大领域从事工作,感觉自己现在的水平应该仅够满足实战需求了,所以今天在这里不敢说为大家做分享,只能说为大家汇报一些自己在这三个领域工作的心得体会。 互联网直播的话题已经是老生常谈了,我们也很难再讲出来一些新的东西。我最早来到陌陌的时候,陌陌做音视频传输技术的只有四个人,一个做客户端,一个做支付,一个做后台,剩下一个由我来做音视频。可以说我见证了陌陌直播从襁褓之中成长为现在这样一个成熟直播平台的全过程。2017年Q4财报显示,陌陌现在月活跃用户数9910万人,收入是3.58亿美元,而陌陌视频收入约3.2亿美元,也就是说陌陌90%多的收入都是视频提供的,这是现在陌陌直播平台的发展情况。 今天我向大家分享的主要内容有: 基于CDN架构的直播应用 基于C...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Red5直播服务器,属于Java语言的直播服务器
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8安装Docker,最新的服务器搭配容器使用