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

對(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ù)庫：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ù)庫、TiDB數(shù)據(jù)庫、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ū)?/h3>

領(lǐng)域?qū)?，也叫做Domain層，領(lǐng)域?qū)涌梢哉f是DDD設(shè)計(jì)的精髓所在，它是將業(yè)務(wù)系統(tǒng)中相對(duì)不變的部分抽象出來封裝成領(lǐng)域模型。

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

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

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

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

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

圖片

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

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

（2）后端平臺(tái)將消息緩存起來，并且會(huì)將消息異步寫入消息庫。

（3）后端平臺(tái)從Redis中獲取用戶B連接的IM即時(shí)通訊服務(wù)的ID。

（4）后端平臺(tái)獲取到用戶B連接的IM即時(shí)通訊服務(wù)的ID后，會(huì)向RocketMQ中用戶B連接的IM即時(shí)通訊服務(wù)ID對(duì)應(yīng)的Topic發(fā)送消息。

（5）IM即時(shí)通訊服務(wù)會(huì)監(jiān)聽自身服務(wù)ID對(duì)應(yīng)的RocketMQ中Topic的消息，此時(shí)，用戶B連接的IM即時(shí)通訊服務(wù)會(huì)接收到消息。

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

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

（1）后端平臺(tái)滿足分布式條件，可隨時(shí)橫向擴(kuò)展。

（2）IM即時(shí)通訊服務(wù)滿足分布式條件，可隨時(shí)橫向擴(kuò)展。

（3）每個(gè)啟動(dòng)的IM即時(shí)通訊服務(wù)實(shí)例在集群中都有一個(gè)唯一的ID。

（4）每個(gè)IM即時(shí)通訊服務(wù)，都只監(jiān)聽自身ID對(duì)應(yīng)的RocketMQ中Topic的消息。

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

（6）用戶發(fā)送消息時(shí)，會(huì)根據(jù)目標(biāo)用戶的ID和終端從Redis中獲取IM即時(shí)通訊服務(wù)的ID，進(jìn)而向當(dāng)前IM即時(shí)通訊服務(wù)的ID對(duì)應(yīng)的RocketMQ的Topic發(fā)送消息。

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

九、單聊交互鏈路

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

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

圖片

可以看到，用戶A向用戶B發(fā)送消息時(shí)，如果用戶B在線，就可以按照發(fā)送消息的交互鏈路向用戶B發(fā)送消息了。如果用戶B不在線，此時(shí)就無法向用戶B正常推送消息。

當(dāng)用戶B登錄分布式IM即時(shí)通訊系統(tǒng)后，就會(huì)調(diào)用后端平臺(tái)的接口拉取所有未讀消息，并通過用戶B在線流程向用戶B推送消息。

十、群聊交互鏈路

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

圖片

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

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

（2）后端平臺(tái)將消息緩存并異步寫入消息庫。

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

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

（5）循環(huán)向每個(gè)服務(wù)ID對(duì)應(yīng)的RocketMQ中的Topic發(fā)送消息。

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

（7）IM即時(shí)通訊服務(wù)會(huì)監(jiān)聽自身服務(wù)ID對(duì)應(yīng)的Topic，會(huì)隨時(shí)接收推送到自身服務(wù)的消息。

（8）當(dāng)IM即時(shí)通訊服務(wù)接收到消息后，此時(shí)用戶掉線，或者用戶不在線，向用戶推送消息就會(huì)失敗，或者未查詢到用戶與IM即時(shí)通訊服務(wù)建立的連接，就不會(huì)向用戶推送消息。

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

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

十一、如何寫簡(jiǎn)歷描述

大部分簡(jiǎn)歷上都會(huì)有項(xiàng)目描述部分，也就是要求寫你所經(jīng)歷的項(xiàng)目，對(duì)于某個(gè)具體的項(xiàng)目來說，一般可以從項(xiàng)目描述、所使用的技術(shù)以及你在項(xiàng)目中的職責(zé)三個(gè)方面進(jìn)行介紹。

項(xiàng)目描述

分布式IM即時(shí)通訊系統(tǒng)是為一個(gè)而完全自主研發(fā)的分布式IM即時(shí)通訊平臺(tái)，在架構(gòu)設(shè)計(jì)和實(shí)現(xiàn)上后端服務(wù)整體包含：大后端平臺(tái)、即時(shí)通訊后端服務(wù)、IM即時(shí)通訊SDK、OpenAI大模型接入服務(wù)：PC端、H5和小程序。

主要實(shí)現(xiàn)的功能包含：?jiǎn)瘟摹⑷毫模l(fā)送文本、圖片、文件、語音、視頻，支持群聊@功能、離線消息、歷史消息、消息已讀、未讀、添加好友、刪除好友、創(chuàng)建群、加群、拉人入群、退出群、踢人出群、查看群成員、群公告、修改群備注等一系列完整的功能，后續(xù)為了擴(kuò)展支持對(duì)接OpenAI大模型，專門設(shè)計(jì)和開發(fā)了對(duì)接多個(gè)OpenAI大模型的OpenAI接入服務(wù)。

工作職責(zé)

1.負(fù)責(zé)整個(gè)分布式IM即時(shí)通訊系統(tǒng)的架構(gòu)設(shè)計(jì)和擴(kuò)展性設(shè)計(jì)，接口規(guī)范化設(shè)計(jì)。

2.負(fù)責(zé)整體消息通訊的架構(gòu)設(shè)計(jì)與核心代碼編寫。

3.負(fù)責(zé)數(shù)據(jù)庫優(yōu)化設(shè)計(jì)、系統(tǒng)與子系統(tǒng)之間的緩存共享設(shè)計(jì)。

