基于ZeroMQ&JSON的SOA網絡傳輸中間件研究

黃江 張李超 王森林 郭強強 李萌

（華中科技大學 湖北省武漢市 430074）

隨著互聯網技術的發展和業務需求的擴張，分布式系統成為現代軟件架構設計的熱點。傳統的單體架構、垂直架構雖然結構簡單，但是不易擴展，能夠承接的業務復雜度有限，因此分布式系統應運而生。分布式系統由一組通過計算機網絡鏈接、自治的、配備了分布式系統軟件的計算機組合而成。近年來，基于服務的架構(SOA)、基于微服務的架構的提出更是將分布式系統推向了高潮。

分布式系統最重要的就是進程（位于同一臺或多臺計算機）之間的通信。進程間的通信機制主要有：

（1）使用基于同步請求/響應的通信機制，如REST 風格的HTTP、gRPC；

（2）使用異步的基于消息的通信機制，如高級消息隊列協議（AMQP）、流文本定向消息協議（STOMP）。[1]

消息隊列經常被用來設計分布式系統的通信系統。陳瑤基于ActiveMQ 設計實現了一個數據傳輸框架[2]；汪然基于ActiveMQ實現了消息中間件系統[3]；孟承、王建基于RabbitMQ 實現了軟件化的雷達通信中間件[4]；袁小軍基于ZeroMQ 設計實現了分布式的3D 打印控制系統[5]；蒲鳳平基于ZeroMQ 設計實現了列車檢測系統[6]；朱民新基于ZeroMQ 實現了分布式存儲系統。

以下采用異步的消息隊列作為進程間通信的基礎，通過二次封裝，構建兩套輕量級的基于SOA 的分布式系統網絡傳輸中間件。

1 ZeroMQ&JSON

1.1 ZeroMQ

ZeroMQ 是一個基于C++ 的輕量級開源消息隊列，支持AMQP、異步、多線程。同類的

開源消息隊列還有RabbitMQ，基于Erlang 語言，同樣支持AMQP；ActiveMQ，基于java，只支持JVM 平臺，跨平臺性不好。根據Nicolas Estrada 等人[2]的研究測試，ZeroMQ 在性能和可伸縮性方面都要優于RabbitMQ，在負載增加時的退化閾值要高于后者，具有更好的可擴展性和更快的速度。

最新的ZeroMQ 提供了多種傳輸模式：客戶端-服務器模式、廣播-接收模式、發布-訂閱模式、管道模式、獨立對模式、原生模式、請求-響應模式。其中，客戶端-服務器和廣播-接受模式目前還不穩定；發布-訂閱模式用于一對多的傳輸，數據從單一的發布者發送到多個訂閱者；管道模式類似于linux 傳統的管道傳輸；獨立對模式用于兩端的單一鏈接，常用于跨線程的通信；原生模式用于底層的tcp 連接通信；請求-響應模式可用的套接字類型更多，功能更豐富，既可以通過簡單的REQ 和REP 套接字實現簡單的兩端之間的對話，也可以通過Router 和Dealer 套接字實現負載均衡和路由轉發。

在實際開發中，ZeroMQ的API雖然簡潔，但是由于相對較底層，因此各大開發語言C/C++、JAVA、PHP 等都對ZeroMQ 進行了封裝，且都是開源的。筆者選擇支持C++開發的Czmq 開源庫，該庫在gitub 中使用也是最多的。

1.2 JSON

信息的序列化和反序列化也是一個關鍵問題。序列化(Serialization)是將對象的狀態信息轉換為可以存儲或傳輸的形式的過程。序列化常用的格式有二進制格式、XML、JSON。

圖1：各JSON 庫綜合評價[10]

圖2：類的主要成員

JSON 是當下很流行的數據格式，JSON 來源于javascrpit 的對象表示方法，根據Valeriu Manuel Ionescu 對于前面提到的三種序列化格式的性能對比，當數據用JSON 編碼時，最終文件大小一般小于用XML 格式編碼的文件。并且，JSON 比另外兩者的可讀性和簡潔性更好，這也是它流行的原因。因此筆者選擇用JSON 作為參數數據的傳輸格式。

C++語言中的JSON 開源庫也有很多，根據github 中作者Milo Yip[4]對眾多JSON 庫綜合考量解析時間、占用內存、序列化時間、代碼長度、優化時間的測評（如圖1 所示），選擇騰訊公司的開源庫RappidJson。

1.3 基于C++面向對象與繼承的設計

