消息推送技术干货：美团实时消息推送服务的技术演进之路

JackJiang · 2 年前

本文由美团技术团队分享，作者“健午、佳猛、陆凯、冯江”，原题“美团终端消息投递服务Pike的演进之路”，即时通讯网收录时有修订。

1、引言

传统意义上来说，实时消息推送通常都是IM即时通讯这类应用的技术范畴，随着移动端互联网的普及，人人拥有手机、随时都是“在线”已属常态，于是消息的实时触达能力获得了广泛的需求，已经不再局限于IM即时通讯这类应用中。

对于美团这种移动端“入口”级应用来说，实时消息的推送能力已经深入整个APP的方方面面。目前美团应用中使用的推送技术，是一个被命名为Pike的一套易接入、高可靠、高性能的双向消息实时投递服务。

本文将首先从Pike的系统架构升级、工作模式升级、长稳保活机制升级等方面介绍2.0版本的技术演进，随后介绍其在直播、游戏等新业务场景下的技术特性支持，并对整个系统升级过程中的技术实践进行了总结，希望本文能给消息实时推送服务感兴趣或从事相关工作的读者以帮助和启发。

本文已同步发布于“即时通讯技术圈”公众号，欢迎关注。公众号上的链接是：点此进入。

2、相关文章

实时消息推送技术文章参考：

美团技术团队分享的其它文章：

3、v1.0的前世今生

3.1v1.0 的诞生背景

2015年，美团诞生了Shark终端网络通道，为公司移动端提供长连代理加速服务。Shark通过网络接入点的全球多地部署和保持长连来提升网络请求的端到端成功率，降低端到端延时，从而提升用户体验。

Pike 1.0是基于Shark长连通道实现的应用内推送服务。由于底层传输基于Shark长连通道，使得Pike 1.0天生便具有了低延时、高可靠、防DNS劫持等优秀基因。目前Pike 1.0在美团内部的即时通讯聊天、营销推送、状态下发、配置同步等业务场景都有广泛使用。

3.2v1.0 的工作流程

Pike 1.0 移动端SDK会在每次长连接创建成功后：

1）使用APPID、设备唯一标识UnionID（美团唯一标识、点评唯一标识等）向服务器发起注册；
2）在注册成功之后业务服务端就可以通过Pike 1.0服务端SDK提供的接口，主动向设备的App推送消息；
3）服务端推送的消息通过长连接通道抵达客户端，最后通过注册的回调接口投递给业务方。

整体工作流程参见下图：

3.3v1.0的优势

Pike 1.0底层传输基于Shark长连通道。

所以Pike 1.0在以下几个方面有不错的表现：

1）防劫持：底层通道直接使用IP直连，省去DNS解析耗时的同时也避免了被DNS劫持的风险；
2）低延时：Shark长连接采用就近接入点长连接的方式，省去了传统HTTP需要多次建连、握手的消耗，端到端数据传输延时相比HTTP大幅缩短；
3）安全高：Shark采用自定义二进制协议进行数据传输，进行了通道级别的TLS加密，防篡改，更安全；
4）体验好：Pike 1.0与Shark共享服务集群，Shark长连通道在海外多地都部署了接入点，代理加速接入，网络延时及成功率表现要优于常规请求。

PS：移动网络下HTTP、DNS的优化文章，可以看看下面这几篇：

3.4v1.0的技术痛点

Pike 1.0作为Shark的衍生产品固然有其闪光的地方，但是对Shark的强依赖所带来的痛点更是让开发人员叫苦不迭，主要痛点如下。

3.4.1）代码结构耦合：

在客户端SDK方面，Pike 1.0代码与Shark代码结构耦合，共用底层通道建连、数据加解密、二进制协议等逻辑。

Pike 1.0与Shark代码结构示意图：

耦合带来的弊端一：代码优化升级困难。针对一个SDK的变更经常需要更多地考虑对另一个SDK是否有负面影响，是否影响面可控，这就无端地增加了开发成本。

耦合带来的弊端二：Shark与Pike 1.0的网络配置环境共用，如上图所示，通过DebugPanel对SharkTunnel进行网络环境配置都会同时对Shark和Pike 1.0生效，但是业务方在使用的时候往往只关注其中的一个SDK，不同SDK之间的相互影响引入了很多客服问题，也给客服问题的排查带来了较多干扰因素。

