本文由美團(tuán)技術(shù)團(tuán)隊(duì)分享，作者“健午、佳猛、陸凱、馮江”，原題“美團(tuán)終端消息投遞服務(wù)Pike的演進(jìn)之路”， 有修訂。

1、引言

傳統(tǒng)意義上來說，實(shí)時(shí)消息推送通常都是IM即時(shí)通訊這類應(yīng)用的技術(shù)范疇，隨著移動(dòng)端互聯(lián)網(wǎng)的普及，人人擁有手機(jī)、隨時(shí)都是“在線”已屬常態(tài)，于是消息的實(shí)時(shí)觸達(dá)能力獲得了廣泛的需求，已經(jīng)不再局限于IM即時(shí)通訊這類應(yīng)用中。

對(duì)于美團(tuán)這種移動(dòng)端“入口”級(jí)應(yīng)用來說，實(shí)時(shí)消息的推送能力已經(jīng)深入整個(gè)App的方方面面。目前美團(tuán)應(yīng)用中使用的推送技術(shù)，是一個(gè)被命名為Pike的一套易接入、高可靠、高性能的雙向消息實(shí)時(shí)投遞服務(wù)。

本文將首先從Pike的系統(tǒng)架構(gòu)升級(jí)、工作模式升級(jí)、長(zhǎng)穩(wěn)?；顧C(jī)制升級(jí)等方面介紹2.0版本的技術(shù)演進(jìn)，隨后介紹其在直播、游戲等新業(yè)務(wù)場(chǎng)景下的技術(shù)特性支持，并對(duì)整個(gè)系統(tǒng)升級(jí)過程中的技術(shù)實(shí)踐進(jìn)行了總結(jié)，希望本文能給消息實(shí)時(shí)推送服務(wù)感興趣或從事相關(guān)工作的讀者以幫助和啟發(fā)。

（本文同步發(fā)布于：http://www.52im.net/thread-3662-1-1.html）

2、相關(guān)文章

實(shí)時(shí)消息推送技術(shù)文章參考：

1. 《魅族2500萬長(zhǎng)連接的實(shí)時(shí)消息推送架構(gòu)的技術(shù)實(shí)踐分享》

2. 《專訪魅族架構(gòu)師：海量長(zhǎng)連接的實(shí)時(shí)消息推送系統(tǒng)的心得體會(huì)》

3. 《百萬在線的美拍直播彈幕系統(tǒng)的實(shí)時(shí)推送技術(shù)實(shí)踐之路》

4. 《京東京麥商家開放平臺(tái)的消息推送架構(gòu)演進(jìn)之路》

5. 《解密“達(dá)達(dá)-京東到家”的訂單即時(shí)派發(fā)技術(shù)原理和實(shí)踐》

6. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(四)：愛奇藝WebSocket實(shí)時(shí)推送網(wǎng)關(guān)技術(shù)實(shí)踐》

7. 《喜馬拉雅億級(jí)用戶量的離線消息推送系統(tǒng)架構(gòu)設(shè)計(jì)實(shí)踐》

8. 《微信直播聊天室單房間1500萬在線的消息架構(gòu)演進(jìn)之路》

9. 《百度直播的海量用戶實(shí)時(shí)消息系統(tǒng)架構(gòu)演進(jìn)實(shí)踐》

10. 《技術(shù)干貨：從零開始，教你設(shè)計(jì)一個(gè)百萬級(jí)的消息推送系統(tǒng)》

美團(tuán)技術(shù)團(tuán)隊(duì)分享的其它文章：

1. 《美團(tuán)點(diǎn)評(píng)的移動(dòng)端網(wǎng)絡(luò)優(yōu)化實(shí)踐：大幅提升連接成功率、速度等》

2. 《深度解密美團(tuán)的分布式ID生成算法》

3、v1.0的前世今生

3.1 v1.0 的誕生背景

2015年，美團(tuán)誕生了Shark終端網(wǎng)絡(luò)通道，為公司移動(dòng)端提供長(zhǎng)連代理加速服務(wù)。Shark通過網(wǎng)絡(luò)接入點(diǎn)的全球多地部署和保持長(zhǎng)連來提升網(wǎng)絡(luò)請(qǐng)求的端到端成功率，降低端到端延時(shí)，從而提升用戶體驗(yàn)。

Pike 1.0是基于Shark長(zhǎng)連通道實(shí)現(xiàn)的應(yīng)用內(nèi)推送服務(wù)。由于底層傳輸基于Shark長(zhǎng)連通道，使得Pike 1.0天生便具有了低延時(shí)、高可靠、防DNS劫持等優(yōu)秀基因。目前Pike 1.0在美團(tuán)內(nèi)部的即時(shí)通訊聊天、營(yíng)銷推送、狀態(tài)下發(fā)、配置同步等業(yè)務(wù)場(chǎng)景都有廣泛使用。

3.2 v1.0 的工作流程

Pike 1.0 移動(dòng)端SDK會(huì)在每次長(zhǎng)連接創(chuàng)建成功后：

• 1）使用AppID、設(shè)備唯一標(biāo)識(shí)UnionID（美團(tuán)唯一標(biāo)識(shí)、點(diǎn)評(píng)唯一標(biāo)識(shí)等）向服務(wù)器發(fā)起注冊(cè)；

• 2）在注冊(cè)成功之后業(yè)務(wù)服務(wù)端就可以通過Pike 1.0服務(wù)端SDK提供的接口，主動(dòng)向設(shè)備的App推送消息；

• 3）服務(wù)端推送的消息通過長(zhǎng)連接通道抵達(dá)客戶端，最后通過注冊(cè)的回調(diào)接口投遞給業(yè)務(wù)方。

整體工作流程參見下圖：

3.3 v1.0的優(yōu)勢(shì)

Pike 1.0底層傳輸基于Shark長(zhǎng)連通道。

所以Pike 1.0在以下幾個(gè)方面有不錯(cuò)的表現(xiàn)：

• 1）防劫持：底層通道直接使用IP直連，省去DNS解析耗時(shí)的同時(shí)也避免了被DNS劫持的風(fēng)險(xiǎn)；

• 2）低延時(shí)：Shark長(zhǎng)連接采用就近接入點(diǎn)長(zhǎng)連接的方式，省去了傳統(tǒng)HTTP需要多次建連、握手的消耗，端到端數(shù)據(jù)傳輸延時(shí)相比HTTP大幅縮短；

• 3）安全高：Shark采用自定義二進(jìn)制協(xié)議進(jìn)行數(shù)據(jù)傳輸，進(jìn)行了通道級(jí)別的TLS加密，防篡改，更安全；

• 4）體驗(yàn)好：Pike 1.0與Shark共享服務(wù)集群，Shark長(zhǎng)連通道在海外多地都部署了接入點(diǎn)，代理加速接入，網(wǎng)絡(luò)延時(shí)及成功率表現(xiàn)要優(yōu)于常規(guī)請(qǐng)求。

PS：移動(dòng)網(wǎng)絡(luò)下HTTP、DNS的優(yōu)化文章，可以看看下面這幾篇：

