消息傳輸系統(tǒng)研究

張勇+裴東良+張會兵

摘要：針對目前軟件系統(tǒng)之間的消息傳輸解決方案中存在的缺陷，提出了一種消息傳輸系統(tǒng)，并對其核心的路由單元進(jìn)行了分析和設(shè)計。此外，建立了基于隊列庫的動態(tài)路由機(jī)制。該消息傳輸系統(tǒng)可支持多級分布式部署的軟件系統(tǒng)之間的消息存儲轉(zhuǎn)發(fā)，且部署、維護(hù)、配置、集成都極其便捷。

關(guān)鍵詞：消息傳輸；路由；隊列

中圖分類號：TP312 文獻(xiàn)標(biāo)識碼：A DOI：10.3969/j.issn.1003-6970.2016.03.013

0引言

軟件系統(tǒng)之間的消息傳輸有兩種解決方案：一種解決方案為：數(shù)據(jù)傳輸由兩個軟件系統(tǒng)之間協(xié)調(diào)完成，常用方式有Web Service；一種方案為：建立獨立的消息傳輸系統(tǒng)，作為各個軟件系統(tǒng)之間進(jìn)行消息（數(shù)據(jù)）傳輸?shù)臉蛄?，類似郵局的功能。兩種方式適用范圍不同。第二種方式適用了業(yè)務(wù)量大，業(yè)務(wù)軟件較多、部署結(jié)構(gòu)復(fù)雜的情況。

目前，對于上述第二種實現(xiàn)方式，一般都采用商用的消息中間件來實現(xiàn)，如ActiveMQ、TLQ等。但無一例外的，都需要進(jìn)行二次開發(fā)，且還需要在這些消息中間件上進(jìn)行手動的配置（如建立收發(fā)隊列）。如果面對軟件系統(tǒng)多、部署情況復(fù)雜的情況，這種方式則表現(xiàn)出部署復(fù)雜、配置共工作量大、不易維護(hù)等缺點。

針對上述情況，本文提出了一種消息傳輸系統(tǒng)，并對核心的路由單元進(jìn)行分析和設(shè)計。該系統(tǒng)可支持多級分布式部署的軟件系統(tǒng)之間的消息存儲轉(zhuǎn)發(fā)，且部署、維護(hù)、配置、集成都極其便捷。

1系統(tǒng)構(gòu)建

消息傳輸系統(tǒng)是按照分布式部署方式進(jìn)行設(shè)計的，可根據(jù)實際情況進(jìn)行部署，如可按“中央一省級”兩級部署，也可按照“中央一省級一市級”三級部署。理論上，部署層級是無限制的。考慮到現(xiàn)實情況，按照三級部署基本可滿足要求，其部署結(jié)構(gòu)如圖1所示。在整個傳輸系統(tǒng)中，有三個角色：消息發(fā)送方系統(tǒng)、消息接收方系統(tǒng)、消息傳輸系統(tǒng)。消息發(fā)送方系統(tǒng)通過消息傳輸系統(tǒng)提供的API將消息發(fā)送至消息傳輸系統(tǒng)的消息接收隊列；消息傳輸系統(tǒng)監(jiān)聽發(fā)送隊列情況，發(fā)現(xiàn)有新到的消息則將消息取出，并進(jìn)行路由計算，如果是消息接收方為同一個域內(nèi)的業(yè)務(wù)系統(tǒng)，則直接將消息插入到消息接收方的隊列中；如果消息接收方是上級域或者是同級非同域的業(yè)務(wù)系統(tǒng)時，則把消息轉(zhuǎn)發(fā)給上級消息傳輸系統(tǒng)，由上級傳輸系統(tǒng)按照上述邏輯繼續(xù)進(jìn)行消息的存儲轉(zhuǎn)發(fā)。消息接收方監(jiān)聽自己的隊列中是否有消息，如果有，則取走消息進(jìn)行消費。

2路由機(jī)制設(shè)計

2.1路由單元結(jié)構(gòu)設(shè)計

消息傳輸系統(tǒng)中的路由單元由三部分組成：路由計算模塊、策略庫和消息轉(zhuǎn)發(fā)模塊。路由計算模塊負(fù)責(zé)根據(jù)接收方地址與當(dāng)前消息傳輸系統(tǒng)地址進(jìn)行計算，得出策略代碼，并根據(jù)策略代碼查找策略庫，得出下一跳地址；策略庫中存儲的路由策略；消息轉(zhuǎn)發(fā)模塊負(fù)責(zé)根據(jù)下一跳地址發(fā)送給指定的接收方。

