共计 13490 个字符，预计需要花费 34 分钟才能阅读完成。
本文由美团技术团队分享，作者“健午、佳猛、陆凯、冯江”，原题“美团终端音讯投递服务 Pike 的演进之路”，有订正。
1、引言
传统意义上来说，实时音讯推送通常都是 IM 即时通讯这类利用的技术领域，随着挪动端互联网的遍及，人人领有手机、随时都是“在线”已属常态，于是音讯的实时触达能力取得了宽泛的需要，曾经不再局限于 IM 即时通讯这类利用中。
对于美团这种挪动端“入口”级利用来说，实时音讯的推送能力曾经深刻整个 APP 的方方面面。目前美团利用中应用的推送技术，是一个被命名为 Pike 的一套易接入、高牢靠、高性能的双向音讯实时投递服务。
本文将首先从 Pike 的零碎架构降级、工作模式降级、长稳保活机制降级等方面介绍 2.0 版本的技术演进，随后介绍其在直播、游戏等新业务场景下的技术个性反对，并对整个系统升级过程中的技术实际进行了总结，心愿本文能给音讯实时推送服务感兴趣或从事相干工作的读者以帮忙和启发。
（本文同步公布于：http://www.52im.net/thread-36…）
2、相干文章
实时音讯推送技术文章参考：
- 《魅族 2500 万长连贯的实时音讯推送架构的技术实际分享》
- 《专访魅族架构师：海量长连贯的实时音讯推送零碎的心得体会》
- 《百万在线的美拍直播弹幕零碎的实时推送技术实际之路》
- 《京东京麦商家开放平台的音讯推送架构演进之路》
- 《解密“达达 - 京东到家”的订单即时派发技术原理和实际》
- 《长连贯网关技术专题(四)：爱奇艺 WebSocket 实时推送网关技术实际》
- 《喜马拉雅亿级用户量的离线音讯推送零碎架构设计实际》
- 《微信直播聊天室单房间 1500 万在线的音讯架构演进之路》
- 《百度直播的海量用户实时音讯零碎架构演进实际》
- 《技术干货：从零开始，教你设计一个百万级的音讯推送零碎》
美团技术团队分享的其它文章：
- 《美团点评的挪动端网络优化实际：大幅晋升连贯成功率、速度等》
- 《深度解密美团的分布式 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 继续关注的话题，感兴趣的读读上面这些：
- 《微信团队原创分享：Android 版微信后盾保活实战分享(过程保活篇)》
- 《微信团队原创分享：Android 版微信后盾保活实战分享(网络保活篇)》
- 《挪动端 IM 实际：实现 Android 版微信的智能心跳机制》
- 《挪动端 IM 实际：WhatsApp、Line、微信的心跳策略剖析》
- 《一文读懂即时通讯利用中的网络心跳包机制：作用、原理、实现思路等》
- 《融云技术分享：融云安卓端 IM 产品的网络链路保活技术实际》
- 《正确理解 IM 长连贯的心跳及重连机制，并入手实现（有残缺 IM 源码）》
- 《一种 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…
