基于ZeroMQ&JSON的分布式測控系統消息通信架構設計

摘 要： 為了提高異構環境下的分布式測控系統內部網絡的通信效率，采用消息中間件技術和一種輕量級的數據交換格式，設計了一種有效的分布式測控網絡消息通信架構。該架構用在智能樓宇監控實驗中，提高了數據的傳輸效率。該架構解決了異構系統集成的困難以及其數據交換格式的選擇問題，經過實踐的檢驗，該框架切實可行，可以勝任不斷變化的環境和任務要求，具有廣泛的適用性和良好的應用性。

關鍵詞： 消息中間件； ZeroMQ； 消息管道； 消息通信架構

中圖分類號： TN911?34； TP273.5 文獻標識碼： A 文章編號： 1004?373X（2014）02?0105?05

0 引 言

分布式測控系統通常由多個測控部件及其接口電路構成。各功能相對獨立的測控部件及其電路被稱為系統節點功能模塊，構成相對獨立的數據采集系統。每個節點只需完成系統的部分功能，而所有節點協同工作則可完成測控系統預期的全部功能。

目前的測控系統，大多采用基于單片機的傳感器無線組網或者采用工業現場總線的有線組網形式，受限于單片機的處理能力、所處環境的電磁兼容性以及總線組網通信能力的約束，網絡阻塞、數據的傳輸過程中丟失數據以及實時性問題尤為突出。

由于測控任務和測控環境在不斷的向復雜化、大型化方向發展，測控系統的監控對象越來越復雜，越來越分散，信號采集終端呈現分布式趨勢。在整個系統中，由于各臺儀器與設備種類繁多，硬件平臺各異，軟件環境也各不一致，所需要的控制命令、數據報文的格式也不統一，使得系統的靈活性很差，一旦對設備重新部署，就會大范圍改動軟件通信中的報文格式，導致系統可靠性較差，維護困難。

隨著大量帶有嵌入式操作系統的控制設備的應用和工業以太網絡環境的不斷完善，集成WSN和多種現場總線的網關的大量應用，整個系統對數據的處理能力和通信能力得到很大的提高，為消息中間件技術應用提供了良好的硬件平臺，該技術是一種由消息傳送機制或者消息隊列模式組成的中間件技術，利用該技術可以進行平臺無關的數據通信，并利用數據通信對各個設備進行分布式系統集成，而且在嵌入式多任務操作系統的支持下，可以擴展為進程間的數據通信。

以往的系統中，為了避免數據在通信中丟失，數據的發送方需要專門等待已發送的消息的回復，不利于多任務的并發。而消息中間件技術具有異步工作的特性，發送方可以發送數據到消息中間件后，無需等待，直接處理其他任務，由消息中間件來確保數據被接收方完整接收，對于系統中設備之間工作速率不同步，不會影響系統數據傳輸的穩定性和可靠性。消息中間件實現了整個系統的互聯，確保系統安全、可靠、實時的工作。

目前消息中間件主要采用兩種消息處理模型：點對點模型和發布/訂閱模型[1]：

點對點模型是一種基于連接的模型。消息發送方（生產者）和消息接收方（消費者）在進行通信時必須維持一條數據鏈路的連接，生產者將消息發送到消息隊列（生產），該消息將一直保留到被消費者從隊列中提取（消費）或者消息過期為止。這種模型既支持異步消息傳送模式，也支持同步請求/應答模式。

發布/訂閱模型是一種基于推送的模型。消息發送方（發布者）和消息接收方（訂閱者）采用透明的形式進行通信，發布者和多個訂閱者都會被注冊到消息通道上，消息通道一旦接收到消息，會主動地調用注冊在通道中的訂閱者，進而完成對消息內容的消費。這種模型既支持廣播機制，可以將一條消息傳遞給多個訂閱者，也支持搶占機制，同一時間只能有一個消費者處理該消息。

由于發布/訂閱模型的消息主動推送特點，使得它成為現代分布式計算環境的理想選擇。

1 ZeroMQJSON的特點

分布式計算環境需要處理大量的網絡通信，分布式測控系統中需要解析大量的控制命令、數據報文。

