大家好，我是冰河~~

分布式IM即時(shí)通訊系統(tǒng)本質(zhì)上就是對(duì)線上聊天和用戶的管理，針對(duì)聊天本身來說，最核心的需求就是：發(fā)送文字、圖片、文件、語音、視頻、消息緩存、消息存儲(chǔ)、消息未讀、已讀、撤回，離線消息、歷史消息、單聊、群聊，多端同步，以及其他一些需求。

對(duì)用戶管理來說，存在的需求包含：添加好友、查看好友列表、刪除好友、查看好友信息、創(chuàng)建群聊、加入群聊、查看群成員信息、退出群聊、修改群昵稱、拉人進(jìn)群、踢人出群、解散群聊、填寫群公告、修改群備注以及其他用戶相關(guān)的需求等。

注：拿小本子記錄下，后續(xù)可以寫到簡(jiǎn)歷上的整合了OpenAI大模型的分布式IM即時(shí)通訊系統(tǒng)，從此，簡(jiǎn)歷上又多了一個(gè)可以拿的出手的高并發(fā)、高性能、高可用、可監(jiān)控、可預(yù)警、可伸縮，支持無限擴(kuò)展的真實(shí)業(yè)務(wù)場(chǎng)景項(xiàng)目。

一、前言

為了能夠讓小伙伴們更好的理解分布式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ā)送消息的交互鏈路、單聊和群聊的交互鏈路。以方便各位小伙伴將分布式IM即時(shí)通訊系統(tǒng)寫到自己的簡(jiǎn)歷中，增強(qiáng)自己的競(jìng)爭(zhēng)力。

二、方案目標(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)。

• 業(yè)務(wù)目標(biāo)：滿足需求設(shè)計(jì)篇章中的各類需求場(chǎng)景。
• 技術(shù)目標(biāo)：支持無限擴(kuò)容，百萬用戶同時(shí)在線聊天。
• 架構(gòu)目標(biāo)：高并發(fā)、高性能、高可用、可監(jiān)控、可預(yù)警、可伸縮，支持無限擴(kuò)展。

三、技術(shù)選型

在技術(shù)選型上，除了采用SpringBoot等基礎(chǔ)框架外，也會(huì)采用容器化方案。同時(shí)，考慮到為了盡量降低技術(shù)門檻，在整個(gè)分布式IM即時(shí)通訊系統(tǒng)的技術(shù)選型中，主要采用市面上比較流行的技術(shù)框架和方案，具體選型如下所示。

• 開發(fā)框架：SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo。
• 緩存：Redis分布式緩存+Guava本地緩存。
• 數(shù)據(jù)庫：MySQL、TiDB、HBase。
• 流量網(wǎng)關(guān)：OpenResty+Lua。
• 業(yè)務(wù)網(wǎng)關(guān)：SpringCloud Gateway + Sentinel。
• 持久層框架：MyBatis、Mybatis-Plus。
• 服務(wù)配置、服務(wù)注冊(cè)與發(fā)現(xiàn)：Nacos。
• 消息中間件：RocketMQ。
• 網(wǎng)絡(luò)通信：Netty。
• 文件存儲(chǔ)：Minio。
• 日志可視化治理：ELK。
• 容器化管理：Swarm、Portainer。
• 監(jiān)控：Prometheus、Grafana。
• 前端：Vue。
• 單元測(cè)試：Junit。
• 基準(zhǔn)測(cè)試：JMH。
• 壓力測(cè)試：JMeter。

四、系統(tǒng)初步架構(gòu)設(shè)計(jì)

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

其實(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ù)造成一定的影響。

五、系統(tǒng)架構(gòu)設(shè)計(jì)優(yōu)化

既然圖1-1所示的架構(gòu)設(shè)計(jì)存在性能瓶頸，那我們?nèi)绾芜M(jìn)行優(yōu)化呢？為此我們?cè)谌?-1的基礎(chǔ)上進(jìn)行了優(yōu)化，優(yōu)化后的架構(gòu)如圖1-2所示。

對(duì)比圖1-1和圖1-2可以看出，在屏蔽掉技術(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ù)建立長(zhǎng)連接，并且會(huì)以用戶ID和終端為Key，以IM即時(shí)通訊服務(wù)的ID為value，將其存儲(chǔ)到分布式緩存中。同時(shí)，會(huì)以用戶ID和終端為Key，以用戶終端與IM即時(shí)通訊服務(wù)建立的長(zhǎng)連接為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)用戶建立長(zhǎng)連接的IM即時(shí)通訊服務(wù)就會(huì)接收到RocketMQ中的消息，隨后根據(jù)用戶ID和終端從本地緩存中獲取到與用戶終端建立的長(zhǎng)連接，并基于此長(zhǎng)連接向用戶推送消息。

另外，在實(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)化的空間嗎？

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

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

可以看到，我們對(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è)等。

七、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ì)代碼分層，具體按照如圖1-4所示。

可以看到，分布式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ū)?/h4>

領(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ī)制等。

八、發(fā)送消息交互鏈路

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

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

