第三方服务在开发成本和消息到达率上表现都不错，但所有信息会经过第三方服务器，对于信息敏感类 APP 而言，有必要考虑自建一套消息推送服务，能最大化保证安全，但对于自建推送服务，如果从零开始来做需要解决几个难点：

　　第一，移动推送服务器对 App 客户端海量长连接的维护管理。第二，App 客户端如何保证 Push Service 常驻，对于 Android 我们可以通过发现 push service 不存在可以定时拉起的方式。第三，通信协议的制定，我们可以采用开源的 XMPP 方式实现，也可以自定义协议，不管哪种方式我们都要保证消息传送的到达率的准确性。第四，在移动互联网网络环境下，经常出现弱网环境，特别是 2G、3G 等网络不稳定的情况下，如果保证消息在弱网环境下不重、不丢也是一个挑战。

　　存在问题

　　无论是第三方推送服务，还是自建推送服务，在实际的使用过程中，发现都存在以下问题：

　　应用服务端与推送服务强耦合。当推送服务不可用时，造成整个业务系统无法推送，甚无法正常工作。

　　缺乏 ACK 机制。推送的过程是异步的，从应用服务端发送到推送服务时，可以得知发送是否成功，但是从第三方推送服务下发到 APP 时，无法得知客户端是否接收到。iOS 平台中，从推送服务发送到苹果 APNs 服务时，同样无法确定 APNs 是否收到。同时，第三方推送服务通常使用共享的推送通道，受其他推送方的影响，可能造成消息的延迟和丢失。

　　服务会被杀死。尤其在 Android 平台上，后台推送 service 会被各种主动或者被动原因 kill 掉，导致消息丢失。

　　缺乏消息的持久化。对于推送服务而言，消息推送是来一条推一条，无法追溯历史消息和消息状态。

　　缺乏重传机制。整个推送过程涉及多个环节，当其中某个环节出现问题，造成客户端接收不到推送的消息时，就导致消息丢失，再无法接收到。

　　客户端接入逻辑复杂。每接入一个新的 APP，都要进行重复的接入工作，接入逻辑完全一致，代码无法复用，需要在不同项目中拷贝。

　　客户端与推送服务的 SDK 强耦合。客户端使用推送服务的接口，而各推送服务提供的接口不统一，如果需要替换推送服务，那么接入部分代码需完全重写。

　　缺乏数据监控和统计。每个应用每天推送了多少消息，成功到达 app 多少，失败多少，目前均没有统计。

　　解决之道

　　为了解决以上问题，我们考虑基于第三方消息推送服务构建一套移动消息推送中间件平台，该消息平台采用了低耦合的分层架构设计（如图 2 所示），分为三层：接入层、传输层和应用层。其中接入层是业务方调用的入口，我们采用异步消息队列的方式提供了较高的业务系统发送消息的速度，并且具备了消息缓冲功能，即使高峰期的海量消息推送对整个平台冲击较少，保护了推送系统；

　　传输层会从接入层接收消息并进行解析，对推送消息进行合法性检查校验，如果消息不合法直接丢弃，同时将合法的消息进行协议转换并发送到对应的第三方推送平台；应用层主要是提供统一的 SDK 供业务使用，封装适配第三方推送平台的 SDK 接口到统一的接口 SDK 中，这样业务 APP 使用方只关注统一封装的 SDK 即可实现业务消息的操作，而不需要考虑各种滤重、校验等通用操作。主要功能包括：

屏蔽推送接口，实现业务与推送服务解耦，提供一套通用的客户端 SDK，简化客户端接入。

实现多点接入，可同时接入多套推送服务，根据历史推送成功率动态选择最优推送路径，当一条路径失效可选择备用路径进行推送，保证消息推送万无一失。

引入消息持久化机制，方便追溯和统计。

引入消息的 ACK 机制和重传机制，提高消息的到达率。

实现数据监控和统计机制，提供相关数据的统计分析，和报警预警功能。

提供 web 管理后台，便于进行 APP 设置、推送设置、查看数据报表，提高系统维护的工作效率。

　　整个系统设计由三部分组成：移动推送平台、客户端 SDK、应用管理界面（第三方推送服务和自建推送服务统称为推送服务）。

　　图 2：系统架构