3.4.2）账号体系混乱：

Pike 1.0在同一个App上只支持一种设备唯一标识UnionID，不同App上注册使用的UnionID会有不同，例如美团使用美团唯一标识，点评则使用点评唯一标识。

假如一个业务只在一个App上使用的话Pike 1.0自然可以很好地工作，但是同一个业务有可能需要在多个App上同时使用（如下图所示），如果业务方不对账号体系进行兼容的话，美团App上使用点评唯一标识作为推送标识的业务将无法工作，点评App上使用美团唯一标识作为推送标识的的业务也会无法工作。

这就导致同一个业务在不同App上的推送标识ID逻辑会非常复杂，后端要同时维护多套账号体系之间的映射，才能解决账号体系混乱的问题。

Pike 1.0账号体系不兼容示意图：

3.4.3）推送连接不稳定：

Pike 1.0由于共用Shark的通道逻辑而缺乏推送场景专项优化，在检测通道异常、断连恢复等方面表现不够优秀。在通道可用性上，Shark与Pike 1.0关注的SLA也有着很大的不同。

例如：Shark在长连接通道不可用的情况下，可以通过降级短连接来规避业务网络请求持续失败所带来的成功率下降问题。但是对于Pike 1.0此时如果通道不能快速恢复的话就会造成业务消息投送失败，将直接影响消息投递成功率。所以Shark通道针对连接保活的公共逻辑并不能完美地应用在Pike 1.0业务场景上。

虽然Pike 1.0在Shark通道的基础上进一步在协议层强化了心跳探测机制以提高通道可用性，但通道不能及时检测异常还是时有发生。

此外：Pike 1.0内部使用的事件分发技术的可靠性还暂时没能达到100%，零星地会上报一些异常断连而导致推送不成功的客服问题。

综上：针对推送连接不稳定专项优化的诉求也就不断被提上日程。

3.5v2.0的诞生

Pike 1.0现有的技术痛点在业务场景日益丰富的现状下遭遇了诸多挑战。

为求解决Pike 1.0现有在Android和iOS平台运营上遇到的问题：

1）我们重新梳理产品架构与代码实现；
2）与基础技术部另一个服务于H5的消息投递服务Pike Web进行产品融合。

进而推出全新的升级产品——Pike 2.0。

下图展示了Pike 2.0的产品全景。针对Pike 1.0的现状，Pike 2.0前后端都做了诸多优化，包括技术架构升级、集群独立、协议扩展等。

其中在客户端方面Pike 2.0提供了基于多语言实现服务于多平台的SDK，在服务端方面Pike使用部署Java应用的分布式集群来提供服务。

Pike 2.0产品全景图：

以下内容将主要从客户端视角，详细阐述Pike 2.0 客户端SDK的技术方案设计，从原理上说明Pike 2.0带来的技术优势。

4、v2.0架构设计

针对上文提及的Pike 1.0代码结构耦合的技术痛点，Pike 2.0进行了全新的架构升级，在代码结构、环境配置、服务集群等方面上都与Shark保持产品隔离。

4.1设计思想

经过接近一年的技术积累与沉淀，从Shark提炼的TunnelKit长连内核组件和TNTunnel通用通道组件已经趋于稳定，所以Pike 2.0选择基于TunnelKit与TNTunnel来构建双向消息通道服务。

具体优势有：

1）Pike 2.0基于TunnelKit长连内核构建，能有效地复用现有长连接控制相关的功能，减少不必要的开发工作；
2）Pike 2.0能够共享TNTunnel的相关通用特性，如Shark协议封装、数据加解密等，后期维护成本较小；
3）Pike 2.0协议作为Shark协议的Payload传输，可以灵活定制自己特性相关的协议。

4.2整体架构

客户端架构演进图：

整体架构如上图所示，包括：

1）Pike接口层；
2）Pike通道层；
3）TNTunnel通道层；
4）TunnelKit长连内核层。

4.2.1）接口层：

Pike接口层旨在为主流前端技术栈中所有需要应用内消息服务的业务提供简洁可靠的接口。

主要是：

