張勇+裴東良+張會(huì)兵

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

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

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

0引言

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

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

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

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

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

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

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

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

整個(gè)路由過程流程為：

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

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

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

2.2定義

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

1）消息

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

2）域名

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

3）消息隊(duì)列

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

4）策略

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

2.3路由算法設(shè)計(jì)

（1）基本原則

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

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

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

（2）路由算法

1）符號(hào)定義

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

2）路由算法

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

3動(dòng)態(tài)路由

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

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

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

4結(jié)論

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