摘要：封宇到家架構(gòu)師。主要負(fù)責(zé)到家消息系統(tǒng)以及門戶等公司戰(zhàn)略級產(chǎn)品研發(fā)。消息服務(wù)器收到拉取離線消息請求，表明端已經(jīng)收到之前的數(shù)據(jù)。統(tǒng)一消息推送通道，整合個(gè)推米推微信短信等消息推送方式，盡最大可能確保消息送達(dá)用戶。

本篇文章內(nèi)容來自2016年TOP100summit 58到家架構(gòu)師封宇的案例分享。
編輯：Cynthia
2017年11月9-12日北京國家會(huì)議中心第六屆TOP100summit，留言評論有機(jī)會(huì)獲得免費(fèi)體驗(yàn)票。

封宇：58到家架構(gòu)師。主要負(fù)責(zé)到家消息系統(tǒng)以及H5門戶等公司戰(zhàn)略級產(chǎn)品研發(fā)。在消息設(shè)計(jì)，流量增長等方面經(jīng)驗(yàn)豐富。

導(dǎo)讀：經(jīng)歷野蠻發(fā)展階段后，58到家存在眾多消息收發(fā)場景及不同技術(shù)。本案例總結(jié)多個(gè)業(yè)務(wù)場景下消息收發(fā)的難點(diǎn)與挑戰(zhàn)，梳理各項(xiàng)技術(shù)的特點(diǎn)，結(jié)合實(shí)際業(yè)務(wù)及研發(fā)需求，構(gòu)建了一套通用消息投遞方案。方案建立統(tǒng)一的端到端、端到服務(wù)器、服務(wù)器到端的消息通道，對業(yè)務(wù)方屏蔽不同技術(shù)的差異，提供消息到達(dá)率等核心指標(biāo)的監(jiān)控統(tǒng)計(jì)。實(shí)現(xiàn)業(yè)務(wù)線能夠快速接入各類消息服務(wù)的目標(biāo)。
本文將介紹本次實(shí)踐的具體過程、步驟和方法，供同行借鑒。

一．問題的提出

1.1 到家業(yè)務(wù)復(fù)雜
58到家是一家做生活服務(wù)類O2O業(yè)務(wù)的創(chuàng)業(yè)公司，自成立至今，業(yè)務(wù)發(fā)展迅速。公司自營三大業(yè)務(wù)：家政、麗人、速運(yùn)。找保潔、保姆、月嫂可以使用家政業(yè)務(wù)；指甲美容等可以使用麗人業(yè)務(wù)；拉貨搬家可以找速運(yùn)。除了三大自營業(yè)務(wù)，還有非常重要的開放平臺(tái)，商家在開放平臺(tái)上發(fā)布服務(wù)、用戶可以在平臺(tái)消費(fèi)服務(wù)。開放平臺(tái)涵蓋了你能想到的各種內(nèi)容，從開鎖到換燈泡，從送花到健身。

1.2 消息需求多樣
眾多業(yè)務(wù)和不同場景給消息系統(tǒng)帶來很大的挑戰(zhàn)。
比如速運(yùn)業(yè)務(wù)：用戶需要搬家，拿出手機(jī)查看司機(jī)位置、下單、司機(jī)搶單、運(yùn)送完成后計(jì)算路程，這些業(yè)務(wù)都要求及時(shí)高效地傳遞訂單及經(jīng)緯度信息；
又比如用戶資產(chǎn)變化或者優(yōu)惠券即將到期，系統(tǒng)需要給用戶推送提示信息，而用戶不會(huì)一直開著58到家的應(yīng)用，我們需要低成本有效地將提示類信息送達(dá)用戶；
再比如開放平臺(tái)里，用戶需要跟商家溝通，了解提供的服務(wù)或商品的具體情況，系統(tǒng)需要確保用戶商家不同時(shí)在線的情況下能夠?qū)崿F(xiàn)交流。

