消息隊列技術(shù)在氣象軟件系統(tǒng)中的應(yīng)用

■ 王恩文

國內(nèi)氣象通信軟件系統(tǒng)第二版（CTS2）中的消息傳輸模塊已經(jīng)在全國2000多個氣象站進(jìn)行業(yè)務(wù)運行。目前全國所有的國家級地面自動站BUFR數(shù)據(jù)均通過該系統(tǒng)進(jìn)入國家級、省級的氣象數(shù)據(jù)環(huán)境，并且為省級的MDOS系統(tǒng)提供了數(shù)據(jù)服務(wù)支撐。從試點運行到現(xiàn)在的業(yè)務(wù)運行，消息傳輸運行穩(wěn)健，90%的數(shù)據(jù)從臺站到國家的傳輸時間在2 s以內(nèi)，99.99%的數(shù)據(jù)在10 s以內(nèi)完成傳輸。

國內(nèi)氣象通信系統(tǒng)是承擔(dān)國內(nèi)氣象資料和產(chǎn)品收集以及國內(nèi)外氣象資料和產(chǎn)品的國內(nèi)分發(fā)的業(yè)務(wù)系統(tǒng)。隨著現(xiàn)代氣象業(yè)務(wù)快速發(fā)展，氣象數(shù)據(jù)的種類、數(shù)量日益增加，關(guān)鍵業(yè)務(wù)資料觀測、更新頻次達(dá)到分鐘級，傳輸時效要求達(dá)到秒級?，F(xiàn)有國內(nèi)氣象通信系統(tǒng)，包括目前業(yè)務(wù)運行的新一代國內(nèi)通信系統(tǒng)、國內(nèi)氣象通信軟件系統(tǒng)第一版（CMA domestic telecommunication system（version 1），CTS1），僅支持國家級和省級間基于文件的數(shù)據(jù)傳輸，難以滿足未來的統(tǒng)一省以下通信傳輸技術(shù)體制，難以支持多種類、高頻次、大容量實時氣象資料的高時效傳輸。

國內(nèi)氣象通信軟件系統(tǒng)第二版（CMA domestic telecommunication system（version 2），CTS2），在現(xiàn)有系統(tǒng)基礎(chǔ)上新增消息傳輸、流傳輸模式，并以Redis消息隊列（Redis message queue，RMQ）為核心的交換控制系統(tǒng)替換現(xiàn)有的調(diào)度系統(tǒng)，大幅度提升了氣象數(shù)據(jù)實時傳輸效率。

1 消息隊列技術(shù)

1.1 消息隊列基本概念

消息（Message）是消息隊列中最小的概念，本質(zhì)上是一段數(shù)據(jù)，它能被一個或者多個應(yīng)用程序所理解，是應(yīng)用程序之間傳遞的信息載體，消息可以非常簡單，比如只包含文本字符串、XML、JSON等，也可以非常復(fù)雜，比如圖片、BUFR（Binary universal form for representation of meteorological data）編碼的二進(jìn)制文件。

消息隊列（Message queue，MQ），也可以稱為消息隊列中間件或消息中間件，是指利用高效可靠的消息傳輸機(jī)制進(jìn)行與平臺無關(guān)的數(shù)據(jù)交流，并給予數(shù)據(jù)通信進(jìn)行分部署系統(tǒng)的集成。通過提供消息傳遞和消息排隊模型，它可以在分布式環(huán)境下擴(kuò)展進(jìn)程間通信。

消息隊列一般有兩種傳遞模式：點對點（P2P，Point-to-Point）模式和發(fā)布/訂閱（Pub/Sub）模式。點對點模式是基于隊列的，消息生產(chǎn)者發(fā)布消息到對壘，消息消費者從隊列中接收消息，隊列的存在使得消息的異步傳輸成為可能。發(fā)布/訂閱模式定義了如何向一個內(nèi)容節(jié)點發(fā)布和訂閱消息，這個內(nèi)容節(jié)點稱為主題（Topic），主題可以認(rèn)為是消息傳遞的中介，消息發(fā)布者將消息發(fā)布到某個主題， 而消息訂閱者則從主題中訂閱消息。主題使得消息的訂閱者與消息的發(fā)布者保持獨立，不需要進(jìn)行接觸即可保證消息的傳遞，發(fā)布/訂閱模式在消息的一對多廣播時采用。

1.2 采用RabbitMQ的原因

目前市場上的消息中間件有很多，比較主流的消息隊列有RabbitMQ、ActiveMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。

