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