58同城高性能移动端消息推送技术架构演进之路

前言

58同城作为中国最大的生活服务平台，涵盖了房产、招聘、二手、二手车、黄页等核心业务。随着移动化时代的到来，每个业务线都有移动端消息推送的需求，满足多个业务线海量的消息PUSH推送需求，成为我们急需优先解决的关键问题之一。58同城高性能移动端消息推送平台经过不断演化，目前能够满足58同城所有业务线的移动端消息推送需求，每秒中能够达到10万QPS的吞吐量，每天的吞吐量为百亿量级。众多的移动业务线已经接入进来：58同城、转转、58帮帮、58速聘、58违章、58二手车等等。

本文详细讲述58同城高性能移动端消息推送平台架构演进的三个阶段：

• 第一阶段（单平台）：架构如何设计?
• 第二阶段（多平台）：架构如何设计优化?
• 第三阶段（公司级统一高性能）：架构和协议如何设计和优化?移动端消息推送典型性能问题分析解决以及高可用、高性能、高稳定性我们如何保证?
  

什么是移动端消息推送?

移动端消息推送是移动互联网最基础的需求之一，用于满足移动互联环境下消息到达Apps客户端。以转转（58赶集旗下真实个人的闲置交易平台）为例，当买家下单后，我们通过移动端消息推送消息告诉卖家，当卖家已经发货时，我们通过移动端消息推送告诉买家，让买卖双方及时掌握二手商品交易的实时订单动态。

转转订单移动端消息推送消息如下图：

为什么需要移动端消息推送？

移动互联网络环境下，经常会出现弱网环境，特别是2G、3G等网络环境下，弱网环境下网络不够稳定，Apps客户端和相应服务器端的长连接已经断开，消息无法触达到Apps客户端。而我们业务需要把Message（转转Apps交易消息等）、Operation（转转Apps运营活动等）、Alert（转转红包未消费提醒等）等消息推送给Apps客户端，从而触发用户看到这些消息，通过点击这些PUSH消息达到相应目标。

移动端消息推送原理和方案对比

1移动端消息推送主要有三种实现方式

• 移动Apps轮询方式（PULL）：
  Apps客户端定期发起PUSH消息查询请求，来达到消息推送的目的。PULL方案的优点和缺点都比较明显，整体架构简单但实时性较差，我们可以通过加快查询频率，提高实时性，但这会造成电量、流量消耗过高。
• 移动Apps基于短信推送方式(SMS PUSH)：
  通过短信发送推送消息，并在客户端置入短信拦截模块，将接收到的短信拦截，并解析后转发给Apps应用处理。这个方案实时性好、到达率高，但成本很高。
• 移动Apps长连接方式(PUSH)：
  移动端消息推送基于TCP长连接实现，消息实时性好，这是目前主流的实现方式，需要维护Apps客户端和服务端的长连接心跳，会带来额外的电量、流量消耗，在架构设计时，需要做些折中，以避免流量和电量的大量消耗。此外PUSH推送技术架构复杂度较高，维护移动Apps客户端的海量长连接请求，并建立与Apps客户端通信的加密通道，整合成内部少量有限的长连接，对通信数据进行压缩与解压，以节省流量。
  

目前移动端消息推送技术基本都是结合这 3 个方案进行。

2移动端消息推送开源方案

对于开源移动端消息推送协议，常见的有XMPP等, 事实上谷歌的 C2DM 底层也是基于 XMPP协议实现的。

我们通过线下测试发现，开源移动端消息推送方案主要有两个问题：

• 第一、没有ACK 机制，移动端消息消息到达性不保证，因此消息到达不可靠；
• 第二、当移动端消息消息请求量并发增大时，系统开始变的不稳定，甚至出现了模块宕机的情况。
  

因此直接使用移动端消息推送开源方案，也不是非常可靠，我个人建议：在大规模使用开源的移动端消息推送方案之前，需要能够做到对开源技术方案整体的HOLD住，不然一旦出现问题，无法及时定位和修复的话，带来的后果将可能是灾难性的。

3借助第三方移动端消息推送方案

除此之外，目前移动端消息推送市场上，还有不少第三方移动端消息推送产品供选择，使用第三方移动端消息产品需要面临以下几个问题：

