一、技術選型

有些小伙伴可能不太了解咱們分布式IM即時通訊系統(tǒng)使用了哪些技術和框架，請允許我再嘮叨下分布式IM即時通訊系統(tǒng)的技術選型，我們主要使用的技術棧和中間件，整體如下所示。

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

在之前的文章中，跟大家透露過：業(yè)務網(wǎng)關后續(xù)會計劃替換成星球的自研網(wǎng)關，這個網(wǎng)關的專欄和視頻教程即將給大家安排，值得一提的是，這個網(wǎng)關項目是一個能夠應對真實超高并發(fā)場景的生產(chǎn)級項目，經(jīng)實際對比壓測，其性能甚至比某些成熟的開源項目還要高，關于網(wǎng)關項目暫時就跟大家透漏這么多，我們拭目以待，哈哈。

為了更好的理解整個分布式IM即時通訊系統(tǒng)如何同時支持發(fā)送文本消息、表情消息、圖片消息、文件消息、語言消息和雙向視頻通話，也為了更好的理解消息在整個分布式IM即時通訊系統(tǒng)中的流程過程，在正式演示雙向視頻通話前，我們再來看看在分布式IM即時通訊系統(tǒng)中消息收發(fā)的流程、單聊的交互鏈路以及群聊的交互鏈路。

二、消息收發(fā)的流程

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

圖片

可以看到，用戶在分布式IM即時通訊系統(tǒng)發(fā)送消息時，不管是單聊還是群聊，最終的消息都會推送到用戶登錄的終端設備上。

假設此時用戶A給用戶B發(fā)送消息，或者用戶A和用戶B在同一個群組，用戶A向群組發(fā)送消息，用戶B接收消息的主要流程如下。

（1）用戶A調(diào)用后端平臺的接口向用戶B發(fā)送消息，并且發(fā)送的消息中會帶有用戶B的ID以及終端信息。

（2）后端平臺將消息緩存起來，并且會將消息異步寫入消息庫。

（3）后端平臺從Redis中獲取用戶B連接的IM即時通訊服務的ID。

（4）后端平臺獲取到用戶B連接的IM即時通訊服務的ID后，會向RocketMQ中用戶B連接的IM即時通訊服務ID對應的Topic發(fā)送消息。

（5）IM即時通訊服務會監(jiān)聽自身服務ID對應的RocketMQ中Topic的消息，此時，用戶B連接的IM即時通訊服務會接收到消息。

（6）IM即時通訊服務接收到消息后，會根據(jù)用戶B的ID以及終端信息從緩存中獲取用戶B與IM即時通訊服務建立的連接，并且通過這個連接向用戶B推送消息。

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

（1）后端平臺滿足分布式條件，可隨時橫向擴展。

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

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

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

（4）用戶登錄分布式IM即時通訊系統(tǒng)后，會與IM即時通訊服務建立長連接，并且會根據(jù)用戶ID和所在的終端緩存長連接，同時會根據(jù)用戶ID和所在的終端將連接的IM即時通訊服務的ID緩存到Redis。

（6）用戶發(fā)送消息時，會根據(jù)目標用戶的ID和終端從Redis中獲取IM即時通訊服務的ID，進而向當前IM即時通訊服務的ID對應的RocketMQ的Topic發(fā)送消息。

（7）對應的IM即時通訊服務監(jiān)聽并接收到RocketMQ消息后，會根據(jù)目標用戶的ID和終端從緩存中獲取到用戶的連接信息，向目標用戶推送消息。

三、單聊交互鏈路

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

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

圖片

可以看到，用戶A向用戶B發(fā)送消息時，如果用戶B在線，就可以按照發(fā)送消息的交互鏈路向用戶B發(fā)送消息了。

如果用戶B不在線，此時就無法向用戶B正常推送消息。當用戶B登錄分布式IM即時通訊系統(tǒng)后，就會調(diào)用大后端平臺的接口拉取所有未讀消息，并通過用戶B在線流程向用戶B推送消息。

四、群聊交互鏈路

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

圖片

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

（1）用戶調(diào)用后端平臺的接口向群組發(fā)送消息。

（2）后端平臺將消息緩存并異步寫入消息庫。

（3）由于是向群組發(fā)送消息，群里有多個用戶，此時就會從Redis中獲取所有用戶連接的IM即時通訊服務ID列表。

（4）對用戶按照服務ID分組，將相同服務ID下的用戶分在同一個邏輯分組里，方便后續(xù)推送消息，并且會記錄未在線的用戶列表。

（5）循環(huán)向每個服務ID對應的RocketMQ中的Topic發(fā)送消息。

（6）廣播處理未在線用戶的未讀消息ID。

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

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

（9）當用戶登錄分布式IM即時通訊系統(tǒng)后，會從后端平臺拉取歷史（離線）消息，并通過用戶在線的流程，向用戶推送消息。

五、雙向視頻通話

沒錯，再說一遍：分布式IM即時通訊系統(tǒng)已經(jīng)上線雙向視頻通話功能，至此，已完全支持發(fā)送文本消息、表情消息、圖片消息、文件消息、語言消息和雙向視頻通話。所有的功能從需求、原型、設計、架構(gòu)、編碼，到測試、部署、運維，冰河都為你安排的妥妥的。

5.1 原型草稿

我們先來看看分布式IM即時通訊系統(tǒng)設計雙向視頻通話時的原型草稿，像群組、單聊、群聊等等模塊的設計和實現(xiàn)，大家可以到星球通過 專欄+視頻+小冊+源碼+答疑 的方式進行學習，這里不再贅述。

在聊天框上方添加視頻呼叫的圖標，作為視頻呼叫的入口，聊天頁面添加視頻呼叫按鈕的原型設計草稿如下圖所示。

圖片

當視頻呼叫撥通后，好友接受視頻呼叫時，雙方正在視頻通話的原型設計草稿如下圖所示。

圖片

5.2 展示效果

這里，就拿幾個視頻通話的效果給大家展示下，像群組、單聊、群聊等等模塊的設計和實現(xiàn)效果，大家同樣可以到星球通過 專欄+視頻+小冊+源碼+答疑 的方式進行學習，這里不再贅述。

注意：這里我是在同一臺電腦不同瀏覽器上進行測試，由于電腦只有一個攝像頭，無法同時顯示主動呼叫方畫面和被動呼叫方畫面，大家可以在不同的電腦上進行測試，由一臺電腦的用戶呼叫另一臺電腦的用戶，即可同時看到主動呼叫方畫面和被動呼叫方畫面。

聊天頁面添加視頻呼叫按鈕如下圖所示。

圖片

視頻通話過程中主動發(fā)出視頻呼叫的用戶畫面如下圖所示。

圖片

視頻通話過程中接受視頻呼叫的用戶畫面如下圖所示。

圖片

再說一遍，哈哈：這里我是在同一臺電腦不同瀏覽器上進行測試，由于電腦只有一個攝像頭，無法同時顯示主動呼叫方畫面和被動呼叫方畫面，大家可以在不同的電腦上進行測試，由一臺電腦的用戶呼叫另一臺電腦的用戶，即可同時看到主動呼叫方畫面和被動呼叫方畫面。