整個路由過程流程為：

（1）消息傳輸系統(tǒng)中的消息監(jiān)聽單元負(fù)責(zé)監(jiān)聽本傳輸系統(tǒng)中本地隊列中的輸入隊列，發(fā)現(xiàn)消息即將此消息傳遞給路由計算模塊；

（2）路由計算模塊獲取消息，并對消息進(jìn)行解析，取出消息接收方（一條消息可能有多個接收方），地址并與本傳輸系統(tǒng)的地址進(jìn)行計算，得出策略代碼；然后根據(jù)策略代碼查詢策略庫，得出下一跳的地址；并將消息重新包裝，傳遞給消息轉(zhuǎn)發(fā)模塊；

（3）消息轉(zhuǎn)發(fā)模塊根據(jù)下一跳的地址將消息發(fā)送給指定的接收方。

2.2定義

為方面后續(xù)的算法說明，做以下名稱和符號的定義及說明

1）消息

在消息的格式中，本文僅關(guān)注核心的消息接收方部分的內(nèi)容。消息接收方分為兩部分：接收方列表Dperm、臨時接收方列表Dtemp。Dperm是由消息發(fā)送方在發(fā)送消息時寫入的，代表了當(dāng)前消息的所有接收方。Dtemp是由消息傳輸系統(tǒng)在進(jìn)行消息轉(zhuǎn)發(fā)時寫入的，代表了消息的臨時接收方。Dperm和Dtemp都是一個數(shù)組，由接收方地址組成，如下所示：

2）域名

由于消息傳輸系統(tǒng)是按照行政級別的方式進(jìn)行分級部署的，每一級的應(yīng)用系統(tǒng)都通過本級的消息傳輸系統(tǒng)進(jìn)行消息的收發(fā)。因此，需要對消息傳輸系統(tǒng)的管轄范圍進(jìn)行定義，這就是域名（domain）的概念，用符號D_om表示，取值為國家標(biāo)準(zhǔn)的域名庫。域名通過點分制的字符串來描述，每一段代表了一個行政級別，如浙江省的域名zj.cn，石家莊的域名的sjz.he.cn

3）消息隊列

每個消息傳輸系統(tǒng)在部署完成后都會初始化一部分消息隊列。這些消息隊列分為兩類：業(yè)務(wù)應(yīng)用隊列和系統(tǒng)隊列。業(yè)務(wù)應(yīng)用隊列是與該消息傳輸每一類隊列又分為兩個子類：IN隊列和OUT隊列。IN隊列是接收消息的隊列，即消息傳輸系統(tǒng)將消息放到接收方的IN隊列，接收方負(fù)責(zé)監(jiān)聽此隊列，并在消息來到時進(jìn)行消費。OUT隊列是發(fā)送消息的隊列，消息發(fā)送方將消息發(fā)送至自己的OUT隊列，消息傳輸系統(tǒng)負(fù)責(zé)監(jiān)聽所有的OUT隊列，并在有消息時進(jìn)行消費。

4）策略

策略用一組代碼來指明符合特定代碼的下一跳的地址。策略用符號T表示，T是一個二元組，由策略代碼、下一跳地址組成，分別使用c和N表示。如下所示：

2.3路由算法設(shè)計

（1）基本原則

消息的傳輸路徑與消息傳輸系統(tǒng)的部署框架存在一定關(guān)系，因此，在第2章節(jié)所描述的系統(tǒng)部署架構(gòu)的下，路由算法有兩個基本原則：

1）任意兩個業(yè)務(wù)系統(tǒng)之間不能直接收發(fā)消息，必須將消息發(fā)送給所屬的消息傳輸系統(tǒng)，由消息傳輸系統(tǒng)負(fù)責(zé)完成消息的存儲轉(zhuǎn)發(fā)。

2）不同域的消息傳輸系統(tǒng)之間不能直接進(jìn)行消息的收發(fā)，必須通過上級消息傳輸系統(tǒng)完成，如長沙的業(yè)務(wù)系統(tǒng)需要向杭州的業(yè)務(wù)系統(tǒng)發(fā)送消息時，只能通“長沙->湖南->中央->浙江->浙江”的路由進(jìn)行消息轉(zhuǎn)發(fā)。

