高可用的移动消息推送平台方案

高可用的移动消息推送平台方案

消息推送作为移动APP 运营中的一项关键技术，已经被越来越广泛的运用。本文追溯了推送技术的发展历史，剖析了其核心原理，并对推送服务的关键技术进行深入剖析，围绕消息推送时产生的服务不稳定性，消息丢失、延迟，接入复杂性，统计缺失等问题，提供了一整套平台级的高可用消息推送解决方案。实践中，借助于该平台，不仅能提能显著提高消息到达率，还能提高研发效率，并道出了移动开发基础设施的平台化架构思路。推送基础

移动互联网蓬勃发展的今天，大部分手机APP 都提供了消息推送功能，如新闻客户端的热点新闻推荐，IM 工具的聊天消息提醒，电商产品促销信息，企业应用的通知和审批流程等等。推送对于提高产品活跃度、提高功能模块使用率、提升用户粘性、提升用户留存率起到了重要作用，作为APP 运营中一个关键的免费渠道，对消息推送的合理运用能有效促进目标的实现。

推送最早诞生于Email 中，用于提醒新的消息，而移动互联网时代则更多的运用在了移动客户端程序。要获取服务器的数据，通常有两种方式：第一种是客户端PULL（拉）方式，即每隔一段时间去服务器获取是否有数据；第二种是服务端PUSH（推）方式，服务器在有数据的时候主动发给客户端。

很显然，PULL 方案优点是简单但是实时性较差，我们也可以通过提高查询频率来提高实时性，但这又会造电量、流量的消耗过高，反之PUSH 方案基于TCP 长连接方式实现，消息实时性好，但是由于要保持APP 客户端和服务端的长连接心跳，也会带来额外的电量和流量消耗。因此在整体架构设计中需要折中平衡，目前主流的推送实现方式都是基于PUSH 的方案。

移动推送的三种实现方式

目前移动推送技术实现方式主要有以下三种：

轮询方式（PULL）

客户端和服务器定期的建立连接，通过消息队列等方式来查询是否有新的消息，需要控制连接和查询的频率，频率不能过慢或过快，过慢会导致部分消息更新不及时，过快会消耗更多的资源（流量、电量等），对用户体验有较大伤害。

短信推送方式（SMS PUSH）

通过短信发送推送消息，并在客户端植入短信拦截模块（主要针对Android 平台），可以实现对短信进行拦截并提取其中的内容转发给App 应用处理，这个方案借助于运营商的短消息，能够保证最好的实时性和到达率，但此方案对于成本要求较高，开发者需要为每一条SMS 支付费用。

长连接方式（PUSH）

移动Push 推送基于TCP 长连接实现，客户端主动和服务器建立TCP 长连接之后, 客户端定期向服务器发送心跳包用于保持连接, 有消息的时候, 服务器直接通过这个已经建立好的TCP 连接通知客户端。尽管长连接也会造成一定的开销，对于轮询和SMS 方案的硬伤来说，目前已经是最优的方式，而且通过良好的设计，可以将损耗降至最低。不过，随着客户端数量和消息并发量的上升，对于消息服务器的性能和稳定性要求提出了非常大的考验。因此，就难度而言，此方式代价最高。

推送解决方案

基于TCP 长连接的方式是主流的推送方式，基于该推送方式逐步发展出系统级、应用级一系列的推送解决方案。

系统级方案iOS 平台（APNs）

图1：消息推送流程

目前应用最为广泛的第三方推送服务提供商包括个推、极光、友盟、小米、华为、BAT 等，绝大部分APP 都会优先考虑采用第三方推送服务。

2. 自建推送服务

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

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

存在问题

无论是第三方推送服务，还是自建推送服务，在实际的使用过程中，发现都存在以下问题：∙应用服务端与推送服务强耦合。当推送服务不可用时，造成整个业务系统无法推送，甚无法正常工作。

∙缺乏ACK 机制。推送的过程是异步的，从应用服务端发送到推送服务时，可以得知发送是否成功，但是从第三方推送服务下发到APP 时，无法得知客户端是否接收到。iOS 平台中，从推送

服务发送到苹果APNs 服务时，同样无法确定APNs 是否收到。同时，第三方推送服务通常使用共享的推送通道，受其他推送方的影响，可能造成消息的延迟和丢失。

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

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

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

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

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

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

解决之道

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

传输层会从接入层接收消息并进行解析，对推送消息进行合法性检查校验，如果消息不合法直接丢弃，同时将合法的消息进行协议转换并发送到对应的第三方推送平台；应用层主要是提供统一的SDK 供业务使