本文由冰河分享五续，作者博客 binghe.gitcode.host，原題“這套分布式IM即時(shí)通訊系統(tǒng)如何寫到簡(jiǎn)歷上龄恋？我給你整理好了疙驾！”，本文有修訂和改動(dòng)篙挽。

1荆萤、引言

分布式IM即時(shí)通訊系統(tǒng)本質(zhì)上就是對(duì)線上聊天和用戶的管理。

針對(duì)聊天本身來說铣卡，最核心的需求就是：發(fā)送文字链韭、圖片、文件煮落、語音敞峭、視頻、消息緩存蝉仇、消息存儲(chǔ)旋讹、消息未讀、已讀轿衔、撤回沉迹，離線消息、歷史消息害驹、單聊鞭呕、群聊，多端同步宛官，以及其他一些需求葫松。

對(duì)用戶管理來說，存在的需求包含：添加好友底洗、查看好友列表腋么、刪除好友、查看好友信息亥揖、創(chuàng)建群聊珊擂、加入群聊、查看群成員信息费变、退出群聊摧扇、修改群昵稱、拉人進(jìn)群胡控、踢人出群扳剿、解散群聊旁趟、填寫群公告昼激、修改群備注以及其他用戶相關(guān)的需求等庇绽。

為了更好的理解分布式IM即時(shí)通訊系統(tǒng)的設(shè)計(jì)，我站在架構(gòu)師的角度橙困，在充分了解系統(tǒng)需求瞧掺、業(yè)務(wù)流程和技術(shù)流程后，從全局視角為系統(tǒng)設(shè)定方案目標(biāo)凡傅，對(duì)技術(shù)方案進(jìn)行選型辟狈，對(duì)系統(tǒng)進(jìn)行總體架構(gòu)設(shè)計(jì)和分層架構(gòu)設(shè)計(jì)，并梳理清楚發(fā)送消息的交互鏈路夏跷、單聊和群聊的交互鏈路哼转。希望對(duì)你有幫助。

2槽华、方案目標(biāo)

在進(jìn)行技術(shù)選型與總體架構(gòu)設(shè)計(jì)之前壹蔓，需要明確一個(gè)事項(xiàng)，就是系統(tǒng)無論采用哪種方案猫态，采用哪種架構(gòu)設(shè)計(jì)都需要明確這種方案的業(yè)務(wù)目標(biāo)佣蓉、技術(shù)目標(biāo)和架構(gòu)目標(biāo)，并在研發(fā)過程中不斷評(píng)估系統(tǒng)的總體性能表現(xiàn)亲雪，發(fā)現(xiàn)系統(tǒng)瓶頸并不斷進(jìn)行優(yōu)化勇凭。

總體上，我們搭建和開發(fā)的分布式IM即時(shí)通訊系統(tǒng)义辕，需要滿足如下方案目標(biāo)虾标。

具體是：

1）業(yè)務(wù)目標(biāo)：滿足需求設(shè)計(jì)篇章中的各類需求場(chǎng)景；

2）技術(shù)目標(biāo)：支持無限擴(kuò)容终息，百萬用戶同時(shí)在線聊天夺巩；

3）架構(gòu)目標(biāo)：高并發(fā)、高性能周崭、高可用柳譬、可監(jiān)控、可預(yù)警续镇、可伸縮美澳，支持無限擴(kuò)展。

3摸航、技術(shù)選型

在技術(shù)選型上制跟，除了采用SpringBoot等基礎(chǔ)框架外，也會(huì)采用容器化方案酱虎。

同時(shí)雨膨，考慮到為了盡量降低技術(shù)門檻，在整個(gè)分布式IM即時(shí)通訊系統(tǒng)的技術(shù)選型中读串，主要采用市面上比較流行的技術(shù)框架和方案聊记。

具體選型如下所示：

1）開發(fā)框架：SpringBoot脾还、SpringCloud础钠、SpringCloud Alibaba宾袜、Dubbo玖瘸；

2）緩存：Redis分布式緩存+Guava本地緩存；