• 第一、到达率：
  虽然第三方移动端消息推送产品都宣传到达率能够达到 90%及以上，但是实际使用起来，发现远远达不到。当然到达率低的问题，除了第三方移动端消息推送平台本身技术原因外，还和业务推送方推送用户选取有很大关系，如果选取的推送用户较活跃，那么移动端消息推送达到率就会高些，如果选取的用户不活跃，可能这些用户已经卸载了相应的Apps客户端，必然造成移动端消息推送到达率进一步降低。
• 第二、实时性&控制度：
  第三方移动端消息推送产品的推送通道是共用的，会面向多个推送客户，如果某一个客户PUSH推送量特别大，那么其他的移动端消息推送消息实时性可能就会受到影响，这些都是业务推送方不可控的，会比较被动。
  

4完全自主研发的移动端消息推送方案

我们曾经考虑实现一套完全自主的移动端消息推送平台。

如果从零开始来做，需要解决几个难点：

• 第一、移动端消息推送服务端对移动Apps客户端海量长连接的维护管理；
• 第二、Apps客户端常驻service 稳定性，如何使push service常驻？我们可以借助父子进程互相监控的方式来做到，一旦发现对方进程不在了，会重新建立对方进程，继续循环监控；
• 第三、手机在内存不足的时候，系统会杀掉push service，甚至有些操作系统比较强势，它会向iOS系统一样并不允许第三方push service 常驻；
• 第四、移动端消息推送到达率的提高，除了技术手段外，还有一些PR的手段，比如移动Apps客户端pushservice通过在相应操作系统上添加白名单的方式使其永久常驻。
  

总之，在移动互联复杂的场景下如何让移动端消息推送到达率变的更高，不是一件简单的事儿。

558同城移动端消息推送方案

我们综合考虑前面讲述的开源方案、基于第三方方案、完全自主研发方案，58同城的移动端消息推送方案并没有选择从零开始完全自主研发的方案，我们最终采用了基于第三方移动端消息推送平台和自主研发高性能Provider的方案[图4]，满足每天百亿量级的吞吐量，并通过动态组合和扩展的方式，结合离线的移动端消息推送数据分析，不同手机使用不同的推送策略，针对性的优化，在Android平台方法，我们融合多种第三方移动端消息平台，从而有效提升到达率。

58同城移动端消息推送平台技术架构如下图：

移动端消息推送第一阶段（单平台）：架构如何设计?

1背景&需求

2011年我们研发了58帮帮，58帮帮是一款满足58用户和58商户之间沟通的即时通讯软件，用户间可以互相添加好友、收发消息等。58帮帮帮的消息推送是基于Apps客户端和服务器的长连接，一旦这条长连接断开，那么IM服务端的消息将无法推送给Apps客户端，用户也无法看到这些消息。在iOS平台上，由于iOS平台的特殊性，58帮帮Apps切换到后台后，Apps与IM的长连接断开，消息无法触达，这时候我们需要借助iOS APNS机制，IM消息需要发送给APNS，APNS再转发对应的消息到58帮帮Apps。Android切换至后台，Apps与IM的长连接保持，IM消息可以正常推送，因此在这个阶段我们需要解决的问题是在iOS平台上，当58帮帮Apps切后台后，IM在长连接断开后的消息触达需求。

2设计目标

基于上述的背景和需求，我们在设计移动端消息推送第一阶段（单平台）架构时，首先要满足在iOS平台上，当IM长连接断开后，IM消息的能够触达到Apps客户端。其次我们的移动端消息推送协议设计也具备很好的扩展性，在可以预见的未来，我们的移动端消息推送平台逐步接入更多的Apps，因此我们设计目标是iOSProvider是一个通用的iOS推送服务。不同Apps通过使用不同的移动端消息推送证书借助同一的iOSProvider完成移动端消息消息推送，对于不同Apps的接入，我们采用了配置文件方式动态扩展接入，iOSProvider根据所配置Apps证书与APNS建立并维护多条TSL连接。

配置文件的格式如下：

第一个域#第二个域#第三个域#第四个域

其中，第一个域为推送服务类型Type，以备扩展，1为APNS；第二个域为内部定义的APPID号，对应服务的Apps；第三个域为Apps的Apple证书文件名；第四个域为与APNS建立的连接数。

每个Apps接入的配置为一行，举例如下：

1#88#zhuanzhuan.p12#64
1#66#58tongcheng.p12#32

除此之外，iOSProvider[图5]需要对每个接入Apps的APNS连接池进行管理，动态增删TSL连接，具备动态重连机制，并具有单独的反馈接收线程，用于异步的接收APNS返回无效的Token，反馈给移动端消息推送业务方，用于下次移动端消息消息推送的优化。iOSProdiver根据Type、APPID选择对应的APNS连接，通过推送线程组装APNS包发送到APNS服务器。

