58到家多端消息整合之路

經歷野蠻發展階段后，58到家存在眾多消息收發場景及不同技術。案例分享總結多個業務場景下消息收發的難點與挑戰，梳理各項技術的特點，結合實際業務及研發需求，構建了一套通用消息投遞方案。方案建立統一的端到端、端到服務器、服務器到端的消息通道，對業務方屏蔽不同技術的差異，提供消息到達率等核心指標的監控統計。實現業務線能夠快速接入各類消息服務的目標。

實踐的具體過程、步驟和方法可供同行借鑒。

一．問題的提出

1.1  到家業務復雜

58到家是一家做生活服務類O2O業務的創業公司，勢頭很猛，業務發展迅速。公司自營三大業務，家政、麗人、速運。找保潔、保姆、月嫂可以使用家政業務；做個指甲美個容可以使用麗人業務；拉貨搬家可以找速運。除了三大自營業務，還有非常重要的開放平臺，商家在開放平臺上發布服務，用戶消費服務。開放平臺涵蓋了你能想到的各種內容，從開鎖到換燈泡，從送花到健身。

1.2  消息需求多樣

眾多業務和不同場景，給消息系統帶來很大的挑戰。比如速運業務，用戶需要搬家，拿出手機查看司機位置，下單，司機搶單，運送完成后計算路程，這些業務都要求及時高效的傳遞訂單及經緯度信息；又比如用戶資產變化或者優惠券即將到期，系統需要給用戶推送提示信息，而到家的用戶不會一直開著58到家的應用，我們需要低成本有效地將提示類信息送達用戶；開放平臺里，用戶需要跟商家溝通，了解提供的服務或商品的具體情況，系統需要確保用戶商家不同時在線的情況下能夠實現交流。

1.3 重復開發嚴重

為了應對業務的快速發展，初創公司都會怎么容易實現怎么來。結果建設了眾多的消息系統，散落在各個業務線。有的用MQTT，有的用HTTP，有的用個推，有的用米推，消息協議不一致，互聯互通存在障礙。研發人員需要熟悉多套消息系統，研發效率低下，研發質量很難保證。

圖1：混亂的消息系統

因此迫切需要建設一個統一的消息系統，對研發人員屏蔽細節，提升開發效率，提高開發質量。

二．解決思路

2.1  統一消息平臺

統一消息平臺主要包括四大部分，TCP消息系統、推送通道、策略中心、端。

圖2：統一消息平臺架構

1、TCP消息系統。自研的基于TCP協議的消息系統，支持端到端、端到服務器、服務器到端的消息傳遞，具有性能高、開銷小等優點。用于逐步替換五花八門的消息系統。

2、推送通道，強化推送消息能力。整合個推、米推、APNS、微信、短信等消息推送方式。自研的TCP消息系統也是一種消息推送方式。

3、策略中心，人為配置消息投遞的策略，可以根據消息可達率，或者業務場景需要，進行修改。

4、端，主要是指移動端。統一消息平臺提供統一的SDK，支持移動端與消息平臺服務器的交互。同時，端還包括微信、手機短信等用戶常用的接收消息的軟件。

在這個架構下，業務研發人員只需關注端上的統一SDK，和服務器端統一消息交互接口。其他的精力都可以放在處理業務邏輯上。

2.2  TCP消息系統

TCP消息系統的整體結構如下圖。

圖3：TCP消息系統

虛線框描述了TCP消息系統的功能組成。包括接入層（msg-gate）、邏輯層（msg-logic）、ip配置（ipconfig）、路由緩存（redis）四大部分。

1、接入層

圖中的msg-gate模塊是接入層，主要功能包括，

連接整流：維護與客戶端的海量TCP長連接，將外界海量TCP長連接整流為少量與后端msg-logic的TCP長連接。

安全信道：建立安全的TCP信道，加密與解密。

初步攻防：實施初步的anti-attack策略，限速策略，消息體大小限制。

消息投遞：將msg-logic投遞過來的消息發送給客戶端。

2、邏輯層

