微服務(wù)化的即時(shí)通信系統(tǒng)架構(gòu)分析與設(shè)計(jì)

0 引言

近些年，隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，越來越多應(yīng)用軟件逐漸將即時(shí)通信服務(wù)與本業(yè)務(wù)相黏合，來提高本應(yīng)用的交互效率。而運(yùn)用傳統(tǒng)技術(shù)開發(fā)單體即時(shí)通信系統(tǒng)，一是開發(fā)周期過于繁雜，不適合與現(xiàn)階段主流線上產(chǎn)品搭配使用，二是在吞吐并發(fā)支持量上也沒法隨訪問量動(dòng)態(tài)提高。伴隨著微服務(wù)軟件架構(gòu)技術(shù)的不斷成熟，本文將以此設(shè)計(jì)出一種輕量級(jí)、高可靠、低成本的即時(shí)通信架構(gòu)方案。

1即時(shí)通信的基本技術(shù)原理

即時(shí)通信是一種基于Internet的交互技術(shù)，涉及IP、TCP、UDP、套接字（Socket）及通信過程中傳輸數(shù)據(jù)的編解碼和不同平臺(tái)接入方式等多種技術(shù)。其模式基本分為客戶端/服務(wù)器（C/S）通信模式和點(diǎn)對(duì)點(diǎn)（P2P）通信模式[1]。

C/S結(jié)構(gòu)是以服務(wù)器為中心將網(wǎng)絡(luò)上多個(gè)不同客戶機(jī)連接在一起，服務(wù)器與客戶機(jī)以“兩層”物理形式分別完成不同的功能。但在多客戶機(jī)并行訪問下，會(huì)涉及數(shù)據(jù)的存儲(chǔ)變更及服務(wù)器被多用戶并行訪問控制等問題。因此，采取一種“三層\"的C/S架構(gòu)更為合理[2]?！叭龑覾"的C/S并不是將物理結(jié)構(gòu)多抽出來一種，而是在服務(wù)端設(shè)計(jì)出“一層”專門負(fù)責(zé)存儲(chǔ)數(shù)據(jù)的持久層?！叭龑覾"C/S結(jié)構(gòu)中客戶端主要服務(wù)用戶交互，服務(wù)端邏輯處理層對(duì)信息進(jìn)行邏輯處理，服務(wù)端數(shù)據(jù)層負(fù)責(zé)信息數(shù)據(jù)的管理。

點(diǎn)對(duì)點(diǎn)（P2P）通信模式是無中心服務(wù)器的對(duì)等模式，與有中心服務(wù)器的中央服務(wù)系統(tǒng)不同，每個(gè)用戶端節(jié)點(diǎn)既是服務(wù)的提供者又是服務(wù)的使用者，節(jié)點(diǎn)之間直接通信可以充分利用網(wǎng)絡(luò)資源，減少網(wǎng)絡(luò)阻塞情況。且無中央服務(wù)器集中管理，系統(tǒng)能夠有效避免單點(diǎn)故障所帶來的問題，大大提高了系統(tǒng)容錯(cuò)性能。不過，P2P模式有分散性、自治性和動(dòng)態(tài)性等特點(diǎn)，造成了在一些情況下用戶訪問結(jié)果的不確定性。

當(dāng)下，比較流行的IM系統(tǒng)都是組合使用C/S模式和P2P模式，利用服務(wù)器來實(shí)現(xiàn)傳輸信息的管控和漫游，以構(gòu)建出虛擬P2P通信。用戶在使用系統(tǒng)時(shí)通過C/S架構(gòu)的服務(wù)器端保存用戶之間的鏈路狀態(tài)，以便用戶以后進(jìn)行通信時(shí)可以直接從服務(wù)器獲取自己及其他用戶之間的鏈路信息，進(jìn)而快速完成信息的轉(zhuǎn)發(fā)與投遞，實(shí)現(xiàn)用戶之間點(diǎn)對(duì)點(diǎn)通信。

2 即時(shí)通信系統(tǒng)架構(gòu)的分析與設(shè)計(jì)