1）Pike 2.0提供了 Android、iOS、MRN等公司主流技术栈的接入SDK，业务可以根据自己的需求灵活选择；
2）Pike 2.0针对不同的消息QPS，设计了两种不同Client（详见下方）；
3）Pike 2.0针对线上Pike 1.0系统提供了业务无感的迁移方案，业务方无需任何人力投入便可以从之前的Pike 1.0系统迁移至Pike 2.0系统来进行消息的收发。

针对第 2）点，我们是这样设计的：

1）对于消息量超过50条每秒的业务，例如直播弹幕推送，我们推荐接入聚合消息Client；
2）对于消息量较小的其他业务，普通消息Client则可以满足需求。

4.2.2）通道层：

Pike通道层是特性的实现层，所有Pike接口层的API调用都会通过线程调度转变成封装的Task在Pike通道层完成具体的操作，Pike通道层是单线程模型，最大程度规避掉了线程安全问题。

Pike特性如下：

1）断线重连：鉴于长连接的不稳定特征，Pike 2.0通道通过断线重连机制来使的业务方可以认为在网络没有发生故障的情况下是持续可用的；
2）业务鉴权：业务后端可以通过Pike 2.0通道对连接的监控来感知连接变更，同时对接入网络的客户端设备进行可用性判别；
3）别名机制：针对不同业务方对业务标识做了隔离，每个业务可以自定义标识ID，解决了Pike 1.0同一个App平台不同业务必须强制使用相同标识ID的痛点；
4）上/下行消息：Pike 2.0是双向通道服务，不仅支持Pike 1.0原有的消息推送能力，即服务端向客户端发送下行消息；同时也支持客户端主动发送消息，即客户端向服务端发送上行消息。业务只要通过Pike 2.0系统便可以形成消息的闭环；
5）分组/聚合消息：Pike 2.0支持消息分组和消息聚合来满足高QPS业务场景的使用。其中消息分组表示业务可以通过自定义标签来对一组用户进行消息广播；消息聚合表示将短时间内井喷式的消息进行聚合下发以提高系统的吞吐量；
6）消息保序：Pike 2.0支持同一客户端发送的上行消息有序投递到固定的业务服务器；
7）独立通道：Pike 2.0默认所有业务是使用一条共享的通道，针对业务量大或者对吞吐量有要求的业务可以自动切换独享的通道来保证消息的投递成功率和时延；
8）通道保活：Pike 2.0在连接保活的基础上增加了通道巡检，能够在检测到异常的情况下自动重启通道，确保在要求长稳的环境下进一步提升通道可用性。

4.2.3）TNTunnel通道层：

TNTunnel通道层是封装通用通道逻辑的功能层，主要涉及通道状态管理、协议封装、数据加解密等通用核心模块，是将通用通道逻辑从原先Shark通道中提炼而成的独立分层。

Pike协议虽然是构建在现有Shark协议之上的应用层协议，但是Pike通道已经和原先的Shark通道在逻辑上完全解耦。

一方面，Pike 2.0会最大限度地复用Shark协议已成熟的技术，但是又不依赖于原有的Shark逻辑；
另一面，后续涉及二进制协议、安全协议等协议方面的升级优化都可以同时服务于Pike 2.0。

4.2.4）TunnelKit长连内核层：

TunnelKit长连内核层主要功能是对接Socket来处理TCP或者UDP数据的发送与接收，管理各个连接的可用性等。

每条Pike 2.0通道在TunnelKit中都是维护一条连接的，通过心跳保活机制和连接管理来保证在网络环境正常的情况下永远有一条连接来承载Pike数据。

TunnelKit作为所有通道层的基础，是决定上层长连接通道稳定性最重要的一层。

5、v2.0工作机制

在进行了全新推送架构升级的基础上，Pike针对上文提及的Pike 1.0账号体系混乱、推送连接不稳定的痛点重新设计并完善了工作机制。

其中，PikeClient作为Pike系统对接业务方的门户，在整个Pike 2.0系统中起着至关重要的作用，本节将以PikeClient为切入点介绍其工作机制。

5.1PikeClient生命周期

为了更好地维护Pike 2.0内部状态，PikeClient使用状态机来负责生命周期管理。

PikeClient生命周期图：

如上图所示，PikeClient生命周期主要包括如下几个部分：

