推送服务已经是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后端”文章。

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

微信打赏：

支付宝打赏：