iOSProvider架构图：

移动端消息推送第二阶段（多平台）：架构如何设计优化?

随着移动互联时代的到来，58同城研发了多个Apps：58帮帮、58同城等等，每一个Apps都有移动端消息消息推送的需求（消息、运营活动、过期提醒等），并且每一款Apps同时具有多个终端：Android版本、iOS版本等。在这样的需求背景下，我们的移动端消息推送平台需要继续演进，如何演进呢？

iOS移动端消息推送通道可以很好的满足业务推送的需求，目前还不具备Android移动端消息推送的能力，因此我们急需要研发Android移动端消息推送通道。如何做？综合目前可选择的Android移动端消息推送方案，我们选择了基于第三方推送平台以及自主研发高性能AndroidProvider的方案。

首先重点讲述针对Android移动端消息推送的流程（见下图）：

• 第一、Apps客户端向第三方移动端消息推送平台注册，获取对应的Apps唯一标示(Token)；
• 第二、Apps把从第三方移动端消息推送平台注册获取的Token信息发送给AndroidProvider并集中存储，以便后续基于Token的移动端消息推送；
• 第三、AndroidProvider通过HTTPS或者TSL的方式和第三方移动端消息推送平台建立连接，并把需要推送的消息发送到第三方移动端消息推送平台；
• 第四、第三方移动端消息推送平台收到AndroidProver推送的消息后，会把此消息及时的推送到Apps，从而完成整个移动端消息消息的推送过程。
  

Android移动端消息推送流程：


AndroidProvider子系统整体结构分为四个层次（见下图）：

• 第一层为业务方移动端消息推送接入，用于众多移动端消息推送业务方的接入层；
• 第二层为网络交互层，用于接收移动端消息推送业务方的消息数据以及发送请求处理层的处理数据给业务推动调用层；
• 第三层为请求处理层，用于处理网络交互层放入请求队列的数据，组装成第三方移动端消息推送接口需要的数据，通过HTTP或者HTTPS的方式调用下游的接口，并等待请求结果的返回，把请求返回的结果放入回应队列；
• 第四层为第三方移动端消息推送平台，由第三方提供，开放给使用方接口，供调用其功能。
  

AndroidProiver系统架构图：


随着越来越多的移动Apps接入，移动端消息推送需求变的越来越多样化，同时移动端消息推送业务逻辑复杂化（多终端、批量发送、业务规则多样），公共策略每个业务方重复开发（深夜防打扰功能、发送频率和发送速率的限制等），造成开发效率低下。为了解决这些问题，我们抽象了公共的逻辑（见下图），并进行了统一的封装，对业务调用方透明，这些公共的逻辑包括：通用的策略和通用的控制。

Android移动端消息推送演进业务架构：


在移动移动端消息推送第二阶段（多平台）阶段，我们具备了Android、iOS的通道服务能力，满足满足移动端消息推送消息的需求。但是我们没有提供统一的发送接口，业务方需要各自组包（Android、iOS）发送不同的移动端消息推送通道，除此之外，移动端消息推送通道性能方面还有待提升，移动端消息推送通道稳定性方面还有待提升，移动端消息推送通道包含了相对共同的业务逻辑，移动端消息推送通道还不够“纯粹”。

移动端消息推送第三阶段：架构和协议如何设计和优化？

移动端消息推送第二阶段还存在一系列的问题，因此在移动端消息推送第三阶段我们需要解决这些问题，并且随着更多Apps接入进来，我们需要提供公司级统一的高性能移动端消息推送平台。基于第三方移动端消息推送平台，我们自主研发了满足每天推送百亿量级的高性能Provider，移动端消息推送平台具备了高稳定性、接入方便，并提供了较高的推送到达率。

移动端消息推送平台第三阶段我们如何架构和设计？首先我们满足对下游接入方多种连接的管理（HTTP、HTTPS、TCP、SSL、TSL）。具备了多种连接动态伸缩性，从而满足Provider层对移动端消息推送连接的要求；其次我们平台要具备高并发的特性，通过完全异步的设计和多线程的支持，做到了高并发和支持10万QPS的吞吐量；再次我们需要对接入下游的错误进行处理，一旦发现连接被断开等错误后，要能够自动使用新的连接，并且对已经发出还没到达Apps客户端的推送消息进行重发，以保证推送消息的不丢失；第四我们需要对通道进行封装，对外提供统一的友好接入接口，屏蔽底层iOS和Android接入的差异性；最后在Android移动推送方面，我们接入了更多的第三方推送平台，以达到更高的到达率。