1）onStart：该状态是业务方调用StartClient或者RestartClient之后进入的状态，此时PikeClient已经正常启动，之后Pike 2.0内部会发起业务鉴权并根据鉴权结果流转到其他的状态，如图所示如果业务鉴权失败则进入onStop状态，如果业务鉴权成功则进入running状态；
2）onStop：该状态是业务方调用StopClient或者业务鉴权失败之后进入的状态，此时PikeClient已经停止工作，客户端进入该状态之后需要Restart才能重新使用；
3）running：该状态是PikeClient长稳工作的状态，此时Pike 2.0等待响应服务推送的下行消息或者随时准备发送上行消息。作为双向消息通道，Pike 2.0处理上下行消息的能力是完全并行的；
4）onReceive: 该状态是PikeClient成功接收到下行消息之后进入的状态，Pike 2.0将接收到的消息投递给业务方之后重新进入running状态等待下一次操作；
5）onSendSuccess/onSendFailure：该状态是PikeClient发送上行消息之后进入的状态，业务方可以通过监听该状态来获取本次消息发送的结果。

通过基于状态机的生命周期管理，既严格定义了PikeClient的工作流程，也可以准确监控其内部状态，提高了PikeClient的可维护性。

5.2PikeClient工作模式

针对Pike 1.0混乱的账号体系痛点，Pike 2.0设计了全新的工作模式。

如下图所示，Pike通过通道代理模块提供共享通道和独立通道两种模式来满足不通业务场景的需求。

5.2.1）共享通道模式：

共享通道模式是Pike 2.0基本的工作模式，新增的业务方在默认情况下都会使用该模式接入Pike 2.0。

在Pike 2.0中PikeClient与Pike通道服务是多对一的共享关系，每个业务方都会有自己的PikeClient，每个PikeClient都可以自定义消息推送标识ID而避免使用全局标识ID。业务后端可以精简推送标识逻辑，避免同时维护多套账号体系。

不同业务的PikeClient仅在接入层面做了业务隔离，在Pike 2.0通道中会由Pike通道服务完成统一的管理。这种多对一的共享关系使得所有Pike业务共享Pike 2.0通道特性，同时又可以针对每个业务的使用场景设置其特定的消息处理能力，每个接入Pike 2.0的业务方都只需要关注其自己的PikeClient即可。

5.2.2）独立通道模式：

独立通道模式是共享通道模式的拓展能力，Pike 2.0通过配置控制来决策是否切换至该模式。

Pike 2.0默认情况下所有业务方都是共享同一个Pike通道服务，然而鉴于业务场景的不同，每个业务对于消息吞吐量，消息时延等SLA指标的诉求也有差异，例如游戏业务对于消息时延过长的容忍性就比较差。针对特殊业务Pike 2.0提供了独立通道切换的能力支持。

所有PikeClient都通过Pike通道代理模块来对接Pike通道服务，Pike通道代理模块可以通过开关配置来控制PikeClient与特定的Pike通道服务协同工作。通过运用代理模式，既保证了原有结构的完整性，在不需要调整Pike通道代码逻辑的基础上就能够完成独立通道能力支持；又可以扩展通道切换能力，有效地管理通道切换的流程，让Pike 2.0通道最大化提供业务能力的同时避免资源浪费。

5.3PikeClient保活机制

PikeClient的保活完全依赖Pike 2.0通道的保活，针对Pike 1.0推送连接不稳定的痛点，Pike 2.0通道在吸收Pike 1.0在保活机制方面沉淀的技术的基础上继续优化，最后设计出基于心跳探测、重连机制和通道巡检的三重保活机制。

保活机制如下图：

5.3.1）心跳探测：

心跳探测是一种检查网络连接状态的常见手段，Pike长连接是TCP连接，而TCP是虚拟连接：如果实际物理链路中出现诸如异常网络节点等因素导致连接出现异常，客户端和服务端并不能及时感应到连接异常，这时就会出现连接的状态处于ESTABLISHED状态，但连接可能已死的现象，心跳探测就是为了解决这种网络异常的技术方案。

PS：关于tcp协议为什么还需要心跳保活，可以详读这篇《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》。

客户端在心跳巡检计时器设置的心跳周期到达时判断是否存在上次心跳超时的异常，如果心跳超时则认为该连接已经不可用了，则会从连接池移除该连接并触发下文的重连机制。