1.3 重復(fù)開發(fā)嚴(yán)重
為了應(yīng)對業(yè)務(wù)的快速發(fā)展，初創(chuàng)公司都會(huì)選擇最容易實(shí)現(xiàn)的方法和框架。58到家也一樣，結(jié)果建設(shè)了眾多的消息系統(tǒng)（如圖1），散落在各個(gè)業(yè)務(wù)線。有的用MQTT、有的用HTTP、有的用個(gè)推、有的用米推，消息協(xié)議不一致，互聯(lián)互通存在障礙。研發(fā)人員需要熟悉多套消息系統(tǒng)，研發(fā)效率低下，研發(fā)質(zhì)量很難保證。

圖1：混亂的消息系統(tǒng)

因此迫切需要建設(shè)一個(gè)統(tǒng)一的消息系統(tǒng)，對研發(fā)人員屏蔽細(xì)節(jié)，提升開發(fā)效率、提高開發(fā)質(zhì)量。

二．解決思路

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

圖2：統(tǒng)一消息平臺(tái)架構(gòu)
● TCP消息系統(tǒng)
自研的基于TCP協(xié)議的消息系統(tǒng)，支持端到端、端到服務(wù)器、服務(wù)器到端的消息傳遞，具有性能高、開銷小等優(yōu)點(diǎn)。用于逐步替換五花八門的消息系統(tǒng)。
● 推送通道
強(qiáng)化推送消息能力。整合個(gè)推、米推、APNS、微信、短信等消息推送方式。自研的TCP消息系統(tǒng)也是一種消息推送方式。
● 策略中心
人為配置消息投遞的策略，可以根據(jù)消息可達(dá)率或者業(yè)務(wù)場景需要進(jìn)行修改。
● 端

主要是指移動(dòng)端。統(tǒng)一消息平臺(tái)提供統(tǒng)一的SDK，支持移動(dòng)端與消息平臺(tái)服務(wù)器的交互。同時(shí)，端還包括微信、手機(jī)短信等用戶常用的接收消息的軟件。
在這個(gè)架構(gòu)下，業(yè)務(wù)研發(fā)人員只需關(guān)注端上的統(tǒng)一SDK和服務(wù)器端統(tǒng)一消息交互接口，其他的精力都可以放在處理業(yè)務(wù)邏輯上。

2.2 TCP消息系統(tǒng)
TCP消息系統(tǒng)的整體結(jié)構(gòu)如圖3所示。

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

接入層

圖中的msg-gate模塊是接入層，主要功能包括：
● 連接整流：維護(hù)與客戶端的海量TCP長連接，將外界海量TCP長連接整流為少量與后端msg-logic的TCP長連接。
● 安全信道：建立安全的TCP信道，加密與解密。
● 初步攻防：實(shí)施初步的anti-attack策略，限速策略，消息體大小限制。
● 消息投遞：將msg-logic投遞過來的消息發(fā)送給客戶端。

邏輯層
msg-logic模塊叫邏輯層，主要功能包括：
● 連接驗(yàn)證（可以理解為在消息系統(tǒng)中登錄）。
● APP向app-server發(fā)送消息的接口，可以理解為C2S接口。
● app-server向APP發(fā)送消息的接口，包括單發(fā)和群發(fā)。

Redis緩存
緩存業(yè)務(wù)客戶端的連接狀態(tài)，連到哪一個(gè)msg-gate，連接狀態(tài)是否正常。用于向用戶推送消息時(shí)，提供消息路由。
ipconfig
為客戶端提供接入層ip地址，實(shí)現(xiàn)負(fù)載均衡、業(yè)務(wù)分組等功能。

2.2.1 Session管理
接入層保持著與海量客戶端的TCP長連接，需要實(shí)時(shí)跟蹤這些連接的狀態(tài)，TCP消息系統(tǒng)將客戶端的連接信息保存在接入層的內(nèi)存中，叫做session。session記錄了客戶端對應(yīng)的channel，可以理解為socketid，標(biāo)記了登錄狀態(tài)isLogin、登錄時(shí)間loginTime，和最后活躍時(shí)間lastKeepAliveTime。

