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

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

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

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

一．問題的提出

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

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

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

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

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

二．解決思路

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1 離線消息

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

圖5：離線消息邏輯

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

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

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

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

2.4 策略中心

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

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

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

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

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

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

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

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

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

2.4 端

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

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

三．實踐過程

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

圖9：消息分類

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

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

3.2目標明確，循序漸進

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

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

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

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

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

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