3）數(shù)據(jù)庫：MySQL舆床、TiDB棋蚌、HBase；

4）流量網(wǎng)關(guān)：OpenResty+Lua挨队；

5）業(yè)務(wù)網(wǎng)關(guān)：SpringCloud Gateway + Sentinel谷暮；

6）持久層框架：MyBatis、Mybatis-Plus盛垦；

7）服務(wù)配置坷备、服務(wù)注冊(cè)與發(fā)現(xiàn)：Nacos；

8）消息中間件：RocketMQ情臭；

9）網(wǎng)絡(luò)通信：Netty省撑；

10）文件存儲(chǔ)：Minio；

11）日志可視化治理：ELK俯在；

12）容器化管理：Swarm竟秫、Portainer；

13）監(jiān)控：Prometheus跷乐、Grafana肥败；

14）前端：Vue；

15）單元測(cè)試：Junit愕提；

16）基準(zhǔn)測(cè)試：JMH馒稍；

17）壓力測(cè)試：JMeter。

4浅侨、初步架構(gòu)設(shè)計(jì)

對(duì)于IM即時(shí)通訊系統(tǒng)來說纽谒，涵蓋了即時(shí)通訊后端服務(wù)、大后端平臺(tái)如输、SDK接入服務(wù)鼓黔、OpenAI接入服務(wù)、大前端UI不见，我相信不少小伙伴多多少少能夠畫出IM即時(shí)通訊系統(tǒng)的架構(gòu)圖澳化，大致如下圖所示。

其實(shí)稳吮，這種這種架構(gòu)設(shè)計(jì)也比較常見缎谷，在這種架構(gòu)設(shè)計(jì)中，Kong/Openresty/Nginx只做負(fù)載均衡和反向代理灶似，研發(fā)人員更多的是關(guān)注業(yè)務(wù)層和基礎(chǔ)層的開發(fā)列林，流量比較小時(shí)眼虱，這種架構(gòu)設(shè)計(jì)一般不會(huì)有什么問題。但是一旦流量比較大席纽，用戶調(diào)用后端平臺(tái)的接口發(fā)送消息時(shí)，即時(shí)通訊SDK同步調(diào)用即時(shí)通訊服務(wù)的接口就會(huì)出現(xiàn)性能問題撞蚕。

因?yàn)槊總€(gè)終端同時(shí)只能與一個(gè)IM即時(shí)通訊服務(wù)實(shí)例建立連接润梯，如果大量的用戶終端恰好都與一個(gè)IM即時(shí)通訊服務(wù)建立連接，那即時(shí)通訊SDK頻繁同步調(diào)用同一個(gè)IM即時(shí)通訊服務(wù)的接口就會(huì)出現(xiàn)性能瓶頸甥厦。此時(shí)纺铭，出現(xiàn)性能瓶頸時(shí)，不僅僅會(huì)影響到IM即時(shí)通訊服務(wù)刀疙，也會(huì)對(duì)后端平臺(tái)接收請(qǐng)求的業(yè)務(wù)造成一定的影響舶赔。

5、架構(gòu)設(shè)計(jì)優(yōu)化

既然上節(jié)圖中所示的架構(gòu)設(shè)計(jì)存在性能瓶頸谦秧，那我們?nèi)绾芜M(jìn)行優(yōu)化呢竟纳？

為此我們?cè)谇皥D基礎(chǔ)上進(jìn)行了優(yōu)化，優(yōu)化后的架構(gòu)如下圖所示疚鲤。

對(duì)比兩圖可以看出锥累，在屏蔽掉技術(shù)實(shí)現(xiàn)細(xì)節(jié)的前提下，我們將對(duì)業(yè)務(wù)的校驗(yàn)和流量管控進(jìn)行前置化集歇，放大Kong/OpenResty/Nginx的職責(zé)桶略，使得這些軟件不僅具備反向代理和負(fù)載均衡的功能，還能實(shí)現(xiàn)限流诲宇、黑白名單际歼、流量管控、業(yè)務(wù)校驗(yàn)等功能姑蓝。