为了更快地发现通道异常，Pike 2.0对于心跳周期与心跳超时都是可配置的，针对不同App使用的场景可以灵活地设置。

而且在每次发送上行数据的时候都会及时检测上次心跳是否超时，使得心跳探测结果不必等到下次心跳周期到达的时刻才知悉。

Pike 2.0并不是采用固定心跳频率来发送心跳包，Pike 2.0会利用通道的上下行数据包来动态减少心跳包的发送次数。

此外，智能心跳也是Pike 2.0持续关注的话题，感兴趣的读读下面这些：

5.3.2）重连机制：

重连机制是Pike 2.0作为长连接通道最核心的特性，也是Pike 2.0连接稳定性建设最重要的一环。

客户端会在发送消息、接收消息和心跳探测三个环节来决策是否需要触发重连：

1）一方面，如果主动发现连接池中可用连接不足则自动启动重连机制；
2）另一面，当现有可用连接关闭时也会自动触发重连机制。

Pike 2.0在重连的过程中会采用斐波那契数列退避算法来发起建连请求直至建连成功：

1）一方面，Pike 2.0保证只要在网络可用的情况下总能够维持可用的长连接来服务于业务消息；
2）另方面，Pike 2.0在网络持续不可用的情况下避免连续建连使得系统满载。

有关断线重连这方面的文章，可以系统的读一读下面这些：

PS：如果需要实践性的代码，也可读一下开源工程MobileIMSDK ，它对于im的心跳和重连机制有完整的逻辑实现，可以借鉴参考。

5.3.3）通道巡检：

通道巡检是在心跳探测和重连机制的基础上进一步提升Pike 2.0稳定性的有效机制。

客户端会根据心跳周期设置一个全局的巡检定时器，在每次定时器设置的时刻到达时，客户端会触发通道异常检测逻辑，一旦发现异常都会尝试重启通道。

Pike 2.0首先会在触发通道异常检测的时候获取当前通道状态，如果通道当前没有主动关闭但是通道处于不可用的状态，Pike 2.0会强制执行一次自启动。

此外，在通道巡检的过程中，巡检管理器会不断收集消息收发过程中出现的超时异常，当超时异常次数连续累计超过配置的最大阈值时，Pike 2.0会认为当前通道可用性较低，需要强制关闭并执行一次自启动。

6、v2.0新增的技术特性

Pike 2.0作为Pike 1.0的升级版，不只是为了解决Pike 1.0的技术痛点，通过新增特性以开拓新的应用场景也是Pike 2.0关注的点。

6.1聚合消息

随着公司内直播业务的兴起，公司内部也有很多业务方使用Pike 1.0作为弹幕、评论、直播间控制信令等下行实时消息的传输通道。

但Pike 1.0基于早先的设计架构为弹幕、评论这种短时间需要处理海量消息的场景提供可靠服务的能力渐渐力不从心。

主要表现在QPS大幅增长时，消息投递成功率降低、延时增加和系统性能开销增长等方面。Pike通过引入聚合消息为直播场景中消息的投递提出更加通用的解决方案。

6.1.1）设计思想：

直播场景中涉及的消息主要具备以下特点：

1）弹幕作为一种实时互动的载体，短时间内需处理大量的图片、文本等信息，如果不做聚合会浪费大量的带宽；
2）直播间相比普通推送场景，由于用户已经进入直播间，用户行为也相对统一可控，所以更需要一种群组消息来统一处理；
3）直播间对于不同类型的消息处理逻辑可以区分优先级，比如抽奖、控制信令是要求可靠性不能丢弃，而对于弹幕则可根据直播间热度、服务承受能力适当丢弃。

聚合消息在设计上主要采用下述思想：

1）从时间维度对消息进行聚合，减少不必要的带宽消耗；
2）采用消息分级策略，根据消息的类型设定不同的优先级，保证重要消息的可靠性；
3）抽象出类似直播间的聚合单元，统一管理加入聚合单元的用户行为；
4）采用客户端主动拉取的策略；
5）提供上行消息能力，提供更完整的消息流通路径。

针对第 4）点：相比传统的服务端推送策略，主动拉取是利用客户端天然分布式的特点将用户状态保存在客户端，服务端通过减少状态维护进而可以留出更多的资源用于业务处理。

6.1.2）方案流程：