1. 《全面了解移動(dòng)端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》

2. 《美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半》

3. 《百度App移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(一)：DNS優(yōu)化篇》

3.4 v1.0的技術(shù)痛點(diǎn)

Pike 1.0作為Shark的衍生產(chǎn)品固然有其閃光的地方，但是對(duì)Shark的強(qiáng)依賴所帶來的痛點(diǎn)更是讓開發(fā)人員叫苦不迭，主要痛點(diǎn)如下。

3.4.1）代碼結(jié)構(gòu)耦合：

在客戶端SDK方面，Pike 1.0代碼與Shark代碼結(jié)構(gòu)耦合，共用底層通道建連、數(shù)據(jù)加解密、二進(jìn)制協(xié)議等邏輯。

Pike 1.0與Shark代碼結(jié)構(gòu)示意圖：

耦合帶來的弊端一：代碼優(yōu)化升級(jí)困難。針對(duì)一個(gè)SDK的變更經(jīng)常需要更多地考慮對(duì)另一個(gè)SDK是否有負(fù)面影響，是否影響面可控，這就無端地增加了開發(fā)成本。

耦合帶來的弊端二：Shark與Pike 1.0的網(wǎng)絡(luò)配置環(huán)境共用，如上圖所示，通過DebugPanel對(duì)SharkTunnel進(jìn)行網(wǎng)絡(luò)環(huán)境配置都會(huì)同時(shí)對(duì)Shark和Pike 1.0生效，但是業(yè)務(wù)方在使用的時(shí)候往往只關(guān)注其中的一個(gè)SDK，不同SDK之間的相互影響引入了很多客服問題，也給客服問題的排查帶來了較多干擾因素。

3.4.2）賬號(hào)體系混亂：

Pike 1.0在同一個(gè)App上只支持一種設(shè)備唯一標(biāo)識(shí)UnionID，不同App上注冊(cè)使用的UnionID會(huì)有不同，例如美團(tuán)使用美團(tuán)唯一標(biāo)識(shí)，點(diǎn)評(píng)則使用點(diǎn)評(píng)唯一標(biāo)識(shí)。

假如一個(gè)業(yè)務(wù)只在一個(gè)App上使用的話Pike 1.0自然可以很好地工作，但是同一個(gè)業(yè)務(wù)有可能需要在多個(gè)App上同時(shí)使用（如下圖所示），如果業(yè)務(wù)方不對(duì)賬號(hào)體系進(jìn)行兼容的話，美團(tuán)App上使用點(diǎn)評(píng)唯一標(biāo)識(shí)作為推送標(biāo)識(shí)的業(yè)務(wù)將無法工作，點(diǎn)評(píng)App上使用美團(tuán)唯一標(biāo)識(shí)作為推送標(biāo)識(shí)的的業(yè)務(wù)也會(huì)無法工作。

這就導(dǎo)致同一個(gè)業(yè)務(wù)在不同App上的推送標(biāo)識(shí)ID邏輯會(huì)非常復(fù)雜，后端要同時(shí)維護(hù)多套賬號(hào)體系之間的映射，才能解決賬號(hào)體系混亂的問題。

Pike 1.0賬號(hào)體系不兼容示意圖：

3.4.3）推送連接不穩(wěn)定：

Pike 1.0由于共用Shark的通道邏輯而缺乏推送場(chǎng)景專項(xiàng)優(yōu)化，在檢測(cè)通道異常、斷連恢復(fù)等方面表現(xiàn)不夠優(yōu)秀。在通道可用性上，Shark與Pike 1.0關(guān)注的SLA也有著很大的不同。

例如：Shark在長(zhǎng)連接通道不可用的情況下，可以通過降級(jí)短連接來規(guī)避業(yè)務(wù)網(wǎng)絡(luò)請(qǐng)求持續(xù)失敗所帶來的成功率下降問題。但是對(duì)于Pike 1.0此時(shí)如果通道不能快速恢復(fù)的話就會(huì)造成業(yè)務(wù)消息投送失敗，將直接影響消息投遞成功率。所以Shark通道針對(duì)連接?；畹墓策壿嫴⒉荒芡昝赖貞?yīng)用在Pike 1.0業(yè)務(wù)場(chǎng)景上。

雖然Pike 1.0在Shark通道的基礎(chǔ)上進(jìn)一步在協(xié)議層強(qiáng)化了心跳探測(cè)機(jī)制以提高通道可用性，但通道不能及時(shí)檢測(cè)異常還是時(shí)有發(fā)生。

此外：Pike 1.0內(nèi)部使用的事件分發(fā)技術(shù)的可靠性還暫時(shí)沒能達(dá)到100%，零星地會(huì)上報(bào)一些異常斷連而導(dǎo)致推送不成功的客服問題。

綜上：針對(duì)推送連接不穩(wěn)定專項(xiàng)優(yōu)化的訴求也就不斷被提上日程。

3.5 v2.0的誕生

Pike 1.0現(xiàn)有的技術(shù)痛點(diǎn)在業(yè)務(wù)場(chǎng)景日益豐富的現(xiàn)狀下遭遇了諸多挑戰(zhàn)。

為求解決Pike 1.0現(xiàn)有在Android和iOS平臺(tái)運(yùn)營(yíng)上遇到的問題：

• 1）我們重新梳理產(chǎn)品架構(gòu)與代碼實(shí)現(xiàn)；

• 2）與基礎(chǔ)技術(shù)部另一個(gè)服務(wù)于H5的消息投遞服務(wù)Pike Web進(jìn)行產(chǎn)品融合。

進(jìn)而推出全新的升級(jí)產(chǎn)品——Pike 2.0。

下圖展示了Pike 2.0的產(chǎn)品全景。針對(duì)Pike 1.0的現(xiàn)狀，Pike 2.0前后端都做了諸多優(yōu)化，包括技術(shù)架構(gòu)升級(jí)、集群獨(dú)立、協(xié)議擴(kuò)展等。

其中在客戶端方面Pike 2.0提供了基于多語(yǔ)言實(shí)現(xiàn)服務(wù)于多平臺(tái)的SDK，在服務(wù)端方面Pike使用部署Java應(yīng)用的分布式集群來提供服務(wù)。

Pike 2.0產(chǎn)品全景圖：

以下內(nèi)容將主要從客戶端視角，詳細(xì)闡述Pike 2.0 客戶端SDK的技術(shù)方案設(shè)計(jì)，從原理上說明Pike 2.0帶來的技術(shù)優(yōu)勢(shì)。

4、v2.0架構(gòu)設(shè)計(jì)

針對(duì)上文提及的Pike 1.0代碼結(jié)構(gòu)耦合的技術(shù)痛點(diǎn)，Pike 2.0進(jìn)行了全新的架構(gòu)升級(jí)，在代碼結(jié)構(gòu)、環(huán)境配置、服務(wù)集群等方面上都與Shark保持產(chǎn)品隔離。

4.1 設(shè)計(jì)思想