（2）路由算法

1）符號定義

dpdomi：表示當(dāng)前消息的第i個接收方的域名；Mdom：表示當(dāng)前消息傳輸系統(tǒng)的域名

2）路由算法

在3.2節(jié)及上述定義的之下，路由算法如圖3所示。

3動態(tài)路由

在前面的消息傳輸?shù)姆治龊脱芯恐?，主要考慮消息的正向傳輸過程中的核心問題：消息是如何進(jìn)行路由選擇的，而并未考慮作為消息接收方的業(yè)務(wù)系統(tǒng)在整個消息傳輸過程中的作用。不管是接受消息的業(yè)務(wù)系統(tǒng)還是進(jìn)行存儲轉(zhuǎn)發(fā)的消息傳輸系都具有動態(tài)調(diào)整自身接受消息策略的需求。尤其對于作為橋梁的消息傳輸系統(tǒng)。為了保證消息傳輸?shù)母咝院桶踩?，為每個業(yè)務(wù)系統(tǒng)都不止分配一個接受隊列。在正常的消息傳輸過程中，消息傳輸模塊是按照下一跳的地址進(jìn)行轉(zhuǎn)發(fā)時，是隨機(jī)發(fā)送到下一跳系統(tǒng)任意一個隊列中，以用隨機(jī)的方式保證各隊列的負(fù)載均衡。隨機(jī)性的缺陷是很明顯的，如果隨機(jī)選擇的隊列已經(jīng)負(fù)載很大或者根本不可用時，就需要將當(dāng)前的消息轉(zhuǎn)發(fā)至其他隊列中的一個，達(dá)到真正的負(fù)載均衡的效果。此外，也存在業(yè)務(wù)系統(tǒng)不需要接收消息的需求，此時可通知消息傳輸系統(tǒng)，不再發(fā)送消息。

針對上述需求，在第3節(jié)所述結(jié)構(gòu)的基礎(chǔ)上，增加隊列庫，隊列的使用方及消息傳輸系統(tǒng)對隊列的狀態(tài)進(jìn)行實時更新，消息轉(zhuǎn)發(fā)模塊在轉(zhuǎn)發(fā)時，查詢隊列庫，并根據(jù)各個隊列的實時狀態(tài)，擇優(yōu)選擇目的隊列。其結(jié)構(gòu)如圖4所示。

其中，隊列庫的結(jié)構(gòu)如表2所示。每一個隊列是一個三元組Q=。Code使用方的代碼。Queue是隊列名，隊列分為兩類，發(fā)送隊列（OUT開頭），接收隊列（IN開頭）。Status是狀態(tài)，0表示不可用，其他值代表當(dāng)前隊列中待消費的消息數(shù)。業(yè)務(wù)系統(tǒng)僅維護(hù)自己的IN隊列，即如果不需要接收消息，則設(shè)置其OUT隊列的status狀態(tài)為0。消息傳輸系統(tǒng)維護(hù)所有的IN和OUT隊列，如果業(yè)務(wù)系統(tǒng)的IN隊列已經(jīng)設(shè)置為0，則不進(jìn)行維護(hù)。隊列庫可以實時反映當(dāng)前所有的隊列的負(fù)載情況，消息轉(zhuǎn)發(fā)模塊在進(jìn)行消息轉(zhuǎn)發(fā)時，通過查詢隊列庫，選擇合適的隊列進(jìn)行消息的發(fā)送，均衡負(fù)載，實現(xiàn)動態(tài)路由。

4結(jié)論

通過對軟件系統(tǒng)之間的消息傳輸方式進(jìn)行分析，指出目前常用的解決方案的缺陷。針對上述缺陷，提出了一種分布式跨級的消息傳輸系統(tǒng)。在上述基礎(chǔ)上，對消息傳輸系統(tǒng)中的核心部分一路由單元的架構(gòu)進(jìn)行了設(shè)計，建立了基于策略庫和隊列庫的路由算法集。該系統(tǒng)的彈性部署方式可應(yīng)對絕大多數(shù)的應(yīng)用場景，且部署、維護(hù)、配置、集成、性能方面都有一定的優(yōu)勢。