Pike 2.0针对每个聚合单元都使用环形队列来维护消息列表，发送到该聚合单元的消息在经过优先级过滤之后都会插入队列tail指针标示的位置，随着该聚合单元内消息不断增加最后达到最大队列长度时，head指针会不断移动来给tail指针腾出位置。聚合单元通过控制最大长度的环形队列来避免消息短时间井喷式增长带来的服务性能问题。

客户端在主动拉取的时候都会携带上一次获取到的消息处在环形队列中的偏移量，这样服务就会将偏移量标示的位置到tail指针标示的位置之间的消息进行聚合作为本次拉取的结果一次性返回给客户端。不同客户端各自维护自己的偏移量，以此来避免服务端对于客户端的状态维护。

客户端与服务端的具体交互如下图所示：客户端在加入聚合单元之后主动拉取，如果本次拉取携带的偏移量能够从服务的环形队列中获取到聚合消息，那么就将消息回调给业务之后马上进行下一次拉取操作。如果本次携带的偏移量已经位于环形队列tail指针的位置，那么服务端将不做任何响应，客户端等待本次拉取超时之后开始下一次拉取操作，重复该流程直至客户端离开该聚合单元。与此同时，业务服务端如果有消息需要推送，则通过RPC的方式发送给Pike服务端，消息处理模块将执行消息分级策略过滤之后的有效消息插入环形队列。

聚合消息交互流程图：

6.2消息保序

Pike 1.0在设计之初就只适用于消息推送的场景，而Pike 2.0在其基础上演进为双向消息投递服务，即不仅支持下行的消息推送，还支持上行的消息投递。Pike 2.0在上行的消息投递方面进一步拓展了消息保序的功能。

这里的消息保序主要包含两个层面的含义：

1）首先每一个业务客户端发送的消息都最大程度地到达同一个业务服务器；
2）其次这些消息是按照客户端发送的时序一致地到达该业务服务器。

6.2.1）粘性会话：

为了使每一个业务客户端发送的消息都最大程度地到达同一个业务服务器，Pike 2.0引入了粘性会话的概念。

粘性会话指的是：同一客户端连接上的消息固定转发至某一特定的业务方机器处理，客户端断连重连后，保持新连接上的消息仍转发至该业务机器。

粘性会话可以归纳为如下的流程：

1）首次业务登录的时候Pike 2.0服务器会利用负载均衡算法选择一台业务服务器，并将该业务服务器的路由标识通过业务登录结果通知客户端并保存，之后如果通道状态稳定的话所有的上行消息就都会投递到该业务服务器；
2）如果期间通道状态波动出现断连的情况，Pike 2.0在发起重连之后会重新进行业务登录，这一次业务登录会将之前保存的路由标识重新上报给Pike 2.0服务器，这样Pike 2.0服务器就会通过路由标识重新绑定该业务服务器；
3）如果路由标识指示的业务服务器已经停止提供服务，那么Pike 2.0服务器会重新通过负载均衡算法选择新的一台业务服务器，同时客户端会获取到新的路由标识，之后的逻辑重复该过程直至Pike 2.0客户端退出。

6.2.2）时序一致性：

我们都知道TCP是有序的，那么在同一个TCP连接的前提下什么情况会出现客户端发送的消息乱序到达业务服务器呢？

原因就是：Pike 2.0服务器从TCP中读出消息之后将其投递给业务服务器是通过RPC异步调用的。

为了解决这种问题：最简单的方案当然是客户端将消息队列的发送窗口限定为1，每一条发送消息都在Pike 2.0服务器投递给业务服务器之后才能收到ACK，这时再发送下一条消息。但是考虑到网络传输在链路上的时延远远大于端上处理的时延，所以该方案的QPS被网络传输设了瓶颈，假设一个RTT是200ms，那么该方案理论也只能达到5的QPS。

Pike 2.0为了提高上行消息保序投递的QPS，采用服务端设置消息队列缓存的方案。

如下图所示：客户端可以在发送窗口允许的范围内一次性将多条消息发送出去，服务端把收到的消息都按顺序缓存在消息队列中，然后串行的通过RPC调用将这些缓存的消息依序投递给业务服务器。

这种保序方案将QPS性能的瓶颈点从之前网络传输在链路上的时延转移到了RPC调用的时延上，而实际场景中一次RPC调用往往在几个毫秒之间，远远小于网络传输在链路上的时延，继而显著地提升了QPS。