經(jīng)過接近一年的技術(shù)積累與沉淀，從Shark提煉的TunnelKit長(zhǎng)連內(nèi)核組件和TNTunnel通用通道組件已經(jīng)趨于穩(wěn)定，所以Pike 2.0選擇基于TunnelKit與TNTunnel來構(gòu)建雙向消息通道服務(wù)。

具體優(yōu)勢(shì)有：

• 1）Pike 2.0基于TunnelKit長(zhǎng)連內(nèi)核構(gòu)建，能有效地復(fù)用現(xiàn)有長(zhǎng)連接控制相關(guān)的功能，減少不必要的開發(fā)工作；

• 2）Pike 2.0能夠共享TNTunnel的相關(guān)通用特性，如Shark協(xié)議封裝、數(shù)據(jù)加解密等，后期維護(hù)成本較??；

• 3）Pike 2.0協(xié)議作為Shark協(xié)議的Payload傳輸，可以靈活定制自己特性相關(guān)的協(xié)議。

4.2 整體架構(gòu)

客戶端架構(gòu)演進(jìn)圖：

整體架構(gòu)如上圖所示，包括：

• 1）Pike接口層；

• 2）Pike通道層；

• 3）TNTunnel通道層；

• 4）TunnelKit長(zhǎng)連內(nèi)核層。

4.2.1）接口層：

Pike接口層旨在為主流前端技術(shù)棧中所有需要應(yīng)用內(nèi)消息服務(wù)的業(yè)務(wù)提供簡(jiǎn)潔可靠的接口。

主要是：

• 1）Pike 2.0提供了 Android、iOS、MRN等公司主流技術(shù)棧的接入SDK，業(yè)務(wù)可以根據(jù)自己的需求靈活選擇；

• 2）Pike 2.0針對(duì)不同的消息QPS，設(shè)計(jì)了兩種不同Client（詳見下方）；

• 3）Pike 2.0針對(duì)線上Pike 1.0系統(tǒng)提供了業(yè)務(wù)無感的遷移方案，業(yè)務(wù)方無需任何人力投入便可以從之前的Pike 1.0系統(tǒng)遷移至Pike 2.0系統(tǒng)來進(jìn)行消息的收發(fā)。

針對(duì)第 2）點(diǎn)，我們是這樣設(shè)計(jì)的：

• 1）對(duì)于消息量超過50條每秒的業(yè)務(wù)，例如直播彈幕推送，我們推薦接入聚合消息Client；

• 2）對(duì)于消息量較小的其他業(yè)務(wù)，普通消息Client則可以滿足需求。

4.2.2）通道層：

Pike通道層是特性的實(shí)現(xiàn)層，所有Pike接口層的API調(diào)用都會(huì)通過線程調(diào)度轉(zhuǎn)變成封裝的Task在Pike通道層完成具體的操作，Pike通道層是單線程模型，最大程度規(guī)避掉了線程安全問題。

Pike特性如下：

• 1）斷線重連：鑒于長(zhǎng)連接的不穩(wěn)定特征，Pike 2.0通道通過斷線重連機(jī)制來使的業(yè)務(wù)方可以認(rèn)為在網(wǎng)絡(luò)沒有發(fā)生故障的情況下是持續(xù)可用的；

• 2）業(yè)務(wù)鑒權(quán)：業(yè)務(wù)后端可以通過Pike 2.0通道對(duì)連接的監(jiān)控來感知連接變更，同時(shí)對(duì)接入網(wǎng)絡(luò)的客戶端設(shè)備進(jìn)行可用性判別；

• 3）別名機(jī)制：針對(duì)不同業(yè)務(wù)方對(duì)業(yè)務(wù)標(biāo)識(shí)做了隔離，每個(gè)業(yè)務(wù)可以自定義標(biāo)識(shí)ID，解決了Pike 1.0同一個(gè)App平臺(tái)不同業(yè)務(wù)必須強(qiáng)制使用相同標(biāo)識(shí)ID的痛點(diǎn)；

• 4）上/下行消息：Pike 2.0是雙向通道服務(wù)，不僅支持Pike 1.0原有的消息推送能力，即服務(wù)端向客戶端發(fā)送下行消息；同時(shí)也支持客戶端主動(dòng)發(fā)送消息，即客戶端向服務(wù)端發(fā)送上行消息。業(yè)務(wù)只要通過Pike 2.0系統(tǒng)便可以形成消息的閉環(huán)；

• 5）分組/聚合消息：Pike 2.0支持消息分組和消息聚合來滿足高QPS業(yè)務(wù)場(chǎng)景的使用。其中消息分組表示業(yè)務(wù)可以通過自定義標(biāo)簽來對(duì)一組用戶進(jìn)行消息廣播；消息聚合表示將短時(shí)間內(nèi)井噴式的消息進(jìn)行聚合下發(fā)以提高系統(tǒng)的吞吐量；

• 6）消息保序：Pike 2.0支持同一客戶端發(fā)送的上行消息有序投遞到固定的業(yè)務(wù)服務(wù)器；

• 7）獨(dú)立通道：Pike 2.0默認(rèn)所有業(yè)務(wù)是使用一條共享的通道，針對(duì)業(yè)務(wù)量大或者對(duì)吞吐量有要求的業(yè)務(wù)可以自動(dòng)切換獨(dú)享的通道來保證消息的投遞成功率和時(shí)延；

• 8）通道?；睿篜ike 2.0在連接?；畹幕A(chǔ)上增加了通道巡檢，能夠在檢測(cè)到異常的情況下自動(dòng)重啟通道，確保在要求長(zhǎng)穩(wěn)的環(huán)境下進(jìn)一步提升通道可用性。

4.2.3）TNTunnel通道層：

TNTunnel通道層是封裝通用通道邏輯的功能層，主要涉及通道狀態(tài)管理、協(xié)議封裝、數(shù)據(jù)加解密等通用核心模塊，是將通用通道邏輯從原先Shark通道中提煉而成的獨(dú)立分層。

Pike協(xié)議雖然是構(gòu)建在現(xiàn)有Shark協(xié)議之上的應(yīng)用層協(xié)議，但是Pike通道已經(jīng)和原先的Shark通道在邏輯上完全解耦。

• 一方面，Pike 2.0會(huì)最大限度地復(fù)用Shark協(xié)議已成熟的技術(shù)，但是又不依賴于原有的Shark邏輯；

• 另一面，后續(xù)涉及二進(jìn)制協(xié)議、安全協(xié)議等協(xié)議方面的升級(jí)優(yōu)化都可以同時(shí)服務(wù)于Pike 2.0。

4.2.4）TunnelKit長(zhǎng)連內(nèi)核層：

TunnelKit長(zhǎng)連內(nèi)核層主要功能是對(duì)接Socket來處理TCP或者UDP數(shù)據(jù)的發(fā)送與接收，管理各個(gè)連接的可用性等。

每條Pike 2.0通道在TunnelKit中都是維護(hù)一條連接的，通過心跳保活機(jī)制和連接管理來保證在網(wǎng)絡(luò)環(huán)境正常的情況下永遠(yuǎn)有一條連接來承載Pike數(shù)據(jù)。

