大家好，我是冰河~~

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

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

注：拿小本子記錄下，后續(xù)可以寫(xiě)到簡(jiǎn)歷上的整合了OpenAI大模型的分布式IM即時(shí)通訊系統(tǒng)，從此，簡(jiǎn)歷上又多了一個(gè)可以拿的出手的高并發(fā)、高性能、高可用、可監(jiān)控、可預(yù)警、可伸縮，支持無(wú)限擴(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)寫(xiě)到自己的簡(jiǎn)歷中，增強(qiáng)自己的競(jìng)爭(zhēng)力。

二、方案目標(biāo)

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

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

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

三、技術(shù)選型

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

• 開(kāi)發(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)來(lái)說(shuō)，涵蓋了即時(shí)通訊后端服務(wù)、大后端平臺(tái)、SDK接入服務(wù)、OpenAI接入服務(wù)、大前端UI，我相信不少小伙伴多多少少能夠畫(huà)出IM即時(shí)通訊系統(tǒng)的架構(gòu)圖，大致如圖1-1所示。

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

因?yàn)槊總€(gè)終端同時(shí)只能與一個(gè)IM即時(shí)通訊服務(wù)實(shí)例建立連接，如果大量的用戶(hù)終端恰好都與一個(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)等功能。

也就是說(shuō)，在這種架構(gòu)模式下，我們充分發(fā)揮了整個(gè)分布式IM即時(shí)通訊系統(tǒng)的入口職責(zé)，充分利用Kong/OpenResty/Nginx的高并發(fā)、高吞吐量的能力，盡量將大部分無(wú)效請(qǐng)求擋在整個(gè)系統(tǒng)之外。例如，用戶(hù)在沒(méi)登錄系統(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)定性和安全。

為了解決大量用戶(hù)終端恰好連接到同一個(gè)IM即時(shí)通訊服務(wù)實(shí)例，IM即時(shí)通訊SDK頻繁調(diào)用同一個(gè)IM即時(shí)通訊服務(wù)實(shí)例的接口造成的性能問(wèn)題。我們?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)聽(tīng)RocketMQ中與自身ID相關(guān)的Topic。這樣每個(gè)IM即時(shí)通訊服務(wù)只會(huì)收到與自身ID相關(guān)的Topic中的消息，不會(huì)接收所有的消息。

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

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

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

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

那么問(wèn)題來(lái)了：這種架構(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ì)通過(guò)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)來(lái)說(shuō)，還要考慮異常監(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的原則來(lái)設(shè)計(jì)代碼分層，具體按照如圖1-4所示。

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

（1）展示層

展示層，也叫做用戶(hù)UI層，是DDD設(shè)計(jì)的最上層，對(duì)外提供API接口，接收客戶(hù)端請(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(shuō)是DDD設(shè)計(jì)的精髓所在，它是將業(yè)務(wù)系統(tǒng)中相對(duì)不變的部分抽象出來(lái)封裝成領(lǐng)域模型。

在分布式IM即時(shí)通訊系統(tǒng)的設(shè)計(jì)中，領(lǐng)域?qū)踊静粫?huì)依賴(lài)其他層，也不會(huì)依賴(lài)基礎(chǔ)設(shè)施層，這里是與DDD設(shè)計(jì)存在區(qū)別的地方。

（4）基礎(chǔ)設(shè)施層

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

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

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

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

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

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

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

九、單聊交互鏈路

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

例如，用戶(hù)A給用戶(hù)B發(fā)送消息時(shí)，用戶(hù)B可能不在線(xiàn)。此時(shí)，我們就需要將用戶(hù)A向用戶(hù)B發(fā)送的消息存儲(chǔ)起來(lái)。其實(shí)，在我們實(shí)現(xiàn)的分布式IM即時(shí)通訊系統(tǒng)中，無(wú)論把用戶(hù)B是否在線(xiàn)，都會(huì)存儲(chǔ)消息記錄。當(dāng)用戶(hù)B登錄系統(tǒng)后，將消息同步給用戶(hù)B，如圖1-6所示。

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

十、群聊交互鏈路

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

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

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

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

十一、寫(xiě)在最后

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