消息傳輸系統研究

張勇+裴東良+張會兵

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

關鍵詞：消息傳輸；路由；隊列

中圖分類號：TP312 文獻標識碼：A DOI：10.3969/j.issn.1003-6970.2016.03.013

0引言

軟件系統之間的消息傳輸有兩種解決方案：一種解決方案為：數據傳輸由兩個軟件系統之間協調完成，常用方式有Web Service；一種方案為：建立獨立的消息傳輸系統，作為各個軟件系統之間進行消息（數據）傳輸的橋梁，類似郵局的功能。兩種方式適用范圍不同。第二種方式適用了業務量大，業務軟件較多、部署結構復雜的情況。

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

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

1系統構建

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

2路由機制設計

2.1路由單元結構設計

消息傳輸系統中的路由單元由三部分組成：路由計算模塊、策略庫和消息轉發模塊。路由計算模塊負責根據接收方地址與當前消息傳輸系統地址進行計算，得出策略代碼，并根據策略代碼查找策略庫，得出下一跳地址；策略庫中存儲的路由策略；消息轉發模塊負責根據下一跳地址發送給指定的接收方。

整個路由過程流程為：

（1）消息傳輸系統中的消息監聽單元負責監聽本傳輸系統中本地隊列中的輸入隊列，發現消息即將此消息傳遞給路由計算模塊；

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

（3）消息轉發模塊根據下一跳的地址將消息發送給指定的接收方。

2.2定義

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

1）消息

在消息的格式中，本文僅關注核心的消息接收方部分的內容。消息接收方分為兩部分：接收方列表Dperm、臨時接收方列表Dtemp。Dperm是由消息發送方在發送消息時寫入的，代表了當前消息的所有接收方。Dtemp是由消息傳輸系統在進行消息轉發時寫入的，代表了消息的臨時接收方。Dperm和Dtemp都是一個數組，由接收方地址組成，如下所示：

2）域名

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

3）消息隊列

每個消息傳輸系統在部署完成后都會初始化一部分消息隊列。這些消息隊列分為兩類：業務應用隊列和系統隊列。業務應用隊列是與該消息傳輸每一類隊列又分為兩個子類：IN隊列和OUT隊列。IN隊列是接收消息的隊列，即消息傳輸系統將消息放到接收方的IN隊列，接收方負責監聽此隊列，并在消息來到時進行消費。OUT隊列是發送消息的隊列，消息發送方將消息發送至自己的OUT隊列，消息傳輸系統負責監聽所有的OUT隊列，并在有消息時進行消費。

4）策略

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

2.3路由算法設計

（1）基本原則

消息的傳輸路徑與消息傳輸系統的部署框架存在一定關系，因此，在第2章節所描述的系統部署架構的下，路由算法有兩個基本原則：

1）任意兩個業務系統之間不能直接收發消息，必須將消息發送給所屬的消息傳輸系統，由消息傳輸系統負責完成消息的存儲轉發。

2）不同域的消息傳輸系統之間不能直接進行消息的收發，必須通過上級消息傳輸系統完成，如長沙的業務系統需要向杭州的業務系統發送消息時，只能通“長沙->湖南->中央->浙江->浙江”的路由進行消息轉發。

（2）路由算法

1）符號定義

dpdomi：表示當前消息的第i個接收方的域名；Mdom：表示當前消息傳輸系統的域名

2）路由算法

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

3動態路由

在前面的消息傳輸的分析和研究中，主要考慮消息的正向傳輸過程中的核心問題：消息是如何進行路由選擇的，而并未考慮作為消息接收方的業務系統在整個消息傳輸過程中的作用。不管是接受消息的業務系統還是進行存儲轉發的消息傳輸系都具有動態調整自身接受消息策略的需求。尤其對于作為橋梁的消息傳輸系統。為了保證消息傳輸的高效性和安全性，為每個業務系統都不止分配一個接受隊列。在正常的消息傳輸過程中，消息傳輸模塊是按照下一跳的地址進行轉發時，是隨機發送到下一跳系統任意一個隊列中，以用隨機的方式保證各隊列的負載均衡。隨機性的缺陷是很明顯的，如果隨機選擇的隊列已經負載很大或者根本不可用時，就需要將當前的消息轉發至其他隊列中的一個，達到真正的負載均衡的效果。此外，也存在業務系統不需要接收消息的需求，此時可通知消息傳輸系統，不再發送消息。

針對上述需求，在第3節所述結構的基礎上，增加隊列庫，隊列的使用方及消息傳輸系統對隊列的狀態進行實時更新，消息轉發模塊在轉發時，查詢隊列庫，并根據各個隊列的實時狀態，擇優選擇目的隊列。其結構如圖4所示。

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

4結論

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