TunnelKit作為所有通道層的基礎(chǔ)，是決定上層長(zhǎng)連接通道穩(wěn)定性最重要的一層。

5、v2.0工作機(jī)制

在進(jìn)行了全新推送架構(gòu)升級(jí)的基礎(chǔ)上，Pike針對(duì)上文提及的Pike 1.0賬號(hào)體系混亂、推送連接不穩(wěn)定的痛點(diǎn)重新設(shè)計(jì)并完善了工作機(jī)制。

其中，PikeClient作為Pike系統(tǒng)對(duì)接業(yè)務(wù)方的門戶，在整個(gè)Pike 2.0系統(tǒng)中起著至關(guān)重要的作用，本節(jié)將以PikeClient為切入點(diǎn)介紹其工作機(jī)制。

5.1 PikeClient生命周期

為了更好地維護(hù)Pike 2.0內(nèi)部狀態(tài)，PikeClient使用狀態(tài)機(jī)來負(fù)責(zé)生命周期管理。

PikeClient生命周期圖：

如上圖所示，PikeClient生命周期主要包括如下幾個(gè)部分：

• 1）onStart：該狀態(tài)是業(yè)務(wù)方調(diào)用StartClient或者RestartClient之后進(jìn)入的狀態(tài)，此時(shí)PikeClient已經(jīng)正常啟動(dòng)，之后Pike 2.0內(nèi)部會(huì)發(fā)起業(yè)務(wù)鑒權(quán)并根據(jù)鑒權(quán)結(jié)果流轉(zhuǎn)到其他的狀態(tài)，如圖所示如果業(yè)務(wù)鑒權(quán)失敗則進(jìn)入onStop狀態(tài)，如果業(yè)務(wù)鑒權(quán)成功則進(jìn)入running狀態(tài)；

• 2）onStop：該狀態(tài)是業(yè)務(wù)方調(diào)用StopClient或者業(yè)務(wù)鑒權(quán)失敗之后進(jìn)入的狀態(tài)，此時(shí)PikeClient已經(jīng)停止工作，客戶端進(jìn)入該狀態(tài)之后需要Restart才能重新使用；

• 3）running：該狀態(tài)是PikeClient長(zhǎng)穩(wěn)工作的狀態(tài)，此時(shí)Pike 2.0等待響應(yīng)服務(wù)推送的下行消息或者隨時(shí)準(zhǔn)備發(fā)送上行消息。作為雙向消息通道，Pike 2.0處理上下行消息的能力是完全并行的；

• 4）onReceive: 該狀態(tài)是PikeClient成功接收到下行消息之后進(jìn)入的狀態(tài)，Pike 2.0將接收到的消息投遞給業(yè)務(wù)方之后重新進(jìn)入running狀態(tài)等待下一次操作；

• 5）onSendSuccess/onSendFailure：該狀態(tài)是PikeClient發(fā)送上行消息之后進(jìn)入的狀態(tài)，業(yè)務(wù)方可以通過監(jiān)聽該狀態(tài)來獲取本次消息發(fā)送的結(jié)果。

通過基于狀態(tài)機(jī)的生命周期管理，既嚴(yán)格定義了PikeClient的工作流程，也可以準(zhǔn)確監(jiān)控其內(nèi)部狀態(tài)，提高了PikeClient的可維護(hù)性。

5.2 PikeClient工作模式

針對(duì)Pike 1.0混亂的賬號(hào)體系痛點(diǎn)，Pike 2.0設(shè)計(jì)了全新的工作模式。

如下圖所示，Pike通過通道代理模塊提供共享通道和獨(dú)立通道兩種模式來滿足不通業(yè)務(wù)場(chǎng)景的需求。

5.2.1）共享通道模式：

共享通道模式是Pike 2.0基本的工作模式，新增的業(yè)務(wù)方在默認(rèn)情況下都會(huì)使用該模式接入Pike 2.0。

在Pike 2.0中PikeClient與Pike通道服務(wù)是多對(duì)一的共享關(guān)系，每個(gè)業(yè)務(wù)方都會(huì)有自己的PikeClient，每個(gè)PikeClient都可以自定義消息推送標(biāo)識(shí)ID而避免使用全局標(biāo)識(shí)ID。業(yè)務(wù)后端可以精簡(jiǎn)推送標(biāo)識(shí)邏輯，避免同時(shí)維護(hù)多套賬號(hào)體系。

不同業(yè)務(wù)的PikeClient僅在接入層面做了業(yè)務(wù)隔離，在Pike 2.0通道中會(huì)由Pike通道服務(wù)完成統(tǒng)一的管理。這種多對(duì)一的共享關(guān)系使得所有Pike業(yè)務(wù)共享Pike 2.0通道特性，同時(shí)又可以針對(duì)每個(gè)業(yè)務(wù)的使用場(chǎng)景設(shè)置其特定的消息處理能力，每個(gè)接入Pike 2.0的業(yè)務(wù)方都只需要關(guān)注其自己的PikeClient即可。

5.2.2）獨(dú)立通道模式：

獨(dú)立通道模式是共享通道模式的拓展能力，Pike 2.0通過配置控制來決策是否切換至該模式。

Pike 2.0默認(rèn)情況下所有業(yè)務(wù)方都是共享同一個(gè)Pike通道服務(wù)，然而鑒于業(yè)務(wù)場(chǎng)景的不同，每個(gè)業(yè)務(wù)對(duì)于消息吞吐量，消息時(shí)延等SLA指標(biāo)的訴求也有差異，例如游戲業(yè)務(wù)對(duì)于消息時(shí)延過長(zhǎng)的容忍性就比較差。針對(duì)特殊業(yè)務(wù)Pike 2.0提供了獨(dú)立通道切換的能力支持。

所有PikeClient都通過Pike通道代理模塊來對(duì)接Pike通道服務(wù)，Pike通道代理模塊可以通過開關(guān)配置來控制PikeClient與特定的Pike通道服務(wù)協(xié)同工作。通過運(yùn)用代理模式，既保證了原有結(jié)構(gòu)的完整性，在不需要調(diào)整Pike通道代碼邏輯的基礎(chǔ)上就能夠完成獨(dú)立通道能力支持；又可以擴(kuò)展通道切換能力，有效地管理通道切換的流程，讓Pike 2.0通道最大化提供業(yè)務(wù)能力的同時(shí)避免資源浪費(fèi)。

5.3 PikeClient?；顧C(jī)制

PikeClient的?；钔耆蕾嘝ike 2.0通道的?；?，針對(duì)Pike 1.0推送連接不穩(wěn)定的痛點(diǎn)，Pike 2.0通道在吸收Pike 1.0在保活機(jī)制方面沉淀的技術(shù)的基礎(chǔ)上繼續(xù)優(yōu)化，最后設(shè)計(jì)出基于心跳探測(cè)、重連機(jī)制和通道巡檢的三重?；顧C(jī)制。

保活機(jī)制如下圖：

5.3.1）心跳探測(cè)：

