本文详细讲述58同城高性能移动Push推送平台架构演进的三个阶段，并介绍了什么是移动Push推送，为什么需要，原理和方案对比；移动Push推送第一阶段（单平台）架构如何设计；移动Push推送典型性能问题分析解决，以及高可用、高性能、高稳定性如何保证。
什么是移动Push推送
移动Push推送是移动互联网最基础的需求之一，用于满足移动互联环境下消息到达App客户端。以转转（58赶集旗下真实个人的闲置交易平台）为例，当买家下单后，我们通过移动Push推送消息告诉卖家，当卖家已经发货时，我们通过移动Push消息告诉买家，让买卖双方及时掌握二手商品交易的实时订单动态。
为什么需要移动Push推送？
移动互联网络环境下，经常会出现弱网环境，特别是2G、3G等网络环境下，网络不够稳定，App客户端和相应服务器端的长连接已经断开，消息无法触达App客户端。而我们业务需要把Message（转转App交易消息等）、Operation（转转App运营活动等）、Alert（转转红包未消费提醒等）等消息推送给App客户端，从而触发用户看到这些消息，通过点击这些Push消息达到相应目标。
推送原理和方案对比
移动Push推送主要有以下三种实现方式。
-
移动App轮询方式（PULL）
App客户端定期发起Push消息查询请求，来达到消息推送的目的。PULL方案的优点和缺点都比较明显，整体架构简单但实时性较差，我们可以通过加快查询频率，提高实时性，但这会造成电量、流量消耗过高。
-
移动App基于短信推送方式（SMS Push）
通过短信发送推送消息，并在客户端置入短信拦截模块，能拦截短信，并解析后转发给App应用处理。这个方案实时性好、到达率高，但成本很高。
-
移动App长连接方式（Push）
移动Push推送基于TCP长连接实现，消息实时性好，这是目前主流的实现方式，需要维护App客户端和服务端的长连接心跳，会带来额外的电量、流量消耗；在架构设计时，需要做些折中，以避免流量和电量的大量消耗。此外Push推送技术架构复杂度较高，维护移动App客户端的海量长连接请求，并建立与App客户端通信的加密通道，整合成内部少量有限的长连接，对通信数据进行压缩与解压，以节省流量。
目前移动Push推送技术基本都是结合这3个方案进行，但对于不同的移动终端平台，又有各自不同的实现，这里详细介绍iOS和Android平台上的具体实现方案。
iOS平台
对于iOS平台，由于其特殊性，移动Push推送相对简单，iOS应用是不允许service后台常驻的，所以你没有别的选择，也没办法通过开发自己的Push service来完成推送下发，只能通过苹果APNS方式来完成。iOS移动Push推送流程如图1所示。
图1 iOS移动PUSH推送流程
Android平台
在Android平台上，由于对service常驻没有限制，可用的方案就多一些：可以通过Google官方C2DM 完成、开源方案（例如XMPP）、借助第三方，或者完全自主研发的移动Push推送方案。
Google C2DM的主要流程如图2所示。
图2 C2DM移动PUSH推送流程
Google C2DM和Apple APNS流程大致类似，但其最大的问题是移动Push推送服务器在国外，很容易被屏蔽，而且Push推送延迟较大。此外由于 Android社区分裂比较严重，很多厂商直接就把C2DM模块给去掉了，所以在国内这个方案极不可靠，变成了一个理论上的方案。
移动Push推送开源方案
对于开源移动Push推送协议，常见的有XMPP等, 事实上Google的C2DM底层也是基于XMPP协议实现的，我们通过线下测试发现，开源移动Push推送方案主要有两个问题：第一，没有ACK机制，消息到达没有保证，不可靠；第二，当移动Push消息请求量并发增大时，系统开始变得不稳定，甚至出现了模块宕机的情况。因此直接使用移动Push推送开源方案，也不是非常可靠，我个人建议：在大规模使用开源的移动Push推送方案之前，必须做到对开源技术方案整体把握住，不然一旦出现问题，无法及时定位和修复的话，带来的后果将会是灾难性的。
借助第三方移动Push推送方案
除此之外，目前移动Push推送市场上，还有不少第三方推送产品可供选择，但需要面临以下几个问题：
-
到达率
虽然第三方移动Push推送产品都宣传到达率高于90%，但是实际使用起来，发现远远达不到。当然到达率低的问题，除了第三方移动Push推送平台本身技术原因外，还和业务推送方的用户选取有很大关系，如果用户较活跃，到达率就会高些，如果用户不活跃，或者用户已经卸载了相应的App客户端，必然造成到达率进一步降低。
-
实时性&控制度
第三方移动Push推送产品的推送通道是共用的，会面向多个推送客户，如果某一个客户Push推送量特别大，那么其他的消息实时性可能就会受到影响，这些都是业务推送方不可控的，会比较被动。
完全自主研发的移动Push推送方案
我们曾经考虑实现一套完全自主的移动Push推送平台，如果从零开始来做，需要解决几个难点：第一，移动Push推送服务端对移动App客户端海量长连接的维护管理。第二，App客户端常驻 service稳定性，如何使Push service常驻？我们可以借助父子进程互相监控的方式来做到，一旦发现对方进程不在了，会重新建立，继续循环监控。第三，手机内存不足时，系统会杀掉Push service，甚至有些操作系统比较强势，它会向iOS系统一样并不允许第三方Push service 常驻。第四，移动Push推送到达率的提高，除了技术手段外，还有一些PR的手段，比如移动App客户端Push service通过在相应操作系统上添加白名单的方式使其永久常驻。总之，在移动互联复杂的场景下如何让移动Push推送到达率变得更高，不是一件简单的事儿。
58同城移动Push推送方案
我们综合考虑前面讲述的开源、基于第三方、完全自主研发方案，58同城并没有选择从零开始完全自主研发而是采用了基于第三方移动Push推送平台和自主研发高性能Provider的方案（如图3所示），满足每天百亿量级的吞吐量，并通过动态组合和扩展的方式，结合离线的移动Push推送数据分析，不同手机使用不同的推送策略，针对性地优化。在Android平台，我们融合多种第三方移动Push平台，从而有效提升到达率。
图3 58同城移动PUSH推送平台技术架构
第一阶段（单平台）：架构如何设计
背景&需求
2011年我们研发了58帮帮，这是一款满足58用户和商户之间沟通的即时通讯软件，用户间可以互相添加好友、收发消息等。58帮帮的消息推送基于App客户端和服务器的长连接，一旦这条长连接断开，那么IM服务端的消息将无法推送给App客户端，用户也无法看到这些消息。在iOS平台上，58帮帮App切换到后台后，App与IM的长连接断开，消息无法触达，这时候我们需要借助iOS APNS机制，IM消息需要发送给APNS，APNS再转发对应的消息到58帮帮App。Android切换至后台，App与IM的长连接保持，IM消息可以正常推送，因此在这个阶段我们需要解决的问题是在iOS平台上