消息时序一致性问题，在实时通信领域是个很热门的技术点：

7、v2.0的稳定性保障

7.1监控体系

Pike 2.0依赖美团监控平台Raptor完成监控体系建设，服务端和客户端都建设了各自完善的指标监控。

Pike 2.0客户端通过利用Raptor的端到端指标能力和自定义指标能力输出了超过10+个监控指标来实时监控Pike系统，这些指标覆盖通道建立、消息投递、业务登录、系统异常等多维度。

在实时指标监控的基础上Pike 2.0针对不同指标配置了报警阈值，以推送消息为例，如果特定App的大盘数据在每分钟的上下波动幅度超过10%，那么Raptor系统就会向Pike项目组成员推送告警信息。

基于所有Raptor监控指标，Pike 2.0提炼核心SLA指标如下：

Pike 2.0会定期输出基于核心SLA指标的大盘数据报表，同时可以基于App、业务类型、网络类型等多维度对数据进行筛选以满足不同用户对于指标数据的需求。

7.2个案用户追踪

监控体系能从全局的角度反映推送系统稳定性，针对个案用户，Pike管理平台提供完整的链路追踪信息。

每个Pike 2.0连接都由唯一标识Token来区分，通过该唯一标识Token在Pike管理平台的“连接嗅探”模块主动探测便能获得对应连接上所有信令的交互流程。

如下图所示：流程中明确标注了客户端建立连接、发起鉴权、绑定别名等信令，点击对应信令可以跳转信令详情进一步查看该信令所携带的信息，再结合SDK埋点在美团日志服务Logan的离线日志就可以快速发现并定位问题。

8、建设成果

截至2021年6月，Pike共接入业务200+个，日均消息总量约50亿+，Pike 2.0消息到达率 >99.5%（相比Pike 1.0提升0.4%），Pike 2.0平均端到端延时<220ms（相比Pike 1.0减少约37%）。

部分应用案例：

1）直播场景消息服务方案：支持直播业务的直播互动功能，具备了支持同时在线百万级别大型直播的能力；
2）消息推送、Feed流预加载等实时触达方案：支持营销类、控制类等业务消息实时推送，业务消息到达率最高提升10%，长连通道建联耗时减少5%；
3）IoT设备接入方案：支持取餐柜业务IoT接入能力，帮助业务消息到达率从98.4%提升到99.6%；
4）小游戏场景消息投递方案：支持美团小游戏场景通信能力，消息到达率达到99.8%以上，上行延时低至195ms。

9、未来展望

Pike实时消息推送服务在美团应用广泛，目前主要集中在实时触达、互动直播、移动同步等业务场景。随着公司业务的快速发展，Pike对可用性、易用性、可扩展性提出了更高要求，希望提升各种业务场景下的网络体验。

因此未来Pike的规划重点主要是：提供多端、多场景下的网络通信方案，不断完善协议生态，在各种应用场景下对抗复杂网络。

具体就是：

1）拓展通用基础能力：提升通道性能。通过优化保序方案，提供专用通道，优化传输协议等方式，进一步提升吞吐量和稳定性，降低推送时延；
2）建设物联网的接入：提供IoT接入层方案。为公司内物联网应用场景（单车、充电宝、取餐柜、智能头盔、仓库、门店设备等）提供统一的IoT接入层解决方案，支持多种接入协议（HTTP、MQTT、CoAP等），为业务提供安全可靠的设备连接通信能力；
3）优化弱网通信体验：在移动端和IoT端基于美团自研MQUIC网络协议库，探索Pike over QUIC，在桌面端探索WebTransport技术，通过全面支持QUIC协议，提升弱网大包场景下的网络性能，降低长尾分布的请求耗时。

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

《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的高性能消息推送(服务端篇)》
《解密“达达-京东到家”的订单即时派发技术原理和实践》
《技术干货：从零开始，教你设计一个百万级的消息推送系统》
《长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践》
《喜马拉雅亿级用户量的离线消息推送系统架构设计实践》
《直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路》
《直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践》
《消息推送技术干货：美团实时消息推送服务的技术演进之路》
>> 更多同类文章 ……

2 楼: 椎锋陷陈 · 2 年前

