即時(shí)通信（InstantMessaging，IM）服務(wù)基礎(chǔ)架構(gòu)從早期的C/S、P2P架構(gòu)發(fā)展到現(xiàn)在已變成一個(gè)復(fù)雜的分布式系統(tǒng)，而微服務(wù)化的系統(tǒng)架構(gòu)是未來(lái)軟件系統(tǒng)發(fā)展的方向?；诖耍芯苛思磿r(shí)通信的基本技術(shù)原理，分析了即時(shí)通信系統(tǒng)微服務(wù)化的架構(gòu)和服務(wù)間的通信方式，設(shè)計(jì)出一種分層的即時(shí)通信系統(tǒng)微服務(wù)架構(gòu)，為基于微服務(wù)架構(gòu)開(kāi)發(fā)即時(shí)通信服務(wù)提供了清晰的架構(gòu)模型。近些年，隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，越來(lái)越多應(yīng)用軟件逐漸將即時(shí)通信服務(wù)與本業(yè)務(wù)相黏合，來(lái)提高本應(yīng)用的交互效率。而運(yùn)用傳統(tǒng)技術(shù)開(kāi)發(fā)單體即時(shí)通信系統(tǒng)，一是開(kāi)發(fā)周期過(guò)于繁雜，不適合與現(xiàn)階段主流線上產(chǎn)品搭配使用，二是在吞吐并發(fā)支持量上也沒(méi)法隨訪問(wèn)量動(dòng)態(tài)提高。伴隨著微服務(wù)軟件架構(gòu)技術(shù)的不斷成熟，本文將以此設(shè)計(jì)出一種輕量級(jí)、高可靠、低成本的即時(shí)通信架構(gòu)方案。一、即時(shí)通信的基本技術(shù)原理當(dāng)前對(duì)蘋果品質(zhì)的檢測(cè)工作主要依靠人工完成，但是人工檢測(cè)會(huì)存在誤判、效率低和成本高問(wèn)題，且對(duì)于后期的水果分揀工作也存在效率和準(zhǔn)確率低的問(wèn)題。即時(shí)通信是一種基于Internet的交互技術(shù)，涉及IP、TCP、UDP、套接字（Socket）及通信過(guò)程中傳輸數(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ī)并行訪問(wèn)下，會(huì)涉及數(shù)據(jù)的存儲(chǔ)變更及服務(wù)器被多用戶并行訪問(wèn)控制等問(wèn)題。因此，采取一種“三層”的C/S架構(gòu)更為合理[2]?！叭龑印钡腃/S并不是將物理結(jié)構(gòu)多抽出來(lái)一種，而是在服務(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ú)中心服務(wù)器的對(duì)等模式，與有中心服務(wù)器的中央服務(wù)系統(tǒng)不同，每個(gè)用戶端節(jié)點(diǎn)既是服務(wù)的提供者又是服務(wù)的使用者，節(jié)點(diǎn)之間直接通信可以充分利用網(wǎng)絡(luò)資源，減少網(wǎng)絡(luò)阻塞情況。且無(wú)中央服務(wù)器集中管理，系統(tǒng)能夠有效避免單點(diǎn)故障所帶來(lái)的問(wèn)題，大大提高了系統(tǒng)容錯(cuò)性能。不過(guò)，P2P模式有分散性、自治性和動(dòng)態(tài)性等特點(diǎn)，造成了在一些情況下用戶訪問(wèn)結(jié)果的不確定性。當(dāng)下，比較流行的IM系統(tǒng)都是組合使用C/S模式和P2P模式，利用服務(wù)器來(lái)實(shí)現(xiàn)傳輸信息的管控和漫游，以構(gòu)建出虛擬P2P通信。用戶在使用系統(tǒng)時(shí)通過(guò)C/S架構(gòu)的服務(wù)器端保存用戶之間的鏈路狀態(tài)，以便用戶以后進(jìn)行通信時(shí)可以直接從服務(wù)器獲取自己及其他用戶之間的鏈路信息，進(jìn)而快速完成信息的轉(zhuǎn)發(fā)與投遞，實(shí)現(xiàn)用戶之間點(diǎn)對(duì)點(diǎn)通信。二、即時(shí)通信系統(tǒng)架構(gòu)的分析與設(shè)計(jì)對(duì)于一個(gè)即時(shí)通信系統(tǒng)，消息傳輸會(huì)經(jīng)過(guò)客戶端接入服務(wù)器進(jìn)行消息處理，在處理過(guò)程中，會(huì)按照用戶限定的關(guān)系進(jìn)行發(fā)送投遞；在存儲(chǔ)與同步過(guò)程中，針對(duì)消息的不同屬性需要選擇不同種類的存儲(chǔ)數(shù)據(jù)庫(kù)。因此，客戶端（Client）使用不同的平臺(tái)經(jīng)過(guò)不同協(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ù)名詞說(shuō)明如表1所示，不同服務(wù)間相互調(diào)用與傳輸方法說(shuō)明如表2所示。注：①longpolling：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é)議，通過(guò)http解析一個(gè)upgrade請(qǐng)求與服務(wù)器“握手”，形成一條持久且快速的通道，客戶端和服務(wù)端都可以主動(dòng)推送消息，可以是文本數(shù)據(jù)也可以是二進(jìn)制數(shù)據(jù)，而且沒(méi)有同源策略的限制，不存在跨域問(wèn)題[3]。PC端和手機(jī)移動(dòng)端一般都是基于本地運(yùn)行系統(tǒng)開(kāi)發(fā)而成，一般在傳輸上將數(shù)據(jù)信息通過(guò)一定的應(yīng)用層級(jí)編解碼后直接使用TCP或UDP兩種基礎(chǔ)協(xié)議傳輸。TCP協(xié)議能夠提供可靠的數(shù)據(jù)傳輸，它通過(guò)“三次握手”的過(guò)程來(lái)構(gòu)建一個(gè)虛擬連接通道實(shí)現(xiàn)信息數(shù)據(jù)交互，當(dāng)數(shù)據(jù)包在交付期間遭到破壞丟失或變得無(wú)序時(shí)，TCP協(xié)議可以通過(guò)為其發(fā)送的每個(gè)數(shù)據(jù)包提供一個(gè)序號(hào)來(lái)完成此恢復(fù)。不過(guò)，UDP可以爭(zhēng)用網(wǎng)絡(luò)通道，而且不需要在傳輸信息之前構(gòu)建數(shù)據(jù)通道，因此它的傳輸過(guò)程非?？?。要保證消息完整不丟包，IM系統(tǒng)可以TCP協(xié)議來(lái)構(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è)過(guò)程也叫路由。路由服務(wù)負(fù)責(zé)對(duì)請(qǐng)求的處理過(guò)程進(jìn)行干預(yù)，實(shí)現(xiàn)請(qǐng)求校驗(yàn)、服務(wù)聚合等過(guò)濾功能，在集群部署下，也把請(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ù)消息地址去拉取富媒體文件，過(guò)程如圖2所示。當(dāng)下，由于云計(jì)算技術(shù)的發(fā)展，針對(duì)大文件富媒體信息的存儲(chǔ)都會(huì)選擇第三方云平臺(tái)服務(wù)，將圖片和音視頻保存在遠(yuǎn)端，以輕量化本地服務(wù)器存儲(chǔ)[5]。2.3、邏輯處理層邏輯處理層用來(lái)實(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)”。由于沒(méi)有消息數(shù)據(jù)方面的處理，關(guān)系服務(wù)的調(diào)用方式一般是在客戶端通過(guò)路由確定該服務(wù)后，直接運(yùn)用RPC或Restful方式調(diào)用響應(yīng)，之后再通過(guò)同樣的方式調(diào)用數(shù)據(jù)庫(kù)服務(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)。過(guò)去常將消息處理服務(wù)與接口服務(wù)層的接入服務(wù)融為一體，而隨著用戶數(shù)量的不斷增長(zhǎng)，消息處理的接入服務(wù)能力成為瓶頸。隨著不少像Kafka、RabbitMQ等優(yōu)秀的開(kāi)源消息隊(duì)列（MQ）誕生，可以引入消息隊(duì)列（MQ）使接入服務(wù)和真正的消息處理模塊相解耦，在大量消息到達(dá)消息處理服務(wù)后如來(lái)不及處理可暫緩至消息隊(duì)列中，防止消息丟失。圖3給出了消息處理服務(wù)與其他相關(guān)服務(wù)的調(diào)用模型，可以看出消息處理服務(wù)（messageserver）是IM系統(tǒng)的核心，傳輸接入服務(wù)（gateserver）、業(yè)務(wù)關(guān)系服務(wù)（relationshipserver）和消息存儲(chǔ)（msgstore）都會(huì)通過(guò)消息隊(duì)列（MQ）或方法調(diào)用（RPC/Restful）與消息處理服務(wù)（messageserver）相交互。2.4、數(shù)據(jù)存儲(chǔ)層由于IM系統(tǒng)的適用場(chǎng)景使其會(huì)有多種不同形式的數(shù)據(jù)源，因此在數(shù)據(jù)庫(kù)的選擇上采取多種不同的數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)這些數(shù)據(jù)信息。像用戶個(gè)人信息、好友關(guān)系和群組信息等關(guān)系型數(shù)據(jù)會(huì)采用關(guān)系數(shù)據(jù)庫(kù)進(jìn)行保存，如MySql數(shù)據(jù)庫(kù)等；客戶端與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ù)庫(kù)，比如阿里云TableStore表格存儲(chǔ)數(shù)據(jù)庫(kù)，該數(shù)據(jù)庫(kù)支持一種專門針對(duì)消息信息的TimeLine模型，非常適合消息數(shù)據(jù)的同步存儲(chǔ)，在容量上也沒(méi)有并發(fā)瓶頸的限制，且支持根據(jù)用戶屬性關(guān)系動(dòng)態(tài)地建立或變更關(guān)系數(shù)據(jù)表；最后，MQ消息隊(duì)列作為中間件是很多中大型分布式系統(tǒng)中重要的組件，它主要用來(lái)處理應(yīng)用解耦、異步消息、流量削峰等問(wèn)題，用以實(shí)現(xiàn)高性能、高可用、可伸縮和最終一致性架構(gòu)。在IM系統(tǒng)中，即時(shí)消息屬于高吞吐情形，直接操縱消息數(shù)據(jù)很容易使其宕機(jī)，所以消息信息在落地入庫(kù)前，可以引入MQ消息隊(duì)列，將消息信息先扔到MQ消息隊(duì)列中，再由消息處