msg-logic模塊叫邏輯層，主要功能包括，

連接驗證（可以理解為在消息系統中登錄）。

APP向app-server發送消息的接口，可以理解為C2S接口。

app-server向APP發送消息的接口，包括單發和群發。

3、Redis緩存

緩存業務客戶端的連接狀態，連到哪一個msg-gate，連接狀態是否正常。用于向用戶推送消息時，提供消息路由。

4、ipconfig

為客戶端提供接入層ip地址，實現負載均衡、業務分組等功能。

2.2.1 Session管理

接入層保持著與海量客戶端的TCP長連接，需要實時跟蹤這些連接的狀態，TCP消息系統將客戶端的連接信息保存在接入層的內存中，叫做session。session記錄了客戶端對應的channel，可以理解為socketid，標記了登錄狀態isLogin，登錄時間loginTime，和最后活躍時間lastKeepAliveTime。

session需要狀態及信息需要實時維護，維護時機主要包括一下內容。

1、登錄、登出很好理解，需要修改Peer的登錄狀態。

2、Keepalive，心跳需要修改session的最后活躍時間。

3、Logic層請求踢人，來自后端的踢人請求。

4、接入層對某個客戶端的限速、客戶端發消息速度過快會被認為是攻擊行為，強制斷開連接。

5、socket可能發生異常，非法消息，通不過消息頭校驗，也需要斷開連接。

6、還有一種情況，客戶端連接到服務器后，沒有傳輸任何消息，這種情況有可能是網絡原因造成的，也有可能是疑似攻擊行為。我們需要定時遍歷所有session，發現長時間不活躍的session，將它清除掉。

這么多的讀寫維護session的場景，歸結起來有3類。1、通過業務屬性用戶id定位session；2、通過channel定位session；3、遍歷session。

下圖是session結構圖。

圖4：session結構圖

session管理主要包括3個結構，中間的Map是保存Peer的核心數據結構，可以通過channelid檢索到session。右側的雙向Map保存uid和channelid的映射關系，雙向Map可以根據uid檢索channelid，也可以根據channelid檢索uid，為什么用雙向結構，后續會提到。

左側的隊列保存有連接到接入服務器的所有客戶端的channelid，隊列采用無鎖實現方式，定時任務逐條遍歷session，不會產生鎖，不影響性能。

定時任務從隊列讀出channelid1，判斷channel1是否正常，如果發現長時間不活躍，認為對應的客戶端沒有連接到接入服務器。需要將HashMap中的session清除，同時需要將BiMap對應的數據清除，清楚BiMap數據的時候，需要根據channelid定位數據，這就是雙向Map的用處。

其他的根據uid或者channelid定位并修改數據的請求也不會產生鎖，不會對性能構成影響。

有一個點要注意，在新增或刪除Peer的時候，需要做好相應的并發控制。

2.2.1 離線消息

離線消息拉取方式如下圖。

圖5：離線消息邏輯

為了防止一次拉取過多離線消息，拉取方式采用分頁拉取的方式。每次拉取10條。

1、APP端拉取離線消息，傳遞三個參數uid=123, msgid=100,size=10，uid表示是誰拉取消息，msgid是App現有消息中最大的消息id，消息id遞增，最大的消息id表示App端最后收到的消息數據。如果App端還沒有收到過消息，msgid傳0。

2、消息服務器收到拉取離線消息請求，msgid=100表明App端已經收到msgid=100之前的數據。將msgid=100之前的離線消息刪除。

3、檢索msgid=100之后的10條消息，假設msid從101到110。

4、消息服務器將這10條數據返回App端，完成1頁離線數據拉取。

5、如果APP端拉取到的離線消息條數不為0，則APP端將msgid=110做為參數再次請求拉取離線消息，直到服務端不返回數據結束離線消息拉取。

2.3  推送通道

58到家的用戶不會經常打開App， TCP消息系統很可能無法及時把消息送達用戶。類似限時搶購類的活動，必須在某個時間把消息投送給用戶，單靠TCP消息系統無法滿足需求。