1.1 ZeroMQ

在分布式系統通信網絡中，進程間的交互所使用的API實際上是封裝了TCP/IP協議的Berkeley套接字（BSD）SOCKET，在基于Socket API開發TCP通信程序時，需要處理很多網絡異常（比如連接異常中斷以及重連），為了提高通信性能，往往進行異步（非阻塞）、緩沖區、多線程之類的優化，這些都極大地增加了通信程序的開發難度。

為了適應系統中的各個節點分散在分布式系統間，ZeroMQ被設計成網絡協議棧中的一個可伸縮層，不僅僅是一個點對點交互，還定義了適應于分布式系統的全局拓撲以便于在多個線程、內核和主機盒之間彈性伸縮[2]。

ZeroMQ是一個開源的、跨平臺、高性能、精簡靈活的網絡消息中間件，將操作系統的異步、消息緩沖區和多線程處理機制封裝在內，對各種套接字類型（如進程內通信、IPC、TCP和UDP）、網絡連接建立、數據打包成幀、路由選擇等底層網絡通信行為進行了抽象，ZeroMQ可以自動感知路由和網絡拓撲，靈活地支持多種通信環境[3]。

ZeroMQ主要支持 4 類通信模式：請求應答模式、發布/訂閱模式、管道模式以及信號模式， 其中前3種模式使用較多，信號模式使用較少，主要是用來支持傳統的TCP Socket 點對點模型。

相對于同類中間件MSMQ、ActiveMQ和RabbitMQ在部署時需要專門的一個服務器，ZeroMQ只需要讓應用程序引用ZeroMQ程序庫，就可以在多個進程間進行消息發送，使得部署起來非常簡單。

ZeroMQ采用 C/C++ 開發，并且協議格式定義得很簡潔，所以性能遠遠高于其他的消息中間件，如圖1所示[4]。缺點是ZeroMQ被設計成側重于消息傳輸的輕量級消息中間件，缺少消息服務器來存儲和轉發消息，所以不支持消息持久化及崩潰恢復。

圖1 MSMQ、ActiveMQ、RabbitMQ和ZeroMQ的消息傳輸性能對比

根據ZeroMQ給出的測試報告，對于一個長度為120 B的消息，在1 Gb Ethernet網環境下，消息的傳輸可達到900 Mb/s，完全滿足系統的實時性要求。

1.2 JSON

由于各種測控節點平臺的異構性，需要一個格式統一、跨平臺的數據交換格式以方便對系統中的命令、數據報文進行解析。JSON和XML是目前網絡中最常用的兩大數據傳輸格式。XML是一種標記語言，用于結構性標記電子文件，可以用來標記數據、定義數據類型，允許用戶自定義標簽，用于傳輸和存儲數據。DOM是對XML文檔進行應用開發、編程的應用程序接口，把XML文檔作為樹結構來查看，能夠通過DOM樹來訪問所有元素（節點），可以修改或刪除節點的內容，并創建新的節點，因此，可以把XML看成是一種數據結構或者是一種虛擬數據庫。

XML文件中存在很多用于解析的附加信息，由于XML最初是用于在WEB中傳輸大數據，解析信息在整個文件中所占比例較小。然而分布式測控系統中，需要解析的命令、數據報文都是一些小數據，使得XML文件變的很臃腫，因此XML在小數據上的傳輸、存儲的效率上存在一定問題。JSON也是基于純文本的數據格式，旨在傳送基于文本的數據，支持的數據結構為：名稱/值對集合，其對象格式如圖2所示。

圖2 JSON對象包裝格式

以一個命令的JSON和XML格式作為對比，例如一條移動顯示組件窗口的命令。

如表1所示，相對于復雜的XML數據格式，JSON格式簡單，易于讀寫，用于解析的信息格式壓縮，內存占用小，傳輸速度快，對JSON的解析效率高。在存取速度上，JSON是XML的2.3倍左右，而JSON文件的大小則為XML文件的[12]左右[5?6]。

表1 JSON與XML格式對比

2 系統的總體結構

