這套分散式IM即時通訊系統如何寫到簡歷上？我給你整理好了！

來源：冰河技術

分散式IM即時通訊系統本質上就是對線上聊天和使用者的管理，針對聊天本身來說，最核心的需求就是：傳送文字、圖片、檔案、語音、影片、訊息快取、訊息儲存、訊息未讀、已讀、撤回，離線訊息、歷史訊息、單聊、群聊，多端同步，以及其他一些需求。

對使用者管理來說，存在的需求包含：新增好友、檢視好友列表、刪除好友、檢視好友資訊、建立群聊、加入群聊、檢視群成員資訊、退出群聊、修改群暱稱、拉人進群、踢人出群、解散群聊、填寫群公告、修改群備註以及其他使用者相關的需求等。

注：拿小本子記錄下，後續可以寫到簡歷上的整合了OpenAI大模型的分散式IM即時通訊系統，從此，簡歷上又多了一個可以拿的出手的高併發、高效能、高可用、可監控、可預警、可伸縮，支援無限擴充套件的真實業務場景專案。

一、前言

為了能夠讓小夥伴們更好的理解分散式IM即時通訊系統的設計，我們站在架構師的角度，在充分了解系統需求，業務流程和技術流程後，從全域性視角為系統設定方案目標，對技術方案進行選型，對系統進行總體架構設計和分層架構設計，並梳理清楚傳送訊息的互動鏈路、單聊和群聊的互動鏈路。以方便各位小夥伴將分散式IM即時通訊系統寫到自己的簡歷中，增強自己的競爭力。

二、方案目標

在進行技術選型與總體架構設計之前，需要明確一個事項，就是系統無論採用哪種方案，採用哪種架構設計都需要明確這種方案的業務目標、技術目標和架構目標，並在研發過程中不斷評估系統的總體效能表現，發現系統瓶頸並不斷進行最佳化。

總體上，我們搭建和開發的分散式IM即時通訊系統，需要滿足如下方案目標。

• 業務目標：滿足需求設計篇章中的各類需求場景。
• 技術目標：支援無限擴容，百萬使用者同時線上聊天。
• 架構目標：高併發、高效能、高可用、可監控、可預警、可伸縮，支援無限擴充套件。

三、技術選型

在技術選型上，除了採用SpringBoot等基礎框架外，也會採用容器化方案。同時，考慮到為了儘量降低技術門檻，在整個分散式IM即時通訊系統的技術選型中，主要採用市面上比較流行的技術框架和方案，具體選型如下所示。

• 開發框架：SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo。
• 快取：Redis分散式快取+Guava本地快取。
• 資料庫：MySQL、TiDB、HBase。
• 流量閘道器：OpenResty+Lua。
• 業務閘道器：SpringCloud Gateway + Sentinel。
• 持久層框架：MyBatis、Mybatis-Plus。
• 服務配置、服務註冊與發現：Nacos。
• 訊息中介軟體：RocketMQ。
• 網路通訊：Netty。
• 檔案儲存：Minio。
• 日誌視覺化治理：ELK。
• 容器化管理：Swarm、Portainer。
• 監控：Prometheus、Grafana。
• 前端：Vue。
• 單元測試：Junit。
• 基準測試：JMH。
• 壓力測試：JMeter。

四、系統初步架構設計

對於IM即時通訊系統來說，涵蓋了即時通訊後端服務、大後端平臺、SDK接入服務、OpenAI接入服務、大前端UI，我相信不少小夥伴多多少少能夠畫出IM即時通訊系統的架構圖，大致如圖1-1所示。

其實，這種這種架構設計也比較常見，在這種架構設計中，Kong/Openresty/Nginx只做負載均衡和反向代理，研發人員更多的是關注業務層和基礎層的開發，流量比較小時，這種架構設計一般不會有什麼問題。但是一旦流量比較大，使用者呼叫後端平臺的介面傳送訊息時，即時通訊SDK同步呼叫即時通訊服務的介面就會出現效能問題。