在系統(tǒng)設(shè)計初期進(jìn)行了大量的業(yè)務(wù)環(huán)節(jié)消息中間件選型測試，從以下方面進(jìn)行選型和對比：

1)傳輸效率：在所選的6類消息MQ中傳輸效率ZeroMQ最高，RabbitMQ次之。

2）持久化消息：ZeroMQ不支持，ActiveMQ和RabbitMQ都支持。持久化消息主要是指機(jī)器在不可抗力因素等情況下掛掉后，消息不會丟失的機(jī)制。

3）綜合技術(shù)實現(xiàn)：可靠性、靈活的路由、集群、事務(wù)、高可用的隊列、消息排序、問題追蹤、可視化管理工具、插件系統(tǒng)等。RabbitMQ/ Kafka 最好，ActiveMQ次之，ZeroMQ最差。當(dāng)然ZeroMQ也可以做到，不過必須手動寫代碼實現(xiàn)，代碼量不小。

4）高并發(fā)：RabbitMQ最高，因為它的實現(xiàn)語言是天生具備高并發(fā)、高可用的erlang語言。

經(jīng)過綜合考慮，RabbitMQ最符合業(yè)務(wù)需求。

1.3 消息隊列的作用

消息隊列憑借其獨到的特性，在不同的應(yīng)用場景下可以展現(xiàn)不同的作用：

解耦：消息隊列在處理過程中間插入了一個隱含的基于數(shù)據(jù)的接口層，這允許程序獨立地擴(kuò)展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束即可。CTS2中消息通信解耦了數(shù)據(jù)傳輸線路中各環(huán)節(jié)的生成、入庫等應(yīng)用的強(qiáng)關(guān)聯(lián)，各應(yīng)用只須做好自己的工作，無須擔(dān)心向下游的程序是否正常，簡化了系統(tǒng)架構(gòu)。

冗余（持久化）：處理數(shù)據(jù)有時進(jìn)程失敗。除非數(shù)據(jù)持續(xù)存在，否則它將永遠(yuǎn)丟失。消息隊列通過持久化數(shù)據(jù)，直到完全處理來緩解這一點。許多消息隊列使用的put-get-delete范例需要一個進(jìn)程來明確指出在郵件從隊列中刪除之前已經(jīng)完成了處理消息，確保數(shù)據(jù)保持安全，直到完成。應(yīng)用場景：CTS2中正是使用這一特性來保證數(shù)據(jù)的完整性。

可擴(kuò)展性：消息隊列解耦了應(yīng)用的處理過程，所以可以輕松地擴(kuò)展。將消息添加到隊列，只須添加另一個進(jìn)程。不需要更改代碼，不需要調(diào)整任何配置。應(yīng)用場景：CTS2中利用這一特性，可使國家級、省級各個平臺根據(jù)直接的數(shù)據(jù)規(guī)模配置適量的消息隊列服務(wù)器（Broker）即可。

彈性（流控）：消息隊列能夠使關(guān)鍵主鍵支撐突發(fā)訪問壓力，不會因為突發(fā)的超負(fù)荷請求而完全崩潰。如果正在處理來自隊列的消息的進(jìn)程失敗，那么仍然可以將消息添加到隊列中以在系統(tǒng)恢復(fù)時進(jìn)行處理。應(yīng)用場景：在CTS2中這一特性可以使當(dāng)數(shù)據(jù)源端異常時（比如傳輸客戶端因配置錯誤突然導(dǎo)入多年歷史數(shù)據(jù)），整個傳輸系統(tǒng)可以保證穩(wěn)定運行。

緩沖：在任何重要的系統(tǒng)中，都需要不同處理時間的組件。消息隊列通過提供緩沖層來幫助這些任務(wù)以最高效率運行，該緩沖區(qū)有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)系統(tǒng)的速度。應(yīng)用場景：CTS2系統(tǒng)中數(shù)據(jù)源程序、數(shù)據(jù)處理程序、數(shù)據(jù)入庫程序無須保證同時啟動，任何環(huán)節(jié)的應(yīng)用再啟動后只要有任務(wù)或數(shù)據(jù)即可進(jìn)入工作狀態(tài)。

異步通信：消息隊列啟用異步處理，允許將消息放在隊列上，而不是立即處理?？梢噪S意添加多個消息，然后隨意處理。這樣可使CTS2在下游系統(tǒng)未啟動的情況下，仍然正常收發(fā)。

2 RMQ在CTS2中的應(yīng)用