C++面向對象的編程思想，將最原始的服務端與客戶抽象出來作為兩個對象，服務具有多樣性而請求服務具有一般性，即不同的服務將實現不同的計算處理，不同的服務請求只是變更傳輸的參數或文件。因此，將服務端實現為一個虛類，通過繼承來實現多樣化的服務，重寫(overwrite)服務的計算處理函數的一個子類即是一個具體的服務。

圖3：傳輸的主要過程

圖4：類的基本成員

2 局域網內傳輸

2.1 對象設計

局域網內傳輸由于數據不經過互聯網，只在幾臺計算機內傳輸，結構相對比較簡單。設計兩個對象：Worker（工作站）、Client（客戶端）。Worker 提供復雜的運算；Client 向Worker 發送帶有參數或文件的任務，Worker 接收任務并完成。一個任務可以只是一次計算，也可以帶有向下一個Worker 發送的任務，也就說，任務是具有遞歸性的。類的主要成員如圖2 所示，主要傳輸過程如圖3 所示。

2.2 對象UUID

為了識別系統中每一個對象的身份，區分同類型不同對象，根據套接字的特點，選擇對象（Worker/Client）的IP 地址和端口號為參數由哈希函數生成unsignedint 型的UUID,在跨局域網傳輸中尤為重要，因為Router 套接字的路由是以連接的眾多套接字的identity 選項為識別依據。

2.3 局域網內Worker的發現機制

為了解決Client 如何知道局域網某種Worker 存在且可用（不忙碌）的問題，Worker 通過廣播的方式向每一臺計算機發送自己的服務信息，包括服務名稱和自己的IP 地址。由于ZeroMQ 的底層是TCP 協議，并且內置的廣播-接收模式尚不穩定，因此選擇底層的udp 套接字進行廣播的發送和接受。

圖5：傳輸的主要過程

圖6：簡單消息結構

圖7：引入中間代理后的消息結構

Client 每次發送任務前會啟用udp 接收局域網內所有可用的Worker服務信息，并將可用服務信息保留在本地服務信息緩沖區中，下次再次發起任務時將優先查詢本地服務緩沖區。

2.4 大型文件傳輸

當Worker 與Client 在同一計算上時，文件的傳輸就沒有必要，所以每當接收端發現要接收文件時，會將JSON 字符串參數發送方的IP 與自身IP 進行比較再決定是否傳輸文件。

由于ZeroMQ 消息緩存限制，大型文件的傳輸需要進行分塊。由于Req/Rep 套接字一問一答的固定順序，且消息的傳輸具有可靠性，文件的分塊傳輸不必采用滑動窗口式的擁塞控制策略,每次向發送方回復”OK”以確定文件被準確接收，再次增強了消息傳輸的穩定性。

分塊傳輸的文件會暫存在外存，每當一塊文件到達接收端，接收端都會將文件存儲在工作路徑下的固定文件夾，文件接收完成后會返回文件路徑及文件名，作下一步計算處理。對象銷毀后將自動清除緩存文件，也可以調用cleanBuf 清除。

表1：不同大小文件傳輸時間

圖8：容量因子控制傳輸

圖9：遠程彩色3D 打印

2.5 異步

如果一個任務包含大型文件，Client 發送請求后將會阻塞很長一段時間。為了實現Client 異步請求，實現了一個簡單FIFO 隊列，隊列里存放的是Task(任務)對象。Client 發送請求時，不會直接產生動作，而是將Task 放入隊列，然后立即返回，再次詢問時可以獲悉當前任務的執行狀態。后臺線程將輪詢FIFO 隊列，存在Task時將其發送到Worker，返回后將結果放到結果緩沖區以供查詢。為了查詢的效率，用哈希值生產函數將Task 生成唯一的ID 值，作為鍵值存入哈希表。

3 跨局域網傳輸

3.1 對象設計

跨局域網的傳輸需要跨越互聯網，沒有公網IP 的設備無法進行直接通信，因此，額外設計一個中間代理Manager，中間代理需要具有可供連接的公網IP。Manager 擁有一個Router 套接字來實現消息的路由。由于三方消息傳輸中很難保證一問一答的模式，Worker/Client 將套接字改為Dealer。除了Worker 的發現機制，其它方面幾乎和局域網下一摸一樣。類的主要成員如圖4 所示，主要傳輸過程如圖5 所示。

3.2 傳輸協議設計

