沉淀，成長(zhǎng)，突破，幫助他人，成就自我。

大家好，我是冰河~~

分布式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ù)庫(kù)：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)連接向用戶推送消息。

那么問題來了：這種架構(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ù)庫(kù)、TiDB數(shù)據(jù)庫(kù)、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ū)?/strong>