26.app后端怎么架设推送服务

         推送服务已经是app的标配了。架设推送服务,除了可以使用第三方服务商外,也有大量的开源技术可以选择。

 

         现在推送主要分两块,android推送和ios推送,在下面分别论述:

 

1.    Android推送

 

Android手机由于没有系统的限制,当app进入了后台后,也能运行服务,所以android的推送可以基于长连接,这就注定了android的推送服务器和一般的app后端是不一样,技术细节上,架构上也不一样,幸好,现在有大量的开源软件可以轻松地实现推送。

 

下面深入研究过的开源推送软件:gopush-cluster为例,说明android推送服务的一般架构。

 

gopush-cluster,这是由猎豹移动开源的推送软件,已经被广泛应用于下面的业务:

 

微看、猎豹浏览器热剧推荐,追剧提示;

游戏的游戏活动推送;

手机助手app推荐,广告;

电池医生实时推荐、求生手册的实时消息;

PC毒霸的指令下发(web换肤,升级提示),漏洞泡泡等;

PC手机助手实时游戏、广告推荐;

PC猎豹浏览器上WEB

 

         和gopush-cluster架构师毛剑讨论技术,很感谢毛剑同学不厌其烦的解答,帮助我理清了很多gopush-cluster设计上不容易明白的地方,而且毛剑同学还是个美男架构师哦^-^

 

         下面对gopush-cluster的讲解来源于毛剑同学的博客,决定真实可靠的资料:

 

gopush-cluster的架构图:

 技术分享

 

主要分为三个模块来开发,comet/web/message。

 

(1)comet

 

主要负责消息排队、消息推送以及和客户端的连接维护;整套系统依据是消息ID顺序原则获取消息(客户端本地获取最大的消息是1,那么之后获取的消息就是大于1的,获取离线消息的时候也要从上次最大消息ID来获取),因此消息推送以后需要在comet中排队然后发起RPC给message实现存储。

 

(2)message

 

主要负责消息的存储和读写;接受来自comet模块的消息进行持久化,或者接受web模块的读取消息请求获取离线消息。message是可以部署多个节点来负载来自大量comet的推送压力,比如不同的comet使用不同的message节点(节点无状态),之后在comet也会做多message节点的负载均衡RPC调用和故障转移(TODO)。

 

(3)web

 

主要负责节点询问,以及离线消息获取和后台节点管理等;节点询问主要依据客户端的订阅Key一致性hash计算出连接的comet节点地址,因此海量客户端连接的时候可以打散到多个comet来服务;另外离线消息也是通过web接口返回给客户端的,但是消息的读取是通过RPC发送给message模块的,尽量的职责单一。web节点因为无状态,可以部署多个web,来实现负载均衡和故障转移。

 

(4)thrid-part

消息存储现在主要依赖Redis进行消息读写(SortedSet),因为Sorted Set不支持int64类型的Score(我们也开发了一个支持int64 Score的分支但是因为时间原因没有大量测试上线),之后可能会使用HBase集群代替Redis的使用,已提供更安全的离线消息存储(TODO)。

 

另外使用了Zookeeper来实现的同一个comet的故障转移,例如comet节点1可以有一个备选节点节点2,当节点1注册到zookeeper之后,因为机器或者其他原因宕了,这时候会在web层触发zookeeper的选举选中节点2来服务。

 

2.    ios推送

 

APNS 是Apple PushNotification Service(Apple Push服务器),由于ios系统的限制,大部分应用是不允许在后台运行并连接网络的。在应用没有被运行的时候,只能通过 Apple Push Notification Service (APNs) 把消息送到app。

 

         Apns的推送原理如下图:

技术分享

 

推送的过程经过如下步骤:

 

1.      首先,安装了具有推送功能的应用,我们的设备在有网络的情况下会连接苹果推送服务器,连接过程中,APNS会验证device_token,连接成功后维持一个长连接。

2.      Provider(我们自己的服务器)收到需要被推送的消息并结合被推送设备的device_token一起打包发送给APNS服务器。

3.      APNS服务器将推送信息推送给指定device_token的设备。

4.      设备收到推送消息后通知我们的应用程序并显示和提示用户(声音、弹出框)。

 

在接入apns服务过程中,有两个问题需要注意:

 

1.      服务端连接到apns服务器的连接,空闲了一段时间后,apns服务器会自动断开这个连接,这时服务器就需要做重连操作。

2.      发送了无效device_token后的处理 。

 

        为啥会有无效的device_token呢?当用户卸载了app后,用户的device_token就失效了,这个失效的device_token已经被保存在数据库中。当向apns服务器推送消息时,如果推送了这个无效的token,就会error-response。

 

         如果有error-response,那么这条之后的通知都需要重发。隔一段时间后,这个连接会断开,但是,在断开前的时间,发送的device_token都会失效。所以我们考虑重发的问题。error-response中返回的通知ID,可以帮助我们找出哪条出错了,这样就能知道哪些需要重发了.

 

          另外,APNS的feedbackservice会返回那些已经卸载的设备的device_token。在数据库中删除这些device_token,下次就不用再给他们发了,可以节省点资源。

 

在网络上找到解决了上面两个apns推送问题的开源软件:

1.      java方面:dbay-apns-for-java

2.      python方面:apns-client

 

3.    结语


         对于创业公司来说,我一直推崇的架构原则是“尽量使用成熟的第三方服务和软件,自己只负责业务逻辑”。

 

         如果没达到百万级的规模,实在没必要架设自己的推送服务器。而且,现在所有的推送软件,都缺一个良好的管理后台。例如,我想知道某个用户为啥没收到推送,是因为推送不发送,还是发送了用户没收到啊?只能在海量的日志中寻找答案,每次遇到这种问题,都是一个杯具。

 

--------------------------------------------------------------------------------------------------------------------------

打开链接  app后端系列文章总目录 总目录 ,能查看本人发表过的所有原创“app后端”文章。

【作者】曾健生
【QQ】190678908
【app后端qq群】254659220 
【微信公众号】 appbackend
【新浪微博】 @newjueqi
【博客】http://blog.csdn.net/newjueqi 


如果您觉得文章对你有所帮助,欢迎打赏。


微信打赏:

技术分享


支付宝打赏:

技术分享




郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。