因為每個終端同時只能與一個IM即時通訊服務例項建立連線，如果大量的使用者終端恰好都與一個IM即時通訊服務建立連線，那即時通訊SDK頻繁同步呼叫同一個IM即時通訊服務的介面就會出現效能瓶頸。此時，出現效能瓶頸時，不僅僅會影響到IM即時通訊服務，也會對後端平臺接收請求的業務造成一定的影響。

五、系統架構設計最佳化

既然圖1-1所示的架構設計存在效能瓶頸，那我們如何進行最佳化呢？為此我們在如1-1的基礎上進行了最佳化，最佳化後的架構如圖1-2所示。

對比圖1-1和圖1-2可以看出，在遮蔽掉技術實現細節的前提下，我們將對業務的校驗和流量管控進行前置化，放大Kong/OpenResty/Nginx的職責，使得這些軟體不僅具備反向代理和負載均衡的功能，還能實現限流、黑白名單、流量管控、業務校驗等功能。

也就是說，在這種架構模式下，我們充分發揮了整個分散式IM即時通訊系統的入口職責，充分利用Kong/OpenResty/Nginx的高併發、高吞吐量的能力，儘量將大部分無效請求擋在整個系統之外。例如，使用者在沒登入系統的前提下，就嘗試呼叫傳送訊息、新增好友、新增群組等等介面。這樣會大大減輕後臺平臺的業務壓力。

除了在Kong/OpenResty/Nginx中實現限流、黑白名單、流量管控、業務校驗等功能外，我們還引入了業務閘道器叢集，實現限流、降級、熔斷、流控、校驗、鑑權等功能，進一步保證下游系統的穩定性和安全。

為了解決大量使用者終端恰好連線到同一個IM即時通訊服務例項，IM即時通訊SDK頻繁呼叫同一個IM即時通訊服務例項的介面造成的效能問題。我們在IM即時通訊服務SDK與IM即時通訊服務之間引入了RocketMQ叢集。

IM即時通訊服務叢集中的每一個IM即時通訊服務例項在叢集中都有一個唯一的ID，並且每個IM即時通訊服務例項在啟動後，只會監聽RocketMQ中與自身ID相關的Topic。這樣每個IM即時通訊服務只會收到與自身ID相關的Topic中的訊息，不會接收所有的訊息。

當使用者登入系統後，就會與IM即時通訊服務建立長連線，並且會以使用者ID和終端為Key，以IM即時通訊服務的ID為value，將其儲存到分散式快取中。同時，會以使用者ID和終端為Key，以使用者終端與IM即時通訊服務建立的長連線為value，將其儲存到IM即時通訊服務本地記憶體中。

當使用者呼叫後端平臺的介面發訊息時，會帶上目標使用者的ID，並且在IM即時通訊SDK中會指定使用者登入的終端裝置，最終會透過IM即時通訊SDK向RocketMQ傳送訊息。

此時IM即時通訊SDK會根據目標使用者ID和終端從分散式快取中獲取目標使用者連線的IM即時通訊服務的ID，並向此ID相關的Topic傳送訊息。此時與目標使用者建立長連線的IM即時通訊服務就會接收到RocketMQ中的訊息，隨後根據使用者ID和終端從本地快取中獲取到與使用者終端建立的長連線，並基於此長連線向使用者推送訊息。

另外，在實際實現中，為了避免大量使用者同時只連線IM即時通訊服務叢集中的某一個服務例項，會對使用者連線的IP、瀏覽器指紋、手機裝置等做Hash和取模運算，使其儘量均勻分佈到叢集中的每一個服務例項上。

那麼問題來了：這種架構設計還有進一步最佳化的空間嗎？

六、容器化架構設計

為進一步增強分散式IM即時通訊系統的效能、可用性和彈性伸縮能力，我們可以對分散式IM即時通訊系統進行容器化架構設計，如圖1-3所示。

