Pike 2.0致力於爲美團提供一套易接入、高可靠、高性能的雙向消息投遞服務。本文首先從系統架構升級、工作模式升級、長穩保活機制升級等方面介紹了Pike2.0的技術演進，然後介紹了Pike 2.0在直播、遊戲等新業務場景下的特性支持。希望本文能給對消息投遞服務感興趣或者從事相關工作的讀者一些幫助和啓發。
1 Pike的前世今生
1.1 Pike 1.0的誕生背景
2015年，美團誕生了Shark終端網絡通道，爲公司移動端提供長連代理加速服務。Shark通過網絡接入點的全球多地部署和保持長連來提升網絡請求的端到端成功率，降低端到端延時，從而提升用戶體驗。
Pike 1.0是基於Shark長連通道實現的應用內推送服務。由於底層傳輸基於Shark長連通道，使得Pike 1.0天生便具有了低延時、高可靠、防DNS劫持等優秀基因。目前Pike 1.0在美團內部的實時互動、營銷推送、狀態下發、配置同步等業務場景都有廣泛使用。
1.2 Pike 1.0的工作流程
移動端SDK會在每次長連接創建成功後，使用APPID、設備唯一標識UnionID（美團唯一標識、點評唯一標識等）向服務器發起註冊，在註冊成功之後業務服務端就可以通過Pike 1.0服務端SDK提供的接口，主動向設備的App推送消息。服務端推送的消息通過長連接通道抵達客戶端，最後通過註冊的回調接口投遞給業務方。整體工作流程參見下圖：
1.3 Pike 1.0的優勢
Pike 1.0底層傳輸基於Shark長連通道，所以Pike 1.0在以下幾個方面有不錯的表現：
- 防DNS劫持：底層通道直接使用IP直連，省去DNS解析耗時的同時也避免了被DNS劫持的風險。
- 低延時：Shark長連接採用就近接入點長連接的方式，省去了傳統HTTP傳輸需要多次建連、握手的消耗，端到端數據傳輸延時相比HTTP大幅縮短。
- 安全性好：Shark採用自定義二進制協議進行數據傳輸，進行了通道級別的TLS加密，防篡改，更安全。
- 更好的境外體驗：Pike 1.0與Shark共享服務集羣，Shark長連通道在海外多地都部署了接入點，代理加速接入，網絡延時及成功率表現要優於常規請求。
1.4 Pike 1.0的痛點
Pike 1.0作爲Shark的衍生產品固然有其閃光的地方，但是對Shark的強依賴所帶來的痛點更是讓開發人員叫苦不迭，主要痛點如下。
1.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之間的相互影響引入了很多客服問題，也給客服問題的排查帶來了較多幹擾因素。
1.4.2 賬號體系混亂
Pike 1.0在同一個App上只支持一種設備唯一標識UnionID，不同App上註冊使用的UnionID會有不同，例如美團使用美團唯一標識，點評則使用點評唯一標識。假如一個業務只在一個App上使用的話Pike 1.0自然可以很好地工作，但是同一個業務有可能需要在多個App上同時使用（如圖所示），如果業務方不對賬號體系進行兼容的話，美團App上使用點評唯一標識作爲推送標識的業務將無法工作，點評App上使用美團唯一標識作爲推送標識的的業務也會無法工作。這就導致同一個業務在不同App上的推送標識ID邏輯會非常複雜，後端要同時維護多套賬號體系之間的映射，才能解決賬號體系混亂的問題。
1.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%，零星地會上報一些異常斷連而導致推送不成功的客服問題。綜上，針對推送連接不穩定專項優化的訴求也就不斷被提上日程。
1.5 Pike 2.0的誕生
Pike 1.0現有的痛點在業務場景日益豐富的現狀下遭遇了諸多挑戰。力求解決Pike 1.0現有在Android和iOS平臺運營上遇到的問題，一方面我們重新梳理產品架構與代碼實現，另一方面我們決定與基礎技術部另一個服務於H5的消息投遞服務Pike Web進行產品融合，進而推出全新的升級產品——Pike 2.0。
下圖展示了Pike 2.0的產品全景，針對Pike 1.0的現狀，Pike 2.0前後端都做了諸多優化，包括技術架構升級、集羣獨立、協議擴展等。其中在客戶端方面Pike 2.0提供了基於多語言實現服務於多平臺的SDK，在服務端方面Pike使用部署Java應用的分佈式集羣來提供服務。
本文主要從客戶端視角，詳細闡述Pike 2.0 客戶端SDK的技術方案設計，從原理上說明Pike 2.0帶來的技術優勢。
2 Pike 2.0架構設計
針對上文提及的Pike 1.0代碼結構耦合的痛點，Pike 2.0進行了全新的架構升級，在代碼結構、環境配置、服務集羣等方面上都與Shark保持產品隔離。
2.1 設計思想
經過接近一年的技術積累與沉澱，從Shark提煉的TunnelKit長連內核組件和TNTunnel通用通道組件已經趨於穩定，所以Pike 2.0選擇基於TunnelKit與TNTunnel來構建雙向消息通道服務。具體優勢有：
- Pike 2.0基於TunnelKit長連內核構建，能有效地複用現有長連接控制相關的功能，減少不必要的開發工作。
- Pike 2.0能夠共享TNTunnel的相關通用特性，如Shark協議封裝、數據加解密等，後期維護成本較小。
- Pike 2.0協議作爲Shark協議的Payload傳輸，可以靈活定製自己特性相關的協議。
2.2 整體架構
整體架構如圖所示，包括Pike接口層，Pike通道層，TNTunnel通道層和TunnelKit長連內核層。
2.2.1 Pike接口層
Pike接口層旨在爲主流前端技術棧中所有需要應用內消息服務的業務提供簡潔可靠的接口：
- Pike 2.0提供了 Android、iOS、MRN等公司主流技術棧的接入SDK，業務可以根據自己的需求靈活選擇。
- Pike 2.0針對不同的消息QPS，設計了兩種不同Client。對於消息量超過50條每秒的業務，例如直播彈幕推送，我們推薦接入聚合消息Client；對於消息量較小的其他業務，普通消息Client則可以滿足需求。
- Pike 2.0針對線上Pike 1.0系統提供了業務無感的遷移方案，業務方無需任何人力投入便可以從之前的Pike 1.0系統遷移至Pike 2.0系統來進行消息的收發。
2.2.2 Pike通道層
Pike通道層是特性的實現層，所有Pike接口層的API調用都會通過線程調度轉變成封裝的Task在Pike通道層完成具體的操作，Pike通道層是單線程模型，最大程度規避掉了線程安全問題。
Pike特性如下：
- 斷線重連：鑑於長連接的不穩定特徵，Pike 2.0通道通過斷線重連機制來使的業務方可以認爲在網絡沒有發生故障的情況下是持續可用的。
- 業務鑑權：業務後端可以通過Pike 2.0通道對連接的監控來感知連接變更，同時對接入網絡的客戶端設備進行可用性判別。
- 別名機制：針對不同業務方對業務標識做了隔離，每個業務可以自定義標識ID，解決了Pike 1.0同一個App平臺不同業務必須強制使用相同標識ID的痛點。
- 上行/下行消息：Pike 2.0是雙向通道服務，不僅支持Pike 1.0原有的消息推送能力，即服務端向客戶端發送下行消息；同時也支持客戶端主動發送消息，即客戶端向服務端發送上行消息。業務只要通過Pike 2.0系統便可以形成消息的閉環。
- 分組/聚合消息：Pike 2.0支持消息分組和消息聚合來滿足高QPS業務場景的使用。其中消息分組表示業務可以通過自定義標籤來對一組用戶進行消息廣播；消息聚合表示將短時間內井噴式的消息進行聚合下發以提高系統的吞吐量。
- 消息保序：Pike 2.0支持同一客戶端發送的上行消息有序投遞到固定的業務服務器。
- 獨立通道：Pike 2.0默認所有業務是使用一條共享的通道，針對業務量大或者對吞吐量有要求的業務可以自動切換獨享的通道來保證消息的投遞成功率和時延。
- 通道保活：Pike 2.0在連接保活的基礎上增加了通道巡檢，能夠在檢測到異常的情況下自動重啓通道，確保在要求長穩的環境下進一步提升通道可用性。
2.2.3 TNTunnel通道層
TNTunnel通道層是封裝通用通道邏輯的功能層。主要涉及通道狀態管理、協議封裝、數據加解密等通用核心模塊，是將通用通道邏輯從原先Shark通道中提煉而成的獨立分層。Pike協議雖然是構建在現有Shark協議之上的應用層協議，但是Pike通道已經和原先的Shark通道在邏輯上完全解耦。一方面，Pike 2.0會最大限度地複用Shark協議已成熟的技術，但是又不依賴於原有的Shark邏輯；另一方面，後續涉及二進制協議、安全協議等協議方面的升級優化都可以同時服務於Pike 2.0。
2.2.4 TunnelKit長連內核層
TunnelKit長連內核層主要功能是對接Socket來處理TCP或者UDP數據的發送與接收，管理各個連接的可用性等。每條Pike 2.0通道在TunnelKit中都是維護一條連接的，通過心跳保活機制和連接管理來保證在網絡環境正常的情況下永遠有一條連接來承載Pike數據。TunnelKit作爲所有通道層的基礎，是決定上層長連接通道穩定性最重要的一層。
3 Pike 2.0工作機制
在進行了全新架構升級的基礎上，Pike針對上文提及的Pike 1.0賬號體系混亂、推送連接不穩定的痛點重新設計並完善了工作機制。
其中，PikeClient作爲Pike系統對接業務方的門戶，在整個Pike 2.0系統中起着至關重要的作用，本文將以PikeClient爲切入點介紹Pike的工作機制。
3.1 PikeClient生命週期
爲了更好地維護Pike 2.0內部狀態，PikeClient使用狀態機來負責生命週期管理。
如圖所示，PikeClient生命週期主要包括如下幾個部分：
- onStart：該狀態是業務方調用StartClient或者RestartClient之後進入的狀態，此時PikeClient已經正常啓動，之後Pike 2.0內部會發起業務鑑權並根據鑑權結果流轉到其他的狀態，如圖所示如果業務鑑權失敗則進入onStop狀態，如果業務鑑權成功則進入running狀態。
- onStop：該狀態是業務方調用StopClient或者業務鑑權失敗之後進入的狀態，此時PikeClient已經停止工作，客戶端進入該狀態之後需要Restart才能重新使用。
- running：該狀態是PikeClient長穩工作的狀態，此時Pike 2.0等待響應服務推送的下行消息或者隨時準備發送上行消息。作爲雙向消息通道，Pike 2.0處理上下行消息的能力是完全並行的。
- onReceive: 該狀態是PikeClient成功接收到下行消息之後進入的狀態，Pike 2.0將接收到的消息投遞給業務方之後重新進入running狀態等待下一次操作。
- onSendSuccess/onSendFailure：該狀態是PikeClient發送上行消息之後進入的狀態，業務方可以通過監聽該狀態來獲取本次消息發送的結果。
通過基於狀態機的生命週期管理，既嚴格定義了PikeClient的工作流程，也可以準確監控其內部狀態，提高了PikeClient的可維護性。
3.2 PikeClient工作模式
針對Pike 1.0混亂的賬號體系痛點，Pike 2.0設計了全新的工作模式。如下圖所示，Pike通過通道代理模塊提供共享通道和獨立通道兩種模式來滿足不通業務場景的需求。
3.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即可。
3.2.2 獨立通道模式
獨立通道模式是共享通道模式的拓展能力，Pike 2.0通過配置控制來決策是否切換至該模式。
Pike 2.0默認情況下所有業務方都是共享同一個Pike通道服務，然而鑑於業務場景的不同，每個業務對於消息吞吐量，消息時延等SLA指標的訴求也有差異，例如遊戲業務對於消息時延過長的容忍性就比較差。針對特殊業務Pike 2.0提供了獨立通道切換的能力支持。
所有PikeClient都通過Pike通道代理模塊來對接Pike通道服務，Pike通道代理模塊可以通過開關配置來控制PikeClient與特定的Pike通道服務協同工作。通過運用代理模式，既保證了原有結構的完整性，在不需要調整Pike通道代碼邏輯的基礎上就能夠完成獨立通道能力支持；又可以擴展通道切換能力，有效地管理通道切換的流程，讓Pike 2.0通道最大化提供業務能力的同時避免資源浪費。
3.3 PikeClient保活機制
PikeClient的保活完全依賴Pike 2.0通道的保活，針對Pike 1.0推送連接不穩定的痛點，Pike 2.0通道在吸收Pike 1.0在保活機制方面沉澱的技術的基礎上繼續優化，最後設計出基於心跳探測、重連機制和通道巡檢的三重保活機制。保活機制如下圖：
3.3.1 心跳探測
心跳探測是一種檢查網絡連接狀態的常見手段，Pike長連接是TCP連接，TCP是虛擬連接，如果實際物理鏈路中出現諸如異常網絡節點等因素導致連接出現異常，客戶端和服務端並不能及時感應到連接異常，這時就會出現連接的狀態處於ESTABLISHED狀態，但連接可能已死的現象，心跳探測就是爲了解決這種網絡異常的技術方案。
客戶端在心跳巡檢計時器設置的心跳週期到達時判斷是否存在上次心跳超時的異常，如果心跳超時則認爲該連接已經不可用了，則會從連接池移除該連接並觸發下文的重連機制。爲了更快地發現通道異常，Pike 2.0對於心跳週期與心跳超時都是可配置的，針對不同App使用的場景可以靈活地設置；而且在每次發送上行數據的時候都會及時檢測上次心跳是否超時，使得心跳探測結果不必等到下次心跳週期到達的時刻才知悉。
Pike 2.0並不是採用固定心跳頻率來發送心跳包，Pike 2.0會利用通道的上下行數據包來動態減少心跳包的發送次數。此外，智能心跳也是Pike 2.0持續關注的話題。
3.3.2 重連機制
重連機制是Pike 2.0作爲長連接通道最核心的特性，也是Pike 2.0連接穩定性建設最重要的一環。
客戶端會在發送消息、接收消息和心跳探測三個環節來決策是否需要觸發重，一方面，如果主動發現連接池中可用連接不足則自動啓動重連機制；另一方面，當現有可用連接關閉時也會自動觸發重連機制。
Pike 2.0在重連的過程中會採用斐波那契數列退避算法來發起建連請求直至建連成功，一方面，Pike 2.0保證只要在網絡可用的情況下總能夠維持可用的長連接來服務於業務消息；另一方面，Pike 2.0在網絡持續不可用的情況下避免連續建連使得系統滿載。
3.3.3 通道巡檢
通道巡檢是在心跳探測和重連機制的基礎上進一步提升Pike 2.0穩定性的有效機制。
客戶端會根據心跳週期設置一個全局的巡檢定時器，在每次定時器設置的時刻到達時，客戶端會觸發通道異常檢測邏輯，一旦發現異常都會嘗試重啓通道。
Pike 2.0首先會在觸發通道異常檢測的時候獲取當前通道狀態，如果通道當前沒有主動關閉但是通道處於不可用的狀態，Pike 2.0會強制執行一次自啓動；此外，在通道巡檢的過程中，巡檢管理器會不斷收集消息收發過程中出現的超時異常，當超時異常次數連續累計超過配置的最大閾值時，Pike 2.0會認爲當前通道可用性較低，需要強制關閉並執行一次自啓動。
4 Pike 2.0新增特性
Pike 2.0作爲Pike 1.0的升級產品，不只是爲了解決Pike 1.0的痛點，通過新增特性以開拓新的應用場景也是Pike 2.0時刻關注的點。
4.1 聚合消息
隨着公司內直播業務的興起，公司內部也有很多業務方使用Pike 1.0作爲彈幕、評論、直播間控制信令等下行實時消息的傳輸通道。但Pike 1.0基於早先的設計架構爲彈幕、評論這種短時間需要處理海量消息的場景提供可靠服務的能力漸漸力不從心，主要表現在QPS大幅增長時，消息投遞成功率降低、延時增加和系統性能開銷增長等方面。Pike通過引入聚合消息爲直播場景中消息的投遞提出更加通用的解決方案。
4.1.1 設計思想
直播場景中涉及的消息主要具備以下特點：
- 彈幕作爲一種實時互動的載體，短時間內需處理大量的圖片、文本等信息，如果不做聚合會浪費大量的帶寬。
- 直播間相比普通推送場景，由於用戶已經進入直播間，用戶行爲也相對統一可控，所以更需要一種羣組消息來統一處理。
- 直播間對於不同類型的消息處理邏輯可以區分優先級，比如抽獎、控制信令是要求可靠性不能丟棄，而對於彈幕則可根據直播間熱度、服務承受能力適當丟棄。
聚合消息在設計上主要採用下述思想：
- 從時間維度對消息進行聚合，減少不必要的帶寬消耗。
- 採用消息分級策略，根據消息的類型設定不同的優先級，保證重要消息的可靠性。
- 抽象出類似直播間的聚合單元，統一管理加入聚合單元的用戶行爲。
- 採用客戶端主動拉取的策略。相比傳統的服務端推送策略，主動拉取是利用客戶端天然分佈式的特點將用戶狀態保存在客戶端，服務端通過減少狀態維護進而可以留出更多的資源用於業務處理。
- 提供上行消息能力，提供更完整的消息流通路徑。
4.1.2 方案流程
Pike 2.0針對每個聚合單元都使用環形隊列來維護消息列表，發送到該聚合單元的消息在經過優先級過濾之後都會插入隊列tail指針標示的位置，隨着該聚合單元內消息不斷增加最後達到最大隊列長度時，head指針會不斷移動來給tail指針騰出位置。聚合單元通過控制最大長度的環形隊列來避免消息短時間井噴式增長帶來的服務性能問題。
客戶端在主動拉取的時候都會攜帶上一次獲取到的消息處在環形隊列中的偏移量，這樣服務就會將偏移量標示的位置到tail指針標示的位置之間的消息進行聚合作爲本次拉取的結果一次性返回給客戶端。不同客戶端各自維護自己的偏移量，以此來避免服務端對於客戶端的狀態維護。
客戶端與服務端的具體交互如圖所示，客戶端在加入聚合單元之後主動拉取，如果本次拉取攜帶的偏移量能夠從服務的環形隊列中獲取到聚合消息，那麼就將消息回調給業務之後馬上進行下一次拉取操作。如果本次攜帶的偏移量已經位於環形隊列tail指針的位置，那麼服務端將不做任何響應，客戶端等待本次拉取超時之後開始下一次拉取操作，重複該流程直至客戶端離開該聚合單元。與此同時，業務服務端如果有消息需要推送，則通過RPC的方式發送給Pike服務端，消息處理模塊將執行消息分級策略過濾之後的有效消息插入環形隊列。
4.2 消息保序
Pike 1.0在設計之初就只適用於消息推送的場景，而Pike 2.0在其基礎上演進爲雙向消息投遞服務，即不僅支持下行的消息推送，還支持上行的消息投遞。Pike 2.0在上行的消息投遞方面進一步拓展了消息保序的功能，這裏的消息保序主要包含兩個層面的含義，首先每一個業務客戶端發送的消息都最大程度地到達同一個業務服務器，其次這些消息是按照客戶端發送的時序一致地到達該業務服務器。
4.2.1 粘性會話
爲了使每一個業務客戶端發送的消息都最大程度地到達同一個業務服務器，Pike 2.0引入了粘性會話的概念。粘性會話指的是同一客戶端連接上的消息固定轉發至某一特定的業務方機器處理，客戶端斷連重連後，保持新連接上的消息仍轉發至該業務機器。
粘性會話可以歸納爲如下的流程。首次業務登錄的時候Pike 2.0服務器會利用負載均衡算法選擇一臺業務服務器，並將該業務服務器的路由標識通過業務登錄結果通知客戶端並保存，之後如果通道狀態穩定的話所有的上行消息就都會投遞到該業務服務器。如果期間通道狀態波動出現斷連的情況，Pike 2.0在發起重連之後會重新進行業務登錄，這一次業務登錄會將之前保存的路由標識重新上報給Pike 2.0服務器，這樣Pike 2.0服務器就會通過路由標識重新綁定該業務服務器。當然，如果路由標識指示的業務服務器已經停止提供服務，那麼Pike 2.0服務器會重新通過負載均衡算法選擇新的一臺業務服務器，同時客戶端會獲取到新的路由標識，之後的邏輯重複該過程直至Pike 2.0客戶端退出。
4.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。
5 Pike 2.0穩定性保障
5.1 Pike 2.0監控體系
Pike 2.0依賴美團監控平臺Raptor完成監控體系建設，服務端和客戶端都建設了各自完善的指標監控。Pike 2.0客戶端通過利用Raptor的端到端指標能力和自定義指標能力輸出了超過10+個監控指標來實時監控Pike系統，這些指標覆蓋通道建立、消息投遞、業務登錄、系統異常等多維度。在實時指標監控的基礎上Pike 2.0針對不同指標配置了報警閾值，以推送消息爲例，如果特定App的大盤數據在每分鐘的上下波動幅度超過10%，那麼Raptor系統就會向Pike項目組成員推送告警信息。
基於所有Raptor監控指標，Pike 2.0提煉核心SLA指標如下：
| 指標名稱 | 指標定義 | 指標意義 |
|---|---|---|
| 上行消息投遞成功率 | 上行消息從發送到收到ACK的成功率 | 代表Pike 2.0業務上行消息投遞能力 |
| 上行消息投遞延時 | 上行消息投遞RTT | 同上 |
| 下行消息投遞成功率 | 下行消息從發送到收到ACK的成功率 | 代表Pike 2.0業務下行消息投遞能力 |
| 下行消息投遞延時 | 下行消息投遞RTT | 同上 |
| 通道可用耗時 | 通道從建立到可以傳遞消息的時間 | 代表Pike 2.0通道建連能力 |
| 日均消息量 | 日均投遞的上下行消息總量 | 代表Pike 2.0產品服務能力 |
Pike 2.0會定期輸出基於核心SLA指標的大盤數據報表，同時可以基於App、業務類型、網絡類型等多維度對數據進行篩選以滿足不同用戶對於指標數據的需求。
5.2 Pike 2.0個案用戶追蹤
監控體系能從全局的角度反映Pike 2.0系統穩定性，針對個案用戶，Pike管理平臺提供完整的鏈路追蹤信息。
每個Pike 2.0連接都由唯一標識Token來區分，通過該唯一標識Token在Pike管理平臺的“連接嗅探”模塊主動探測便能獲得對應連接上所有信令的交互流程。如圖所示，流程中明確標註了客戶端建立連接、發起鑑權、綁定別名等信令，點擊對應信令可以跳轉信令詳情進一步查看該信令所攜帶的信息，再結合SDK埋點在美團日誌服務Logan的離線日誌就可以快速發現並定位問題。
6 Pike 2.0建設成果
截至2021年6月，Pike共接入業務200+個，日均消息總量約50億+，Pike 2.0消息到達率>99.5%（相比Pike 1.0提升0.4% ），Pike 2.0平均端到端延時<220ms（相比Pike 1.0減少約37%）。
部分應用案例：
- 直播場景消息服務方案。支持直播業務的直播互動功能，具備了支持同時在線百萬級別大型直播的能力。
- 消息推送、Feed流預加載等實時觸達方案。支持營銷類、控制類等業務消息實時推送，業務消息到達率最高提升10%，長連通道建聯耗時減少5%。
- IoT設備接入方案。支持取餐櫃業務IoT接入能力，幫助業務消息到達率從98.4%提升到99.6%。
- 小遊戲場景消息投遞方案。支持美團小遊戲場景通信能力，消息到達率達到99.8%以上，上行延時低至195ms。
7 總結與未來展望
Pike在美團應用廣泛，目前主要集中在實時觸達、互動直播、移動同步等業務場景，隨着公司業務的快速發展，Pike對可用性、易用性、可擴展性提出了更高要求，希望提升各種業務場景下的網絡體驗，因此Pike未來的規劃重點主要是：提供多端、多場景下的網絡通信方案，不斷完善協議生態，在各種應用場景下對抗複雜網絡。
- 拓展Pike通用基礎能力，提升通道性能。通過優化保序方案，提供專用通道，優化傳輸協議等方式，進一步提升吞吐量和穩定性，降低推送時延。
- 建設Pike IoT，提供IoT接入層方案。爲公司內物聯網應用場景（單車、充電寶、取餐櫃、智能頭盔、倉庫、門店設備等）提供統一的IoT接入層解決方案，支持多種接入協議（HTTP、MQTT、CoAP等），爲業務提供安全可靠的設備連接通信能力。
- 優化弱網環境通信體驗。在移動端和IoT端基於美團自研MQUIC網絡協議庫，探索Pike over QUIC，在桌面端探索WebTransport技術，通過全面支持QUIC協議，提升弱網大包場景下的網絡性能，降低長尾分佈的請求耗時。
作者簡介
健午、佳猛、陸凱、馮江等，均來自美團基礎技術部-前端技術中心。
招聘信息
閱讀美團技術團隊更多技術文章合集
前端 | 算法 | 後端 | 數據 | 安全 | 運維 | iOS | Android | 測試
| 在公衆號菜單欄對話框回覆【2020年貨】、【2019年貨】、【2018年貨】、【2017年貨】等關鍵詞，可查看美團技術團隊歷年技術文章合集。
