我到現(xiàn)在還記得第一次給IM項(xiàng)目寫(xiě)心跳包時(shí)踩的坑明明兩個(gè)客戶(hù)端都顯示在線消息卻延遲了好幾秒才送達(dá)。后來(lái)才明白所謂“在線”只是一個(gè)狀態(tài)真正讓消息秒達(dá)的是一條被小心維護(hù)著的長(zhǎng)連接。你每天打開(kāi)的微信、釘釘、淘寶客服窗口甚至直播間的彈幕本質(zhì)都屬于IM即時(shí)通信的范疇。它們的業(yè)務(wù)形態(tài)千差萬(wàn)別但底層要解決的問(wèn)題幾乎一致建立連接、傳輸消息、確認(rèn)狀態(tài)、保證不丟。這篇文章想從技術(shù)內(nèi)核講到生活應(yīng)用把一條聊天消息從發(fā)送到送達(dá)的完整鏈路、高并發(fā)場(chǎng)景下的架構(gòu)拆解、常見(jiàn)協(xié)議選型邏輯以及我在線上真實(shí)排查過(guò)的疑難雜癥一次講清楚。不管你剛轉(zhuǎn)后端的新人、負(fù)責(zé)客服系統(tǒng)的產(chǎn)品經(jīng)理還是單純好奇“消息為什么能秒達(dá)”都能從中找到對(duì)應(yīng)的干貨。1. 一條消息從發(fā)送到送達(dá)中間到底發(fā)生了什么IM系統(tǒng)表面上看起來(lái)就是“你發(fā)一句我收一句”但這句話落到工程實(shí)現(xiàn)上涉及的路由、存儲(chǔ)、推送、確認(rèn)環(huán)節(jié)比想象中多。先建立整條鏈路的整體認(rèn)知后面所有架構(gòu)話題都好聊了。1.1 消息鏈路一次發(fā)送背后牽動(dòng)了哪些服務(wù)假設(shè)A在微信里給B發(fā)了一句“晚上一起吃飯”從點(diǎn)擊發(fā)送按鈕開(kāi)始這條消息大致會(huì)經(jīng)歷四個(gè)環(huán)節(jié)客戶(hù)端編碼把消息內(nèi)容、目標(biāo)用戶(hù)、消息類(lèi)型等打包成約定好的二進(jìn)制或JSON結(jié)構(gòu)通過(guò)一條已經(jīng)建立好的長(zhǎng)連接發(fā)送到服務(wù)器網(wǎng)關(guān)。網(wǎng)關(guān)接入服務(wù)器端的第一道門(mén)負(fù)責(zé)識(shí)別這條連接屬于哪個(gè)用戶(hù)、消息該轉(zhuǎn)發(fā)給哪個(gè)后端服務(wù)同時(shí)做基礎(chǔ)的頻率限制和流量控制。業(yè)務(wù)邏輯處理這里才是“理解消息”的地方。判斷接收方是否合法、是不是好友關(guān)系、消息是否需要保存、是否命中敏感詞以及決定后續(xù)怎么推送給B。存儲(chǔ)與推送先把消息落庫(kù)一般會(huì)存兩份一份是會(huì)話維度一份是用戶(hù)維度然后判斷B當(dāng)前是否在線。在線就直接通過(guò)B的長(zhǎng)連接推過(guò)去不在線就寫(xiě)進(jìn)離線消息表等B下次登錄再拉取。絕大多數(shù)IM系統(tǒng)跑完這一整套流程只需要幾十毫秒。但延遲低不等于可靠所以A的客戶(hù)端不會(huì)盲目相信“發(fā)出去就完了”而是會(huì)等服務(wù)端返回一個(gè)確認(rèn)ack。收到ack才把消息狀態(tài)從“發(fā)送中”改成“已發(fā)送”如果超時(shí)沒(méi)收到客戶(hù)端就會(huì)自動(dòng)重發(fā)。這個(gè)設(shè)計(jì)理念可以類(lèi)比寄快遞你把包裹交給快遞員網(wǎng)關(guān)快遞員回執(zhí)確認(rèn)收件ack然后快遞公司內(nèi)部轉(zhuǎn)運(yùn)業(yè)務(wù)邏輯最終由收件地址附近的網(wǎng)點(diǎn)派送推送。如果派送失敗系統(tǒng)會(huì)先存放離線消息直到收件人出現(xiàn)。1.2 為什么必須保持長(zhǎng)連接輪詢(xún)的代價(jià)實(shí)在太高早期Web應(yīng)用沒(méi)有成熟的實(shí)時(shí)通信手段大家用的是輪詢(xún)前端每隔兩三秒發(fā)一個(gè)HTTP請(qǐng)求問(wèn)服務(wù)器“有新消息嗎”。這種方式在IM場(chǎng)景里有兩個(gè)致命問(wèn)題大部分請(qǐng)求都是“空輪詢(xún)”白占帶寬和服務(wù)器資源。消息到達(dá)后用戶(hù)最多只能延遲兩三秒感知談不上實(shí)時(shí)。所以IM系統(tǒng)普遍采用長(zhǎng)連接客戶(hù)端和服務(wù)器之間建立一條TCP連接連接建立后一直保持服務(wù)器可以隨時(shí)主動(dòng)把消息推給客戶(hù)端不需要客戶(hù)端反復(fù)詢(xún)問(wèn)。最直觀的理解就是打電話和寫(xiě)信的區(qū)別打電話是通路一直存在的全雙工通信寫(xiě)信是每次都要重新投遞的短連接。如今網(wǎng)頁(yè)端最常用的是WebSocket移動(dòng)端App則常見(jiàn)基于TCP的自定義長(zhǎng)連接比如微信早期就是基于自研的私有TCP協(xié)議來(lái)做消息收發(fā)。長(zhǎng)連接的核心價(jià)值在于“服務(wù)器主動(dòng)推送”這是所有實(shí)時(shí)性的基礎(chǔ)。1.3 心跳機(jī)制讓服務(wù)器知道你還活著長(zhǎng)連接雖然好用但網(wǎng)絡(luò)環(huán)境從來(lái)不是穩(wěn)定不變的。用戶(hù)進(jìn)了電梯、跨了基站W(wǎng)i-Fi斷了又連TCP連接并不會(huì)每次都被干凈地?cái)嚅_(kāi)很多情況下會(huì)進(jìn)入一種“半開(kāi)”狀態(tài)客戶(hù)端以為連著服務(wù)器也以為連著實(shí)際上數(shù)據(jù)已經(jīng)不通了。如果服務(wù)器把這個(gè)僵尸連接一直留在內(nèi)存里后果很?chē)?yán)重消息推不過(guò)去、連接數(shù)被無(wú)效占用用戶(hù)明明不在線卻顯示在線。所以IM系統(tǒng)需要一個(gè)心跳機(jī)制客戶(hù)端每隔一段時(shí)間常見(jiàn)是30到60秒發(fā)一個(gè)很小的心跳包給服務(wù)器。服務(wù)器記錄每個(gè)連接最近一次心跳時(shí)間。如果超過(guò)某個(gè)閾值比如90到120秒沒(méi)收到就判定連接已死主動(dòng)斷開(kāi)并清理會(huì)話?？蛻?hù)端發(fā)現(xiàn)自己長(zhǎng)時(shí)間沒(méi)收到服務(wù)器心跳響應(yīng)也會(huì)主動(dòng)斷開(kāi)重連。心跳間隔怎么定太短浪費(fèi)流量和電量太長(zhǎng)又會(huì)讓“假在線”持續(xù)太久。我見(jiàn)過(guò)不少剛?cè)胄械耐瑢W(xué)把心跳間隔設(shè)成5秒結(jié)果手機(jī)電量嘩嘩掉也見(jiàn)過(guò)設(shè)成10分鐘導(dǎo)致掉線后推送不達(dá)的。實(shí)踐中一般建議30秒上下同時(shí)讓服務(wù)端超時(shí)閾值是心跳間隔的2到3倍并允許客戶(hù)端在弱網(wǎng)模式下自動(dòng)縮短間隔。2. 高并發(fā)IM架構(gòu)的核心思路把“在線”這兩個(gè)字拆開(kāi)如果你只是寫(xiě)一個(gè)給十個(gè)人用的聊天Demo一臺(tái)單機(jī)就夠了。但用戶(hù)量一旦上來(lái)所有問(wèn)題都會(huì)暴露出來(lái)。早期我做高并發(fā)IM壓力測(cè)試時(shí)感觸最深的一句話是永遠(yuǎn)不要把所有職責(zé)放進(jìn)同一個(gè)進(jìn)程。2.1 單機(jī)瓶頸連接數(shù)本身就是一筆沉重的開(kāi)銷(xiāo)先算一筆賬。每一條TCP長(zhǎng)連接在服務(wù)器上至少需要占用一個(gè)文件描述符、一塊內(nèi)核緩沖區(qū)以及用于超時(shí)管理的定時(shí)器。在Go這類(lèi)并發(fā)友好的語(yǔ)言里每個(gè)連接通常還會(huì)對(duì)應(yīng)一個(gè)goroutine在Java里則可能對(duì)應(yīng)一個(gè)線程或者EventLoop。當(dāng)單機(jī)連接數(shù)達(dá)到幾萬(wàn)甚至十幾萬(wàn)時(shí)CPU、內(nèi)存、文件描述符都會(huì)逼近極限。而IM場(chǎng)景還有個(gè)特點(diǎn)連接多不代表每條連接時(shí)刻都在收發(fā)消息大量連接其實(shí)是“掛著”等消息的狀態(tài)。所以單機(jī)架構(gòu)根本撐不起大規(guī)模IM必須從架構(gòu)上做橫向拆分。這也是搜“高并發(fā)im”時(shí)最常見(jiàn)的核心訴求不是讓一臺(tái)機(jī)器變強(qiáng)而是讓系統(tǒng)能通過(guò)加機(jī)器變強(qiáng)。2.2 網(wǎng)關(guān)層與業(yè)務(wù)層的解耦最關(guān)鍵的架構(gòu)決策高并發(fā)IM的第一步是把“維護(hù)連接”和“處理業(yè)務(wù)”分開(kāi)。服務(wù)器拆分出兩層連接網(wǎng)關(guān)Gateway只負(fù)責(zé)接收、維護(hù)長(zhǎng)連接以及把收到消息的二進(jìn)制流解碼成業(yè)務(wù)對(duì)象再轉(zhuǎn)發(fā)給下游。它不做復(fù)雜邏輯所以可以輕松水平擴(kuò)展。業(yè)務(wù)邏輯層Logic負(fù)責(zé)真正的消息路由、關(guān)系鏈校驗(yàn)、存儲(chǔ)策略、推送決策?？蛻?hù)端發(fā)來(lái)的消息到達(dá)網(wǎng)關(guān)后網(wǎng)關(guān)會(huì)按照某種路由規(guī)則比如對(duì)用戶(hù)ID取模或一致性哈希轉(zhuǎn)給對(duì)應(yīng)的業(yè)務(wù)邏輯節(jié)點(diǎn)。業(yè)務(wù)邏輯處理完后如果需要推送再調(diào)用“推送服務(wù)”找到接收方客戶(hù)端當(dāng)前連接在哪個(gè)網(wǎng)關(guān)上把消息轉(zhuǎn)發(fā)過(guò)去。網(wǎng)關(guān)和邏輯層之間如何通信常見(jiàn)做法是內(nèi)部再用一套R(shí)PC或消息隊(duì)列。這樣做的好處很直接用戶(hù)量漲了只加網(wǎng)關(guān)節(jié)點(diǎn)即可業(yè)務(wù)規(guī)則復(fù)雜了只升級(jí)邏輯層即可兩邊互不拖累。2.3 消息隊(duì)列與寫(xiě)擴(kuò)散群聊消息的高效路由群聊是IM系統(tǒng)里最考驗(yàn)性能的場(chǎng)景之一。一個(gè)500人的群有人發(fā)一條消息理論上要把這條消息推送給499個(gè)成員。如果每個(gè)人單獨(dú)存一份那存儲(chǔ)成本會(huì)很可觀如果要求所有人實(shí)時(shí)拉取又會(huì)有延遲。IM行業(yè)積累下來(lái)的經(jīng)典方案是“寫(xiě)擴(kuò)散”和“讀擴(kuò)散”結(jié)合寫(xiě)擴(kuò)散發(fā)消息時(shí)直接給群里的每個(gè)成員生成一條會(huì)話消息記錄收件箱里放一份優(yōu)點(diǎn)是讀消息很快缺點(diǎn)是群人數(shù)越多寫(xiě)入放大越嚴(yán)重。讀擴(kuò)散群里消息只存一份成員按需獲取最近的消息優(yōu)點(diǎn)是存儲(chǔ)省缺點(diǎn)是每次拉取要聚合。大多數(shù)IM系統(tǒng)會(huì)根據(jù)群的規(guī)模動(dòng)態(tài)選擇策略。小群直接寫(xiě)擴(kuò)散大群退化為讀擴(kuò)散并搭配“已讀位置”記錄。而消息從邏輯層發(fā)出之后往往會(huì)經(jīng)過(guò)消息隊(duì)列做異步扇出把同步阻塞的推送變成異步任務(wù)這樣即使瞬間有大量群消息涌入系統(tǒng)也不會(huì)被拖垮。消息隊(duì)列的另一個(gè)重要作用是削峰填谷。舉個(gè)例子電商大促期間客服IM的流量是平時(shí)的幾十倍如果所有請(qǐng)求都同步推給數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)會(huì)直接被壓垮。引入隊(duì)列后寫(xiě)入可以排隊(duì)消費(fèi)推送可以批量執(zhí)行系統(tǒng)即使短暫過(guò)載也只是增加延遲而不是直接宕機(jī)。2.4 狀態(tài)與Session管理多端在線和踢人邏輯IM系統(tǒng)里“在線狀態(tài)”本身也是一個(gè)很重要的數(shù)據(jù)。用戶(hù)在線、離線、忙碌、離開(kāi)這些狀態(tài)分散在各個(gè)網(wǎng)關(guān)節(jié)點(diǎn)上但業(yè)務(wù)層需要一個(gè)全局視角。所以常規(guī)做法是把會(huì)話信息抽出來(lái)放到Rediskey通常是userIdvalue則包含當(dāng)前登錄的設(shè)備列表、每個(gè)設(shè)備連接所在的網(wǎng)關(guān)節(jié)點(diǎn)ID、最近心跳時(shí)間等。用戶(hù)登錄成功后業(yè)務(wù)層通過(guò)分布式鎖保證同一個(gè)賬號(hào)同一設(shè)備只有一個(gè)連接重復(fù)登錄時(shí)老連接會(huì)被踢下線或提示“賬號(hào)在其他設(shè)備登錄”。狀態(tài)變更還需要廣播給相關(guān)聯(lián)系人比如你上線了你的好友列表會(huì)顯示“在線”。這個(gè)動(dòng)作如果全量廣播社交大V會(huì)瞬間讓推送服務(wù)爆炸所以一般會(huì)加上頻控和好友分群推送。不要小看這些細(xì)節(jié)高并發(fā)IM里很多線上問(wèn)題都出在這種“看似簡(jiǎn)單”的狀態(tài)同步上。3. 協(xié)議選型XMPP、MQTT、WebSocket和自研私有協(xié)議怎么選聊完架構(gòu)下一個(gè)繞不開(kāi)的問(wèn)題是客戶(hù)端和服務(wù)器之間用什么協(xié)議通信協(xié)議決定研發(fā)效率、兼容性、流量開(kāi)銷(xiāo)以及可維護(hù)性。沒(méi)有絕對(duì)的最好只有適合場(chǎng)景的方案。3.1 XMPP老牌IM協(xié)議為什么漸漸邊緣化XMPP可擴(kuò)展消息處理協(xié)議誕生于IM領(lǐng)域早期核心是基于XML流的數(shù)據(jù)交換強(qiáng)調(diào)聯(lián)邦互通和擴(kuò)展性。它的優(yōu)勢(shì)是標(biāo)準(zhǔn)成熟、實(shí)現(xiàn)豐富、社區(qū)文檔多早期包括Google Talk都用過(guò)。但它在移動(dòng)時(shí)代的軟肋太明顯XML冗余大傳輸效率低弱網(wǎng)下表現(xiàn)差。而且XMPP雖然擴(kuò)展性強(qiáng)但默認(rèn)能力并不覆蓋移動(dòng)端的“消息到達(dá)確認(rèn)”“離線消息拉取”“多端同步”等IM必備功能需要大量擴(kuò)展協(xié)議去補(bǔ)等于繼承了一個(gè)框架又自己造了一輛整車(chē)。今天新啟動(dòng)的IM項(xiàng)目除非有特殊兼容需求幾乎沒(méi)人再?gòu)牧氵xXMPP了。它的價(jià)值更多體現(xiàn)在歷史系統(tǒng)和跨組織通信場(chǎng)景。3.2 MQTT弱網(wǎng)與物聯(lián)網(wǎng)場(chǎng)景的實(shí)用選擇MQTT最早是為衛(wèi)星通信和物聯(lián)網(wǎng)設(shè)計(jì)的基于發(fā)布/訂閱模型非常適合帶寬有限、網(wǎng)絡(luò)不穩(wěn)定的設(shè)備。它自帶三個(gè)QoS等級(jí)QoS 0至多一次可能丟消息。QoS 1至少一次可能重復(fù)。QoS 2恰好一次保證不重不丟代價(jià)是性能開(kāi)銷(xiāo)大。IM場(chǎng)景一般用QoS 1就能滿(mǎn)足“不丟但允許重復(fù)”的需求配合客戶(hù)端去重即可。很多IoT設(shè)備推送比如智能門(mén)鎖報(bào)警、遠(yuǎn)程控制指令都跑在MQTT上。它有個(gè)額外的好處是Broker消息代理生態(tài)成熟EMQX、Mosquitto都是常用組件部署和維護(hù)成本比較低。如果你的IM場(chǎng)景主要在弱網(wǎng)環(huán)境比如車(chē)載、戶(hù)外定位設(shè)備、低功耗傳感器MQTT比自研私有協(xié)議劃算得多。3.3 WebSocket網(wǎng)頁(yè)端IM的事實(shí)標(biāo)準(zhǔn)WebSocket可以理解為跑在TCP之上、通過(guò)HTTP握手建立的全雙工協(xié)議。瀏覽器的原生支持讓它成了網(wǎng)頁(yè)聊天、在線客服、協(xié)同辦公類(lèi)產(chǎn)品的默認(rèn)選擇。你不需要安裝客戶(hù)端打開(kāi)瀏覽器就能用這也是網(wǎng)上經(jīng)常有人搜“csdn盒子im網(wǎng)頁(yè)版”“某某IM網(wǎng)頁(yè)版”的原因——本質(zhì)上就是想要一個(gè)免安裝、拿來(lái)即用的網(wǎng)頁(yè)聊天工具。WebSocket的優(yōu)點(diǎn)是和HTTP生態(tài)天然融合鑒權(quán)可以用已有的登錄態(tài)消息可以用JSON傳遞出錯(cuò)時(shí)的錯(cuò)誤碼可以借用HTTP語(yǔ)義。缺點(diǎn)是協(xié)議本身不提供消息可靠投遞、回執(zhí)重傳等機(jī)制這些都得業(yè)務(wù)層自己補(bǔ)。實(shí)際項(xiàng)目中WebSocket通常和HTTP接口混合使用HTTP負(fù)責(zé)查詢(xún)類(lèi)操作拉好友列表、拉歷史消息WebSocket負(fù)責(zé)實(shí)時(shí)消息收發(fā)。這個(gè)分工模式成熟且高效絕大多數(shù)中大型Web IM都是這么做的。3.4 自研私有協(xié)議大廠為什么寧可自己造輪子微信、QQ這類(lèi)億級(jí)用戶(hù)產(chǎn)品最終都會(huì)走向自研協(xié)議。原因主要有幾點(diǎn)包體更小用二進(jìn)制或protobuf代替JSON同樣的消息能省一半以上流量?？刂屏Ω鼜?qiáng)加密方案、重傳策略、連接遷移、多路復(fù)用都能按自己的需求縱深優(yōu)化。業(yè)務(wù)粘合度更高消息、朋友圈、支付、小程序都跑在同一條連接上統(tǒng)一調(diào)度更加順暢。當(dāng)然自研協(xié)議的代價(jià)也很高客戶(hù)端、服務(wù)端都要維護(hù)編解碼層通信格式變更要嚴(yán)格做兼容測(cè)試成本翻倍。所以我的建議是如果你的團(tuán)隊(duì)規(guī)模、用戶(hù)體量還沒(méi)到那個(gè)階段不要輕易自研。這里整理一張常見(jiàn)協(xié)議選型對(duì)比表供參考協(xié)議傳輸效率實(shí)時(shí)性弱網(wǎng)表現(xiàn)典型場(chǎng)景XMPP低高中歷史IM、聯(lián)邦通信MQTT中高高強(qiáng)IoT、車(chē)載、弱網(wǎng)設(shè)備WebSocket中高中網(wǎng)頁(yè)IM、在線客服自研TCP私有協(xié)議高高強(qiáng)億級(jí)用戶(hù)IM、直播彈幕4. 從社交App到客服工作臺(tái)不同場(chǎng)景的IM落地差異很多資料討論IM時(shí)只盯著“聊天”這一個(gè)動(dòng)作但真實(shí)的IM產(chǎn)品是分行業(yè)的。熟人社交里的IM和客服系統(tǒng)里的IM優(yōu)化目標(biāo)完全不同。4.1 熟人社交IM消息必達(dá)和順序是底線微信、短信這類(lèi)熟人社交場(chǎng)景用戶(hù)最不能容忍的是“消息丟了”和“順序亂了”。所以工程重點(diǎn)放在每條消息有唯一的服務(wù)端序列號(hào)接收方按序列號(hào)排序避免亂序。發(fā)送方必須收到ack才算成功否則自動(dòng)重傳服務(wù)端做冪等去重。多端同步時(shí)各端維護(hù)一個(gè)游標(biāo)cursor離線期間的消息登錄后一起拉取。這個(gè)場(chǎng)景還有一個(gè)用戶(hù)感知極強(qiáng)的功能已讀回執(zhí)。它服務(wù)端不需要把“已讀”做成實(shí)時(shí)消息更常見(jiàn)的做法是讓接收方在打開(kāi)會(huì)話時(shí)匯報(bào)一下“我的已讀位置”服務(wù)端再異步通知發(fā)送方。4.2 客服與營(yíng)銷(xiāo)場(chǎng)景會(huì)話分配和消息合并更關(guān)鍵客服IM面對(duì)的通常不是“對(duì)等的聊天”而是“一個(gè)用戶(hù)面對(duì)一個(gè)坐席”。它有幾個(gè)完全不同的核心問(wèn)題會(huì)話路由用戶(hù)進(jìn)來(lái)后系統(tǒng)自動(dòng)分配一個(gè)空閑坐席可能還要考慮技能組、客戶(hù)等級(jí)、歷史接待人。消息排隊(duì)高峰時(shí)坐席不夠用戶(hù)消息要進(jìn)隊(duì)列并明確展示“前面還有幾位”。機(jī)器人轉(zhuǎn)人工先由機(jī)器人應(yīng)答根據(jù)語(yǔ)義判斷是否需要人工介入轉(zhuǎn)移時(shí)要把上下文一并帶上?？头蘒M的商業(yè)價(jià)值遠(yuǎn)遠(yuǎn)不止“聊天功能”。它需要和CRM、工單、知識(shí)庫(kù)打通消息往往要轉(zhuǎn)成可跟蹤的業(yè)務(wù)記錄。所以這個(gè)賽道的技術(shù)重心不是把單條消息延遲壓到幾十毫秒而是把路由、排隊(duì)、狀態(tài)機(jī)和業(yè)務(wù)系統(tǒng)無(wú)縫縫合起來(lái)。4.3 網(wǎng)頁(yè)版與嵌入式IM瀏覽器生態(tài)的特殊問(wèn)題網(wǎng)頁(yè)版IM的需求長(zhǎng)期存在。很多企業(yè)想在官網(wǎng)加一個(gè)“在線咨詢(xún)”按鈕想在后臺(tái)管理系統(tǒng)里嵌入站內(nèi)信模塊或者做一個(gè)只有單一功能的IM網(wǎng)頁(yè)版供內(nèi)部使用。這類(lèi)場(chǎng)景繞不開(kāi)瀏覽器兼容和單頁(yè)應(yīng)用帶來(lái)的特殊問(wèn)題。一個(gè)很常見(jiàn)的現(xiàn)象是聊天組件用著用著控制臺(tái)突然報(bào)出類(lèi)似“failed to fetch dynamically im”的錯(cuò)誤。這個(gè)報(bào)錯(cuò)本身信息量很少關(guān)鍵詞是“動(dòng)態(tài)獲取”和“fetch”。我排查過(guò)的案例里多數(shù)都是前端在初始化聊天配置時(shí)動(dòng)態(tài)拉取會(huì)話Token或者用戶(hù)檔案的接口出了問(wèn)題比如Token過(guò)期但前端還在用舊Token發(fā)消息?？缬蚺渲貌煌暾麨g覽器攔截了接口響應(yīng)。網(wǎng)絡(luò)切換導(dǎo)致請(qǐng)求發(fā)出去了但響應(yīng)超時(shí)。后端返回的數(shù)據(jù)結(jié)構(gòu)里少了某個(gè)字段前端解構(gòu)時(shí)直接拋錯(cuò)。這類(lèi)問(wèn)題的排查思路放在下一章詳細(xì)展開(kāi)。這里只想提醒一點(diǎn)網(wǎng)頁(yè)版IM對(duì)于“優(yōu)雅降級(jí)”的要求更高連接失敗時(shí)至少要讓用戶(hù)能夠刷新重試并給出可讀的提示而不是控制臺(tái)一片紅頁(yè)面卻沒(méi)有反應(yīng)。4.4 IM能力的外溢IoT通知、遠(yuǎn)程協(xié)作、直播彈幕IM并不只在聊天軟件里出現(xiàn)。萬(wàn)物互聯(lián)的背景下IM的核心能力“長(zhǎng)連接實(shí)時(shí)推送”被復(fù)用在大量生活化場(chǎng)景家里的智能門(mén)鎖開(kāi)鎖報(bào)警、快遞柜取件通知本質(zhì)是一個(gè)單向IM推送通道。在線文檔多人同時(shí)編輯時(shí)光標(biāo)位置和評(píng)論提醒需要低延遲通道也常復(fù)用WebSocket。直播彈幕、在線答題、遠(yuǎn)程白板底層同樣是消息分發(fā)。這也是為什么理解IM架構(gòu)的價(jià)值不止于做聊天應(yīng)用。任何需要“實(shí)時(shí)”二字的產(chǎn)品都離不開(kāi)這套內(nèi)核能力。很多時(shí)候你不是在設(shè)計(jì)一個(gè)聊天軟件而是在設(shè)計(jì)一個(gè)實(shí)時(shí)協(xié)同的底座而IM就是這個(gè)底座最經(jīng)典的形態(tài)。5. 線上IM故障排查那些我踩過(guò)的坑和定位套路紙上得來(lái)終覺(jué)淺。IM系統(tǒng)上線之后的故障排查才是真正拉開(kāi)工程師差距的地方。我這里整理幾個(gè)高頻問(wèn)題重點(diǎn)講定位思路而不是直接給答案因?yàn)檫@些坑換成別的項(xiàng)目往往只是報(bào)錯(cuò)文案不同而已。5.1 “連接不上”先分清是網(wǎng)絡(luò)、網(wǎng)關(guān)還是客戶(hù)端問(wèn)題用戶(hù)報(bào)“消息發(fā)不出去”“一直連接中”第一件事永遠(yuǎn)不是改代碼而是分層排查。我習(xí)慣按這樣的順序來(lái)確認(rèn)當(dāng)前用戶(hù)是否完全離線。如果只有某個(gè)用戶(hù)離線大概率是客戶(hù)端本地狀態(tài)異?；蚴窃撚脩?hù)的會(huì)話被服務(wù)端踢下了線。看網(wǎng)關(guān)實(shí)時(shí)連接數(shù)。如果整體連接數(shù)大幅下降說(shuō)明是網(wǎng)關(guān)或網(wǎng)絡(luò)層出了問(wèn)題可能是機(jī)房網(wǎng)絡(luò)抖動(dòng)、網(wǎng)關(guān)節(jié)點(diǎn)OOM。在客戶(hù)端抓日志看連接失敗的階段是TCP建連失敗還是證書(shū)校驗(yàn)失敗還是WebSocket握手返回了非預(yù)期狀態(tài)碼。重點(diǎn)檢查NAT超時(shí)引發(fā)的半開(kāi)連接。很多游客網(wǎng)絡(luò)下TCP連接被運(yùn)營(yíng)商/路由器靜默回收但兩端都不知道。用戶(hù)看起來(lái)在線實(shí)際已經(jīng)失聯(lián)。這種情況最常見(jiàn)的解決方案就是前文說(shuō)的心跳機(jī)制和自動(dòng)重連。5.2 消息發(fā)不出去ack超時(shí)的定位鏈路如果連接正常但某些消息發(fā)不出去矛頭就要指向消息鏈路的某個(gè)環(huán)節(jié)。發(fā)送方的表現(xiàn)通常是“消息一直轉(zhuǎn)圈”或狀態(tài)變成“發(fā)送失敗”。定位的時(shí)候別盯著客戶(hù)端猜去看服務(wù)端日志里有沒(méi)有收到這條消息。實(shí)操套路是這樣給每條消息一個(gè)全局唯一的客戶(hù)端消息IDclientMsgId。排查時(shí)先按這個(gè)ID查網(wǎng)關(guān)日志、邏輯層日志、存儲(chǔ)日志看消息到底走到了哪一步。如果網(wǎng)關(guān)收到了但邏輯層沒(méi)處理問(wèn)題大概率在路由或鑒權(quán)。如果邏輯層處理了但推送沒(méi)成功要查接收方是否在線、Session信息是否過(guò)期、推送服務(wù)是否報(bào)錯(cuò)。有一次我們線上出現(xiàn)過(guò)偶發(fā)消息丟失最后發(fā)現(xiàn)是邏輯層在并發(fā)場(chǎng)景下漏判了接收方的在線狀態(tài)導(dǎo)致消息只存不推客戶(hù)端又不知道去拉離線消息。解決方式是調(diào)整狀態(tài)判斷邏輯同時(shí)讓客戶(hù)端在重連或回到前臺(tái)時(shí)主動(dòng)拉取一次離線消息作為兜底。5.3 “failed to fetch dynamically …”這類(lèi)動(dòng)態(tài)獲取失敗的完整排查前面提過(guò)的控制臺(tái)報(bào)錯(cuò)“failed to fetch dynamically im”報(bào)錯(cuò)本身非常含糊但本質(zhì)上是在說(shuō)“前端頁(yè)面動(dòng)態(tài)獲取某個(gè)IM相關(guān)資源時(shí)網(wǎng)絡(luò)請(qǐng)求失敗了”。我排查過(guò)最具代表性的一次場(chǎng)景是前端聊天插件初始化時(shí)會(huì)先向服務(wù)端請(qǐng)求一個(gè)動(dòng)態(tài)配置內(nèi)容包括當(dāng)前用戶(hù)綁定的客服分組、歡迎語(yǔ)、WebSocket地址等。某天部分用戶(hù)反饋聊天窗口打不開(kāi)控制臺(tái)就是這個(gè)報(bào)錯(cuò)。我當(dāng)時(shí)的排查順序是先看瀏覽器Network面板找到真正失敗的接口確認(rèn)返回狀態(tài)碼。結(jié)果發(fā)現(xiàn)是HTTP 401。打開(kāi)接口日志發(fā)現(xiàn)這些用戶(hù)攜帶的會(huì)話票據(jù)已經(jīng)過(guò)期。原因是頁(yè)面長(zhǎng)期未刷新前端卻用舊的票據(jù)去請(qǐng)求新配置。解決方案分兩處后端在票據(jù)過(guò)期時(shí)返回明確錯(cuò)誤碼前端捕獲該錯(cuò)誤碼后靜默刷新票據(jù)并重試一次而不是直接把異常拋給用戶(hù)。這個(gè)案例給我的啟示是動(dòng)態(tài)獲取類(lèi)報(bào)錯(cuò)十有八九不是網(wǎng)絡(luò)斷了而是配套的“授權(quán)態(tài)”和“數(shù)據(jù)格式”出了問(wèn)題。先看接口返回比死磕前端代碼有效得多。5.4 高并發(fā)下的消息丟失如何在壓力里找真相高并發(fā)導(dǎo)致的故障往往不像普通bug那么自然復(fù)現(xiàn)它更像“壓力到了某個(gè)閾值后突然爆發(fā)”。消息丟失類(lèi)問(wèn)題的高發(fā)點(diǎn)主要在三個(gè)地方消息隊(duì)列積壓扇出消息的生產(chǎn)速度遠(yuǎn)大于消費(fèi)速度消費(fèi)者處理不過(guò)來(lái)產(chǎn)生超時(shí)和丟棄。Redis異常Session或離線消息依賴(lài)Redis如果Redis出現(xiàn)大key、慢查詢(xún)或集群節(jié)點(diǎn)切換整個(gè)鏈路都會(huì)抖動(dòng)。IO線程阻塞某些服務(wù)把耗時(shí)的讀寫(xiě)操作直接放在了IO線程里一旦數(shù)據(jù)庫(kù)或外部接口變慢所有消息都堵在入口。應(yīng)對(duì)這類(lèi)問(wèn)題最重要的前置動(dòng)作是日志里有消息全鏈路的軌跡。建議在網(wǎng)關(guān)收到消息、邏輯層處理完、推送成功這三個(gè)關(guān)鍵節(jié)點(diǎn)都打上同一批消息ID的日志。排查時(shí)通過(guò)消息ID把三段日志拼在一起一眼就能看出消息斷在了哪里。平時(shí)壓測(cè)時(shí)也要提前驗(yàn)證如果單臺(tái)網(wǎng)關(guān)掛了連接會(huì)不會(huì)自動(dòng)遷移消息隊(duì)列堆積十萬(wàn)條時(shí)系統(tǒng)是否能迅速恢復(fù)這些演練做多了真正線上出事時(shí)才不會(huì)手忙腳亂。6. 一周做一個(gè)最小可運(yùn)行的IM從Demo到基本能用的實(shí)踐路講了這么多理論最后給想親手驗(yàn)證的同學(xué)一條可執(zhí)行的路徑。我建議不要一上來(lái)就去復(fù)刻微信而是從“網(wǎng)頁(yè)版單聊工具”做起這個(gè)范圍恰好能覆蓋IM的核心環(huán)節(jié)又控制在一周業(yè)余時(shí)間內(nèi)。6.1 技術(shù)棧和項(xiàng)目結(jié)構(gòu)一個(gè)最小可運(yùn)行IM技術(shù)棧不必復(fù)雜后端Node.js或Go任選一個(gè)你熟的。Go更貼近生產(chǎn)環(huán)境Node.js寫(xiě)起來(lái)更省事。通信WebSocket瀏覽器端天然支持省去寫(xiě)TCP客戶(hù)端的時(shí)間。存儲(chǔ)Redis存在線狀態(tài)和離線消息順手解決“消息過(guò)期”問(wèn)題MySQL存歷史消息和用戶(hù)賬號(hào)數(shù)據(jù)。目錄結(jié)構(gòu)可以這樣規(guī)劃im-demo/ ├── server/ # WebSocket服務(wù)端 │ ├── auth.go # 登錄與Token校驗(yàn) │ ├── hub.go # 連接管理、消息路由 │ └── message.go # 消息結(jié)構(gòu)與存儲(chǔ) ├── web/ # 前端頁(yè)面 │ ├── index.html # 聊天界面 │ └── chat.js # WebSocket客戶(hù)端 └── data/ # Redis/MySQL初始化腳本這個(gè)項(xiàng)目不需要微服務(wù)不需要消息隊(duì)列等跑通后再去演進(jìn)也不遲。6.2 核心流程從登錄到WebSocket連接整個(gè)流程很簡(jiǎn)單用戶(hù)在頁(yè)面輸入用戶(hù)名密碼調(diào)用HTTP接口登錄服務(wù)端校驗(yàn)后返回一個(gè)Token。前端拿著Token去連WebSocket服務(wù)端在握手階段校驗(yàn)Token并建立會(huì)話。連接建立后服務(wù)端把連接注冊(cè)進(jìn)內(nèi)存管理結(jié)構(gòu)并往Redis寫(xiě)入用戶(hù)狀態(tài)。發(fā)消息時(shí)客戶(hù)端發(fā)送JSON例如{type:chat,to:userB,content:hello,clientMsgId:uuid-001}。服務(wù)端收到后先落庫(kù)再根據(jù)to字段找到接收方的WebSocket連接把消息推過(guò)去。這里有個(gè)容易忽略的點(diǎn)服務(wù)端推送給接收方時(shí)也要把消息ID帶上接收方客戶(hù)端需要做去重。因?yàn)槿绻扑统瑫r(shí)發(fā)送方可能會(huì)重發(fā)同一條消息。6.3 離線消息、歷史消息和已讀回執(zhí)在線用戶(hù)直接推送離線用戶(hù)的消息則不能丟。最小版本的做法是推送失敗時(shí)把消息追加到Redis里以用戶(hù)ID為key的List結(jié)構(gòu)中。用戶(hù)下次登錄建立連接后服務(wù)端把List里未讀消息一次性撈出來(lái)發(fā)給他然后清空List。歷史消息更簡(jiǎn)單MySQL里存一份消息表字段大致是msg_id, from_user, to_user, content, created_at。打開(kāi)會(huì)話時(shí)按這兩個(gè)用戶(hù)的組合查最近50條即可。已讀回執(zhí)可以放在最后做接收方打開(kāi)聊天窗口時(shí)發(fā)送一個(gè){type:read,lastMsgId:123}服務(wù)端把這個(gè)已讀位置更新到Redis再異步通知對(duì)方。這個(gè)功能雖然簡(jiǎn)單但足以幫你理解“狀態(tài)同步”的核心邏輯。6.4 壓測(cè)與調(diào)優(yōu)別讓Demo只是Demo項(xiàng)目跑通之后建議做一次最簡(jiǎn)單的壓測(cè)讓“高并發(fā)”這個(gè)抽象的詞落地。工具可以使用wsbench或自己寫(xiě)個(gè)腳本模擬一百個(gè)并發(fā)連接。重點(diǎn)關(guān)注三個(gè)指標(biāo)最大連接數(shù)服務(wù)端能穩(wěn)定掛住多少條連接。消息吞吐量單位時(shí)間內(nèi)能轉(zhuǎn)發(fā)多少條消息。錯(cuò)誤率消息發(fā)送失敗、重復(fù)投遞的比例。我第一次做這種Demo時(shí)就發(fā)現(xiàn)如果每來(lái)一條消息都同步寫(xiě)一次MySQL消息吞吐量會(huì)被拖到慘不忍睹。后來(lái)改成異步批量寫(xiě)內(nèi)存里攢夠一定數(shù)量再落庫(kù)吞吐量立刻翻了幾倍。這就是一個(gè)最簡(jiǎn)單的IM性能優(yōu)化案例也是從Demo走向可用的必經(jīng)之路。最后說(shuō)一點(diǎn)我自己的體會(huì)。IM這個(gè)東西入門(mén)門(mén)檻并不高任何程序員都能在一周內(nèi)寫(xiě)出能聊天的Demo但真正難的是在復(fù)雜的網(wǎng)絡(luò)環(huán)境、高并發(fā)流量、多端同步、消息可靠性這些層面把細(xì)節(jié)磨扎實(shí)。如果你正在做一個(gè)IM相關(guān)的項(xiàng)目我的建議是不要迷信任何現(xiàn)成框架而是親手把消息鏈路走一遍把連接、存儲(chǔ)、推送、確認(rèn)這些環(huán)節(jié)逐步打通。哪怕只是抱著學(xué)習(xí)目的做一個(gè)小Demo這個(gè)過(guò)程都會(huì)讓后面讀任何IM的代碼都清晰很多。