但凡接手過IM系統(tǒng)的同學(xué)都繞不開“消息收發(fā)流程方案選型”這道坎。選型選得好后面開發(fā)順風(fēng)順?biāo)x型選錯(cuò)了改起來就是傷筋動(dòng)骨。市面上聊IM的文章很多但大多停留在“高并發(fā)IM”“消息推送”這種概念層面真正把一條消息從發(fā)送端走到接收端這個(gè)過程掰開了講清楚并且告訴你怎么在不同場景下做取舍的內(nèi)容其實(shí)并不多。這篇文章我想從我自己實(shí)際帶團(tuán)隊(duì)做IM項(xiàng)目的經(jīng)驗(yàn)出發(fā)把消息收發(fā)流程里最關(guān)鍵的幾個(gè)決策點(diǎn)、技術(shù)細(xì)節(jié)和踩坑記錄完整講一遍。無論你是在調(diào)研自研IM、準(zhǔn)備集成第三方SDK還是純粹想弄清楚網(wǎng)頁版IM這種成熟產(chǎn)品背后的設(shè)計(jì)邏輯這篇內(nèi)容都能給你一個(gè)相對(duì)清晰的選型參考。我盡量不堆術(shù)語遇到繞不開的概念會(huì)用生活里的類比去解釋也會(huì)把一些參數(shù)和配置直接列出來方便你照著評(píng)估。1. 消息收發(fā)流程的整體設(shè)計(jì)與方案選型思路1.1 為什么先要捋清楚消息收發(fā)流程再做選型我見過不少團(tuán)隊(duì)上來就糾結(jié)用哪個(gè)框架、哪個(gè)中間件、哪個(gè)云廠商結(jié)果聊了半天發(fā)現(xiàn)連自己要做的是“單聊為主”還是“群聊為主”都沒定下來。說實(shí)話IM系統(tǒng)最核心的復(fù)雜度根本不在于某個(gè)具體組件而在于消息從A端發(fā)出最終如何可靠、有序、低延遲地到達(dá)B端這條鏈路上的每個(gè)環(huán)節(jié)。消息收發(fā)流程往大了說無非就是發(fā)送端→接入層→消息處理服務(wù)→存儲(chǔ)層→推送通道→接收端。但這條鏈路里的任何一環(huán)出了問題表現(xiàn)到用戶側(cè)就是“消息發(fā)了沒收到”“消息重復(fù)了”“消息亂序了”“離線消息丟了”這些非常傷體驗(yàn)的問題。方案選型本質(zhì)上是在為這條鏈路里每個(gè)環(huán)節(jié)選擇最合適的處理方式而不是單純挑一個(gè)“聽起來很厲害”的技術(shù)棧。所以我建議所有剛啟動(dòng)IM項(xiàng)目的團(tuán)隊(duì)第一件事不是寫代碼而是把下面這份問題清單逐項(xiàng)過一遍用戶規(guī)模預(yù)期是多少是幾百人的內(nèi)部工具還是百萬日活的公網(wǎng)產(chǎn)品消息是單聊為主還是群聊為主群規(guī)模上限是多少人在線率和離線率大概什么比例有多少消息需要走離線存儲(chǔ)對(duì)消息丟失的容忍度有多高哪些消息絕對(duì)不能丟對(duì)消息順序的約束是全局嚴(yán)格有序還是只需要會(huì)話內(nèi)有序團(tuán)隊(duì)有多少人可以投入開發(fā)有充裕的時(shí)間做底層自研嗎是否需要多端同步Web、App、桌面端這些問題的答案會(huì)直接決定你在“自研IM”和“接入第三方”之間的傾向也會(huì)決定你在長連接方案、消息存儲(chǔ)方案、離線消息處理方案上的具體取舍。1.2 一條消息從發(fā)出到被看到的完整鏈路把IM的消息收發(fā)流程簡化以后幾乎所有方案都逃不開下面這條鏈路發(fā)送端→接入網(wǎng)關(guān)→消息處理服務(wù)→消息存儲(chǔ)→推送/拉取模塊→接收端發(fā)送端用戶敲完消息點(diǎn)擊發(fā)送客戶端先把消息寫入本地?cái)?shù)據(jù)庫同時(shí)生成一個(gè)本地的臨時(shí)消息ID通常叫clientMsgId然后通過長連接WebSocket或自研TCP協(xié)議把消息上行到服務(wù)端。接入網(wǎng)關(guān)負(fù)責(zé)維持海量客戶端的連接處理連接鑒權(quán)、心跳、斷線重連、流量控制。網(wǎng)關(guān)一般不處理業(yè)務(wù)邏輯只做協(xié)議解析和轉(zhuǎn)發(fā)這樣才能做到無狀態(tài)水平擴(kuò)展。消息處理服務(wù)拿到上行消息后先校驗(yàn)發(fā)送者權(quán)限、做內(nèi)容安全過濾然后生成服務(wù)端消息ID寫入存儲(chǔ)再?zèng)Q定走“實(shí)時(shí)推送”還是“離線存儲(chǔ)”的分支。消息存儲(chǔ)一般分兩部分一份是發(fā)送者和接收者的會(huì)話消息記錄用于歷史消息拉取一份是在線/離線狀態(tài)索引用于判斷消息要不要走推送。推送/拉取模塊接收端在線時(shí)通過長連接實(shí)時(shí)下行推送消息接收端離線時(shí)把消息存入離線消息表等接收端下次上線時(shí)通過增量拉取同步下來?？吹竭@里你應(yīng)該能理解為什么“方案選型”會(huì)被單獨(dú)拿出來當(dāng)成一個(gè)話題來聊。因?yàn)檫@條鏈路上每一個(gè)環(huán)節(jié)都有多種技術(shù)實(shí)現(xiàn)路徑不同路徑組合起來就是一套完全不同的系統(tǒng)形態(tài)。比如接入網(wǎng)關(guān)用Netty手寫長連接還是直接用WebSocket網(wǎng)關(guān)組件消息存儲(chǔ)用MySQL還是NoSQL離線消息用推拉結(jié)合還是純拉取群聊用寫擴(kuò)散還是讀擴(kuò)散——這些都是選型點(diǎn)。1.3 方案選型的三個(gè)關(guān)鍵分流點(diǎn)在線/離線、單聊/群聊、可靠性等級(jí)在我做過的IM項(xiàng)目里有三個(gè)分流點(diǎn)決定了80%的技術(shù)選型走向建議你在選型前先把這三個(gè)問題定下來。第一個(gè)分流點(diǎn)收到消息時(shí)接收方在線還是離線。在線和離線的處理邏輯完全不同。在線用戶適合“推送優(yōu)先”服務(wù)端直接把消息通過長連接懟給客戶端客戶端收到后回ACK鏈路短、時(shí)效性好。離線用戶則必須把消息落庫等用戶上線時(shí)再拉取。如果你的產(chǎn)品是典型的“在線協(xié)同工具”在線率高那你可以把重心放在長連接推送的穩(wěn)定性和可靠性上如果你的產(chǎn)品像郵件一樣“離線為主”那消息存儲(chǔ)和拉取策略反而更重要。第二個(gè)分流點(diǎn)消息是單聊還是群聊群聊規(guī)模上限是多少。單聊消息的處理很簡單一條消息只涉及兩個(gè)用戶寫一份存儲(chǔ)、推送一次就夠了。但群聊尤其是人數(shù)在幾百上千的千人大群處理邏輯會(huì)完全不一樣。這里面有一個(gè)經(jīng)典的“寫擴(kuò)散”和“讀擴(kuò)散”之爭后面我會(huì)單獨(dú)展開。選型時(shí)一定要明確群的上限規(guī)模因?yàn)樗苯記Q定了你消息表的存儲(chǔ)模型和推送扇出量。第三個(gè)分流點(diǎn)對(duì)可靠性和時(shí)序的要求等級(jí)。IM和日志系統(tǒng)不太一樣它對(duì)消息的可靠性要求很高。我不能接受“這條消息丟了算了”這種設(shè)計(jì)思路因?yàn)橛脩袅奶煊涗泚G了產(chǎn)品口碑直接崩塌。但可靠性也有分級(jí)私聊消息必須零丟失、強(qiáng)順序群聊的普通消息可以允許輕微的延遲抖動(dòng)但也不能丟像系統(tǒng)通知這類消息偶爾重發(fā)一次用戶也不會(huì)太在意。不同可靠性等級(jí)會(huì)直接影響消息確認(rèn)ACK、重試、冪等機(jī)制的設(shè)計(jì)復(fù)雜度所以這也是選型前必須想清楚的事。2. 消息收發(fā)流程中的核心細(xì)節(jié)與關(guān)鍵技術(shù)點(diǎn)2.1 消息模型設(shè)計(jì)消息ID、時(shí)序與去重消息模型是整個(gè)IM的“地基”地基沒打牢后面整個(gè)流程都會(huì)受影響。我在項(xiàng)目里踩過最典型的坑就是把消息ID設(shè)計(jì)和業(yè)務(wù)需求割裂開導(dǎo)致排障時(shí)非常痛苦。一套合理的消息模型通常要包含幾個(gè)關(guān)鍵字段msg_id服務(wù)端生成的全局限一消息ID用于消息在整個(gè)系統(tǒng)中的唯一標(biāo)識(shí)。client_msg_id客戶端生成的消息ID一般用UUID用于客戶端冪等去重。session_id會(huì)話ID標(biāo)識(shí)這條消息屬于哪個(gè)單聊或群聊會(huì)話。sender_id/receiver_id發(fā)送者與接收者標(biāo)識(shí)。msg_type文本、圖片、語音、文件、系統(tǒng)消息等。content消息體內(nèi)容。status消息狀態(tài)如正常、撤回、被刪除。send_time/server_time客戶端發(fā)送時(shí)間和服務(wù)端接收時(shí)間。消息ID的生成方案我建議用Snowflake算法或者改造版的分段發(fā)號(hào)器。Snowflake的核心思想是用“時(shí)間戳機(jī)器ID序列號(hào)”拼出一個(gè)64位的整數(shù)ID全局趨勢(shì)遞增且不依賴中心化數(shù)據(jù)庫非常適合IM這種需要高并發(fā)生成分布式ID的場景。在我實(shí)際項(xiàng)目里消息ID生成還承擔(dān)了一個(gè)非常重要的職責(zé)作為消息排序的依據(jù)。所以服務(wù)端生成消息ID時(shí)必須保證同一個(gè)會(huì)話內(nèi)的消息ID順序與用戶發(fā)送順序一致。如果我們用Snowflake就要注意一個(gè)細(xì)節(jié)在同一毫秒內(nèi)序列號(hào)是遞增的能滿足同一發(fā)送端的順序但不同發(fā)送者在同一毫秒發(fā)到不同接入網(wǎng)關(guān)時(shí)后到達(dá)的消息可能拿到更小的ID導(dǎo)致群聊消息亂序。這個(gè)問題可以通過在消息處理服務(wù)里引入會(huì)話級(jí)串行化來解決后面我會(huì)講到。2.2 在線通道長連接推送與消息確認(rèn)在線消息的核心通道是長連接。現(xiàn)在Web端的主流方案就是WebSocketApp端一般用自研的TCP私有協(xié)議或者直接在TCP之上跑WebSocket協(xié)議。選型時(shí)不用過度糾結(jié)協(xié)議本身的優(yōu)劣更重要的是想清楚長連接上要承載哪些機(jī)制。長連接上必須承載的幾件事心跳機(jī)制客戶端和服務(wù)端需要定時(shí)互發(fā)心跳包保證連接不被中間網(wǎng)絡(luò)設(shè)備斷開同時(shí)讓服務(wù)端能感知客戶端是否還在線。心跳間隔一般建議15秒到30秒之間太頻繁耗電耗流量太稀疏又會(huì)導(dǎo)致服務(wù)端釋放連接不及時(shí)。上行消息客戶端發(fā)送消息時(shí)沿長連接發(fā)一個(gè)上行包服務(wù)端處理后返回一個(gè)“收到確認(rèn)”。下行推送服務(wù)端往接收端下行推送消息時(shí)需要攜帶服務(wù)端消息ID接收端成功落庫后返回ACK。推送回執(zhí)接收端對(duì)下行的每一條消息都需要回ACK服務(wù)端收到ACK后這條消息才算真正投遞成功。這就有意思了。很多人以為“服務(wù)端把消息發(fā)出去了”就是投遞成功實(shí)際上服務(wù)端必須等接收端回ACK后才能確認(rèn)。在我?guī)ы?xiàng)目時(shí)我會(huì)明確告訴團(tuán)隊(duì)成員ACK是消息可靠性的基石沒有ACK機(jī)制的消息推送本質(zhì)上就是發(fā)完不管的UDP。這也是為什么在線消息的流程總是比想象中要復(fù)雜一點(diǎn)——一條消息要先經(jīng)過“上行確認(rèn)”再經(jīng)過“下行確認(rèn)”兩次確認(rèn)缺一不可。2.3 離線消息如何“不丟不重不亂”離線消息的處理邏輯核心就一句話把該存的消息存下來等用戶上線時(shí)再拉給TA。但這句話落地沒那么簡單。離線消息通常按“用戶維度”存儲(chǔ)。比如A給B發(fā)了一條消息B離線了服務(wù)端會(huì)往B的離線消息表里插入一條記錄。B上線時(shí)客戶端會(huì)帶著自己本地最新的消息ID增量拉取服務(wù)端把B離線期間積累的所有消息按時(shí)間順序吐給B。這就是“離線拉取”模型。實(shí)現(xiàn)“不丟不重不亂”需要三塊配合不丟離線消息必須持久化到可靠存儲(chǔ)不能只放內(nèi)存?？梢允褂肕ySQL或者Redis落庫雙寫但關(guān)鍵點(diǎn)是消息一旦確認(rèn)寫入離線存儲(chǔ)就要考慮是否需要補(bǔ)償機(jī)制防止寫入失敗。不重客戶端拉取離線消息時(shí)如果網(wǎng)絡(luò)超時(shí)重試了一次可能同一批消息被拉了兩遍。解決方法是客戶端本地維護(hù)一個(gè)last_pulled_msg_id用冪等方式處理重復(fù)消息——本地收到了重復(fù)的msg_id直接跳過。不亂離線消息拉取必須按消息ID嚴(yán)格排序這里又回到消息ID設(shè)計(jì)的問題上。如果消息ID不是趨勢(shì)遞增的離線拉取排序就會(huì)很頭疼。離線消息還有一個(gè)細(xì)節(jié)容易被忽略離線消息的保留期。有些IM產(chǎn)品只保留最近30天的離線消息超過30天直接丟棄讓用戶登錄后從云端歷史消息里拉取。這種策略可以在不犧牲體驗(yàn)的前提下控制離線表的膨脹我覺得非常實(shí)用。2.4 群聊消息的寫擴(kuò)散與讀擴(kuò)散之爭群聊是IM里最能體現(xiàn)技術(shù)深度的地方尤其當(dāng)群人數(shù)上千以后消息收發(fā)的流程設(shè)計(jì)會(huì)直接決定系統(tǒng)能不能撐得住。群聊有兩種經(jīng)典的消息分發(fā)模型寫擴(kuò)散發(fā)送時(shí)擴(kuò)散一條群消息發(fā)到服務(wù)端后服務(wù)端把這條消息復(fù)制N份分別寫入群里每個(gè)成員的收件箱。好處是接收端拉取時(shí)邏輯簡單查詢效率高壞處是群越大寫入放大越恐怖。一個(gè)1000人的群一條消息要寫1000份如果一個(gè)群很活躍存儲(chǔ)量和寫入壓力會(huì)直線上升。讀擴(kuò)散接收時(shí)擴(kuò)散群消息只存儲(chǔ)一份掛在群會(huì)話下。群成員上線拉消息時(shí)再去群會(huì)話里同步屬于自己那條時(shí)間線之后的消息。好處是寫入量小群里幾千人大幾百人緩存無壓力壞處是接收端邏輯復(fù)雜需要知道“上次同步到哪了”而且全量拉取場景比如新用戶進(jìn)群可能出現(xiàn)性能瓶頸。在實(shí)際選型時(shí)我一般建議這樣權(quán)衡群人數(shù) ≤ 200可以直接考慮寫擴(kuò)散因?yàn)閷?shí)現(xiàn)和排查最簡單用戶體驗(yàn)好。群人數(shù) 200 ~ 2000寫擴(kuò)散容易放大寫壓力但也不是不能用關(guān)鍵看群的活躍度?？梢栽趯憯U(kuò)散基礎(chǔ)上做“活躍成員才寫收件箱非活躍成員讀擴(kuò)散”的混合模式。群人數(shù) 2000建議認(rèn)真考慮讀擴(kuò)散且配合Redis緩存群時(shí)間線盡量讓拉取命中緩存而不是打存儲(chǔ)。這里我想到一個(gè)生活化的類比。寫擴(kuò)散相當(dāng)于你發(fā)一條微信到群里群主把消息挨個(gè)私發(fā)給每個(gè)人確保大家都能收到讀擴(kuò)散相當(dāng)于你發(fā)一條公告到公告欄誰想看誰就走到公告欄前自己看。前者的體驗(yàn)好但跑腿多后者的跑腿少但對(duì)看公告的人有要求。2.5 消息可靠性ACK、重試與冪等的組合拳聊透了在線推送和離線存儲(chǔ)可以進(jìn)入消息可靠性這個(gè)話題了。我在給團(tuán)隊(duì)做方案評(píng)審時(shí)經(jīng)常掛在嘴邊的一句話是消息不可靠的根源往往不是某一個(gè)環(huán)節(jié)掛了而是各個(gè)環(huán)節(jié)之間缺少配合。一條消息從發(fā)送端到接收端可能在任何一環(huán)丟失?？蛻舳松闲袝r(shí)網(wǎng)絡(luò)斷了服務(wù)端處理時(shí)宕機(jī)了推送時(shí)連接斷了接收端回ACK時(shí)原連接斷了。每一環(huán)都可能出問題所以可靠性不是靠某一個(gè)“保險(xiǎn)”就能保證的必須靠ACK、重試、冪等的組合拳上行階段客戶端發(fā)消息后如果一段時(shí)間內(nèi)沒收到服務(wù)端的確認(rèn)就自動(dòng)重發(fā)但重發(fā)時(shí)要帶上相同的client_msg_id這樣服務(wù)端能識(shí)別出“這條消息我處理過了”直接返回上一次的確認(rèn)避免重復(fù)入庫。下行階段服務(wù)端推送消息給接收端后接收端要回ACK。如果服務(wù)端沒收到ACK會(huì)走一個(gè)定時(shí)重推邏輯但重推不能無休止地進(jìn)行下去一般有最大次數(shù)和衰減策略。冪等客戶端本地要有按msg_id去重的機(jī)制保證同樣的消息即便被推送多次界面上也只顯示一條。服務(wù)端寫入時(shí)也要做冪等比如通過唯一索引約束client_msg_id防止重試導(dǎo)致的重復(fù)寫入。這里我想額外提醒一個(gè)容易忽略的點(diǎn)ACK本身的丟失也是一種正?，F(xiàn)象不要把它當(dāng)成異常去報(bào)警。我在初期做可靠性模塊時(shí)一度把“推送了消息但沒收回ACK”全部列為異常結(jié)果每天晚上被誤報(bào)警淹沒。實(shí)際上客戶端可能只是切換到后臺(tái)被系統(tǒng)凍結(jié)了等下次打開App才會(huì)補(bǔ)ACK。正確的做法是ACK超時(shí)重推容忍延遲而不是立刻認(rèn)定為故障。3. 不同場景下的方案選型對(duì)比3.1 自研IM vs 集成第三方SDK成本、周期與掌控力每次聊到IM方案選型團(tuán)隊(duì)里都繞不開“到底要不要自研”這個(gè)問題。說實(shí)話這個(gè)決策沒有標(biāo)準(zhǔn)答案取決于你的團(tuán)隊(duì)規(guī)模、業(yè)務(wù)屬性和產(chǎn)品定位。自研IM的優(yōu)勢(shì)非常明顯完全可控。消息收發(fā)流程的每一個(gè)細(xì)節(jié)都掌握在自己手里想做消息雙刪、自定義表情、特殊消息類型、深度性能優(yōu)化都沒有障礙。長期來看自研IM不會(huì)產(chǎn)生按量計(jì)費(fèi)的成本規(guī)模大了以后邊際成本更低。但自研IM的代價(jià)也很真實(shí)開發(fā)周期長技術(shù)棧要求高。一個(gè)能穩(wěn)定運(yùn)行的消息收發(fā)系統(tǒng)至少需要長連接服務(wù)、消息存儲(chǔ)、離線同步、多端一致性、消息可靠投遞這些模塊團(tuán)隊(duì)里如果沒有幾個(gè)精通網(wǎng)絡(luò)編程和分布式系統(tǒng)的同學(xué)很容易在上線后被各種偶發(fā)問題搞得焦頭爛額。集成第三方IM SDK或直接使用成熟的IM產(chǎn)品比如海貍IM這類專門做IM服務(wù)的產(chǎn)品或者類似CSDN盒子提供的網(wǎng)頁版IM能力最大的好處就是開箱即用。登錄、消息收發(fā)、群組、離線消息、多端同步這些能力直接調(diào)接口就行團(tuán)隊(duì)可以把精力全部放在自己的業(yè)務(wù)邏輯上。我的建議是畫一條線來判斷如果你的IM只是業(yè)務(wù)里的一個(gè)輔助模塊不是核心競爭壁壘直接接成熟方案不要再自己重復(fù)造輪子。如果IM本身就是你的核心產(chǎn)品且你對(duì)數(shù)據(jù)隱私、定制化體驗(yàn)有極高的要求那就要認(rèn)認(rèn)真真考慮自研否則業(yè)務(wù)發(fā)展到后期第三方方案的限制會(huì)成為天花板。3.2 高并發(fā)IM場景下的選型要點(diǎn)“高并發(fā)im”這個(gè)詞幾乎快被聊爛了但很多人聊的是“怎么堆機(jī)器”而不是“怎么設(shè)計(jì)消息收發(fā)流程以支撐高并發(fā)”。實(shí)際上高并發(fā)對(duì)消息收發(fā)流程的影響主要在三個(gè)環(huán)節(jié)。第一環(huán)是接入層。高并發(fā)意味著海量長連接同時(shí)掛載。方案選型時(shí)要重點(diǎn)考慮網(wǎng)關(guān)服務(wù)能不能橫向擴(kuò)展客戶端重連時(shí)能不能負(fù)載均衡到不同網(wǎng)關(guān)節(jié)點(diǎn)同時(shí)保證消息不錯(cuò)亂分布式網(wǎng)關(guān)的會(huì)話信息怎么同步我一般建議把網(wǎng)關(guān)設(shè)計(jì)成無狀態(tài)服務(wù)會(huì)話數(shù)據(jù)放在Redis或者內(nèi)存網(wǎng)格里這樣網(wǎng)關(guān)擴(kuò)縮容都很容易。第二環(huán)是消息處理服務(wù)。高并發(fā)下消息處理服務(wù)必須支持多實(shí)例部署但這里有一個(gè)沖突點(diǎn)同一會(huì)話內(nèi)的消息必須有序處理。我在項(xiàng)目里的做法是按session_id對(duì)消息做一致性哈希把同一個(gè)會(huì)話的消息路由到固定的處理實(shí)例上這樣既實(shí)現(xiàn)了并行處理又能保住會(huì)話內(nèi)的順序。第三環(huán)是存儲(chǔ)層。高并發(fā)場景下MySQL單表存消息必然扛不住。方案選型時(shí)要預(yù)先設(shè)計(jì)好分庫分表策略比如按session_id做哈希分表或者按月分表。Redis用來做熱點(diǎn)消息緩存和在線狀態(tài)存儲(chǔ)但注意Redis不是可靠存儲(chǔ)關(guān)鍵消息還是要落庫。我的經(jīng)驗(yàn)是高并發(fā)不是靠某一個(gè)“神器”解決的而是靠每一層的橫向擴(kuò)展和合理的路由策略疊加出來的。3.3 網(wǎng)頁版IM的選型觀察從海貍IM、CSDN盒子這類產(chǎn)品說起網(wǎng)頁版IM是很多業(yè)務(wù)團(tuán)隊(duì)會(huì)優(yōu)先考慮的形態(tài)因?yàn)椴恍枰脩粝螺dApp打開瀏覽器就能聊。做網(wǎng)頁版IM方案選型上有兩類路徑一類是用開源WebSocket框架自己搭服務(wù)端另一類是直接集成第三方IM產(chǎn)品像海貍IM這類面向業(yè)務(wù)場景的IM服務(wù)以及CSDN盒子提供的網(wǎng)頁版IM組件。自建Web端IM的優(yōu)勢(shì)是靈活整個(gè)收發(fā)流程能被你完全掌控。Web端用WebSocket做長連接自然能復(fù)用我之前講的在線推送、ACK確認(rèn)、離線拉取那套流程。劣勢(shì)是Web端的使用環(huán)境比App復(fù)雜得多瀏覽器兼容性、移動(dòng)端網(wǎng)絡(luò)切換、頁面刷新后的連接重建、同賬號(hào)多標(biāo)簽頁互踢這些都是在做方案評(píng)估時(shí)要充分考慮的。集成第三方網(wǎng)頁版IM產(chǎn)品最大價(jià)值是把消息收發(fā)流程整體外包出去。你不需要關(guān)心長連接怎么?；?、離線消息怎么存儲(chǔ)、多端怎么同步SDK內(nèi)部已經(jīng)把這些做完了。如果你對(duì)IM不是強(qiáng)依賴深度定制這種方案會(huì)用很小的成本達(dá)到不錯(cuò)的效果。我在評(píng)估這類方案時(shí)通常不會(huì)只看宣傳語而是重點(diǎn)追問幾件事消息可靠性怎么樣是否支持ACK確認(rèn)和離線消息補(bǔ)償歷史消息能拉多遠(yuǎn)數(shù)據(jù)是否屬于我方可以導(dǎo)出嗎高并發(fā)時(shí)有沒有限流策略超賣或者擴(kuò)容怎么收費(fèi)消息內(nèi)容是否有合規(guī)審查和內(nèi)容安全能力無論是自建還是集成網(wǎng)頁版IM的選型關(guān)鍵都在于拉齊你的業(yè)務(wù)訴求和方案的真實(shí)能力別只看“能收發(fā)消息”這個(gè)表面。3.4 開源方案與SaaS服務(wù)的取舍開源是很多技術(shù)團(tuán)隊(duì)在IM選型時(shí)會(huì)考慮的中間路線。用開源的IM框架可以省掉從零開始的巨大工作量同時(shí)又能基于源碼做二次開發(fā)保留一定程度的可掌控性。這里我推薦兩個(gè)選型方向大家可以根據(jù)團(tuán)隊(duì)背景來判斷如果團(tuán)隊(duì)Java技術(shù)棧可以關(guān)注基于Netty生態(tài)的長連接框架自己搭建接入網(wǎng)關(guān)和消息處理服務(wù)配合MySQL、Redis和MQ完成整套收發(fā)流程。這種方式本質(zhì)上是“半自研”把最復(fù)雜的長連接層交給框架業(yè)務(wù)層自己實(shí)現(xiàn)。如果團(tuán)隊(duì)希望更快速地落地可以直接選用成熟的IM服務(wù)端軟件部署后通過API接入自己的業(yè)務(wù)系統(tǒng)。這種方案省事但要注意開源軟件的許可證規(guī)范以及社區(qū)活躍度和后續(xù)維護(hù)風(fēng)險(xiǎn)。開源方案的隱含成本很容易被低估導(dǎo)入代碼只是第一步后續(xù)的部署、監(jiān)控、bug修復(fù)、性能優(yōu)化全部得自己來。我見過不少團(tuán)隊(duì)導(dǎo)入了一套開源IM服務(wù)端后連跑通都費(fèi)了很大的勁因?yàn)槿鄙倥涮椎倪\(yùn)維文檔和排障經(jīng)驗(yàn)。所以我的一個(gè)經(jīng)驗(yàn)準(zhǔn)則是選擇開源方案時(shí)盡量選擇社區(qū)活躍、文檔完善、且有一定知名度的項(xiàng)目別用那種只發(fā)布過一版就再也沒人維護(hù)的“死碼”。4. 實(shí)操一套可落地的選型決策與部署過程4.1 選型決策的評(píng)估維度與打分表與其拍腦袋選型不如把選型變成一套可復(fù)盤的打分過程。我在實(shí)際項(xiàng)目里整理過一張IM方案選型評(píng)估表這里分享出來供參考評(píng)估維度權(quán)重占比自研方案評(píng)分第三方產(chǎn)品評(píng)分說明業(yè)務(wù)匹配度25%高中核心業(yè)務(wù)與IM的耦合程度交付周期15%低高上線速度是否關(guān)鍵長期成本15%中低按量收費(fèi) vs 內(nèi)部投入技術(shù)掌控力20%高低深度定制與排障能力可靠性保證15%取決于團(tuán)隊(duì)取決于產(chǎn)品必須驗(yàn)證不能盲信生態(tài)與維護(hù)10%需評(píng)估需評(píng)估社區(qū)/廠商的生命力打分時(shí)要注意權(quán)重分配一定要根據(jù)自己團(tuán)隊(duì)的具體情況來定別照搬我的表。比如你的團(tuán)隊(duì)完全沒有網(wǎng)絡(luò)編程經(jīng)驗(yàn)?zāi)恰凹夹g(shù)掌控力”再高的自研方案也很難拿到高分。我的習(xí)慣是讓開發(fā)、產(chǎn)品和運(yùn)維負(fù)責(zé)人一起打分打完分后把差距最大的幾項(xiàng)拿出來單獨(dú)討論這樣選型結(jié)論才真正站得住腳。4.2 典型消息收發(fā)架構(gòu)部署再往后就是架構(gòu)部署層面的實(shí)操了。我以一個(gè)中等規(guī)模的Web IM項(xiàng)目為例說一下核心組件的部署組合。接入網(wǎng)關(guān)部署2個(gè)以上實(shí)例對(duì)外通過負(fù)載均衡暴露WebSocket端口。網(wǎng)關(guān)內(nèi)實(shí)現(xiàn)連接管理、心跳超時(shí)檢測(cè)、消息編碼解碼。建議把網(wǎng)關(guān)做成無狀態(tài)節(jié)點(diǎn)節(jié)點(diǎn)宕機(jī)后客戶端能自動(dòng)重連到其他節(jié)點(diǎn)。消息處理服務(wù)一組無狀態(tài)業(yè)務(wù)服務(wù)通過一致性哈希把同一會(huì)話的消息分發(fā)到同一實(shí)例處理。服務(wù)內(nèi)完成消息ID生成、內(nèi)容過濾、存儲(chǔ)寫入、推送路由。消息存儲(chǔ)MySQL按會(huì)話分庫分表存歷史消息Redis緩存活躍會(huì)話的近期消息和在線狀態(tài)。為了讓離線拉取更高效可以加上一層消息索引表用組合索引user_id msg_id去查。消息推送模塊作為獨(dú)立的推送服務(wù)訂閱消息隊(duì)列里的下行消息根據(jù)在線狀態(tài)決定是走長連接實(shí)時(shí)推送還是寫離線表。與網(wǎng)關(guān)之間通過內(nèi)部RPC或消息隊(duì)列通信。消息隊(duì)列解耦消息處理和消息推送。消息處理服務(wù)寫入存儲(chǔ)成功后把下行推送任務(wù)投遞到消息隊(duì)列推送模塊消費(fèi)隊(duì)列執(zhí)行推送。這樣即使推送模塊瞬時(shí)吞吐不夠消息也不會(huì)立刻丟失。這套架構(gòu)的好處是每一層都能獨(dú)立擴(kuò)容故障域隔離清晰。消息處理服務(wù)再怎么慢也不會(huì)把網(wǎng)關(guān)的連接管理拖垮推送模塊再怎么重試也不會(huì)阻塞消息寫入。4.3 核心參數(shù)與配置要點(diǎn)部署只是第一步真正能讓系統(tǒng)轉(zhuǎn)得穩(wěn)的是那些很少被寫在文檔里的參數(shù)調(diào)優(yōu)。我挑幾個(gè)核心配置說下我的落地經(jīng)驗(yàn)。心跳超時(shí)時(shí)間建議設(shè)置為30秒發(fā)送一次心跳如果服務(wù)端90秒內(nèi)沒收到任何心跳或業(yè)務(wù)包就判定連接已死觸發(fā)資源回收。設(shè)置太短會(huì)導(dǎo)致移動(dòng)網(wǎng)絡(luò)下的頻繁重連設(shè)置太長又會(huì)占用大量無效連接。我之前調(diào)試桌面端IM時(shí)把超時(shí)從90秒提到120秒網(wǎng)絡(luò)切換場景下的斷線率明顯下降了。連接最大空閑數(shù)單機(jī)長連接數(shù)是有上限的因?yàn)槊總€(gè)連接都要占用文件描述符和內(nèi)存。一個(gè)普通的8核16G節(jié)點(diǎn)跑純WebSocket網(wǎng)關(guān)保守估計(jì)可以支撐5萬到8萬并發(fā)連接具體要看每連接的消息量和內(nèi)存占用。你要在選型時(shí)對(duì)峰值連接數(shù)有預(yù)估否則到了擴(kuò)容節(jié)點(diǎn)上限時(shí)消息收發(fā)的體驗(yàn)會(huì)斷崖式下降。離線消息拉取分頁大小用戶上線時(shí)如果離線期間積累了幾百條消息一次性全量拉取會(huì)超時(shí)。建議默認(rèn)分頁每頁50條到100條客戶端邊拉邊展示。另外要配合增量游標(biāo)msg_id做斷點(diǎn)續(xù)傳避免反復(fù)拉取重復(fù)數(shù)據(jù)。重試策略消息推送失敗后的重試間隔我習(xí)慣采用指數(shù)退避第一次1秒、第二次4秒、第三次16秒最多重試5次后轉(zhuǎn)入“待人工介入”狀態(tài)。不要用固定間隔高頻重試否則一個(gè)客戶端批量離線時(shí)服務(wù)端重試風(fēng)暴會(huì)把推送通道打爆。5. 常見問題與排查技巧實(shí)錄5.1 消息丟失從會(huì)話連接池到ACK機(jī)制的排查消息丟失是IM項(xiàng)目里最讓人頭疼的問題也是最常被報(bào)告的問題。我在帶項(xiàng)目時(shí)總結(jié)了一套排查路徑遇到“消息丟了”先別急著懷疑存儲(chǔ)按順序查這幾層查發(fā)送端客戶端發(fā)送后有沒有收到服務(wù)端上行確認(rèn)如果一直沒收到就是上行鏈路問題優(yōu)先查接入網(wǎng)關(guān)的連接狀態(tài)。查消息處理服務(wù)服務(wù)端有沒有接到上行消息接到后有沒有把消息寫入存儲(chǔ)這里的日志很容易斷層所以消息處理服務(wù)每一步都要打日志包括“收到上行”“寫入成功”“推送已投遞”。查推送模塊接收端在線時(shí)走推送離線時(shí)走拉取。如果消息寫入存儲(chǔ)成功但接收端一直沒收到很大概率是推送模塊消費(fèi)消息隊(duì)列失敗或者重試隊(duì)列發(fā)生了阻塞。查接收端接收端是否把消息成功落庫并回ACK有些時(shí)候消息其實(shí)已經(jīng)到了客戶端但客戶端的狀態(tài)展示有bug用戶就誤以為“沒收到”。排查消息丟失最關(guān)鍵的是全程日志鏈路要完整。我在項(xiàng)目里會(huì)在每條消息上帶一個(gè)trace_id從上行到下行全程攜帶這樣出現(xiàn)問題時(shí)能按trace_id一鍵串聯(lián)所有環(huán)節(jié)的日志。5.2 消息亂序時(shí)序約束與分段鎖消息亂序在群聊場景里尤其常見。我之前遇到過一個(gè)案例群里兩人幾乎同時(shí)發(fā)消息結(jié)果是后發(fā)送的那條先出現(xiàn)在接收端界面上用戶立刻就不滿意了。亂序的根源在于不同發(fā)送端的消息到了服務(wù)端后可能被不同的處理實(shí)例并發(fā)處理導(dǎo)致大號(hào)消息ID先被推送。要解決這個(gè)問題必須對(duì)同一個(gè)會(huì)話內(nèi)的消息處理做“串行化”。我在項(xiàng)目里的落地方式是給每個(gè)會(huì)話維護(hù)一把分布式分段鎖比如Redis鎖或者一致性哈希到單實(shí)例處理同一會(huì)話的消息必須串行分配消息ID和寫入存儲(chǔ)。但這里有個(gè)性能陷阱如果把“串行化”的范圍做得太大高并發(fā)場景下某些熱門群的吞吐會(huì)被卡住。我的優(yōu)化實(shí)踐是按session_id拆分成多個(gè)分段比如群聊按成員哈希分桶每個(gè)桶內(nèi)有自己的串行序列這樣既保證同一個(gè)發(fā)送者的消息有序又讓群消息整體的處理并行度不會(huì)太低。5.3 消息重復(fù)冪等表與唯一索引消息重復(fù)和消息丟失剛好相反但一樣傷體驗(yàn)。重復(fù)消息最容易出現(xiàn)在網(wǎng)絡(luò)超時(shí)重試的場景下客戶端發(fā)送時(shí)超時(shí)了于是重發(fā)了一次但其實(shí)第一次的消息已經(jīng)寫入了服務(wù)端。解決消息重復(fù)的核心就是冪等。服務(wù)端在寫入消息之前先查一下client_msg_id是否已經(jīng)存在。為了性能我會(huì)在Redis里存一個(gè)“最近已處理的消息ID集合”同時(shí)給數(shù)據(jù)庫加唯一索引兜底。這樣即使Redis數(shù)據(jù)被清了數(shù)據(jù)庫的唯一索引也能攔住重復(fù)寫入。接收端的重復(fù)展示問題則要靠客戶端的msg_id去重?？蛻舳耸盏揭粭l消息后把msg_id放進(jìn)本地去重集合界面上已經(jīng)展示過相同的msg_id就直接跳過。這里注意去重集合不能無限膨脹我一般建議只保留最近1000條消息的去重記錄更早的由業(yè)務(wù)邏輯保證。5.4 連接不穩(wěn)定心跳、重連與增量同步網(wǎng)頁版IM和移動(dòng)端IM都逃不過連接不穩(wěn)定的問題。網(wǎng)絡(luò)切換、瀏覽器休眠、路由器NAT超時(shí)都會(huì)導(dǎo)致長連接意外斷開。很多用戶反饋“消息要等一會(huì)才能收到”根因往往就是連接已經(jīng)斷了但客戶端沒感知到服務(wù)端也沒及時(shí)重推。針對(duì)這個(gè)問題我的落地經(jīng)驗(yàn)是三件事完善心跳的啟停策略頁面可見時(shí)保持正常心跳頁面切后臺(tái)時(shí)停止心跳但保留連接頁面恢復(fù)可見時(shí)立即發(fā)一個(gè)特殊的Ping包探測(cè)連接是否可用不可用就直接重連。重連后做增量補(bǔ)償客戶端重連成功后不能只依賴服務(wù)端后續(xù)推送而是要主動(dòng)拉取“斷線期間可能漏掉的消息”。具體做法是客戶端帶上本地最新一條消息的msg_id服務(wù)端返回從該ID以后的所有消息這樣即使連接斷掉期間推送全丟了也能通過增量拉取補(bǔ)回來。多端消息同步依賴增量游標(biāo)多端登錄時(shí)每端都要維護(hù)獨(dú)立的同步游標(biāo)。這個(gè)游標(biāo)不能只存內(nèi)存必須落本地?cái)?shù)據(jù)庫否則App一殺進(jìn)程上次同步到哪了就忘了。結(jié)尾做了幾年IM項(xiàng)目我最大的感受是消息收發(fā)流程方案選型這件事最后選的不是某一個(gè)“牛”組件而是選一套“適合自己團(tuán)隊(duì)和業(yè)務(wù)”的完整鏈路。你可能不需要一開始就把離線表分好、把分布式鎖做好但你必須在動(dòng)手前把每一個(gè)關(guān)鍵分叉點(diǎn)都過一遍腦子。哪怕今天先用最簡單的方案把功能跑通也要為明天的演進(jìn)留好接口和余地。最后分享一個(gè)我自己的實(shí)操心得無論是選型調(diào)研還是架構(gòu)落地我都建議先把“消息產(chǎn)線”上每個(gè)環(huán)節(jié)的日志和監(jiān)控指標(biāo)搭好再動(dòng)代碼。你多花在這一步上的時(shí)間在后面每次排障時(shí)會(huì)十倍百倍地還給你。畢竟IM這種東西用戶嘴上不說心里對(duì)消息及時(shí)性和可靠性的要求比任何功能點(diǎn)都要苛刻。