也就是說鹅心，在這種架構(gòu)模式下，我們充分發(fā)揮了整個(gè)分布式IM即時(shí)通訊系統(tǒng)的入口職責(zé)纺荧，充分利用Kong/OpenResty/Nginx的高并發(fā)巴帮、高吞吐量的能力，盡量將大部分無效請(qǐng)求擋在整個(gè)系統(tǒng)之外虐秋。例如榕茧，用戶在沒登錄系統(tǒng)的前提下，就嘗試調(diào)用發(fā)送消息客给、添加好友用押、添加群組等等接口。這樣會(huì)大大減輕后臺(tái)平臺(tái)的業(yè)務(wù)壓力靶剑。

除了在Kong/OpenResty/Nginx中實(shí)現(xiàn)限流蜻拨、黑白名單池充、流量管控、業(yè)務(wù)校驗(yàn)等功能外缎讼，我們還引入了業(yè)務(wù)網(wǎng)關(guān)集群收夸，實(shí)現(xiàn)限流、降級(jí)血崭、熔斷卧惜、流控、校驗(yàn)夹纫、鑒權(quán)等功能咽瓷，進(jìn)一步保證下游系統(tǒng)的穩(wěn)定性和安全。

為了解決大量用戶終端恰好連接到同一個(gè)IM即時(shí)通訊服務(wù)實(shí)例舰讹，IM即時(shí)通訊SDK頻繁調(diào)用同一個(gè)IM即時(shí)通訊服務(wù)實(shí)例的接口造成的性能問題茅姜。我們?cè)贗M即時(shí)通訊服務(wù)SDK與IM即時(shí)通訊服務(wù)之間引入了RocketMQ集群。

IM即時(shí)通訊服務(wù)集群中的每一個(gè)IM即時(shí)通訊服務(wù)實(shí)例在集群中都有一個(gè)唯一的ID月匣，并且每個(gè)IM即時(shí)通訊服務(wù)實(shí)例在啟動(dòng)后钻洒，只會(huì)監(jiān)聽RocketMQ中與自身ID相關(guān)的Topic。這樣每個(gè)IM即時(shí)通訊服務(wù)只會(huì)收到與自身ID相關(guān)的Topic中的消息锄开，不會(huì)接收所有的消息航唆。

當(dāng)用戶登錄系統(tǒng)后，就會(huì)與IM即時(shí)通訊服務(wù)建立長連接院刁，并且會(huì)以用戶ID和終端為Key糯钙，以IM即時(shí)通訊服務(wù)的ID為value，將其存儲(chǔ)到分布式緩存中退腥。同時(shí)任岸，會(huì)以用戶ID和終端為Key，以用戶終端與IM即時(shí)通訊服務(wù)建立的長連接為value狡刘，將其存儲(chǔ)到IM即時(shí)通訊服務(wù)本地內(nèi)存中享潜。

當(dāng)用戶調(diào)用后端平臺(tái)的接口發(fā)消息時(shí)，會(huì)帶上目標(biāo)用戶的ID嗅蔬，并且在IM即時(shí)通訊SDK中會(huì)指定用戶登錄的終端設(shè)備剑按，最終會(huì)通過IM即時(shí)通訊SDK向RocketMQ發(fā)送消息。

此時(shí)IM即時(shí)通訊SDK會(huì)根據(jù)目標(biāo)用戶ID和終端從分布式緩存中獲取目標(biāo)用戶連接的IM即時(shí)通訊服務(wù)的ID澜术，并向此ID相關(guān)的Topic發(fā)送消息艺蝴。此時(shí)與目標(biāo)用戶建立長連接的IM即時(shí)通訊服務(wù)就會(huì)接收到RocketMQ中的消息，隨后根據(jù)用戶ID和終端從本地緩存中獲取到與用戶終端建立的長連接鸟废，并基于此長連接向用戶推送消息猜敢。

