分布式IM即時通訊系統本質上就是對線上聊天和用戶的管理，針對聊天本身來說，最核心的需求就是：發送文字、表情、圖片、文件、語音、視頻、消息緩存、消息存儲、消息未讀、已讀、撤回，離線消息、歷史消息、單聊、群聊，多端同步，對接OpenAI大模型，以及其他一些需求。

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

注：拿小本子記錄下，后續可以寫到簡歷上的整合了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即時通訊系統的性能、可用性和彈性伸縮能力，我們可以對分布式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即時通訊系統了嗎？趕緊拿本子記錄下你學到的知識，將其整理到簡歷上吧！

十一、如何寫簡歷描述

大部分簡歷上都會有項目描述部分，也就是要求寫你所經歷的項目，對于某個具體的項目來說，一般可以從項目描述、所使用的技術以及你在項目中的職責三個方面進行介紹。

項目描述

分布式IM即時通訊系統是為一個而完全自主研發的分布式IM即時通訊平臺，在架構設計和實現上后端服務整體包含：大后端平臺、即時通訊后端服務、IM即時通訊SDK、OpenAI大模型接入服務：PC端、H5和小程序。

主要實現的功能包含：單聊、群聊，發送文本、圖片、文件、語音、視頻，支持群聊@功能、離線消息、歷史消息、消息已讀、未讀、添加好友、刪除好友、創建群、加群、拉人入群、退出群、踢人出群、查看群成員、群公告、修改群備注等一系列完整的功能，后續為了擴展支持對接OpenAI大模型，專門設計和開發了對接多個OpenAI大模型的OpenAI接入服務。

工作職責

1.負責整個分布式IM即時通訊系統的架構設計和擴展性設計，接口規范化設計。

2.負責整體消息通訊的架構設計與核心代碼編寫。

3.負責數據庫優化設計、系統與子系統之間的緩存共享設計。

4.負責大后端平臺與即時通訊后端服務的交互設計與實現。

5.負責大后端平臺與即時通訊服務分布式擴展設計與實現。

6.負責OpenAI大模型SDK的通用化設計與實現。

7.負責核心代碼的編寫，負責技術攻關。

8.組織項目的版本發布、對部門其他人員的代碼進行審查。

9.全面跟進項目的整體進度、把控項目風險。期間，多次攻破了分布式IM即時通訊系統的難點與痛點。

部分技術亮點如下：

1、采用高性能的OpenResty+Lua腳本充當分布式IM即時通訊系統的流量網關，實現了負載均衡，多種限流與防刷策略，涵蓋：基于條件機制限流的防刷策略、基于Token編排機制的防刷策略和基于黑白名單機制的防刷策略，并且在流量網關處可以直接讀取本地緩存和分布式緩存中的數據進行校驗，校驗不通過則直接返回結果，真正做到了校驗前置化，避免了無效流量進入大后端平臺。

2、同樣以流量網關實現高并發流量的第一道防線，業務網關實現高并發流量的第二道防線，本地緩存實現高并發流量的第三道防線，分布式緩存實現高并發流量的第四道防線，盡最大程度保證后端服務的穩定與安全。

3、實現了流量隔離，采用責任鏈模式實現了初步的風控模型，具備多重風控檢驗功能，提供風控擴展點接口，內部初步實現了賬戶風控、IP風控、設備風控、限流風控和自定義風控、消息敏感詞風控、關鍵詞風控等。

4、整體設計上采用用戶管理與消息通訊分離的設計，大后端平臺主要負責用戶的管理，包含用戶基本信息管理、好友關系管理、群組管理等。即時通訊后端服務主要負責消息收發。大后端平臺通過引入即時通訊SDK即可與即時通訊服務進行數據交互，極大的提高了每個服務的擴展性。

5、大后端平臺和即時通訊服務各自都支持集群與分布式部署，支持隨時橫向擴展，提高了整體服務的穩定性和可靠性。

6、即時通訊服務在啟動時會生成唯一的服務ID，并將其注冊到注冊中心，以此來標識自身在即時通訊服務集群中的唯一身份。用戶終端通過長連接的形式連接即時通訊服務成功時，會將用戶id+終端標識作為Key，即時通訊服務的身份ID作為Value，存儲到分布式緩存，以此來確定用戶終端與集群中哪個即時通訊服務建立了連接。同時，在即時通訊服務內部會以用戶ID+終端標識作為Key，用戶終端與即時通訊服務建立的長連接對象作為Value，緩存到即時通訊服務本地緩存。

這樣，不僅實現了大后端平臺和即時通訊服務的集群與分布式部署，保證其能夠隨時橫向擴展，對與其他業務系統來說，也實現了只需要簡單的引入即時通訊SDK，不必過多關注消息交互的細節，即可快速引入即時通訊功能。

7、獨立設計即時通訊SDK，在SDK內部封裝業務系統對接即時通訊功能的具體邏輯，其他業務系統不必過多關注消息的收發細節，只需要簡單的引入即時通訊SDK，便可以快速實現即時通訊功能，極大的降低了團隊的對接成本。

8、在消息的設計上，每條消息都會設計一個全局時間有序的、可反解的ID，以此來實現發送消息的順序性，盡最大程度保證消息收發的順序性，避免消息出現錯亂的問題。并且設計可反解的ID，也能夠追溯到收發消息的用戶與IM即時通訊服務，方便出現問題時跟蹤、排查和解決問題。

9、實現了用戶離線消息的緩存與存儲，當用戶上線后，可拉取未讀消息，隨后即可進行正常聊天互動。實現了歷史消息存儲，用戶可查看與自己相關的單聊和群聊的歷史消息。

10、自主設計和研發了對接多個OpenAI大模型的SDK，系統通過引入OpenAI大模型SDK，經過簡單的配置即可對接OpenAI大模型，例如ChatGPT、ChatGLM等。