對(duì)于一個(gè)即時(shí)通信系統(tǒng)，消息傳輸會(huì)經(jīng)過客戶端接入服務(wù)器進(jìn)行消息處理，在處理過程中，會(huì)按照用戶限定的關(guān)系進(jìn)行發(fā)送投遞；在存儲(chǔ)與同步過程中，針對(duì)消息的不同屬性需要選擇不同種類的存儲(chǔ)數(shù)據(jù)庫。因此，客戶端（Client）使用不同的平臺(tái)經(jīng)過不同協(xié)議接入服務(wù)器端，而微服務(wù)化下服務(wù)器端可以設(shè)計(jì)出接入服務(wù)器（Interface）、消息處理服務(wù)器（Logic）以及數(shù)據(jù)存儲(chǔ)層（DataBase）這三層，再在每層定義不同功能的微服務(wù)模塊，模塊之間使用不同通信方式進(jìn)行解耦。其架構(gòu)模型設(shè)計(jì)如圖1所示，架構(gòu)相關(guān)服務(wù)名詞說明如表1所示，不同服務(wù)間相互調(diào)用與傳輸方法說明如表2所示。

注： ① long polling：HTTP長(zhǎng)輪詢，指服務(wù)器將保留瀏覽器請(qǐng)求的響應(yīng)，一旦服務(wù)器有更新就發(fā)送它，然后客戶機(jī)可以發(fā)送另一個(gè)請(qǐng)求。

2.1 客戶端服務(wù)層

客戶端服務(wù)層主要提供與用戶交互的服務(wù)，主要包括PC端、Web瀏覽器和手機(jī)移動(dòng)端三種平臺(tái)。不同平臺(tái)在獲取與消息服務(wù)器構(gòu)建的連接時(shí)一般使用的傳輸協(xié)議也不同。

在瀏覽器使用IM服務(wù)時(shí)，由于現(xiàn)在的瀏覽器Web網(wǎng)站大多都已采用HTML5標(biāo)準(zhǔn)規(guī)范，所以在網(wǎng)絡(luò)傳輸協(xié)議上也支持websocket協(xié)議，websocket是一種全雙工通信的協(xié)議，通過http解析一個(gè)upgrade請(qǐng)求與服務(wù)器“握手”，形成一條持久且快速的通道，客戶端和服務(wù)端都可以主動(dòng)推送消息，可以是文本數(shù)據(jù)也可以是二進(jìn)制數(shù)據(jù)，而且沒有同源策略的限制，不存在跨域問題[3]。

PC端和手機(jī)移動(dòng)端一般都是基于本地運(yùn)行系統(tǒng)開發(fā)而成，一般在傳輸上將數(shù)據(jù)信息通過一定的應(yīng)用層級(jí)編解碼后直接使用TCP或UDP兩種基礎(chǔ)協(xié)議傳輸。TCP協(xié)議能夠提供可靠的數(shù)據(jù)傳輸，它通過“三次握手\"的過程來構(gòu)建一個(gè)虛擬連接通道實(shí)現(xiàn)信息數(shù)據(jù)交互，當(dāng)數(shù)據(jù)包在交付期間遭到破壞丟失或變得無序時(shí)，TCP協(xié)議可以通過為其發(fā)送的每個(gè)數(shù)據(jù)包提供一個(gè)序號(hào)來完成此恢復(fù)。不過，UDP可以爭(zhēng)用網(wǎng)絡(luò)通道，而且不需要在傳輸信息之前構(gòu)建數(shù)據(jù)通道，因此它的傳輸過程非?？臁ＲＷC消息完整不丟包，IM系統(tǒng)可以TCP協(xié)議來構(gòu)建穩(wěn)定可靠的網(wǎng)絡(luò)通道[4]。

2.2 接口服務(wù)層

接口服務(wù)主要是維護(hù)客戶端與IM服務(wù)器的連接，主要包括路由服務(wù)（route）、消息接入服務(wù)（gate）和負(fù)責(zé)處理圖片和音視頻等富媒體大文件的接口服務(wù)（relay）。

客戶端在接入IM服務(wù)器時(shí)，會(huì)根據(jù)請(qǐng)求的信息將用戶的調(diào)用需求映射至不同的服務(wù)上，這個(gè)過程也叫路由。路由服務(wù)負(fù)責(zé)對(duì)請(qǐng)求的處理過程進(jìn)行干預(yù)，實(shí)現(xiàn)請(qǐng)求校驗(yàn)、服務(wù)聚合等過濾功能，在集群部署下，也把請(qǐng)求分發(fā)到同一服務(wù)的多個(gè)節(jié)點(diǎn)上，實(shí)現(xiàn)系統(tǒng)服務(wù)的負(fù)載均衡。