• 用戶A調(diào)用后端平臺(tái)的接口向用戶B發(fā)送消息，并且發(fā)送的消息中會(huì)帶有用戶B的ID以及終端信息。
• 后端平臺(tái)將消息緩存起來，并且會(huì)將消息異步寫入消息庫。
• 后端平臺(tái)從Redis中獲取用戶B連接的IM即時(shí)通訊服務(wù)的ID。
• 后端平臺(tái)獲取到用戶B連接的IM即時(shí)通訊服務(wù)的ID后，會(huì)向RocketMQ中用戶B連接的IM即時(shí)通訊服務(wù)ID對(duì)應(yīng)的Topic發(fā)送消息。
• IM即時(shí)通訊服務(wù)會(huì)監(jiān)聽自身服務(wù)ID對(duì)應(yīng)的RocketMQ中Topic的消息，此時(shí)，用戶B連接的IM即時(shí)通訊服務(wù)會(huì)接收到消息。
• IM即時(shí)通訊服務(wù)接收到消息后，會(huì)根據(jù)用戶B的ID以及終端信息從緩存中獲取用戶B與IM即時(shí)通訊服務(wù)建立的連接，并且通過這個(gè)連接向用戶B推送消息。

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

• 后端平臺(tái)滿足分布式條件，可隨時(shí)橫向擴(kuò)展。
• IM即時(shí)通訊服務(wù)滿足分布式條件，可隨時(shí)橫向擴(kuò)展。
• 每個(gè)啟動(dòng)的IM即時(shí)通訊服務(wù)實(shí)例在集群中都有一個(gè)唯一的ID。
• 每個(gè)IM即時(shí)通訊服務(wù)，都只監(jiān)聽自身ID對(duì)應(yīng)的RocketMQ中Topic的消息。
• 用戶登錄分布式IM即時(shí)通訊系統(tǒng)后，會(huì)與IM即時(shí)通訊服務(wù)建立長(zhǎng)連接，并且會(huì)根據(jù)用戶ID和所在的終端緩存長(zhǎng)連接，同時(shí)會(huì)根據(jù)用戶ID和所在的終端將連接的IM即時(shí)通訊服務(wù)的ID緩存到Redis。
• 用戶發(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ā)送消息。
• 對(duì)應(yīng)的IM即時(shí)通訊服務(wù)監(jiān)聽并接收到RocketMQ消息后，會(huì)根據(jù)目標(biāo)用戶的ID和終端從緩存中獲取到用戶的連接信息，向目標(biāo)用戶推送消息。

九、單聊交互鏈路

單聊就是在分布式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，如圖1-6所示。

可以看到，用戶A向用戶B發(fā)送消息時(shí)，如果用戶B在線，就可以按照發(fā)送消息的交互鏈路向用戶B發(fā)送消息了。如果用戶B不在線，此時(shí)就無法向用戶B正常推送消息。當(dāng)用戶B登錄分布式IM即時(shí)通訊系統(tǒng)后，就會(huì)調(diào)用后端平臺(tái)的接口拉取所有未讀消息，并通過用戶B在線流程向用戶B推送消息。

十、群聊交互鏈路

群聊就是在分布式IM即時(shí)通訊系統(tǒng)中，多個(gè)用戶在同一個(gè)群組中進(jìn)行聊天，此時(shí)在發(fā)送消息時(shí)，我們可以通過群組ID找出群內(nèi)所有在線的用戶，將消息即時(shí)發(fā)送給在線的用戶。那些未在線的用戶就按照單聊未在線的用戶進(jìn)行處理，如圖1-7所示。

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

• 用戶調(diào)用后端平臺(tái)的接口向群組發(fā)送消息。
• 后端平臺(tái)將消息緩存并異步寫入消息庫。
• 由于是向群組發(fā)送消息，群里有多個(gè)用戶，此時(shí)就會(huì)從Redis中獲取所有用戶連接的IM即時(shí)通訊服務(wù)ID列表。
• 對(duì)用戶按照服務(wù)ID分組，將相同服務(wù)ID下的用戶分在同一個(gè)邏輯分組里，方便后續(xù)推送消息，并且會(huì)記錄未在線的用戶列表。
• 循環(huán)向每個(gè)服務(wù)ID對(duì)應(yīng)的RocketMQ中的Topic發(fā)送消息。
• 廣播處理未在線用戶的未讀消息ID。
• IM即時(shí)通訊服務(wù)會(huì)監(jiān)聽自身服務(wù)ID對(duì)應(yīng)的Topic，會(huì)隨時(shí)接收推送到自身服務(wù)的消息。
• 當(dāng)IM即時(shí)通訊服務(wù)接收到消息后，此時(shí)用戶掉線，或者用戶不在線，向用戶推送消息就會(huì)失敗，或者未查詢到用戶與IM即時(shí)通訊服務(wù)建立的連接，就不會(huì)向用戶推送消息。
• 當(dāng)用戶登錄分布式IM即時(shí)通訊系統(tǒng)后，會(huì)從后端平臺(tái)拉取歷史（離線）消息，并通過用戶在線的流程，向用戶推送消息。

好了，看到這里，你明白如何設(shè)計(jì)一個(gè)高度可擴(kuò)展的分布式IM即時(shí)通訊系統(tǒng)了嗎？趕緊拿本子記錄下你學(xué)到的知識(shí)，將其整理到簡(jiǎn)歷上吧！

十一、寫在最后

這些真實(shí)場(chǎng)景的項(xiàng)目設(shè)計(jì)與落地實(shí)現(xiàn)，在冰河的知識(shí)星球除了分布式IM即時(shí)通訊系統(tǒng)外，還有其他5個(gè)項(xiàng)目，這些項(xiàng)目的需求、方案、架構(gòu)、落地等均來自互聯(lián)網(wǎng)真實(shí)業(yè)務(wù)場(chǎng)景，讓你真正學(xué)到互聯(lián)網(wǎng)大廠的業(yè)務(wù)與技術(shù)落地方案，并將其有效轉(zhuǎn)化為自己的知識(shí)儲(chǔ)備。