微服務化的即時通信系統架構分析與設計

0 引言

近些年，隨著互聯網技術的發展，越來越多應用軟件逐漸將即時通信服務與本業務相黏合，來提高本應用的交互效率。而運用傳統技術開發單體即時通信系統，一是開發周期過于繁雜，不適合與現階段主流線上產品搭配使用，二是在吞吐并發支持量上也沒法隨訪問量動態提高。伴隨著微服務軟件架構技術的不斷成熟，本文將以此設計出一種輕量級、高可靠、低成本的即時通信架構方案。

1即時通信的基本技術原理

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

C/S結構是以服務器為中心將網絡上多個不同客戶機連接在一起，服務器與客戶機以“兩層”物理形式分別完成不同的功能。但在多客戶機并行訪問下，會涉及數據的存儲變更及服務器被多用戶并行訪問控制等問題。因此，采取一種“三層\"的C/S架構更為合理[2]。“三層\"的C/S并不是將物理結構多抽出來一種，而是在服務端設計出“一層”專門負責存儲數據的持久層。“三層\"C/S結構中客戶端主要服務用戶交互，服務端邏輯處理層對信息進行邏輯處理，服務端數據層負責信息數據的管理。

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

當下，比較流行的IM系統都是組合使用C/S模式和P2P模式，利用服務器來實現傳輸信息的管控和漫游，以構建出虛擬P2P通信。用戶在使用系統時通過C/S架構的服務器端保存用戶之間的鏈路狀態，以便用戶以后進行通信時可以直接從服務器獲取自己及其他用戶之間的鏈路信息，進而快速完成信息的轉發與投遞，實現用戶之間點對點通信。

2 即時通信系統架構的分析與設計

對于一個即時通信系統，消息傳輸會經過客戶端接入服務器進行消息處理，在處理過程中，會按照用戶限定的關系進行發送投遞；在存儲與同步過程中，針對消息的不同屬性需要選擇不同種類的存儲數據庫。因此，客戶端（Client）使用不同的平臺經過不同協議接入服務器端，而微服務化下服務器端可以設計出接入服務器（Interface）、消息處理服務器（Logic）以及數據存儲層（DataBase）這三層，再在每層定義不同功能的微服務模塊，模塊之間使用不同通信方式進行解耦。其架構模型設計如圖1所示，架構相關服務名詞說明如表1所示，不同服務間相互調用與傳輸方法說明如表2所示。

注： ① long polling：HTTP長輪詢，指服務器將保留瀏覽器請求的響應，一旦服務器有更新就發送它，然后客戶機可以發送另一個請求。

2.1 客戶端服務層

客戶端服務層主要提供與用戶交互的服務，主要包括PC端、Web瀏覽器和手機移動端三種平臺。不同平臺在獲取與消息服務器構建的連接時一般使用的傳輸協議也不同。

在瀏覽器使用IM服務時，由于現在的瀏覽器Web網站大多都已采用HTML5標準規范，所以在網絡傳輸協議上也支持websocket協議，websocket是一種全雙工通信的協議，通過http解析一個upgrade請求與服務器“握手”，形成一條持久且快速的通道，客戶端和服務端都可以主動推送消息，可以是文本數據也可以是二進制數據，而且沒有同源策略的限制，不存在跨域問題[3]。

PC端和手機移動端一般都是基于本地運行系統開發而成，一般在傳輸上將數據信息通過一定的應用層級編解碼后直接使用TCP或UDP兩種基礎協議傳輸。TCP協議能夠提供可靠的數據傳輸，它通過“三次握手\"的過程來構建一個虛擬連接通道實現信息數據交互，當數據包在交付期間遭到破壞丟失或變得無序時，TCP協議可以通過為其發送的每個數據包提供一個序號來完成此恢復。不過，UDP可以爭用網絡通道，而且不需要在傳輸信息之前構建數據通道，因此它的傳輸過程非常快。要保證消息完整不丟包，IM系統可以TCP協議來構建穩定可靠的網絡通道[4]。

2.2 接口服務層

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

客戶端在接入IM服務器時，會根據請求的信息將用戶的調用需求映射至不同的服務上，這個過程也叫路由。路由服務負責對請求的處理過程進行干預，實現請求校驗、服務聚合等過濾功能，在集群部署下，也把請求分發到同一服務的多個節點上，實現系統服務的負載均衡。

消息接入服務在架構上屬于連接客戶端和消息處理服務的中間件，能夠針對不同平臺的客戶端傳輸協議統一進行傳輸數據的編解碼。在IM服務器部署運行之后，面對復雜的網絡狀況時，消息接入服務必須能夠提供高性能和高可用性的網絡通信服務。

IM服務系統在實際使用中，還會涉及圖片和音視頻等大文件富媒體消息。對于富媒體消息的處理，IM系統服務器生成一個與富媒體消息對應的文本消息體，文本消息體中包含富媒體消息存儲的地址信息及其他相關屬性。客戶端在發送時都是將該富媒體消息對應的文本消息發送至IM服務器，而富媒體消息本身則存儲到單獨的服務中，在客戶端接收這類消息時，就可以根據消息地址去拉取富媒體文件，過程如圖2所示。當下，由于云計算技術的發展，針對大文件富媒體信息的存儲都會選擇第三方云平臺服務，將圖片和音視頻保存在遠端，以輕量化本地服務器存儲[5]。

2.3 邏輯處理層

邏輯處理層用來實現對客戶端請求的邏輯處理，完成相關處理方法的映射和對數據層數據的管理調用，該層涉及的服務主要有業務關系服務（relationshipserver）、消息處理服務（messageserver）。

IM系統服務在運行功能上是基于消息收發的場景，所以會涉及用戶“好友”關系的管理，客戶端在使用消息服務時要能構建起“交流圈”進行消息“生產\"和“消費”。由于沒有消息數據方面的處理，關系服務的調用方式一般是在客戶端通過路由確定該服務后，直接運用RPC或Restful方式調用響應，之后再通過同樣的方式調用數據庫服務完成數據的持久化存儲。

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

2.4 數據存儲層

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

3 結束語

本文分析設計了一種即時通信系統架構模型，該模型架構共分為四層：客戶層、接口層、邏輯層和數據層。客戶層主要負責提供用戶與服務器的交互；接口層主要為客戶端與IM服務建立正確可靠穩定的連接；邏輯層提供了IM系統服務對即時消息的處理；最后，數據層對整個系統產生的不同數據進行持久化。該架構為即時通信系統微服務化的開發、部署和運用方式提供了理論模型支持。

[參考文獻]

[1]郭海生，洪龍.簡論P2P系統的C/S特征[J].信息系統工程，2010（10）：93-95.

[2]葉為正，林聲肯，黃立軒，等.即時通訊系統的設計與實現[J].計算機技術與發展，2020，30（②）：216-220.

[3]李仲岐.基于WebSocket即時通信系統設計與實現[c]//第三十七屆中國（天津）2023'IT、網絡、信息技術、電子、儀器儀表創新學術會議論文集，2023：129-131.

[4]肖鎮.基于Java語言的移動設備即時通信軟件設計[J].電腦編程技巧與維護，2024（6）：60-62.

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