本文由美团技术团队分享，作者“健午、佳猛、陆凯、冯江”，原题“美团终端音讯投递服务Pike的演进之路”，有订正。

1、引言

传统意义上来说，实时音讯推送通常都是IM即时通讯这类利用的技术领域，随着挪动端互联网的遍及，人人领有手机、随时都是“在线”已属常态，于是音讯的实时触达能力取得了宽泛的需要，曾经不再局限于IM即时通讯这类利用中。

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

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

（本文同步公布于：http://www.52im.net/thread-36...）

2、相干文章

实时音讯推送技术文章参考：

  1. 《魅族2500万长连贯的实时音讯推送架构的技术实际分享》
  2. 《专访魅族架构师：海量长连贯的实时音讯推送零碎的心得体会》
  3. 《百万在线的美拍直播弹幕零碎的实时推送技术实际之路》
  4. 《京东京麦商家开放平台的音讯推送架构演进之路》
  5. 《解密“达达-京东到家”的订单即时派发技术原理和实际》
  6. 《长连贯网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实际》
  7. 《喜马拉雅亿级用户量的离线音讯推送零碎架构设计实际》
  8. 《微信直播聊天室单房间1500万在线的音讯架构演进之路》
  9. 《百度直播的海量用户实时音讯零碎架构演进实际》
  10. 《技术干货：从零开始，教你设计一个百万级的音讯推送零碎》

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

  1. 《美团点评的挪动端网络优化实际：大幅晋升连贯成功率、速度等》
  2. 《深度解密美团的分布式ID生成算法》

3、v1.0的前世今生

3.1 v1.0 的诞生背景
2015年，美团诞生了Shark终端网络通道，为公司挪动端提供长连代理减速服务。Shark通过网络接入点的寰球多地部署和放弃长连来晋升网络申请的端到端成功率，升高端到端延时，从而晋升用户体验。

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

3.2 v1.0 的工作流程
Pike 1.0 挪动端SDK会在每次长连贯创立胜利后：

  • 1）应用APPID、设施惟一标识UnionID（美团惟一标识、点评惟一标识等）向服务器发动注册；
  • 2）在注册胜利之后业务服务端就能够通过Pike 1.0服务端SDK提供的接口，被动向设施的App推送音讯；
  • 3）服务端推送的音讯通过长连贯通道到达客户端，最初通过注册的回调接口投递给业务方。

整体工作流程参见下图：

3.3 v1.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的优化文章，能够看看上面这几篇：

  • 《全面理解挪动端DNS域名劫持等杂症：原理、本源、HttpDNS解决方案等》
  • 《美图App的挪动端DNS优化实际：HTTPS申请耗时减小近半》
  • 《百度APP挪动端网络深度优化实际分享(一)：DNS优化篇》

3.4 v1.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.5 v2.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.1 PikeClient生命周期
为了更好地保护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.2 PikeClient工作模式
针对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.3 PikeClient保活机制
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继续关注的话题，感兴趣的读读上面这些：

  1. 《微信团队原创分享：Android版微信后盾保活实战分享(过程保活篇)》
  2. 《微信团队原创分享：Android版微信后盾保活实战分享(网络保活篇)》
  3. 《挪动端IM实际：实现Android版微信的智能心跳机制》
  4. 《挪动端IM实际：WhatsApp、Line、微信的心跳策略剖析》
  5. 《一文读懂即时通讯利用中的网络心跳包机制：作用、原理、实现思路等》
  6. 《融云技术分享：融云安卓端IM产品的网络链路保活技术实际》
  7. 《正确理解IM长连贯的心跳及重连机制，并入手实现（有残缺IM源码）》
  8. 《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》

5.3.2）重连机制：

重连机制是Pike 2.0作为长连贯通道最外围的个性，也是Pike 2.0连贯稳定性建设最重要的一环。

客户端会在发送音讯、接管音讯和心跳探测三个环节来决策是否须要触发重连：

  • 1）一方面，如果被动发现连接池中可用连贯有余则主动启动重连机制；
  • 2）另一面，当现有可用连贯敞开时也会主动触发重连机制。

Pike 2.0在重连的过程中会采纳斐波那契数列退却算法来发动建连申请直至建连胜利：

  • 1）一方面，Pike 2.0保障只有在网络可用的状况下总可能维持可用的长连贯来服务于业务音讯；
  • 2）另方面，Pike 2.0在网络继续不可用的状况下防止间断建连使得零碎满载。

无关断线重连这方面的文章，能够零碎的读一读上面这些：

  • 《Web端即时通讯实际干货：如何让你的WebSocket断网重连更疾速？》
  • 《正确理解IM长连贯的心跳及重连机制，并入手实现（有残缺IM源码）》
  • 《手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制》

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。

音讯时序一致性问题，在实时通信畛域是个很热门的技术点：

  • 《零根底IM开发入门(四)：什么是IM零碎的音讯时序一致性？》
  • 《如何保障IM实时音讯的“时序性”与“一致性”？》
  • 《一个低成本确保IM音讯时序的办法探讨》
  • 《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》

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万在线的音讯架构演进之路》
《直播零碎聊天技术(四)：百度直播的海量用户实时音讯零碎架构演进实际》
《音讯推送技术干货：美团实时音讯推送服务的技术演进之路》

本文已同步公布于“即时通讯技术圈”公众号。

▲ 本文在公众号上的链接是：点此进入。同步公布链接是：http://www.52im.net/thread-36...