另外，在實(shí)際實(shí)現(xiàn)中，為了避免大量用戶同時(shí)只連接IM即時(shí)通訊服務(wù)集群中的某一個(gè)服務(wù)實(shí)例缩擂，會(huì)對(duì)用戶連接的IP鼠冕、瀏覽器指紋、手機(jī)設(shè)備等做Hash和取模運(yùn)算胯盯，使其盡量均勻分布到集群中的每一個(gè)服務(wù)實(shí)例上懈费。

那么問題來了，這種架構(gòu)設(shè)計(jì)還有進(jìn)一步優(yōu)化的空間嗎博脑？

6憎乙、容器化架構(gòu)設(shè)計(jì)

為進(jìn)一步增強(qiáng)分布式IM即時(shí)通訊系統(tǒng)的性能、可用性和彈性伸縮能力趋厉，我們可以對(duì)分布式IM即時(shí)通訊系統(tǒng)進(jìn)行容器化架構(gòu)設(shè)計(jì)，如下圖所示胶坠。

可以看到君账，我們對(duì)分布式IM即時(shí)通訊系統(tǒng)的架構(gòu)設(shè)計(jì)進(jìn)行了進(jìn)一步優(yōu)化，采用了容器化架構(gòu)設(shè)計(jì)沈善。在原有架構(gòu)的基礎(chǔ)上乡数，我們進(jìn)行了如下改進(jìn)和優(yōu)化。

1）基礎(chǔ)支撐服務(wù)：基礎(chǔ)支撐服務(wù)會(huì)由各種基礎(chǔ)中間件闻牡、數(shù)據(jù)存儲(chǔ)服務(wù)净赴、以及監(jiān)控服務(wù)實(shí)現(xiàn)，包含：MySQL數(shù)據(jù)庫罩润、TiDB數(shù)據(jù)庫玖翅、HBase、Redis緩存割以、RocketMQ消息隊(duì)列金度、Prometheus監(jiān)控和Portainer容器管理等基礎(chǔ)中間件實(shí)現(xiàn)，基礎(chǔ)支撐服務(wù)會(huì)對(duì)整個(gè)分布式IM即時(shí)通訊系統(tǒng)提供最基礎(chǔ)的數(shù)據(jù)严沥、傳輸猜极、監(jiān)控和容器管理等服務(wù)。

2）容器化：在容器化層面消玄，會(huì)通過Docker跟伏、Swarm和Portainer實(shí)現(xiàn)，其中翩瓜，會(huì)基于Swarm和Portainer對(duì)容器化進(jìn)行管理受扳。

3）其他基礎(chǔ)性功能實(shí)現(xiàn)：除了上述分層架構(gòu)外，對(duì)于建設(shè)分布式IM即時(shí)通訊系統(tǒng)來說兔跌，還要考慮異常監(jiān)控辞色、服務(wù)注冊(cè)與發(fā)現(xiàn)、可視化、服務(wù)降級(jí)與兜底數(shù)據(jù)相满、服務(wù)限流层亿、服務(wù)容災(zāi)、容量規(guī)劃與擴(kuò)縮容和全鏈路壓測(cè)等立美。

7匿又、DDD分層業(yè)務(wù)架構(gòu)設(shè)計(jì)

在分布式IM即時(shí)通訊系統(tǒng)中，不管是大后端平臺(tái)建蹄，還是IM即時(shí)通訊服務(wù)碌更，我們都會(huì)對(duì)業(yè)務(wù)層的代碼采用分層業(yè)務(wù)架構(gòu)。

這里洞慎，可以借鑒DDD的分層架構(gòu)思想痛单，將代碼總體上分成展示層、應(yīng)用層劲腿、領(lǐng)域?qū)雍突A(chǔ)設(shè)施層四個(gè)層次旭绒。

但是，考慮到分布式IM即時(shí)通訊系統(tǒng)的特殊性焦人，又不會(huì)嚴(yán)格按照DDD的原則來設(shè)計(jì)代碼分層挥吵，具體按照如下圖所示。

可以看到花椭，分布式IM即時(shí)通訊系統(tǒng)會(huì)借鑒DDD的設(shè)計(jì)思想忽匈，但是不會(huì)完全按照DDD的方式進(jìn)行設(shè)計(jì)。