在CTS2中，RMQ消息傳輸承擔(dān)著全局任務(wù)管理、數(shù)據(jù)收集任務(wù)管理、數(shù)據(jù)分發(fā)任務(wù)管理、消息數(shù)據(jù)傳輸?shù)目傄蝿?wù)（圖1），是國家級地面自動站BUFR格式消息數(shù)據(jù)的唯一傳輸途徑，是全局任務(wù)管理的核心。

圖1 消息隊列在CTS2系統(tǒng)架構(gòu)中的應(yīng)用

2.1 消息傳輸架構(gòu)設(shè)計

國內(nèi)氣象通信系統(tǒng)基于RabbitMQ開發(fā)傳輸客戶端和消息服務(wù)端，其中傳輸客戶端部署到臺站，消息服務(wù)端部署到省級和國家級，傳輸流程如圖2所示（以地面自動站BUFR格式數(shù)據(jù)為例）。

2.1.1 消息數(shù)據(jù)傳輸基本架構(gòu)

國家級地面自動站BUFR格式消息數(shù)據(jù)傳輸流程：

1）傳輸客戶端與ISOS實現(xiàn)消息API接口和文件目錄接口，將獲取的消息數(shù)據(jù)上傳至省級消息服務(wù)端。

2）省級MDOS（Meterological Data Operational System）調(diào)用消息接口從消息服務(wù)端獲取消息數(shù)據(jù)，并將質(zhì)控后的消息數(shù)據(jù)送至消息服務(wù)端，消息數(shù)據(jù)入省級數(shù)據(jù)環(huán)境，消息收發(fā)處理進(jìn)程從省級數(shù)據(jù)緩存獲取消息數(shù)據(jù)，導(dǎo)出成文件，同時在省級通過配置shovel，將消息數(shù)據(jù)shovel到國家級RabbitMQ隊列。

3）消息數(shù)據(jù)入國家級數(shù)據(jù)環(huán)境。

消息數(shù)據(jù)傳輸主要包括臺站數(shù)據(jù)上行和國家級控制指令下行。

全國基礎(chǔ)氣象臺站的各種觀測資料通過傳輸客戶端將數(shù)據(jù)傳輸至本省省級通信系統(tǒng)，省級中心將省（區(qū)、市）的全部觀測資料、加工產(chǎn)品以及其他有關(guān)信息上傳至國家級通信系統(tǒng)。

圖2 數(shù)據(jù)傳輸流程圖

國家級業(yè)務(wù)系統(tǒng)由國家級傳輸客戶端發(fā)送下行指令，通過國家級、省級通信系統(tǒng)，由臺站級傳輸客戶端提供給臺站綜合觀測業(yè)務(wù)系統(tǒng)。臺站業(yè)務(wù)系統(tǒng)響應(yīng)指令后，通過臺站傳輸客戶端發(fā)送上行響應(yīng)，國家級通信系統(tǒng)通過國家級傳輸客戶端向該國家級業(yè)務(wù)系統(tǒng)進(jìn)行反饋，同時抄送國家級和省級監(jiān)視系統(tǒng)（客戶端）。

圖3 物理部署圖

圖4 數(shù)據(jù)傳輸時效分析圖

省級業(yè)務(wù)系統(tǒng)由省級傳輸客戶端發(fā)送下行指令，通過省級通信系統(tǒng)，由臺站級傳輸客戶端提供給臺站綜合觀測業(yè)務(wù)系統(tǒng)。臺站業(yè)務(wù)系統(tǒng)響應(yīng)指令后，通過臺站傳輸客戶端發(fā)送上行響應(yīng)，省級通信系統(tǒng)通過省級傳輸客戶端向該省級業(yè)務(wù)系統(tǒng)進(jìn)行反饋，同時抄送國家級和省級監(jiān)視系統(tǒng)（客戶端）。

2.1.2 高時效設(shè)計

為了滿足國家級地面自動站BUFR數(shù)據(jù)的秒級傳輸及以后系統(tǒng)消息傳輸數(shù)據(jù)量可擴(kuò)展的需求，設(shè)計了RMQ多機(jī)多節(jié)點的集群模式（圖3）。

圖4為雙機(jī)多節(jié)點的數(shù)據(jù)傳輸時效性測試圖。通過大量的模擬和業(yè)務(wù)測試?yán)L制出時效性曲線?？梢钥闯觯谒鶎嵤┑臏y試條件下，無論每臺機(jī)器部署幾個節(jié)點，都能很好地滿足傳輸時效性小于2 s的要求。若數(shù)據(jù)的傳輸時效性要求小于1 s，從測試曲線看出，每臺機(jī)器部署8個節(jié)點，同時部署2臺服務(wù)器即可滿足地面自動站BUFR數(shù)據(jù)的秒級傳輸要求，如需要對業(yè)務(wù)進(jìn)行擴(kuò)展，只需成對增加服務(wù)即可。