session需要狀態(tài)、信息需要實(shí)時(shí)維護(hù)，維護(hù)時(shí)機(jī)主要包括以下內(nèi)容：
● 登錄、登出很好理解，需要修改Peer的登錄狀態(tài)。
● Keepalive，心跳需要修改session的最后活躍時(shí)間。
● Logic層請求踢人，來自后端的踢人請求。
● 接入層對某個(gè)客戶端的限速、客戶端發(fā)消息速度過快會(huì)被認(rèn)為是攻擊行為，強(qiáng)制斷開連接。
● socket可能發(fā)生異常，非法消息，通不過消息頭校驗(yàn)，也需要斷開連接。

還有一種情況，客戶端連接到服務(wù)器后，沒有傳輸任何消息，這種情況有可能是網(wǎng)絡(luò)原因造成的，也有可能是疑似攻擊行為。我們需要定時(shí)遍歷所有session，發(fā)現(xiàn)長時(shí)間不活躍的session，將它清除掉。

這么多的讀寫維護(hù)session的場景，歸結(jié)起來有3類：
● 通過業(yè)務(wù)屬性用戶id定位session；
● 通過channel定位session；
● 遍歷session。

圖4：session結(jié)構(gòu)圖

如圖4所示，session管理主要包括3個(gè)結(jié)構(gòu)：
● 中間的Map是保存Peer的核心數(shù)據(jù)結(jié)構(gòu)，可以通過channelid檢索到session；
●右側(cè)的雙向Map保存uid和channelid的映射關(guān)系，雙向Map可以根據(jù)uid檢索channelid，也可以根據(jù)channelid檢索uid，為什么用雙向結(jié)構(gòu)，后續(xù)會(huì)提到。
● 左側(cè)的隊(duì)列保存有連接到接入服務(wù)器的所有客戶端的channelid，隊(duì)列采用無鎖實(shí)現(xiàn)方式，定時(shí)任務(wù)逐條遍歷session，不會(huì)產(chǎn)生鎖，不影響性能。

定時(shí)任務(wù)從隊(duì)列讀出channelid1，判斷channel1是否正常，如果發(fā)現(xiàn)長時(shí)間不活躍，認(rèn)為對應(yīng)的客戶端沒有連接到接入服務(wù)器。需要將HashMap中的session清除，同時(shí)需要將BiMap對應(yīng)的數(shù)據(jù)清除，清除BiMap數(shù)據(jù)的時(shí)候，需要根據(jù)channelid定位數(shù)據(jù)，這就是雙向Map的用處。
其他的根據(jù)uid或者channelid定位并修改數(shù)據(jù)的請求也不會(huì)產(chǎn)生鎖，不會(huì)對性能構(gòu)成影響。
有一個(gè)點(diǎn)要注意：在新增或刪除Peer的時(shí)候，需要做好相應(yīng)的并發(fā)控制。

2.2.1 離線消息

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

圖5：離線消息邏輯

為了防止一次拉取過多離線消息，拉取方式采用分頁拉取的方式。每次拉取10條。
● APP端拉取離線消息，傳遞三個(gè)參數(shù)uid=123,msgid=100,size=10，uid表示是誰拉取消息，msgid是App現(xiàn)有消息中最大的消息id，消息id遞增，最大的消息id表示App端最后收到的消息數(shù)據(jù)。如果App端還沒有收到過消息，msgid傳0。
● 消息服務(wù)器收到拉取離線消息請求，msgid=100表明App端已經(jīng)收到msgid=100之前的數(shù)據(jù)。將msgid=100之前的離線消息刪除。
● 檢索msgid=100之后的10條消息，假設(shè)msid從101到110。
● 消息服務(wù)器將這10條數(shù)據(jù)返回App端，完成1頁離線數(shù)據(jù)拉取。
● 如果APP端拉取到的離線消息條數(shù)不為0，則APP端將msgid=110做為參數(shù)再次請求拉取離線消息，直到服務(wù)端不返回?cái)?shù)據(jù)結(jié)束離線消息拉取。