1）展示層：展示層矿辽，也叫做用戶UI層丹允，是DDD設(shè)計(jì)的最上層，對(duì)外提供API接口袋倔，接收客戶端請(qǐng)求嫌松，解析參數(shù)，返回結(jié)果數(shù)據(jù)奕污，并對(duì)異常進(jìn)行處理萎羔。

2）應(yīng)用層：應(yīng)用層，也叫做Application層碳默，應(yīng)用層主要處理容易變化的業(yè)務(wù)場(chǎng)景贾陷，可對(duì)相關(guān)的事件、調(diào)度和其他聚合操作進(jìn)行相關(guān)的處理嘱根。

3）領(lǐng)域?qū)樱?/i>領(lǐng)域?qū)铀璺希步凶鯠omain層，領(lǐng)域?qū)涌梢哉f是DDD設(shè)計(jì)的精髓所在该抒，它是將業(yè)務(wù)系統(tǒng)中相對(duì)不變的部分抽象出來封裝成領(lǐng)域模型慌洪。在分布式IM即時(shí)通訊系統(tǒng)的設(shè)計(jì)中，領(lǐng)域?qū)踊静粫?huì)依賴其他層，也不會(huì)依賴基礎(chǔ)設(shè)施層冈爹，這里是與DDD設(shè)計(jì)存在區(qū)別的地方涌攻。

4）基礎(chǔ)設(shè)施層：基礎(chǔ)設(shè)施層，也叫做Infrastructure層频伤，基礎(chǔ)設(shè)施層會(huì)對(duì)其他各層提供通用的基礎(chǔ)能力恳谎，在分布式IM即時(shí)通訊系統(tǒng)中，就包括了緩存憋肖、通用工具類因痛、消息、系統(tǒng)的持久化機(jī)制等岸更。

8鸵膏、總體IM消息交互鏈路

在分布式IM即時(shí)通訊系統(tǒng)中，我們忽略掉其他一些細(xì)節(jié)信息怎炊，重點(diǎn)關(guān)注下發(fā)送消息的交互鏈路邏輯谭企。不管是單聊還是群聊，最終都需要通過IM即時(shí)通訊服務(wù)將消息推送給用戶的終端结胀。此時(shí)發(fā)送消息的流程如下圖所示赞咙。

可以看到：用戶在分布式IM即時(shí)通訊系統(tǒng)發(fā)送消息時(shí)责循，不管是單聊還是群聊糟港，最終的消息都會(huì)推送到用戶登錄的終端設(shè)備上。假設(shè)此時(shí)用戶A給用戶B發(fā)送消息院仿，或者用戶A和用戶B在同一個(gè)群組秸抚，用戶A向群組發(fā)送消息，用戶B接收消息的主要流程如下歹垫。

具體是：

1）用戶A調(diào)用后端平臺(tái)的接口向用戶B發(fā)送消息剥汤，并且發(fā)送的消息中會(huì)帶有用戶B的ID以及終端信息；

2）后端平臺(tái)將消息緩存起來排惨，并且會(huì)將消息異步寫入消息庫吭敢；

3）后端平臺(tái)從Redis中獲取用戶B連接的IM即時(shí)通訊服務(wù)的ID；

4）后端平臺(tái)獲取到用戶B連接的IM即時(shí)通訊服務(wù)的ID后暮芭，會(huì)向RocketMQ中用戶B連接的IM即時(shí)通訊服務(wù)ID對(duì)應(yīng)的Topic發(fā)送消息鹿驼；

5）IM即時(shí)通訊服務(wù)會(huì)監(jiān)聽自身服務(wù)ID對(duì)應(yīng)的RocketMQ中Topic的消息，此時(shí)辕宏，用戶B連接的IM即時(shí)通訊服務(wù)會(huì)接收到消息畜晰；

6）IM即時(shí)通訊服務(wù)接收到消息后，會(huì)根據(jù)用戶B的ID以及終端信息從緩存中獲取用戶B與IM即時(shí)通訊服務(wù)建立的連接瑞筐，并且通過這個(gè)連接向用戶B推送消息凄鼻。