心跳探測(cè)是一種檢查網(wǎng)絡(luò)連接狀態(tài)的常見手段，Pike長(zhǎng)連接是TCP連接，而TCP是虛擬連接：如果實(shí)際物理鏈路中出現(xiàn)諸如異常網(wǎng)絡(luò)節(jié)點(diǎn)等因素導(dǎo)致連接出現(xiàn)異常，客戶端和服務(wù)端并不能及時(shí)感應(yīng)到連接異常，這時(shí)就會(huì)出現(xiàn)連接的狀態(tài)處于ESTABLISHED狀態(tài)，但連接可能已死的現(xiàn)象，心跳探測(cè)就是為了解決這種網(wǎng)絡(luò)異常的技術(shù)方案。

PS：關(guān)于tcp協(xié)議為什么還需要心跳保活，可以詳讀這篇《為何基于TCP協(xié)議的移動(dòng)端IM仍然需要心跳保活機(jī)制？》。

客戶端在心跳巡檢計(jì)時(shí)器設(shè)置的心跳周期到達(dá)時(shí)判斷是否存在上次心跳超時(shí)的異常，如果心跳超時(shí)則認(rèn)為該連接已經(jīng)不可用了，則會(huì)從連接池移除該連接并觸發(fā)下文的重連機(jī)制。

為了更快地發(fā)現(xiàn)通道異常，Pike 2.0對(duì)于心跳周期與心跳超時(shí)都是可配置的，針對(duì)不同App使用的場(chǎng)景可以靈活地設(shè)置。

而且在每次發(fā)送上行數(shù)據(jù)的時(shí)候都會(huì)及時(shí)檢測(cè)上次心跳是否超時(shí)，使得心跳探測(cè)結(jié)果不必等到下次心跳周期到達(dá)的時(shí)刻才知悉。

Pike 2.0并不是采用固定心跳頻率來發(fā)送心跳包，Pike 2.0會(huì)利用通道的上下行數(shù)據(jù)包來動(dòng)態(tài)減少心跳包的發(fā)送次數(shù)。

此外，智能心跳也是Pike 2.0持續(xù)關(guān)注的話題，感興趣的讀讀下面這些：