消息接入服務(wù)在架構(gòu)上屬于連接客戶端和消息處理服務(wù)的中間件，能夠針對(duì)不同平臺(tái)的客戶端傳輸協(xié)議統(tǒng)一進(jìn)行傳輸數(shù)據(jù)的編解碼。在IM服務(wù)器部署運(yùn)行之后，面對(duì)復(fù)雜的網(wǎng)絡(luò)狀況時(shí)，消息接入服務(wù)必須能夠提供高性能和高可用性的網(wǎng)絡(luò)通信服務(wù)。

IM服務(wù)系統(tǒng)在實(shí)際使用中，還會(huì)涉及圖片和音視頻等大文件富媒體消息。對(duì)于富媒體消息的處理，IM系統(tǒng)服務(wù)器生成一個(gè)與富媒體消息對(duì)應(yīng)的文本消息體，文本消息體中包含富媒體消息存儲(chǔ)的地址信息及其他相關(guān)屬性?？蛻舳嗽诎l(fā)送時(shí)都是將該富媒體消息對(duì)應(yīng)的文本消息發(fā)送至IM服務(wù)器，而富媒體消息本身則存儲(chǔ)到單獨(dú)的服務(wù)中，在客戶端接收這類消息時(shí)，就可以根據(jù)消息地址去拉取富媒體文件，過程如圖2所示。當(dāng)下，由于云計(jì)算技術(shù)的發(fā)展，針對(duì)大文件富媒體信息的存儲(chǔ)都會(huì)選擇第三方云平臺(tái)服務(wù)，將圖片和音視頻保存在遠(yuǎn)端，以輕量化本地服務(wù)器存儲(chǔ)[5]。

2.3 邏輯處理層

邏輯處理層用來實(shí)現(xiàn)對(duì)客戶端請(qǐng)求的邏輯處理，完成相關(guān)處理方法的映射和對(duì)數(shù)據(jù)層數(shù)據(jù)的管理調(diào)用，該層涉及的服務(wù)主要有業(yè)務(wù)關(guān)系服務(wù)（relationshipserver）、消息處理服務(wù)（messageserver）。

IM系統(tǒng)服務(wù)在運(yùn)行功能上是基于消息收發(fā)的場(chǎng)景，所以會(huì)涉及用戶“好友”關(guān)系的管理，客戶端在使用消息服務(wù)時(shí)要能構(gòu)建起“交流圈”進(jìn)行消息“生產(chǎn)\"和“消費(fèi)”。由于沒有消息數(shù)據(jù)方面的處理，關(guān)系服務(wù)的調(diào)用方式一般是在客戶端通過路由確定該服務(wù)后，直接運(yùn)用RPC或Restful方式調(diào)用響應(yīng)，之后再通過同樣的方式調(diào)用數(shù)據(jù)庫服務(wù)完成數(shù)據(jù)的持久化存儲(chǔ)。

消息處理服務(wù)是IM系統(tǒng)消息收發(fā)的核心服務(wù)，對(duì)投遞到IM服務(wù)器的消息進(jìn)行確認(rèn)反饋，對(duì)消息信息進(jìn)行同步與存儲(chǔ)，還有一些群聊場(chǎng)景、消息漫游和消息已/未讀等特殊功能的實(shí)現(xiàn)。過去常將消息處理服務(wù)與接口服務(wù)層的接入服務(wù)融為一體，而隨著用戶數(shù)量的不斷增長(zhǎng)，消息處理的接入服務(wù)能力成為瓶頸。隨著不少像Kafka、RabbitMQ等優(yōu)秀的開源消息隊(duì)列（MQ）誕生，可以引入消息隊(duì)列（MQ）使接入服務(wù)和真正的消息處理模塊相解耦，在大量消息到達(dá)消息處理服務(wù)后如來不及處理可暫緩至消息隊(duì)列中，防止消息丟失。圖3給出了消息處理服務(wù)與其他相關(guān)服務(wù)的調(diào)用模型，可以看出消息處理服務(wù)（messageserver）是IM系統(tǒng)的核心，傳輸接入服務(wù)（gateserver）、業(yè)務(wù)關(guān)系服務(wù)（relationshipserver）和消息存儲(chǔ)（msgstore）都會(huì)通過消息隊(duì)列（MQ）或方法調(diào)用（RPC/Restful）與消息處理服務(wù)（messageserver）相交互。