要實(shí)現(xiàn)如上發(fā)送消息的流程，前提是要滿足如下條件：

1）后端平臺(tái)滿足分布式條件，可隨時(shí)橫向擴(kuò)展块蚌；

2）IM即時(shí)通訊服務(wù)滿足分布式條件闰非，可隨時(shí)橫向擴(kuò)展；

3）每個(gè)啟動(dòng)的IM即時(shí)通訊服務(wù)實(shí)例在集群中都有一個(gè)唯一的ID匈子；

4）每個(gè)IM即時(shí)通訊服務(wù)河胎，都只監(jiān)聽自身ID對(duì)應(yīng)的RocketMQ中Topic的消息；

5）用戶登錄分布式IM即時(shí)通訊系統(tǒng)后虎敦，會(huì)與IM即時(shí)通訊服務(wù)建立長連接游岳，并且會(huì)根據(jù)用戶ID和所在的終端緩存長連接，同時(shí)會(huì)根據(jù)用戶ID和所在的終端將連接的IM即時(shí)通訊服務(wù)的ID緩存到Redis其徙；

6）用戶發(fā)送消息時(shí)胚迫，會(huì)根據(jù)目標(biāo)用戶的ID和終端從Redis中獲取IM即時(shí)通訊服務(wù)的ID，進(jìn)而向當(dāng)前IM即時(shí)通訊服務(wù)的ID對(duì)應(yīng)的RocketMQ的Topic發(fā)送消息唾那；

7）對(duì)應(yīng)的IM即時(shí)通訊服務(wù)監(jiān)聽并接收到RocketMQ消息后访锻，會(huì)根據(jù)目標(biāo)用戶的ID和終端從緩存中獲取到用戶的連接信息，向目標(biāo)用戶推送消息闹获。

9期犬、IM單聊交互鏈路

單聊就是在分布式IM即時(shí)通訊系統(tǒng)中，一個(gè)用戶直接與另外一個(gè)用戶聊天避诽，也就是一對(duì)一的聊天龟虎。在這種場(chǎng)景下，很有可能單聊的兩個(gè)用戶中沙庐，出現(xiàn)用戶不在線的情況鲤妥。

例如：用戶A給用戶B發(fā)送消息時(shí)，用戶B可能不在線拱雏。

此時(shí)棉安，我們就需要將用戶A向用戶B發(fā)送的消息存儲(chǔ)起來。

其實(shí)铸抑，在我們實(shí)現(xiàn)的分布式IM即時(shí)通訊系統(tǒng)中贡耽，無論把用戶B是否在線，都會(huì)存儲(chǔ)消息記錄鹊汛。當(dāng)用戶B登錄系統(tǒng)后蒲赂，將消息同步給用戶B，如下圖所示柒昏。

可以看到凳宙，用戶A向用戶B發(fā)送消息時(shí)：

1）如果用戶B在線，就可以按照發(fā)送消息的交互鏈路向用戶B發(fā)送消息了职祷；

2）如果用戶B不在線氏涩，此時(shí)就無法向用戶B正常推送消息届囚。當(dāng)用戶B登錄分布式IM即時(shí)通訊系統(tǒng)后，就會(huì)調(diào)用后端平臺(tái)的接口拉取所有未讀消息是尖，并通過用戶B在線流程向用戶B推送消息意系。

10、IM群聊交互鏈路

群聊就是在分布式IM即時(shí)通訊系統(tǒng)中饺汹，多個(gè)用戶在同一個(gè)群組中進(jìn)行聊天蛔添。

此時(shí)在發(fā)送消息時(shí)，我們可以通過群組ID找出群內(nèi)所有在線的用戶兜辞，將消息即時(shí)發(fā)送給在線的用戶迎瞧。

那些未在線的用戶就按照單聊未在線的用戶進(jìn)行處理，如下圖所示逸吵。

可以看到凶硅，群聊的交互鏈路流程如下所示：