1. 《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)保活實(shí)戰(zhàn)分享(進(jìn)程?；钇?》

2. 《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)保活實(shí)戰(zhàn)分享(網(wǎng)絡(luò)?；钇?》

3. 《移動(dòng)端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》

4. 《移動(dòng)端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》

5. 《一文讀懂即時(shí)通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機(jī)制：作用、原理、實(shí)現(xiàn)思路等》

6. 《融云技術(shù)分享：融云安卓端IM產(chǎn)品的網(wǎng)絡(luò)鏈路保活技術(shù)實(shí)踐》

7. 《正確理解IM長(zhǎng)連接的心跳及重連機(jī)制，并動(dòng)手實(shí)現(xiàn)（有完整IM源碼）》

8. 《一種Android端IM智能心跳算法的設(shè)計(jì)與實(shí)現(xiàn)探討（含樣例代碼）》

5.3.2）重連機(jī)制：

重連機(jī)制是Pike 2.0作為長(zhǎng)連接通道最核心的特性，也是Pike 2.0連接穩(wěn)定性建設(shè)最重要的一環(huán)。

客戶端會(huì)在發(fā)送消息、接收消息和心跳探測(cè)三個(gè)環(huán)節(jié)來決策是否需要觸發(fā)重連：

• 1）一方面，如果主動(dòng)發(fā)現(xiàn)連接池中可用連接不足則自動(dòng)啟動(dòng)重連機(jī)制；

• 2）另一面，當(dāng)現(xiàn)有可用連接關(guān)閉時(shí)也會(huì)自動(dòng)觸發(fā)重連機(jī)制。

Pike 2.0在重連的過程中會(huì)采用斐波那契數(shù)列退避算法來發(fā)起建連請(qǐng)求直至建連成功：

• 1）一方面，Pike 2.0保證只要在網(wǎng)絡(luò)可用的情況下總能夠維持可用的長(zhǎng)連接來服務(wù)于業(yè)務(wù)消息；

• 2）另方面，Pike 2.0在網(wǎng)絡(luò)持續(xù)不可用的情況下避免連續(xù)建連使得系統(tǒng)滿載。

有關(guān)斷線重連這方面的文章，可以系統(tǒng)的讀一讀下面這些：

1. 《Web端即時(shí)通訊實(shí)踐干貨：如何讓你的WebSocket斷網(wǎng)重連更快速？》

2. 《正確理解IM長(zhǎng)連接的心跳及重連機(jī)制，并動(dòng)手實(shí)現(xiàn)（有完整IM源碼）》

3. 《手把手教你用Netty實(shí)現(xiàn)網(wǎng)絡(luò)通信程序的心跳機(jī)制、斷線重連機(jī)制》

PS：如果需要實(shí)踐性的代碼，也可讀一下開源工程MobileIMSDK?，它對(duì)于im的心跳和重連機(jī)制有完整的邏輯實(shí)現(xiàn)，可以借鑒參考。

5.3.3）通道巡檢：

通道巡檢是在心跳探測(cè)和重連機(jī)制的基礎(chǔ)上進(jìn)一步提升Pike 2.0穩(wěn)定性的有效機(jī)制。

客戶端會(huì)根據(jù)心跳周期設(shè)置一個(gè)全局的巡檢定時(shí)器，在每次定時(shí)器設(shè)置的時(shí)刻到達(dá)時(shí)，客戶端會(huì)觸發(fā)通道異常檢測(cè)邏輯，一旦發(fā)現(xiàn)異常都會(huì)嘗試重啟通道。

Pike 2.0首先會(huì)在觸發(fā)通道異常檢測(cè)的時(shí)候獲取當(dāng)前通道狀態(tài)，如果通道當(dāng)前沒有主動(dòng)關(guān)閉但是通道處于不可用的狀態(tài)，Pike 2.0會(huì)強(qiáng)制執(zhí)行一次自啟動(dòng)。

此外，在通道巡檢的過程中，巡檢管理器會(huì)不斷收集消息收發(fā)過程中出現(xiàn)的超時(shí)異常，當(dāng)超時(shí)異常次數(shù)連續(xù)累計(jì)超過配置的最大閾值時(shí)，Pike 2.0會(huì)認(rèn)為當(dāng)前通道可用性較低，需要強(qiáng)制關(guān)閉并執(zhí)行一次自啟動(dòng)。

6、v2.0新增的技術(shù)特性

Pike 2.0作為Pike 1.0的升級(jí)版，不只是為了解決Pike 1.0的技術(shù)痛點(diǎn)，通過新增特性以開拓新的應(yīng)用場(chǎng)景也是Pike 2.0關(guān)注的點(diǎn)。

6.1 聚合消息

隨著公司內(nèi)直播業(yè)務(wù)的興起，公司內(nèi)部也有很多業(yè)務(wù)方使用Pike 1.0作為彈幕、評(píng)論、直播間控制信令等下行實(shí)時(shí)消息的傳輸通道。

但Pike 1.0基于早先的設(shè)計(jì)架構(gòu)為彈幕、評(píng)論這種短時(shí)間需要處理海量消息的場(chǎng)景提供可靠服務(wù)的能力漸漸力不從心。

主要表現(xiàn)在QPS大幅增長(zhǎng)時(shí)，消息投遞成功率降低、延時(shí)增加和系統(tǒng)性能開銷增長(zhǎng)等方面。Pike通過引入聚合消息為直播場(chǎng)景中消息的投遞提出更加通用的解決方案。

6.1.1）設(shè)計(jì)思想：

直播場(chǎng)景中涉及的消息主要具備以下特點(diǎn)：

• 1）彈幕作為一種實(shí)時(shí)互動(dòng)的載體，短時(shí)間內(nèi)需處理大量的圖片、文本等信息，如果不做聚合會(huì)浪費(fèi)大量的帶寬；

• 2）直播間相比普通推送場(chǎng)景，由于用戶已經(jīng)進(jìn)入直播間，用戶行為也相對(duì)統(tǒng)一可控，所以更需要一種群組消息來統(tǒng)一處理；

• 3）直播間對(duì)于不同類型的消息處理邏輯可以區(qū)分優(yōu)先級(jí)，比如抽獎(jiǎng)、控制信令是要求可靠性不能丟棄，而對(duì)于彈幕則可根據(jù)直播間熱度、服務(wù)承受能力適當(dāng)丟棄。

聚合消息在設(shè)計(jì)上主要采用下述思想：

• 1）從時(shí)間維度對(duì)消息進(jìn)行聚合，減少不必要的帶寬消耗；

• 2）采用消息分級(jí)策略，根據(jù)消息的類型設(shè)定不同的優(yōu)先級(jí)，保證重要消息的可靠性；

• 3）抽象出類似直播間的聚合單元，統(tǒng)一管理加入聚合單元的用戶行為；

• 4）采用客戶端主動(dòng)拉取的策略；

• 5）提供上行消息能力，提供更完整的消息流通路徑。

針對(duì)第 4）點(diǎn)：相比傳統(tǒng)的服務(wù)端推送策略，主動(dòng)拉取是利用客戶端天然分布式的特點(diǎn)將用戶狀態(tài)保存在客戶端，服務(wù)端通過減少狀態(tài)維護(hù)進(jìn)而可以留出更多的資源用于業(yè)務(wù)處理。

6.1.2）方案流程：

Pike 2.0針對(duì)每個(gè)聚合單元都使用環(huán)形隊(duì)列來維護(hù)消息列表，發(fā)送到該聚合單元的消息在經(jīng)過優(yōu)先級(jí)過濾之后都會(huì)插入隊(duì)列tail指針標(biāo)示的位置，隨著該聚合單元內(nèi)消息不斷增加最后達(dá)到最大隊(duì)列長(zhǎng)度時(shí)，head指針會(huì)不斷移動(dòng)來給tail指針騰出位置。聚合單元通過控制最大長(zhǎng)度的環(huán)形隊(duì)列來避免消息短時(shí)間井噴式增長(zhǎng)帶來的服務(wù)性能問題。

客戶端在主動(dòng)拉取的時(shí)候都會(huì)攜帶上一次獲取到的消息處在環(huán)形隊(duì)列中的偏移量，這樣服務(wù)就會(huì)將偏移量標(biāo)示的位置到tail指針標(biāo)示的位置之間的消息進(jìn)行聚合作為本次拉取的結(jié)果一次性返回給客戶端。不同客戶端各自維護(hù)自己的偏移量，以此來避免服務(wù)端對(duì)于客戶端的狀態(tài)維護(hù)。

客戶端與服務(wù)端的具體交互如下圖所示：客戶端在加入聚合單元之后主動(dòng)拉取，如果本次拉取攜帶的偏移量能夠從服務(wù)的環(huán)形隊(duì)列中獲取到聚合消息，那么就將消息回調(diào)給業(yè)務(wù)之后馬上進(jìn)行下一次拉取操作。如果本次攜帶的偏移量已經(jīng)位于環(huán)形隊(duì)列tail指針的位置，那么服務(wù)端將不做任何響應(yīng)，客戶端等待本次拉取超時(shí)之后開始下一次拉取操作，重復(fù)該流程直至客戶端離開該聚合單元。與此同時(shí)，業(yè)務(wù)服務(wù)端如果有消息需要推送，則通過RPC的方式發(fā)送給Pike服務(wù)端，消息處理模塊將執(zhí)行消息分級(jí)策略過濾之后的有效消息插入環(huán)形隊(duì)列。

聚合消息交互流程圖：

6.2 消息保序

Pike 1.0在設(shè)計(jì)之初就只適用于消息推送的場(chǎng)景，而Pike 2.0在其基礎(chǔ)上演進(jìn)為雙向消息投遞服務(wù)，即不僅支持下行的消息推送，還支持上行的消息投遞。Pike 2.0在上行的消息投遞方面進(jìn)一步拓展了消息保序的功能。

這里的消息保序主要包含兩個(gè)層面的含義：

• 1）首先每一個(gè)業(yè)務(wù)客戶端發(fā)送的消息都最大程度地到達(dá)同一個(gè)業(yè)務(wù)服務(wù)器；

• 2）其次這些消息是按照客戶端發(fā)送的時(shí)序一致地到達(dá)該業(yè)務(wù)服務(wù)器。

6.2.1）粘性會(huì)話：

為了使每一個(gè)業(yè)務(wù)客戶端發(fā)送的消息都最大程度地到達(dá)同一個(gè)業(yè)務(wù)服務(wù)器，Pike 2.0引入了粘性會(huì)話的概念。

粘性會(huì)話指的是：同一客戶端連接上的消息固定轉(zhuǎn)發(fā)至某一特定的業(yè)務(wù)方機(jī)器處理，客戶端斷連重連后，保持新連接上的消息仍轉(zhuǎn)發(fā)至該業(yè)務(wù)機(jī)器。

粘性會(huì)話可以歸納為如下的流程：

• 1）首次業(yè)務(wù)登錄的時(shí)候Pike 2.0服務(wù)器會(huì)利用負(fù)載均衡算法選擇一臺(tái)業(yè)務(wù)服務(wù)器，并將該業(yè)務(wù)服務(wù)器的路由標(biāo)識(shí)通過業(yè)務(wù)登錄結(jié)果通知客戶端并保存，之后如果通道狀態(tài)穩(wěn)定的話所有的上行消息就都會(huì)投遞到該業(yè)務(wù)服務(wù)器；

• 2）如果期間通道狀態(tài)波動(dòng)出現(xiàn)斷連的情況，Pike 2.0在發(fā)起重連之后會(huì)重新進(jìn)行業(yè)務(wù)登錄，這一次業(yè)務(wù)登錄會(huì)將之前保存的路由標(biāo)識(shí)重新上報(bào)給Pike 2.0服務(wù)器，這樣Pike 2.0服務(wù)器就會(huì)通過路由標(biāo)識(shí)重新綁定該業(yè)務(wù)服務(wù)器；

• 3）如果路由標(biāo)識(shí)指示的業(yè)務(wù)服務(wù)器已經(jīng)停止提供服務(wù)，那么Pike 2.0服務(wù)器會(huì)重新通過負(fù)載均衡算法選擇新的一臺(tái)業(yè)務(wù)服務(wù)器，同時(shí)客戶端會(huì)獲取到新的路由標(biāo)識(shí)，之后的邏輯重復(fù)該過程直至Pike 2.0客戶端退出。

6.2.2）時(shí)序一致性：

我們都知道TCP是有序的，那么在同一個(gè)TCP連接的前提下什么情況會(huì)出現(xiàn)客戶端發(fā)送的消息亂序到達(dá)業(yè)務(wù)服務(wù)器呢？

原因就是：Pike 2.0服務(wù)器從TCP中讀出消息之后將其投遞給業(yè)務(wù)服務(wù)器是通過RPC異步調(diào)用的。

為了解決這種問題：最簡(jiǎn)單的方案當(dāng)然是客戶端將消息隊(duì)列的發(fā)送窗口限定為1，每一條發(fā)送消息都在Pike 2.0服務(wù)器投遞給業(yè)務(wù)服務(wù)器之后才能收到ACK，這時(shí)再發(fā)送下一條消息。但是考慮到網(wǎng)絡(luò)傳輸在鏈路上的時(shí)延遠(yuǎn)遠(yuǎn)大于端上處理的時(shí)延，所以該方案的QPS被網(wǎng)絡(luò)傳輸設(shè)了瓶頸，假設(shè)一個(gè)RTT是200ms，那么該方案理論也只能達(dá)到5的QPS。

Pike 2.0為了提高上行消息保序投遞的QPS，采用服務(wù)端設(shè)置消息隊(duì)列緩存的方案。

如下圖所示：客戶端可以在發(fā)送窗口允許的范圍內(nèi)一次性將多條消息發(fā)送出去，服務(wù)端把收到的消息都按順序緩存在消息隊(duì)列中，然后串行的通過RPC調(diào)用將這些緩存的消息依序投遞給業(yè)務(wù)服務(wù)器。

這種保序方案將QPS性能的瓶頸點(diǎn)從之前網(wǎng)絡(luò)傳輸在鏈路上的時(shí)延轉(zhuǎn)移到了RPC調(diào)用的時(shí)延上，而實(shí)際場(chǎng)景中一次RPC調(diào)用往往在幾個(gè)毫秒之間，遠(yuǎn)遠(yuǎn)小于網(wǎng)絡(luò)傳輸在鏈路上的時(shí)延，繼而顯著地提升了QPS。

消息時(shí)序一致性問題，在實(shí)時(shí)通信領(lǐng)域是個(gè)很熱門的技術(shù)點(diǎn)：

1. 《零基礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時(shí)序一致性？》

2. 《如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”？》

3. 《一個(gè)低成本確保IM消息時(shí)序的方法探討》

4. 《一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等》

7、v2.0的穩(wěn)定性保障

7.1 監(jiān)控體系

Pike 2.0依賴美團(tuán)監(jiān)控平臺(tái)Raptor完成監(jiān)控體系建設(shè)，服務(wù)端和客戶端都建設(shè)了各自完善的指標(biāo)監(jiān)控。

Pike 2.0客戶端通過利用Raptor的端到端指標(biāo)能力和自定義指標(biāo)能力輸出了超過10+個(gè)監(jiān)控指標(biāo)來實(shí)時(shí)監(jiān)控Pike系統(tǒng)，這些指標(biāo)覆蓋通道建立、消息投遞、業(yè)務(wù)登錄、系統(tǒng)異常等多維度。

在實(shí)時(shí)指標(biāo)監(jiān)控的基礎(chǔ)上Pike 2.0針對(duì)不同指標(biāo)配置了報(bào)警閾值，以推送消息為例，如果特定App的大盤數(shù)據(jù)在每分鐘的上下波動(dòng)幅度超過10%，那么Raptor系統(tǒng)就會(huì)向Pike項(xiàng)目組成員推送告警信息。

基于所有Raptor監(jiān)控指標(biāo)，Pike 2.0提煉核心SLA指標(biāo)如下：

Pike 2.0會(huì)定期輸出基于核心SLA指標(biāo)的大盤數(shù)據(jù)報(bào)表，同時(shí)可以基于App、業(yè)務(wù)類型、網(wǎng)絡(luò)類型等多維度對(duì)數(shù)據(jù)進(jìn)行篩選以滿足不同用戶對(duì)于指標(biāo)數(shù)據(jù)的需求。

7.2 個(gè)案用戶追蹤

監(jiān)控體系能從全局的角度反映推送系統(tǒng)穩(wěn)定性，針對(duì)個(gè)案用戶，Pike管理平臺(tái)提供完整的鏈路追蹤信息。

每個(gè)Pike 2.0連接都由唯一標(biāo)識(shí)Token來區(qū)分，通過該唯一標(biāo)識(shí)Token在Pike管理平臺(tái)的“連接嗅探”模塊主動(dòng)探測(cè)便能獲得對(duì)應(yīng)連接上所有信令的交互流程。

如下圖所示：流程中明確標(biāo)注了客戶端建立連接、發(fā)起鑒權(quán)、綁定別名等信令，點(diǎn)擊對(duì)應(yīng)信令可以跳轉(zhuǎn)信令詳情進(jìn)一步查看該信令所攜帶的信息，再結(jié)合SDK埋點(diǎn)在美團(tuán)日志服務(wù)Logan的離線日志就可以快速發(fā)現(xiàn)并定位問題。

8、建設(shè)成果

截至2021年6月，Pike共接入業(yè)務(wù)200+個(gè)，日均消息總量約50億+，Pike 2.0消息到達(dá)率?>99.5%（相比Pike 1.0提升0.4%），Pike 2.0平均端到端延時(shí)<220ms（相比Pike 1.0減少約37%）。

部分應(yīng)用案例：

• 1）直播場(chǎng)景消息服務(wù)方案：支持直播業(yè)務(wù)的直播互動(dòng)功能，具備了支持同時(shí)在線百萬級(jí)別大型直播的能力；

• 2）消息推送、Feed流預(yù)加載等實(shí)時(shí)觸達(dá)方案：支持營(yíng)銷類、控制類等業(yè)務(wù)消息實(shí)時(shí)推送，業(yè)務(wù)消息到達(dá)率最高提升10%，長(zhǎng)連通道建聯(lián)耗時(shí)減少5%；

• 3）IoT設(shè)備接入方案：支持取餐柜業(yè)務(wù)IoT接入能力，幫助業(yè)務(wù)消息到達(dá)率從98.4%提升到99.6%；

• 4）小游戲場(chǎng)景消息投遞方案：支持美團(tuán)小游戲場(chǎng)景通信能力，消息到達(dá)率達(dá)到99.8%以上，上行延時(shí)低至195ms。

9、未來展望

Pike實(shí)時(shí)消息推送服務(wù)在美團(tuán)應(yīng)用廣泛，目前主要集中在實(shí)時(shí)觸達(dá)、互動(dòng)直播、移動(dòng)同步等業(yè)務(wù)場(chǎng)景。隨著公司業(yè)務(wù)的快速發(fā)展，Pike對(duì)可用性、易用性、可擴(kuò)展性提出了更高要求，希望提升各種業(yè)務(wù)場(chǎng)景下的網(wǎng)絡(luò)體驗(yàn)。

因此未來Pike的規(guī)劃重點(diǎn)主要是：提供多端、多場(chǎng)景下的網(wǎng)絡(luò)通信方案，不斷完善協(xié)議生態(tài)，在各種應(yīng)用場(chǎng)景下對(duì)抗復(fù)雜網(wǎng)絡(luò)。

具體就是：

• 1）拓展通用基礎(chǔ)能力：提升通道性能。通過優(yōu)化保序方案，提供專用通道，優(yōu)化傳輸協(xié)議等方式，進(jìn)一步提升吞吐量和穩(wěn)定性，降低推送時(shí)延；

• 2）建設(shè)物聯(lián)網(wǎng)的接入：提供IoT接入層方案。為公司內(nèi)物聯(lián)網(wǎng)應(yīng)用場(chǎng)景（單車、充電寶、取餐柜、智能頭盔、倉(cāng)庫(kù)、門店設(shè)備等）提供統(tǒng)一的IoT接入層解決方案，支持多種接入?yún)f(xié)議（HTTP、MQTT、CoAP等），為業(yè)務(wù)提供安全可靠的設(shè)備連接通信能力；