對于多數分布式測控系統而言，基于ZeroMQ和JSON的測控技術更加容易實現系統功能的集成。下面以一個具有普遍意義的分布式測控系統為例，介紹這種系統集成方法的應用。

整個測控系統體系結構如圖3所示，根據功能分成4個層次：

（1） 物理設備層：負責現場數據（模擬量、數字量、圖像）采集以及預處理、接受控制指令輸出控制量（模擬量、開關量等），主要包括數據采集器、

傳感器節點、控制器節點、接口板和攝像頭組成，由支持嵌入式操作系統的嵌入式CPU、存儲單元、網絡通信單元、傳感器和相關總線接口組成。

（2） 操作系統層：在裁剪并移植操作系統的基礎上，利用其提供的多進/線程機制、網絡通信協議棧，通過移植相關的嵌入式數據庫、ZeroMQ和JSON等開源軟件庫，完成相關監控軟件的開發，包括：數據采集與處理、數據存儲、控制量輸出和遠程數據/指令傳輸。

（3） 分布式平臺的中間件層：基于ZeroMQ和JSON機制，由消息管理模塊、鏈路搜索模塊和群組管理模塊組成，構成一個分布式的通信網絡的通信接入服務器。該服務器作為TCP/IP通信的服務器端，通過ZeroMQ的發布/訂閱模型，與物理設備層模塊、基礎組件層模塊通信，負責接收、分發和應答這兩層中模塊的消息，為了在不同平臺之間進行數據交換，通過JSON機制對命令、數據報文進行封裝。

圖3 分布式測控系統結構示意圖

（4） 基礎設施組件層：用戶應用平臺，由各種顯示組件、輸入/輸出、控制策略、Web組件和數據庫組件構成，以圖形化界面實現與分布式測控系統的交互。

如圖4所示，每一層由實體（物理硬件或軟件）組成并進行封裝和抽象，上層能夠接受下層提供的服務，并通過封裝能向上層提供增值服務[7]。

圖4 基于ZeroMQ和JSON集成的分布式測控系統模塊

3 系統的通信模型實現

在分布式測控系統中，由于參與測控的各個物理設備分布在不同的節點中，需要建立一條從一個信號源端點到一個或多個控制節點的、虛擬的、邏輯的、非物理電路連接的數據傳輸通道，可以抽象的認為是一條信息管道。分布式測控系統的信息集成就是根據測控系統的功能要求，用若干條虛擬的信息管道將系統各節點中的相關信息端點在邏輯上連接起來，從而實現分布式測控系統的信息集成[8]。通信服務是整個分布式測控系統的信息入口，消息中間件是分布式消息系統的核心。借助“異步處理”、“保存并轉發”及“保證傳送”機制，消息中間件為通信服務穩定高效的運行提供了有力的支持。

3.1 基于ZeroMQ分布式消息服務

ZeroMQ的實現就是提供一個運行在代理服務器上的通知服務以及一組支持客戶端應用開發與運行的接口庫。面向對象中間件能夠屏蔽底層分布環境的復雜性和異構性，實現異構網絡環境下的分布應用軟件之間的互連、互通和互操作，提高系統的可移植性。分布式消息系統服務采用ZeroMQ提供的REQ?REP模式、PUB?SUB模式來支持不同的消息傳輸方式：

REQ?REP模式：由請求端（REQ）發起請求，并等待回應端（REP）響應請求，該模式是一個同步的雙向通信，應用于數據采集、控制輸出等實時性要求高的通信上。

PUB?SUB模式：發布端（PUB）是單向發送消息，訂閱端（SUB）則只負責接收消息，中間不能反饋，PUB和SUB可以是1∶N，如圖5所示。如果訂閱端連接成功，ZeroMQ會確保發布端發布的信息不會丟失。該模式是一個異步的通信，應用于命令發布，數據顯示等一般性的通信上。

使用PUB?SUB模式，消息的生產者和消費者之間沒有耦合，訂閱者和發布者可以在運行時動態添加，不干擾各子系統正常運行。由于指令具有強制執行性，需要確保指令的接收者能夠接收到數據，這就需要用到REQ?REP的消息隊列模式。