2.1.3 安全可靠性設(shè)計

RMQ多節(jié)點多集群模式除了可以大幅度提升傳輸效率，還可以允許發(fā)布者與生產(chǎn)者在單節(jié)點崩潰的情況下繼續(xù)運行，當(dāng)集群內(nèi)失去一個RMQ節(jié)點時，客戶端能重新連接到集群的任何其他節(jié)點并繼續(xù)生產(chǎn)或消費。

另外，在傳輸客戶端進(jìn)行生產(chǎn)（發(fā)送數(shù)據(jù)）或消費（接收數(shù)據(jù)）時，分別采用了發(fā)布確認(rèn)模式和接收確認(rèn)模式。發(fā)布確認(rèn)模式可以保障消息到達(dá)消息服務(wù)器，當(dāng)指定時間內(nèi)無法到達(dá)消息服務(wù)器會返回發(fā)送超時代碼，客戶端可以嘗試進(jìn)行重新發(fā)送。接收確認(rèn)模式在消費者接收消息后消息體仍然存在于消息隊列中并且被標(biāo)識為“Unacked”，直到消費者處理完消息后發(fā)送“ack”指令，消息體才會從隊列中刪除，如果消費者異常崩潰消息會重新恢復(fù)正常狀態(tài)供其他消費者消費，從而保證消息不丟失。

圖5 交換控制流程圖

2.2 交換控制

交換控制配置項包括收集任務(wù)管理、分發(fā)任務(wù)管理、編輯任務(wù)管理和元數(shù)據(jù)同步任務(wù)管理四個部件（圖5）。各任務(wù)管理部件實時讀取內(nèi)存中的策略配置，解析其中的時間策略和操作環(huán)節(jié)，根據(jù)時間策略觸發(fā)生成作業(yè)任務(wù)，并按照任務(wù)優(yōu)先級將作業(yè)送入到相應(yīng)消息隊列中。相關(guān)配置項從對應(yīng)消息隊列中獲取作業(yè)任務(wù)，解析任務(wù)策略并調(diào)度任務(wù)執(zhí)行，當(dāng)前環(huán)節(jié)操作完成后，將按照后續(xù)流程將數(shù)據(jù)對象向下游傳遞。

3 結(jié)語

CTS2中的消息傳輸模塊已經(jīng)在全國31個?。▍^(qū)、市）的2000多個國家站進(jìn)行業(yè)務(wù)運行，目前全國所有的國家級地面自動站BUFR數(shù)據(jù)均通過該系統(tǒng)進(jìn)入國省的氣象數(shù)據(jù)環(huán)境，并且為省級的MDOS系統(tǒng)提供了數(shù)據(jù)服務(wù)支撐。從試點運行到現(xiàn)在的業(yè)務(wù)運行，消息傳輸運行穩(wěn)健，90%的數(shù)據(jù)從臺站到國家的傳輸時間在2 s以內(nèi)，99.99%的數(shù)據(jù)在10 s以內(nèi)完成傳輸。

CTS2中的交換控制模塊也在國家級、貴州省、湖北省開展了試點運行，承擔(dān)著3個試驗點的文件傳輸、消息傳輸、流傳輸?shù)恼{(diào)度工作，到目前為止運行穩(wěn)定，無重大故障發(fā)生。

深入閱讀

陳玉華, 翟穎佳, 周紅, 等, 2013. 基于氣象通信系統(tǒng)切換信息傳輸流程梳理與優(yōu)化. 農(nóng)業(yè)網(wǎng)絡(luò)信息, (7): 22-24.

林潤生, 孫周軍, 譚小華, 等, 2011. 新一代國內(nèi)氣象通信系統(tǒng)設(shè)計與實現(xiàn). 氣象, 37(3): 356-362.

劉金霞, 王慧瑜, 趙威, 等, 2012. 省級新一代氣象通信系統(tǒng)傳輸流程的設(shè)計與實現(xiàn). 氣象與環(huán)境學(xué)報, 28(6): 76-80.

向筱銘, 徐曉莉, 宋智, 等, 2017. 基于CTS的臺站上行氣象數(shù)據(jù)傳輸監(jiān)控平臺的設(shè)計與實現(xiàn). 氣象科技, 45(4): 647-652.

張來恩, 王鵬, 韓鑫強(qiáng), 2018. CTS2.0消息封裝及交換控制策略設(shè)計及實踐. 氣象科技進(jìn)展, 8(1): 271-273.