• 3）優(yōu)化弱網(wǎng)通信體驗(yàn)：在移動(dòng)端和IoT端基于美團(tuán)自研MQUIC網(wǎng)絡(luò)協(xié)議庫(kù)，探索Pike over QUIC，在桌面端探索WebTransport技術(shù)，通過全面支持QUIC協(xié)議，提升弱網(wǎng)大包場(chǎng)景下的網(wǎng)絡(luò)性能，降低長(zhǎng)尾分布的請(qǐng)求耗時(shí)。

附錄：更多實(shí)時(shí)消息推送技術(shù)文章

1. 《iOS的推送服務(wù)APNs詳解：設(shè)計(jì)思路、技術(shù)原理及缺陷等》

2. 《信鴿團(tuán)隊(duì)原創(chuàng)：一起走過 iOS10 上消息推送(APNS)的坑》

3. 《Android端消息推送總結(jié)：實(shí)現(xiàn)原理、心跳?；?、遇到的問題等》

4. 《掃盲貼：認(rèn)識(shí)MQTT通信協(xié)議》

5. 《一個(gè)基于MQTT通信協(xié)議的完整Android推送Demo》

6. 《IBM技術(shù)經(jīng)理訪談：MQTT協(xié)議的制定歷程、發(fā)展現(xiàn)狀等》