統一消息推送通道，整合TCP、個推、米推、APNS、微信、短信等消息推送方式，盡最大可能確保消息送達用戶。統一推送通道結構如下圖

圖6：統一推送通道結構圖

推送通道，核心工作是完成消息到端的推送。不同的通道，推送時所需參數不完全一致，推送通道能夠獲取相應通道所需的參數。

圖7：推送通道及參數

2.4  策略中心

策略中心支持推送策略的人工配置及自動調整。舉兩個例子。假設我是健身愛好者，我用App通過TCP消息系統跟健身房老板溝通價格，結果健身房老板沒有打開58到家的App，收不到我的消息，這時系統可以根據策略中心的策略，通過APNS或者個推、米推向健身房老板發出消息提醒；再比如，某人確定找一個美甲師做美甲，這個信息對美甲師非常重要，策略中心的一個投遞策略很可能是push的同時給美甲師發送短信。

策略中心結構如下圖，

圖8：策略中心結構圖

策略配置模塊。人為配置消息推送的策略，便于根據消息可達率，或者業務場景需要，修改消息推送策略。比如前面提到的產品來回調整推送通道，就可以通過這個模塊進行配置。

策略解析，解析推送消息策略。讀取配置的消息發送策略。同時根據手機類型選擇推送通道，小米手機用米推、其他android手機用個推、蘋果用apns。

如果是多個通道推送，需要確認是 并行推送（比如資產變化，同時通過APNS、微信推送）或順序推送（根據ACK情況、如速運訂單，優先通過TCP通道推送，如果規定時間沒有收到ACK，則通過個推或米推推送）。

計時調度器，根據推送策略，定時探查消息緩存，判斷消息是否已送達。依據推送策略進行其他渠道推送或反饋消息是否送達結果。

ACK檢測，判斷消息是否送達，通過哪個通道送達。

2.5  端

提供統一的移動端開發SDK來支持整個移動端的消息傳輸。端上SDK有四個核心要點，保活、消息去重、TCP重連隨機延時和電量控制。

保活：確保在各種型號手機上，TCP鏈接可用，是消息傳輸是否正常的最關鍵因素。

消息去重，采用了內存隊列+SQLite的技術實現，確保在復雜網絡環境下，呈現給用戶的消息不出現重復情況。

TCP重連隨機延時，避免TCP接入服務器意外掛掉后，大量客戶端同時發起對其他服務器的連接請求導致雪崩。

控制耗電量是移動開發都需要注意的問題。

三．實踐過程

3.1 抽象到家復雜的消息場景

面對復雜的業務，首先需要進行抽象建模，下圖展示了消息類型的劃分。

圖9：消息分類

圖中上邊一排的手機和筆記本圖標在消息系統中我們叫它為端，或者客戶端，英文用client表示。中間云的圖標是我們的統一消息平臺。下邊的服務器圖標，是業務服務器，英文用sever表示。

到家各種復雜的消息需求，可以抽象為3類。

1、C2S,client to server。例如速運司機手機端，需要將開車軌跡的經緯度近實時的傳遞到速運后臺服務器，服務器才能根據行車軌跡計算車費。

2、S2C,server to client。用戶有張保潔優惠券快到期了，服務器需要通知用戶。這類由服務器主動發起推送的消息。

3、C2C，client to client。開放平臺業務，用戶需要咨詢商家問題，將問題發給商家，商家進行回答。

3.2目標明確，循序漸進

1、系統需要實現的目標明確。統一消息平臺在規劃之初已經考慮到了支持3類消息，同時預見到需要強化消息推送能力以及靈活配置能力。總體結構圖包括的四大部分，TCP消息系統，推送通道，策略中心，端，確保能夠達成最終目標。

2、循序漸進地推動實施。具體實施中，首先研發TCP消息系統，解決大量消息傳輸的痛點，并逐步推廣到各個業務；接著整合多種推送通道，增加推送策略。實施階段的每一步，都能讓業務線看到成效，消息平臺也得以在這個過程中快速推廣。