2.3 推送通道
58到家的用戶不會(huì)經(jīng)常打開App，TCP消息系統(tǒng)很可能無法及時(shí)把消息送達(dá)用戶。類似限時(shí)搶購類的活動(dòng)，必須在某個(gè)時(shí)間把消息投送給用戶，單靠TCP消息系統(tǒng)無法滿足需求。
統(tǒng)一消息推送通道，整合TCP、個(gè)推、米推、APNS、微信、短信等消息推送方式，盡最大可能確保消息送達(dá)用戶。統(tǒng)一推送通道結(jié)構(gòu)如圖6所示。

圖6：統(tǒng)一推送通道結(jié)構(gòu)圖
推送通道的核心工作是完成消息到端的推送。不同的通道，推送時(shí)所需參數(shù)不完全一致，推送通道能夠獲取相應(yīng)通道所需的參數(shù)（如圖7所示）。

圖7：推送通道及參數(shù)

2.4 策略中心

策略中心支持推送策略的人工配置及自動(dòng)調(diào)整。

舉兩個(gè)例子。
第一個(gè)例子：假設(shè)我是健身愛好者，我用App通過TCP消息系統(tǒng)跟健身房老板溝通價(jià)格，結(jié)果健身房老板沒有打開58到家的App，收不到我的消息，這時(shí)系統(tǒng)可以根據(jù)策略中心的策略，通過APNS或者個(gè)推、米推向健身房老板發(fā)出消息提醒；
第二個(gè)例子：某人確定找一個(gè)美甲師做美甲，這個(gè)信息對美甲師非常重要，策略中心的一個(gè)投遞策略很可能是push的同時(shí)給美甲師發(fā)送短信。

策略中心結(jié)構(gòu)如圖8。

圖8：策略中心結(jié)構(gòu)圖

策略配置模塊。人為配置消息推送的策略，便于根據(jù)消息可達(dá)率，或者業(yè)務(wù)場景需要，修改消息推送策略。比如前面提到的產(chǎn)品來回調(diào)整推送通道，就可以通過這個(gè)模塊進(jìn)行配置。

策略解析，解析推送消息策略。讀取配置的消息發(fā)送策略，同時(shí)根據(jù)手機(jī)類型選擇推送通道，小米手機(jī)用米推、其他android手機(jī)用個(gè)推、蘋果用apns。

如果是多個(gè)通道推送，需要確認(rèn)是并行推送（比如資產(chǎn)變化，同時(shí)通過APNS、微信推送）或順序推送（根據(jù)ACK情況、如速運(yùn)訂單，優(yōu)先通過TCP通道推送，如果規(guī)定時(shí)間沒有收到ACK，則通過個(gè)推或米推推送）。

計(jì)時(shí)調(diào)度器，根據(jù)推送策略定時(shí)探查消息緩存，判斷消息是否已送達(dá)。依據(jù)推送策略進(jìn)行其他渠道推送或反饋消息是否送達(dá)結(jié)果。

ACK檢測，判斷消息是否送達(dá)，通過哪個(gè)通道送達(dá)。

2.4 端

提供統(tǒng)一的移動(dòng)端開發(fā)SDK來支持整個(gè)移動(dòng)端的消息傳輸。端上SDK有四個(gè)核心要點(diǎn)：?；睢⑾⑷ブ?、TCP重連隨機(jī)延時(shí)和電量控制。

● ?；睿捍_保在各種型號(hào)手機(jī)上TCP鏈接可用是消息傳輸是否正常的最關(guān)鍵因素。
● 消息去重：采用了內(nèi)存隊(duì)列+SQLite的技術(shù)實(shí)現(xiàn)，確保在復(fù)雜網(wǎng)絡(luò)環(huán)境下，呈現(xiàn)給用戶的消息不出現(xiàn)重復(fù)情況。
● TCP重連隨機(jī)延時(shí)：避免TCP接入服務(wù)器意外掛掉后，大量客戶端同時(shí)發(fā)起對其他服務(wù)器的連接請求導(dǎo)致雪崩。
● 控制耗電量是移動(dòng)開發(fā)都需要注意的問題。

三．實(shí)踐過程

3.1 抽象到家復(fù)雜的消息場景
面對復(fù)雜的業(yè)務(wù)，首先需要進(jìn)行抽象建模，圖9展示了消息類型的劃分。