圖5 ZeroMQ提供的PUB?SUB模式和REQ?REP模式

3.2 分布式測控系統通信架構

一個完整的消息系統可以稱為一個“消息網”，網內包含不同的節點，這些節點分布在不同主機的不同進程中。通信架構圖如圖6所示。

在整個系統的消息通信架構中，最重要的就是消息管理，該模塊負責和節點端系統通信，作為TCP/IP通信的服務器端。

負責接收各種節點端的消息，并利用信號源管理模塊中的信號源節點和顯示組件節點、控制節點之間的對應關系，分送客戶端消息到PC架構子系統，分布式子系統，和總線式子系統中去。具體功能包括：

（1） TCP通信服務器：利用ZeroMQ提供的發布/訂閱模式負責和客戶機通信，具有靈活的可擴展機制；

（2） JSON協議適配器：負責將節點端過來的JSON指令解析成各種調用，并將結果數據JSON傳送給TCP服務器分發給節點端；

（3） 消息分發處理：根據消息類型經適配器轉換后，對群組信息進行搜索得到最短路徑，向其他各種組件分發的控制指令/數據。

在分布式測控系統中一次典型的消息通信過程如下：首先，客戶端組、數據庫組件、控制臺組、信號源組、控制組、控制器組合顯示組訂閱到消息系統中；其次，由客戶端“發布”建立一條從信號源——控制策略——輸入/輸出——到控制節點鏈路的指令，各群組組件“訂閱”到這個指令后，創建各自的線程，在線程中根據傳入的IP地址和端口號建立相應的通信連接；最后，控制臺組件根據從信號源“訂閱”到的傳感器監測數據，依據設定的控制策略，與控制節點進行“請求/響應”通信，控制節點按照指令進行有效的控制。

為了測試整個消息系統的性能，在1 Gb Ethernet網絡環境下，通過服務器連續“發布”JSON封裝的、長度為100個字節的“命令”指令1 000 000條，各群組組件全部成功的“訂閱”，沒有發生“命令”丟失現象，平均延時<10 μs，滿足系統的實時性要求；在攝像頭采集、傳送和顯示組件顯示一幀D1圖像（702×576），平均延時大約<20 ms，滿足視頻實時傳輸顯示要求，全部的測試結果驗證了消息系統的高效性。

4 結 論

本研究結合傳感器網絡、嵌入式計算、分布式信息處理、網絡通信等先進技術，本文創新之處在于提出了一種基于消息中間件的測控網絡中的消息通信架構，提高了通信系統的消息傳遞能力、系統的穩定性和數據的安全性。

通過在各節點之間建立虛擬信息管道，實現具體物理連接鏈路節點信息集成，采用該消息通信架構的分布式測控網絡具有智能化、適應不同環境要求、可靠性好、效率高和易于擴展等特點， 可滿足多種不同環境的工業測控任務要求，具有良好的應用前景。

參考文獻

[1] 李易民，凌捷.安全消息中間件的設計[J].計算機工程與設計，2011，32（6）：1934?1937.

[2] 蒲鳳平，陳建政.基于ZeroMQ的分布式系統[J].電子測試，2012（7）：24?29，33.

[3] HINTJENS Pieter. Code connected volume 1，learning ZeroMQ [EB/OL]. [2013?07?27]. http：//www.ppurl.com/2013/07/code?connected?volume?1?learning?zeromq.

[4] Julien. ActiveMQ or RabbitMQ or ZeroMQ or ActiveMQ [EB/OL]. [2009?04?08]. http：//stackoverflow.com/questions.

[5] 陳京，陳容紅，江志農.設備故障監測診斷平臺多語言技術研究[J].電子設計工程，2012，20（11）： 5?7，11.

[6] 高靜，段會川.JSON數據傳輸效率研究[J].計算機工程與設計，2011，32（7）：2267?2270.

[7] 易勇，曾家智，古天祥.實時構架的分布式測控系統[J].電子測量與儀器學報，2006，20（3）：75?79.

[8] 陳非凡.基于信息管道技術的分布式測控系統集成方法[J].清華大學學報：自然科學版，2010（8）：1229?1233.