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

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

1.    Android推送

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

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

gopush-cluster，这是由猎豹移动开源的推送软件，已被广泛利用于下面的业务：

微看、猎豹阅读器热剧推荐，追剧提示；

游戏的游戏活动推送；

手机助手app推荐，广告；

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

PC毒霸的指令下发（web换肤，升级提示），漏洞泡泡等；

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

PC猎豹阅读器上WEB

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

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

gopush-cluster的架构图：

主要分为3个模块来开发，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

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

（4）thrid-part

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

另外使用了Zookeeper来实现的同1个comet的故障转移，例如comet节点1可以有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，连接成功后保持1个长连接。

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

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

4.      装备收到推送消息后通知我们的利用程序并显示和提示用户（声音、弹出框）。

在接入apns服务进程中，有两个问题需要注意：

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

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

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

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

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

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

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

2.      python方面：apns-client

3.    结语

         对创业公司来讲，我1直推重的架构原则是“尽可能使用成熟的第3方服务和软件，自己只负责业务逻辑”。

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

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

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

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

微信打赏：

支付宝打赏：