圖9：消息分類

圖中上邊一排的手機(jī)和筆記本圖標(biāo)在消息系統(tǒng)中被稱為端，或者客戶端，英文用client表示。中間云的圖標(biāo)是我們的統(tǒng)一消息平臺(tái)。下邊的服務(wù)器圖標(biāo)是業(yè)務(wù)服務(wù)器，英文用sever表示。

58到家各種復(fù)雜的消息需求，可以抽象為3類。
● C2S,client to server
例如速運(yùn)司機(jī)手機(jī)端，需要將開車軌跡的經(jīng)緯度近實(shí)時(shí)的傳遞到速運(yùn)后臺(tái)服務(wù)器，服務(wù)器才能根據(jù)行車軌跡計(jì)算車費(fèi)。
● S2C,server to client
用戶有張保潔優(yōu)惠券快到期了，服務(wù)器需要通知用戶。這類由服務(wù)器主動(dòng)發(fā)起推送的消息。
● C2C，client to client
開放平臺(tái)業(yè)務(wù)，用戶需要咨詢商家問題，將問題發(fā)給商家，商家進(jìn)行回答。

3.2目標(biāo)明確，循序漸進(jìn)

● 系統(tǒng)需要實(shí)現(xiàn)的目標(biāo)明確。
統(tǒng)一消息平臺(tái)在規(guī)劃之初已經(jīng)考慮到了支持3類消息，同時(shí)預(yù)見到需要強(qiáng)化消息推送能力以及靈活配置能力。總體結(jié)構(gòu)圖包括的四大部分：TCP消息系統(tǒng)、推送通道、策略中心、端，確保能夠達(dá)成最終目標(biāo)。
● 循序漸進(jìn)地推動(dòng)實(shí)施。
具體實(shí)施中，首先研發(fā)TCP消息系統(tǒng)，解決大量消息傳輸?shù)耐袋c(diǎn)，并逐步推廣到各個(gè)業(yè)務(wù)；接著整合多種推送通道，增加推送策略。實(shí)施階段的每一步，都能讓業(yè)務(wù)線看到成效，消息平臺(tái)也得以在這個(gè)過程中快速推廣。

四、效果評價(jià)和總結(jié)

在統(tǒng)一消息平臺(tái)之前各個(gè)團(tuán)隊(duì)自行研發(fā)消息收發(fā)功能，重復(fù)投入，代碼質(zhì)量差，維護(hù)沒有延續(xù)性。統(tǒng)一后，一次投入，經(jīng)過持續(xù)改進(jìn)和維護(hù)，大大提高研發(fā)效率，提升系統(tǒng)質(zhì)量。具體表現(xiàn)在以下方面。
● 提供移動(dòng)端SDK，統(tǒng)一端上開發(fā)接口。
●服務(wù)器端接口,統(tǒng)一服務(wù)器側(cè)開發(fā)接口。
● 強(qiáng)化消息推送能力，不開App也能送達(dá)用戶。
● 增加消息推送策略，滿足業(yè)務(wù)需求變化。

11月9-12日，北京國家會(huì)議中心，第六屆TOP100全球軟件案例研究峰會(huì)，58到家資深架構(gòu)師柳忠偉將分享《O2O系統(tǒng)架構(gòu)演進(jìn)》

TOP100全球軟件案例研究峰會(huì)已舉辦六屆，甄選全球軟件研發(fā)優(yōu)秀案例，每年參會(huì)者達(dá)2000人次。包含產(chǎn)品、團(tuán)隊(duì)、架構(gòu)、運(yùn)維、大數(shù)據(jù)、人工智能等多個(gè)技術(shù)專場，現(xiàn)場學(xué)習(xí)谷歌、微軟、騰訊、阿里、百度等一線互聯(lián)網(wǎng)企業(yè)的最新研發(fā)實(shí)踐。

更多TOP100案例信息及日程請前往[官網(wǎng)]查閱。4天時(shí)間集中分享2017年最值得學(xué)習(xí)的100個(gè)研發(fā)案例實(shí)踐。
免費(fèi)體驗(yàn)票申請入口