4.負(fù)責(zé)大后端平臺(tái)與即時(shí)通訊后端服務(wù)的交互設(shè)計(jì)與實(shí)現(xiàn)。

5.負(fù)責(zé)大后端平臺(tái)與即時(shí)通訊服務(wù)分布式擴(kuò)展設(shè)計(jì)與實(shí)現(xiàn)。

6.負(fù)責(zé)OpenAI大模型SDK的通用化設(shè)計(jì)與實(shí)現(xiàn)。

7.負(fù)責(zé)核心代碼的編寫，負(fù)責(zé)技術(shù)攻關(guān)。

8.組織項(xiàng)目的版本發(fā)布、對(duì)部門其他人員的代碼進(jìn)行審查。

9.全面跟進(jìn)項(xiàng)目的整體進(jìn)度、把控項(xiàng)目風(fēng)險(xiǎn)。期間，多次攻破了分布式IM即時(shí)通訊系統(tǒng)的難點(diǎn)與痛點(diǎn)。

部分技術(shù)亮點(diǎn)如下：

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

2、同樣以流量網(wǎng)關(guān)實(shí)現(xiàn)高并發(fā)流量的第一道防線，業(yè)務(wù)網(wǎng)關(guān)實(shí)現(xiàn)高并發(fā)流量的第二道防線，本地緩存實(shí)現(xiàn)高并發(fā)流量的第三道防線，分布式緩存實(shí)現(xiàn)高并發(fā)流量的第四道防線，盡最大程度保證后端服務(wù)的穩(wěn)定與安全。

3、實(shí)現(xiàn)了流量隔離，采用責(zé)任鏈模式實(shí)現(xiàn)了初步的風(fēng)控模型，具備多重風(fēng)控檢驗(yàn)功能，提供風(fēng)控?cái)U(kuò)展點(diǎn)接口，內(nèi)部初步實(shí)現(xiàn)了賬戶風(fēng)控、IP風(fēng)控、設(shè)備風(fēng)控、限流風(fēng)控和自定義風(fēng)控、消息敏感詞風(fēng)控、關(guān)鍵詞風(fēng)控等。

4、整體設(shè)計(jì)上采用用戶管理與消息通訊分離的設(shè)計(jì)，大后端平臺(tái)主要負(fù)責(zé)用戶的管理，包含用戶基本信息管理、好友關(guān)系管理、群組管理等。即時(shí)通訊后端服務(wù)主要負(fù)責(zé)消息收發(fā)。大后端平臺(tái)通過引入即時(shí)通訊SDK即可與即時(shí)通訊服務(wù)進(jìn)行數(shù)據(jù)交互，極大的提高了每個(gè)服務(wù)的擴(kuò)展性。

5、大后端平臺(tái)和即時(shí)通訊服務(wù)各自都支持集群與分布式部署，支持隨時(shí)橫向擴(kuò)展，提高了整體服務(wù)的穩(wěn)定性和可靠性。

6、即時(shí)通訊服務(wù)在啟動(dòng)時(shí)會(huì)生成唯一的服務(wù)ID，并將其注冊(cè)到注冊(cè)中心，以此來標(biāo)識(shí)自身在即時(shí)通訊服務(wù)集群中的唯一身份。用戶終端通過長(zhǎng)連接的形式連接即時(shí)通訊服務(wù)成功時(shí)，會(huì)將用戶id+終端標(biāo)識(shí)作為Key，即時(shí)通訊服務(wù)的身份ID作為Value，存儲(chǔ)到分布式緩存，以此來確定用戶終端與集群中哪個(gè)即時(shí)通訊服務(wù)建立了連接。同時(shí)，在即時(shí)通訊服務(wù)內(nèi)部會(huì)以用戶ID+終端標(biāo)識(shí)作為Key，用戶終端與即時(shí)通訊服務(wù)建立的長(zhǎng)連接對(duì)象作為Value，緩存到即時(shí)通訊服務(wù)本地緩存。

這樣，不僅實(shí)現(xiàn)了大后端平臺(tái)和即時(shí)通訊服務(wù)的集群與分布式部署，保證其能夠隨時(shí)橫向擴(kuò)展，對(duì)與其他業(yè)務(wù)系統(tǒng)來說，也實(shí)現(xiàn)了只需要簡(jiǎn)單的引入即時(shí)通訊SDK，不必過多關(guān)注消息交互的細(xì)節(jié)，即可快速引入即時(shí)通訊功能。

7、獨(dú)立設(shè)計(jì)即時(shí)通訊SDK，在SDK內(nèi)部封裝業(yè)務(wù)系統(tǒng)對(duì)接即時(shí)通訊功能的具體邏輯，其他業(yè)務(wù)系統(tǒng)不必過多關(guān)注消息的收發(fā)細(xì)節(jié)，只需要簡(jiǎn)單的引入即時(shí)通訊SDK，便可以快速實(shí)現(xiàn)即時(shí)通訊功能，極大的降低了團(tuán)隊(duì)的對(duì)接成本。

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

9、實(shí)現(xiàn)了用戶離線消息的緩存與存儲(chǔ)，當(dāng)用戶上線后，可拉取未讀消息，隨后即可進(jìn)行正常聊天互動(dòng)。實(shí)現(xiàn)了歷史消息存儲(chǔ)，用戶可查看與自己相關(guān)的單聊和群聊的歷史消息。

10、自主設(shè)計(jì)和研發(fā)了對(duì)接多個(gè)OpenAI大模型的SDK，系統(tǒng)通過引入OpenAI大模型SDK，經(jīng)過簡(jiǎn)單的配置即可對(duì)接OpenAI大模型，例如ChatGPT、ChatGLM等。