1）用戶調(diào)用后端平臺(tái)的接口向群組發(fā)送消息；

2）后端平臺(tái)將消息緩存并異步寫入消息庫扫皱；

3）由于是向群組發(fā)送消息足绅，群里有多個(gè)用戶，此時(shí)就會(huì)從Redis中獲取所有用戶連接的IM即時(shí)通訊服務(wù)ID列表韩脑；

4）對(duì)用戶按照服務(wù)ID分組氢妈，將相同服務(wù)ID下的用戶分在同一個(gè)邏輯分組里，方便后續(xù)推送消息段多，并且會(huì)記錄未在線的用戶列表首量；

5）循環(huán)向每個(gè)服務(wù)ID對(duì)應(yīng)的RocketMQ中的Topic發(fā)送消息；

6）廣播處理未在線用戶的未讀消息ID衩匣；

7）IM即時(shí)通訊服務(wù)會(huì)監(jiān)聽自身服務(wù)ID對(duì)應(yīng)的Topic蕾总，會(huì)隨時(shí)接收推送到自身服務(wù)的消息粥航；

8）當(dāng)IM即時(shí)通訊服務(wù)接收到消息后琅捏，此時(shí)用戶掉線，或者用戶不在線递雀，向用戶推送消息就會(huì)失敗柄延，或者未查詢到用戶與IM即時(shí)通訊服務(wù)建立的連接，就不會(huì)向用戶推送消息缀程；

9）當(dāng)用戶登錄分布式IM即時(shí)通訊系統(tǒng)后搜吧，會(huì)從后端平臺(tái)拉取歷史（離線）消息，并通過用戶在線的流程杨凑，向用戶推送消息滤奈；

好了，看到這里撩满，你明白如何設(shè)計(jì)一個(gè)高度可擴(kuò)展的分布式IM即時(shí)通訊系統(tǒng)了嗎蜒程？

11绅你、相關(guān)資料

[1]?淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)

[2]?簡(jiǎn)述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端

[3]?一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)

[4]?一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案

[5]?移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率昭躺、實(shí)時(shí)性忌锯？

[6]?一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等

[7]?一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性领炫、有序性偶垮、弱網(wǎng)優(yōu)化等

[8]?從新手到專家：如何設(shè)計(jì)一套億級(jí)消息量的分布式IM系統(tǒng)

[9]?企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬人群帝洪、已讀回執(zhí)似舵、消息撤回等

[10]?融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制

[11]?阿里IM技術(shù)分享(三)：閑魚億級(jí)IM消息系統(tǒng)的架構(gòu)演進(jìn)之路

[12]?基于實(shí)踐：一套百萬消息量小規(guī)模IM系統(tǒng)技術(shù)要點(diǎn)總結(jié)

[13]?跟著源碼學(xué)IM(十)：基于Netty，搭建高性能IM集群（含技術(shù)思路+源碼）

[14]?一套十萬級(jí)TPS的IM綜合消息系統(tǒng)的架構(gòu)實(shí)踐與思考

[15]?得物從0到1自研客服IM系統(tǒng)的技術(shù)實(shí)踐之路

[16]?海量用戶IM聊天室的架構(gòu)設(shè)計(jì)與實(shí)踐

[17]?史上最通俗Netty入門長文：基本介紹葱峡、環(huán)境搭建啄枕、動(dòng)手實(shí)戰(zhàn)

[18]?新手入門：目前為止最透徹的的Netty高性能原理和框架架構(gòu)解析

[19]?寫給初學(xué)者：Java高性能NIO框架Netty的學(xué)習(xí)方法和進(jìn)階策略

[20]?手把手教你用Netty實(shí)現(xiàn)網(wǎng)絡(luò)通信程序的心跳機(jī)制、斷線重連機(jī)制

[21]?史上最強(qiáng)Java NIO入門：擔(dān)心從入門到放棄的族沃，請(qǐng)讀這篇频祝！

（本文已同步發(fā)布于：http://www.52im.net/thread-4564-1-1.html）