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

文档介绍：高可用的移动消息推送平台方案
消息推送作为移动 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）
iOS 在系统层面与苹果 APNs（Apple Push Notification service）服务器建立连接，应用通过观察者模式向 ioS 系统注册关注的消息，系统收到 APNs Server 消息后转发到相应的应用程序，整个过程很清晰，并且所有 APP 都共用同一个系统级的连接，减少了系统开销，虽然 APNs 能无障碍的访问，但实际使用过程中，发现延时和丢消息的情况偶有发生。
Android 平台（C2DM）
Android 的 C2DM（Android Cloud to Device Messaging）采取与 iOS 类似的机制，都是由系统层面来支持消息推送，但是由于 Google 的服务在国内不能稳定的访问，此方案对于中国用户来说基本是无法使用的。
除了 Google 官方提供的方案，中国众多的手机厂商在其定制的系统中也内置了推送功能，如小米、华为等。
应用级方案 1. 第三方推送服务
鉴于 Android 平台 C2DM 推送的不可用性，国内涌现出大量的第三方推送服务提供商，采用第三方推送服务的系统流程如下图：
图 1：消息推送流程
目前应用最为广泛的第三方推送服务提供商包括个推、极光、友盟、小米、华为、BAT 等，绝大部分 APP 都会优先考虑采用第三方推送服务。
2. 自建推送服务
第三方服务在开发成本和消息到达率上表现都不错，但所有信息会经过第三方服务器，对于信息敏感类 APP 而言，有必要考