可以看到，我們對分散式IM即時通訊系統的架構設計進行了進一步最佳化，採用了容器化架構設計。在原有架構的基礎上，我們進行了如下改進和最佳化。

（1）基礎支撐服務

基礎支撐服務會由各種基礎中介軟體、資料儲存服務、以及監控服務實現，包含：MySQL資料庫、TiDB資料庫、HBase、Redis快取、RocketMQ訊息佇列、Prometheus監控和Portainer容器管理等基礎中介軟體實現，基礎支撐服務會對整個分散式IM即時通訊系統提供最基礎的資料、傳輸、監控和容器管理等服務。

（2）容器化

在容器化層面，會透過Docker、Swarm和Portainer實現，其中，會基於Swarm和Portainer對容器化進行管理。

（3）其他基礎性功能實現

除了上述分層架構外，對於建設分散式IM即時通訊系統來說，還要考慮異常監控、服務註冊與發現、視覺化、服務降級與兜底資料、服務限流、服務容災、容量規劃與擴縮容和全鏈路壓測等。

七、DDD分層業務架構設計

在分散式IM即時通訊系統中，不管是大後端平臺，還是IM即時通訊服務，我們都會對業務層的程式碼採用分層業務架構，這裡，可以借鑑DDD的分層架構思想，將程式碼總體上分成展示層、應用層、領域層和基礎設施層四個層次，但是，考慮到分散式IM即時通訊系統的特殊性，又不會嚴格按照DDD的原則來設計程式碼分層，具體按照如圖1-4所示。

可以看到，分散式IM即時通訊系統會借鑑DDD的設計思想，但是不會完全按照DDD的方式進行設計。

（1）展示層

展示層，也叫做使用者UI層，是DDD設計的最上層，對外提供API介面，接收客戶端請求，解析引數，返回結果資料，並對異常進行處理。

（2）應用層

應用層，也叫做Application層，應用層主要處理容易變化的業務場景，可對相關的事件、排程和其他聚合操作進行相關的處理。

（3）領域層

領域層，也叫做Domain層，領域層可以說是DDD設計的精髓所在，它是將業務系統中相對不變的部分抽象出來封裝成領域模型。

在分散式IM即時通訊系統的設計中，領域層基本不會依賴其他層，也不會依賴基礎設施層，這裡是與DDD設計存在區別的地方。

（4）基礎設施層

基礎設施層，也叫做Infrastructure層，基礎設施層會對其他各層提供通用的基礎能力，在分散式IM即時通訊系統中，就包括了快取、通用工具類、訊息、系統的持久化機制等。

八、傳送訊息互動鏈路

在分散式IM即時通訊系統中，我們忽略掉其他一些細節資訊，重點關注下傳送訊息的互動鏈路邏輯。不管是單聊還是群聊，最終都需要透過IM即時通訊服務將訊息推送給使用者的終端。此時傳送訊息的流程如圖1-5所示。

點選展開看大圖

可以看到，使用者在分散式IM即時通訊系統傳送訊息時，不管是單聊還是群聊，最終的訊息都會推送到使用者登入的終端裝置上。假設此時使用者A給使用者B傳送訊息，或者使用者A和使用者B在同一個群組，使用者A向群組傳送訊息，使用者B接收訊息的主要流程如下。

（1）使用者A呼叫後端平臺的介面向使用者B傳送訊息，並且傳送的訊息中會帶有使用者B的ID以及終端資訊。

（2）後端平臺將訊息快取起來，並且會將訊息非同步寫入訊息庫。

（3）後端平臺從Redis中獲取使用者B連線的IM即時通訊服務的ID。

（4）後端平臺獲取到使用者B連線的IM即時通訊服務的ID後，會向RocketMQ中使用者B連線的IM即時通訊服務ID對應的Topic傳送訊息。

（5）IM即時通訊服務會監聽自身服務ID對應的RocketMQ中Topic的訊息，此時，使用者B連線的IM即時通訊服務會接收到訊息。