7. 《求教android消息推送：GCM、XMPP、MQTT三種方案的優(yōu)劣》

8. 《移動(dòng)端實(shí)時(shí)消息推送技術(shù)淺析》

9. 《掃盲貼：淺談iOS和Android后臺(tái)實(shí)時(shí)消息推送的原理和區(qū)別》

10. 《絕對(duì)干貨：基于Netty實(shí)現(xiàn)海量接入的推送服務(wù)技術(shù)要點(diǎn)》

11. 《移動(dòng)端IM實(shí)踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》

12. 《為何微信、QQ這樣的IM工具不使用GCM服務(wù)推送消息？》

13. 《極光推送系統(tǒng)大規(guī)模高并發(fā)架構(gòu)的技術(shù)實(shí)踐分享》

14. 《從HTTP到MQTT：一個(gè)基于位置服務(wù)的App數(shù)據(jù)通信實(shí)踐概述》

15. 《魅族2500萬長(zhǎng)連接的實(shí)時(shí)消息推送架構(gòu)的技術(shù)實(shí)踐分享》

16. 《專訪魅族架構(gòu)師：海量長(zhǎng)連接的實(shí)時(shí)消息推送系統(tǒng)的心得體會(huì)》

17. 《深入的聊聊Android消息推送這件小事》

18. 《基于WebSocket實(shí)現(xiàn)Hybrid移動(dòng)應(yīng)用的消息推送實(shí)踐(含代碼示例)》

19. 《一個(gè)基于長(zhǎng)連接的安全可擴(kuò)展的訂閱/推送服務(wù)實(shí)現(xiàn)思路》

20. 《實(shí)踐分享：如何構(gòu)建一套高可用的移動(dòng)端消息推送系統(tǒng)？》

21. 《Go語(yǔ)言構(gòu)建千萬級(jí)在線的高并發(fā)消息推送系統(tǒng)實(shí)踐(來自360公司)》

22. 《騰訊信鴿技術(shù)分享：百億級(jí)實(shí)時(shí)消息推送的實(shí)戰(zhàn)經(jīng)驗(yàn)》

23. 《百萬在線的美拍直播彈幕系統(tǒng)的實(shí)時(shí)推送技術(shù)實(shí)踐之路》

24. 《京東京麥商家開放平臺(tái)的消息推送架構(gòu)演進(jìn)之路》

25. 《了解iOS消息推送一文就夠：史上最全iOS Push技術(shù)詳解》

26. 《基于APNs最新HTTP/2接口實(shí)現(xiàn)iOS的高性能消息推送(服務(wù)端篇)》

27. 《解密“達(dá)達(dá)-京東到家”的訂單即時(shí)派發(fā)技術(shù)原理和實(shí)踐》

28. 《技術(shù)干貨：從零開始，教你設(shè)計(jì)一個(gè)百萬級(jí)的消息推送系統(tǒng)》

29. 《長(zhǎng)連接網(wǎng)關(guān)技術(shù)專題(四)：愛奇藝WebSocket實(shí)時(shí)推送網(wǎng)關(guān)技術(shù)實(shí)踐》

30. 《喜馬拉雅億級(jí)用戶量的離線消息推送系統(tǒng)架構(gòu)設(shè)計(jì)實(shí)踐》

31. 《直播系統(tǒng)聊天技術(shù)(三)：微信直播聊天室單房間1500萬在線的消息架構(gòu)演進(jìn)之路》

32. 《直播系統(tǒng)聊天技術(shù)(四)：百度直播的海量用戶實(shí)時(shí)消息系統(tǒng)架構(gòu)演進(jìn)實(shí)踐》

33. 《消息推送技術(shù)干貨：美團(tuán)實(shí)時(shí)消息推送服務(wù)的技術(shù)演進(jìn)之路》

34. >>?更多同類文章 ……

本文已同步發(fā)布于“即時(shí)通訊技術(shù)圈”公眾號(hào)。

▲ 本文在公眾號(hào)上的鏈接是：點(diǎn)此進(jìn)入。同步發(fā)布鏈接是：http://www.52im.net/thread-3662-1-1.html