整篇文章看下来收益颇丰，但整体感觉就是文章中的措辞太过「专业」，可能对新手来讲理解难度比较大，这里我对文章中提到的一些内容写一下我自己的一些通俗的理解，如有错误还请指正：

引用：推送连接不稳定
｜通过降级短连接来规避业务网络请求持续失败所带来的成功率下降问题。
｜但如果通道不能快速恢复的话就会造成业务消息投送失败，将直接影响消息投递成功率。

指的是长连接无法建立时，利用轮询请求来拉取最新的消息。但由于这种请求是单向的，只能客户端主动向服务端拉取消息，服务端无法主动向客户端推送消息。
且轮询请求存在时间差，无法保证能及时拉取到最新消息。

引用：断线重连
｜使的业务方可以认为在网络没有发生故障的情况下是持续可用的；

指的是在底层去完成重连操作，偶然的断连不影响用户的操作，用户感受不到断连和重连的情况。

引用：分组/聚合消息
｜通过自定义标签来对一组用户进行消息广播；消息聚合表示将短时间内井喷式的消息进行聚合下发以提高系统的吞吐量；

指的是对消息批量下发，减少消息的往返时间。

引用：实现
｜客户端在心跳巡检计时器设置的心跳周期到达时判断是否存在上次心跳超时的异常，如果心跳超时则认为该连接已经不可用了，则会从连接池移除该连接并触发下文的重连机制。

指的是SDK每次发送心跳包时都会设置一个超时时间，如果在超时时间内没有返回则会记录超时异常。
SDK还会额外开启一个定时器，当到达定时时间节点时检查是否有记录的超时异常，有的话则开始重连操作。

引用：上行数据时及时检测
｜在每次发送上行数据的时候都会及时检测上次心跳是否超时，使得心跳探测结果不必等到下次心跳周期到达的时刻才知悉。

指的是心跳周期比较久时，检查心跳超时可能会不及时，因此在每次发送数据(消息、心跳等)时都会主动检查心跳超时。

引用：非固定心跳
｜利用通道的上下行数据包来动态减少心跳包的发送次数。

指的是业务数据包本身可以充当心跳包的作用，当业务数据收发正常时就证明链路是可用的，就不需要额外再发送心跳包了。

引用：在网络持续不可用的情况下避免连续建连使得系统满载。

指的是当重连失败次数越来越多时，表明短时间内重连成功的几率就越小，这个时候就要适当增加一下重连的间隔，以减轻服务器的负载。

引用：累计异常
｜通道巡检的过程中，巡检管理器会不断收集消息收发过程中出现的超时异常，当超时异常次数连续累计超过配置的最大阈值时，Pike 2.0会认为当前通道可用性较低，需要强制关闭并执行一次自启动。

指的是用错误累计的方法判断连接是否失效，避免偶然的断连使一个原本很好的连接被断开。

3 楼: JackJiang · 2 年前

引用：椎锋陷陈发表于 2021-08-25 19:30
整篇文章看下来收益颇丰，但整体感觉就是文章中的措辞太过「专业」，可能对新手来讲理解难度比较大，这里我 ...

感谢学霸，总结的好！

4 楼: 椎锋陷陈 · 2 年前

引用：JackJiang 发表于 2021-08-26 15:46
感谢学霸，总结的好！

不敢不敢，得益于在即时通讯网长期浸染您分享的优质文章，才能做出这个总结

5 楼: JackJiang · 2 年前

引用：椎锋陷陈发表于 2021-08-26 16:54
不敢不敢，得益于在即时通讯网长期浸染您分享的优质文章，才能做出这个总结

6 楼: 15805817394 · 1 年前

写得太好了

7 楼: BrainWong · 1 年前

我想问问，如果像共享单车那种，采用2g网络接收服务端的推送消息。那么一直保持长连接的情况下，服务端不是会产生巨大的开销吗? 一条tcp连接开销都接近3kb了

8 楼: JackJiang · 1 年前

引用：BrainWong 发表于 2022-09-08 21:18
我想问问，如果像共享单车那种，采用2g网络接收服务端的推送消息。那么一直保持长连接的情况下，服务端不是 ...

长连接代价比较高，有可能是轮询。也有可能是长短配合，并不单纯是长或短

本文目录

1、引言

2、相关文章