（6）IM即時通訊服務接收到訊息後，會根據使用者B的ID以及終端資訊從快取中獲取使用者B與IM即時通訊服務建立的連線，並且透過這個連線向使用者B推送訊息。

要實現如上傳送訊息的流程，前提是要滿足如下條件。

（1）後端平臺滿足分散式條件，可隨時橫向擴充套件。

（2）IM即時通訊服務滿足分散式條件，可隨時橫向擴充套件。

（3）每個啟動的IM即時通訊服務例項在叢集中都有一個唯一的ID。

（4）每個IM即時通訊服務，都只監聽自身ID對應的RocketMQ中Topic的訊息。

（4）使用者登入分散式IM即時通訊系統後，會與IM即時通訊服務建立長連線，並且會根據使用者ID和所在的終端快取長連線，同時會根據使用者ID和所在的終端將連線的IM即時通訊服務的ID快取到Redis。

（6）使用者傳送訊息時，會根據目標使用者的ID和終端從Redis中獲取IM即時通訊服務的ID，進而向當前IM即時通訊服務的ID對應的RocketMQ的Topic傳送訊息。

（7）對應的IM即時通訊服務監聽並接收到RocketMQ訊息後，會根據目標使用者的ID和終端從快取中獲取到使用者的連線資訊，向目標使用者推送訊息。

九、單聊互動鏈路

單聊就是在分散式IM即時通訊系統中，一個使用者直接與另外一個使用者聊天，也就是一對一的聊天。在這種場景下，很有可能單聊的兩個使用者中，出現使用者不線上的情況。

例如，使用者A給使用者B傳送訊息時，使用者B可能不線上。此時，我們就需要將使用者A向使用者B傳送的訊息儲存起來。其實，在我們實現的分散式IM即時通訊系統中，無論把使用者B是否線上，都會儲存訊息記錄。當使用者B登入系統後，將訊息同步給使用者B，如圖1-6所示。

點選展開看大圖

可以看到，使用者A向使用者B傳送訊息時，如果使用者B線上，就可以按照傳送訊息的互動鏈路向使用者B傳送訊息了。如果使用者B不線上，此時就無法向使用者B正常推送訊息。當使用者B登入分散式IM即時通訊系統後，就會呼叫後端平臺的介面拉取所有未讀訊息，並透過使用者B線上流程向使用者B推送訊息。

十、群聊互動鏈路

群聊就是在分散式IM即時通訊系統中，多個使用者在同一個群組中進行聊天，此時在傳送訊息時，我們可以透過群組ID找出群內所有線上的使用者，將訊息即時傳送給線上的使用者。那些未線上的使用者就按照單聊未線上的使用者進行處理，如圖1-7所示。

點選展開看大圖

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

（1）使用者呼叫後端平臺的介面向群組傳送訊息。

（2）後端平臺將訊息快取並非同步寫入訊息庫。

（3）由於是向群組傳送訊息，群裡有多個使用者，此時就會從Redis中獲取所有使用者連線的IM即時通訊服務ID列表。

（4）對使用者按照服務ID分組，將相同服務ID下的使用者分在同一個邏輯分組裡，方便後續推送訊息，並且會記錄未線上的使用者列表。

（5）迴圈向每個服務ID對應的RocketMQ中的Topic傳送訊息。

（6）廣播處理未線上使用者的未讀訊息ID。

（7）IM即時通訊服務會監聽自身服務ID對應的Topic，會隨時接收推送到自身服務的訊息。

（8）當IM即時通訊服務接收到訊息後，此時使用者掉線，或者使用者不線上，向使用者推送訊息就會失敗，或者未查詢到使用者與IM即時通訊服務建立的連線，就不會向使用者推送訊息。

（9）當使用者登入分散式IM即時通訊系統後，會從後端平臺拉取歷史（離線）訊息，並透過使用者線上的流程，向使用者推送訊息。

好了，看到這裡，你明白如何設計一個高度可擴充套件的分散式IM即時通訊系統了嗎？趕緊拿本子記錄下你學到的知識，將其整理到簡歷上吧