由于局域網下僅有Worker 和Client 的消息交互，消息結構設計比較簡潔，如圖5 所示。當有中間代理的出現時，消息的傳遞就需要Router 路由套接字的轉發，傳輸協議就相對豐富。基本結構如圖6 所示。對象類型取WORKER/CLIENT，用于區分發送消息的節點的類型；消息類型可以根據需要擴展，指代消息采取的動作；目的節點ID 為Worker/Client 的ID 號，Router 實現消息路由的基礎就是根據所有連接節點的IDENTITY 選項進行身份識別，由于一個節點只能綁定一個IP 地址的一個端口，因此利用哈希函數生成每個節點唯一的身份ID；以上是消息的路由信息，JSON 字符串和二進制的文件數據data 是消息的實體部分。具體兩個節點之間的具體消息結構根據目的對基本結構進行刪減，最大程度減小消息的尺寸。

3.3 互聯網中Worker的發現機制

互聯網中Worker 的發現通過Manager 進行，Manager 管理著所有的Worker 信息。首先，Worker 向Manager 進行注冊，并附帶自己的服務信息；注冊完畢后，Manager 需要實時地確保Worker 存在且可用，于是Worker 將每隔一段時間發送心跳包給Manager，告訴Manager“我還在”，如果超過指定時間Manager 沒有收到心跳包，將刪除該Worker 的所有信息，宣告其“死亡”。

Client 發起一個服務請求之后，對應的Worker 將進入忙碌狀態，當Worker 計算處理完畢并將結果返回Client 或繼續向流程下游的Worker 發起下一個服務請求后，將向Manager 反饋消息，回到待機狀態。

3.4 互聯網中的大型文件傳輸

由于使用中間代理Manager 對所有消息進行轉發，Dealer 套接字也不遵循Req/Rep 一問一答式的固定順序，所以在大型文件的分塊傳輸時，可以對傳輸過程進行擁塞控制，增加大型文件傳輸的速度。根據袁小軍的測試，三種傳輸方式：

（1）文件塊連續傳輸，發送方直接連續發送文件塊而無需收到接收方的回復。

（2）分塊請求同步傳輸，發送發與接收方模擬Req/Rep 一問一答式的文件傳輸。

（3）容量因子控制傳輸，發送時容量因子減少，接收到回復后容量因子增大，如此達到擁塞控制的效果。

其中連續傳輸速度最快，但是占用內存最多，容量因子控制傳輸方式速度和內存占用均居中。因此采用容量因子控制傳輸的方式。其基本過程如圖8。

3.5 互聯網中Worker/Client直接連接

當Client 發現Worker 位于同一局域網時，會跨過Manager 直接與Worker 進行交互，判斷是否為同一局域網的方法是嘗試發送測試字符串，若在指定時間內接收到回復，則確定可以與其直連，否則二者不在同一局域網。

4 測試

4.1 測試框架設計

本文選擇遠程彩色3D 打印系統作為測試。遠端的計算機將彩色3D 打印所需的AMF 文件發送至彩色3D 打印切片軟件，切片軟件切片完成后將切片數據發送到加工設備進行加工。結構及結果圖如圖9 所示。

其中，客戶端只需要一個Client 請求服務；切片軟件需要提供接收AMF 文件并切片，最后發送到加工設備，需要一個Worker 和Client；加工設備只需要提供接收切片文件并加工的Worker。

4.2 測試結果

經測試，局域網中和跨局域網模式皆可用。局域網測試環境為Intel(R) Core(TM) i3-4150 cpu @ 3.50GHz 3.50GHz 處理器、8GB RAM、x64 版本，局域網網關為千兆網。

局域網下的測試數據如表1 所示。

5 總結

本文選擇ZeroMQ 消息中間件和JSON 數據格式建立了局域網內和跨局域網兩套SOA 遠程傳輸的中間件。具有如下特點：

（1）輕量化，使用者只需要使用頭文件、一個.lib 和.dll 文件就可以使用簡短的代碼創建服務和請求服務。

（2）快速，基于目前最快的開源消息對列ZeroMQ 和最快的JSON 開源庫

（3）適應性強，適應于局域網內的數據傳輸，構建本地的SOA 分布式系統，同時也可以跨局域網，構建云服務系統。

（4）支持大型文件傳輸，根據網絡傳輸設備的狀況設置合理的文件分塊大小。

（5）可靠傳輸，可靠性源于ZeroMQ 消息傳輸的穩定性。

分布式系統的每個進程既可以作為服務請求端，也可以作為服務端，同時也可以同時作為服務端和服務請求端，這取決于服務的劃分和任務的流程。每個進程就可以簡單地持有Worker 或者Client來建立整個服務網絡。