2.4 數(shù)據(jù)存儲(chǔ)層

由于IM系統(tǒng)的適用場(chǎng)景使其會(huì)有多種不同形式的數(shù)據(jù)源，因此在數(shù)據(jù)庫的選擇上采取多種不同的數(shù)據(jù)庫來存儲(chǔ)這些數(shù)據(jù)信息。像用戶個(gè)人信息、好友關(guān)系和群組信息等關(guān)系型數(shù)據(jù)會(huì)采用關(guān)系數(shù)據(jù)庫進(jìn)行保存，如MySql數(shù)據(jù)庫等；客戶端與IM服務(wù)器之間的鏈路狀態(tài)信息，可以鍵值對(duì)的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)到Redis中；msgstore對(duì)即時(shí)通信系統(tǒng)中最核心的消息數(shù)據(jù)提供存儲(chǔ)與同步能力，保證消息數(shù)據(jù)的時(shí)效性與漫游能力，需要采用高效且最好支持該場(chǎng)景應(yīng)用的非關(guān)系型數(shù)據(jù)庫，比如阿里云TableStore表格存儲(chǔ)數(shù)據(jù)庫，該數(shù)據(jù)庫支持一種專門針對(duì)消息信息的TimeLine模型，非常適合消息數(shù)據(jù)的同步存儲(chǔ)，在容量上也沒有并發(fā)瓶頸的限制，且支持根據(jù)用戶屬性關(guān)系動(dòng)態(tài)地建立或變更關(guān)系數(shù)據(jù)表；最后，MQ消息隊(duì)列作為中間件是很多中大型分布式系統(tǒng)中重要的組件，它主要用來處理應(yīng)用解耦、異步消息、流量削峰等問題，用以實(shí)現(xiàn)高性能、高可用、可伸縮和最終一致性架構(gòu)。在IM系統(tǒng)中，即時(shí)消息屬于高吞吐情形，直接操縱消息數(shù)據(jù)很容易使其啟機(jī)，所以消息信息在落地入庫前，可以引入MQ消息隊(duì)列，將消息信息先扔到MQ消息隊(duì)列中，再由消息處理服務(wù)有節(jié)奏地存儲(chǔ)到msgstore中。

3 結(jié)束語

本文分析設(shè)計(jì)了一種即時(shí)通信系統(tǒng)架構(gòu)模型，該模型架構(gòu)共分為四層：客戶層、接口層、邏輯層和數(shù)據(jù)層。客戶層主要負(fù)責(zé)提供用戶與服務(wù)器的交互；接口層主要為客戶端與IM服務(wù)建立正確可靠穩(wěn)定的連接；邏輯層提供了IM系統(tǒng)服務(wù)對(duì)即時(shí)消息的處理；最后，數(shù)據(jù)層對(duì)整個(gè)系統(tǒng)產(chǎn)生的不同數(shù)據(jù)進(jìn)行持久化。該架構(gòu)為即時(shí)通信系統(tǒng)微服務(wù)化的開發(fā)、部署和運(yùn)用方式提供了理論模型支持。

[參考文獻(xiàn)]

[1]郭海生，洪龍.簡(jiǎn)論P(yáng)2P系統(tǒng)的C/S特征[J].信息系統(tǒng)工程，2010（10）：93-95.

[2]葉為正，林聲肯，黃立軒，等.即時(shí)通訊系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)技術(shù)與發(fā)展，2020，30（②）：216-220.

[3]李仲岐.基于WebSocket即時(shí)通信系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[c]//第三十七屆中國(guó)（天津）2023'IT、網(wǎng)絡(luò)、信息技術(shù)、電子、儀器儀表創(chuàng)新學(xué)術(shù)會(huì)議論文集，2023：129-131.

[4]肖鎮(zhèn).基于Java語言的移動(dòng)設(shè)備即時(shí)通信軟件設(shè)計(jì)[J].電腦編程技巧與維護(hù)，2024（6）：60-62.

[5]張雷.基于0SS的云存儲(chǔ)應(yīng)用研究[J].電腦編程技巧與維護(hù)，2024（12）：104-106.