TOP100summit：【分享實錄-封宇】58到家多端消息整合之路

本篇文章內容來自2016年TOP100summit58到家架構師封宇的案例分享。

編輯：Cynthia

2017年11月9-12日北京國家會議中心第六屆TOP100summit，留言評論有機會得到免費體驗票。

封宇：58到家架構師。主要負責到家消息系統以及H5門戶等公司戰略級產品研發。在消息設計，流量增加等方面經驗豐富。

導讀：經歷野蠻發展階段後，58到家存在衆多消息收發場景及不一樣技術。本案例總結多個業務場景下消息收發的難點與挑戰，梳理各項技術的特色，結合實際業務及研發需求，構建了一套通用消息投遞方案。方案創建統一的端到端、端到服務器、服務器到端的消息通道，對業務方屏蔽不一樣技術的差別，提供消息到達率等核心指標的監控統計。實現業務線可以快速接入各種消息服務的目標。

本文將介紹本次實踐的具體過程、步驟和方法，供同行借鑑。

一．問題的提出

1.1 到家業務複雜

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

1.2 消息需求多樣

衆多業務和不一樣場景給消息系統帶來很大的挑戰。

好比速運業務：用戶須要搬家，拿出手機查看司機位置、下單、司機搶單、運送完成後計算路程，這些業務都要求及時高效地傳遞訂單及經緯度信息；

又好比用戶資產變化或者優惠券即將到期，系統須要給用戶推送提示信息，而用戶不會一直開着58到家的應用，咱們須要低成本有效地將提示類信息送達用戶；

再好比開放平臺裏，用戶須要跟商家溝通，瞭解提供的服務或商品的具體狀況，系統須要確保用戶商家不一樣時在線的狀況下可以實現交流。

1.3 重複開發嚴重

爲了應對業務的快速發展，初創公司都會選擇最容易實現的方法和框架。58到家也同樣，結果建設了衆多的消息系統（如圖1），散落在各個業務線。有的用MQTT、有的用HTTP、有的用個推、有的用米推，消息協議不一致，互聯互通存在障礙。研發人員須要熟悉多套消息系統，研發效率低下，研發質量很難保證。

圖1：混亂的消息系統

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

二．解決思路

2.1 統一消息平臺

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

圖2：統一消息平臺架構

●TCP消息系統

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

●推送通道

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

●策略中心

人爲配置消息投遞的策略，能夠根據消息可達率或者業務場景須要進行修改。

●端

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

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

2.2 TCP消息系統

TCP消息系統的總體結構如圖3所示。

圖3：TCP消息系統

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

接入層

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

●鏈接整流：維護與客戶端的海量TCP長鏈接，將外界海量TCP長鏈接整流爲少許與後端msg-logic的TCP長鏈接。

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

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

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

邏輯層

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

●鏈接驗證（能夠理解爲在消息系統中登陸）。

●APP向app-server發送消息的接口，能夠理解爲C2S接口。

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

Redis緩存

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

ipconfig

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

2.2.1 Session管理

接入層保持着與海量客戶端的TCP長鏈接，須要實時跟蹤這些鏈接的狀態，TCP消息系統將客戶端的鏈接信息保存在接入層的內存中，叫作session。session記錄了客戶端對應的channel，能夠理解爲socketid，標記了登陸狀態isLogin、登陸時間loginTime，和最後活躍時間lastKeepAliveTime。

session須要狀態、信息須要實時維護，維護時機主要包括如下內容：

●登陸、登出很好理解，須要修改Peer的登陸狀態。

●Keepalive，心跳須要修改session的最後活躍時間。

●Logic層請求踢人，來自後端的踢人請求。

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

●socket可能發生異常，非法消息，通不過消息頭校驗，也須要斷開鏈接。

還有一種狀況，客戶端鏈接到服務器後，沒有傳輸任何消息，這種狀況有多是網絡緣由形成的，也有多是疑似攻擊行爲。咱們須要定時遍歷全部session，發現長時間不活躍的session，將它清除掉。

這麼多的讀寫維護session的場景，歸結起來有3類：

●經過業務屬性用戶id定位session；

●經過channel定位session；

●遍歷session。

圖4：session結構圖

如圖4所示，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。

圖5：離線消息邏輯

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

●APP端拉取離線消息，傳遞三個參數uid=123,msgid=100,size=10，uid表示是誰拉取消息，msgid是App現有消息中最大的消息id，消息id遞增，最大的消息id表示App端最後收到的消息數據。若是App端尚未收到過消息，msgid傳0。

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

●檢索msgid=100以後的10條消息，假設msid從101到110。

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

●若是APP端拉取到的離線消息條數不爲0，則APP端將msgid=110作爲參數再次請求拉取離線消息，直到服務端不返回數據結束離線消息拉取。

2.3 推送通道

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

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

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

推送通道的核心工做是完成消息到端的推送。不一樣的通道，推送時所需參數不徹底一致，推送通道可以獲取相應通道所需的參數（如圖7所示）。

圖7：推送通道及參數

2.4 策略中心

策略中心支持推送策略的人工配置及自動調整。

舉兩個例子。

第一個例子：假設我是健身愛好者，我用App經過TCP消息系統跟健身房老闆溝通價格，結果健身房老闆沒有打開58到家的App，收不到個人消息，這時系統能夠根據策略中心的策略，經過APNS或者個推、米推向健身房老闆發出消息提醒；

第二個例子：某人肯定找一個美甲師作美甲，這個信息對美甲師很是重要，策略中心的一個投遞策略極可能是push的同時給美甲師發送短信。

策略中心結構如圖8。

圖8：策略中心結構圖

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

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

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

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

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

2.4 端

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

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

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

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

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

三．實踐過程

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

面對複雜的業務，首先須要進行抽象建模，圖9展現了消息類型的劃分。

圖9：消息分類

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

58到家各類複雜的消息需求，能夠抽象爲3類。

●C2S,client to server

例如速運司機手機端，須要將開車軌跡的經緯度近實時的傳遞到速運後臺服務器，服務器才能根據行車軌跡計算車費。

●S2C,server to client

用戶有張保潔優惠券快到期了，服務器須要通知用戶。這類由服務器主動發起推送的消息。

●C2C，client to client

開放平臺業務，用戶須要諮詢商家問題，將問題發給商家，商家進行回答。

3.2目標明確，按部就班

●系統須要實現的目標明確。

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

●按部就班地推進實施。

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

4、效果評價和總結

在統一消息平臺以前各個團隊自行研發消息收發功能，重複投入，代碼質量差，維護沒有延續性。統一後，一次投入，通過持續改進和維護，大大提升研發效率，提高系統質量。具體表如今如下方面。

●提供移動端SDK，統一端上開發接口。

●服務器端接口,統一服務器側開發接口。

●強化消息推送能力，不開App也能送達用戶。

●增長消息推送策略，知足業務需求變化。

11月9-12日，北京國家會議中心，第六屆TOP100全球軟件案例研究峯會，58到家資深架構師柳忠偉將分享《O2O系統架構演進》

TOP100全球軟件案例研究峯會已舉辦六屆，甄選全球軟件研發優秀案例，每一年參會者達2000人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場，現場學習谷歌、微軟、騰訊、阿里、百度等一線互聯網企業的最新研發實踐。

更多TOP100案例信息及日程請前往官網查閱。4天時間集中分享2017年最值得學習的100個研發案例實踐。

免費體驗票申請入口：www.top100summit.com/?qd=juejin