■ 王恩文

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

國內(nèi)氣象通信系統(tǒng)是承擔國內(nèi)氣象資料和產(chǎn)品收集以及國內(nèi)外氣象資料和產(chǎn)品的國內(nèi)分發(fā)的業(yè)務系統(tǒng)。隨著現(xiàn)代氣象業(yè)務快速發(fā)展，氣象數(shù)據(jù)的種類、數(shù)量日益增加，關(guān)鍵業(yè)務資料觀測、更新頻次達到分鐘級，傳輸時效要求達到秒級?，F(xiàn)有國內(nèi)氣象通信系統(tǒng)，包括目前業(yè)務運行的新一代國內(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ù)，它能被一個或者多個應用程序所理解，是應用程序之間傳遞的信息載體，消息可以非常簡單，比如只包含文本字符串、XML、JSON等，也可以非常復雜，比如圖片、BUFR（Binary universal form for representation of meteorological data）編碼的二進制文件。

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

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

1.2 采用RabbitMQ的原因

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

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

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

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

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

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

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

1.3 消息隊列的作用

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

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

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

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

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

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

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

2 RMQ在CTS2中的應用

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

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

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

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

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

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

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

2）省級MDOS（Meterological Data Operational System）調(diào)用消息接口從消息服務端獲取消息數(shù)據(jù)，并將質(zhì)控后的消息數(shù)據(jù)送至消息服務端，消息數(shù)據(jù)入省級數(shù)據(jù)環(huán)境，消息收發(fā)處理進程從省級數(shù)據(jù)緩存獲取消息數(shù)據(jù)，導出成文件，同時在省級通過配置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è)務系統(tǒng)由國家級傳輸客戶端發(fā)送下行指令，通過國家級、省級通信系統(tǒng)，由臺站級傳輸客戶端提供給臺站綜合觀測業(yè)務系統(tǒng)。臺站業(yè)務系統(tǒng)響應指令后，通過臺站傳輸客戶端發(fā)送上行響應，國家級通信系統(tǒng)通過國家級傳輸客戶端向該國家級業(yè)務系統(tǒng)進行反饋，同時抄送國家級和省級監(jiān)視系統(tǒng)（客戶端）。

圖3 物理部署圖

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

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

2.1.2 高時效設(shè)計

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

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

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

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

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

圖5 交換控制流程圖

2.2 交換控制

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

3 結(jié)語

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

CTS2中的交換控制模塊也在國家級、貴州省、湖北省開展了試點運行，承擔著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)境學報, 28(6): 76-80.

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

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