基于这些方面的考虑，58同城移动端消息推送平台采用了低耦合的分层架构设计，分为三层push entry、push transfer、provider(iOSProvider和AndroidProvider)。其中push entry是业务方调用的入口，我们采用异步消息队列的方式，提供了较高的业务方发送的速度，并且具备了消息缓冲的功能，使得高峰期的海量移动端消息消息推送对整个平台冲击较少，也起到了保护移动端消息推送系统的作用；push transfer会从push entry层接收消息进行解析，对移动端消息推送消息进行合法性检查，如果消息格式不合法，直接丢弃，同时会进行接收到的推送消息格式转换成内部的消息格式，分平台转发到iOSProvider或者AndroidProvider上；provider接收到push transfer的消息后，会按照下游需要的消息格式（APNS协议、Android协议）进行转换，进行消息的下发，在下发的过程中，会进行消息的重发，以确保消息下发到第三方推送平台。

provider模块内部我们如何设计？以iOSProvider为例，讲述下我们的设计，iOSProvier分为三个层次（见下图）：接入逻辑、业务逻辑、APNS出口。其中接入逻辑主要处理网络交互和请求分发；业务逻辑主要处理线程分裂扩展、并发处理和错误处理；APNS出口处理向APNS的发送逻辑。

iOSProvider模块结构图：


对于移动端消息推送平台来说，追求达到率是我们最核心的指标，没有之一。因此在Android移动端消息推送方面，我们融合了多个第三方移动推送平台，通过机型控制，对不同的机型使用不同PUSH通道，进一步提升推送到达率。AndroidProvider层进行消息推送策略的控制，先推送一通道，根据此推送通道ACK情况，是否继续推送其他通道。推送多个PUSH通道，会出现推送消息重复到达Apps客户端的情形，此时需要Apps客户端根据推送消息的ID进行去重，收到的重复推送消息忽略处理。

移动端消息推送典型性能问题分析解决以及高可用、高性能、高稳定性我们如何保证?

在移动端消息推送不断演进的过程中，我们遇到AndroidProvider并发低，仔细分析是因为我们采用HTTPS库，由于库中HTTPS的连接实现不是线程安全的，对每个HTTPS的请求都加锁串行化处理，从而保证了线程的安全性。发现问题后，我们通过在线上增加多进程部署的方式暂时解决，使得我们有足够的时间分析此问题产生的根本原因。经过我们深入的分析，发现是我们对HTTPS的库掌握不够，导致我们加锁的粒度过大，通过HTTPS库提供的更小粒度的锁（见下图），我们不仅解决了线程不安全的问题，也提升了AndroidProvider的并发度。

HTTPS库细粒度锁实现方式：

结语

总之，58同城统一的高性能移动端消息推送平台，我们通过无状态化设计和冗余部署等方式提供了推送平台的高可用，通过纯异步、动态多线程的支持提供推送平台的高性能，通过质量保证、多种监控机制（进程监控、语义监控、错误日志监控、数据波动监控等），有问题及时发现处理保证了推送平台的高稳定性。

最后，我要感谢项目组的同学，特别感谢姚劲同学，有了你们持续不断的努力和付出，才有了今天这篇文章；也感谢老婆大人，有你在背后默默的支持，才有了今天这篇文章。

（原文链接：点此进入）

附录：更多消息推送技术的文章

《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《IBM技术经理访谈：MQTT协议的制定历程、发展现状等》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
《极光推送系统大规模高并发架构的技术实践分享》
《从HTTP到MQTT：一个基于位置服务的APP数据通信实践概述》
《魅族2500万长连接的实时消息推送架构的技术实践分享》
《专访魅族架构师：海量长连接的实时消息推送系统的心得体会》
《深入的聊聊Android消息推送这件小事》
《基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)》
《一个基于长连接的安全可扩展的订阅/推送服务实现思路》
《实践分享：如何构建一套高可用的移动端消息推送系统？》
《Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《百万在线的美拍直播弹幕系统的实时推送技术实践之路》
《京东京麦商家开放平台的消息推送架构演进之路》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《基于APNs最新HTTP/2接口实现iOS的高性能消息推送(服务端篇)》
>> 更多同类文章 ……

攒点金币。