基于RocketMQ的認(rèn)知雷達(dá)對抗數(shù)據(jù)交換系統(tǒng)設(shè)計(jì)

周月陽,高墨韻,石遠(yuǎn)東

(中國船舶集團(tuán)有限公司第七二三研究所,江蘇 揚(yáng)州 225101)

0 引 言

隨著戰(zhàn)場電磁環(huán)境的日趨復(fù)雜和認(rèn)知雷達(dá)的快速發(fā)展,傳統(tǒng)基于先驗(yàn)知識的雷達(dá)對抗系統(tǒng)已無法適應(yīng)現(xiàn)代電子對抗需求[1]。一方面,傳統(tǒng)雷達(dá)對抗系統(tǒng)的干擾方依賴固定的干擾策略和人為操作,無法根據(jù)雷達(dá)狀態(tài)和對抗環(huán)境的變化,改變其干擾策略。因此,干擾方的干擾效率較低,干擾措施缺乏自適應(yīng)性[2]。另一方面,各種新體制雷達(dá)的成功研制和認(rèn)知雷達(dá)的研究,使得雷達(dá)的抗干擾能力有了顯著增強(qiáng)。另外,新體制雷達(dá)結(jié)構(gòu)復(fù)雜,存在很多不同的工作模式,這些工作模式在非戰(zhàn)時(shí)狀態(tài)下可能一直被隱藏。傳統(tǒng)雷達(dá)對抗系統(tǒng)無法應(yīng)對這些未知的雷達(dá)狀態(tài)[3]。

認(rèn)知雷達(dá)對抗系統(tǒng)采用了“感知→識別→決策→行動→感知”的閉環(huán)學(xué)習(xí)過程[4],干擾方先通過對感知的雷達(dá)進(jìn)行參數(shù)測量,識別雷達(dá)所處的狀態(tài),然后用強(qiáng)化學(xué)習(xí)算法決策產(chǎn)生干擾樣式及參數(shù)[5],干擾發(fā)射器根據(jù)干擾樣式及參數(shù)發(fā)射相應(yīng)的干擾波形,最后對干擾后的雷達(dá)狀態(tài)進(jìn)行感知,評估干擾效能,形成閉環(huán)。因此,認(rèn)知雷達(dá)對抗系統(tǒng)是一種具有通過先驗(yàn)知識和自主學(xué)習(xí)來識別和干擾敵方雷達(dá)能力的智能、動態(tài)的閉環(huán)系統(tǒng),可在實(shí)時(shí)感知雷達(dá)狀態(tài)的基礎(chǔ)上,高效自主地調(diào)整干擾樣式及參數(shù)以適應(yīng)雷達(dá)狀態(tài)的變化,使干擾更具有主動性和針對性。傳統(tǒng)雷達(dá)對抗系統(tǒng)和認(rèn)知雷達(dá)對抗系統(tǒng)的實(shí)現(xiàn)框架如圖1所示[6]。

圖1 傳統(tǒng)雷達(dá)對抗系統(tǒng)和認(rèn)知雷達(dá)對抗系統(tǒng)的實(shí)現(xiàn)框架

相比于傳統(tǒng)雷達(dá)對抗系統(tǒng),認(rèn)知雷達(dá)對抗系統(tǒng)對數(shù)據(jù)交換的要求顯著提升。由圖1可知,認(rèn)知雷達(dá)對抗系統(tǒng)功能模塊更復(fù)雜,增加了雷達(dá)狀態(tài)識別、干擾效能評估和基于強(qiáng)化學(xué)習(xí)的干擾決策模塊,從而使得各個(gè)模塊產(chǎn)生的數(shù)據(jù)量更多。此外,認(rèn)知雷達(dá)對抗系統(tǒng)需要快速適應(yīng)雷達(dá)狀態(tài)的變化,整個(gè)閉環(huán)對抗過程的延時(shí)越低越好,而閉環(huán)對抗過程存在順序性,從而要求各個(gè)模塊數(shù)據(jù)交換的速度更快。更為重要的是,認(rèn)知雷達(dá)對抗系統(tǒng)更加靈活多態(tài),傳統(tǒng)基于TCP/IP、UDP等協(xié)議的數(shù)據(jù)交換難以滿足其重構(gòu)需求。

基于RocketMQ存在高可靠性、安全性、低延時(shí)、分布式、易擴(kuò)展、保證嚴(yán)格的消息順序、實(shí)時(shí)的消息消費(fèi)機(jī)制、億級的消息堆積能力等優(yōu)點(diǎn)[7],本文提出了一種基于RocketMQ的認(rèn)知雷達(dá)對抗數(shù)據(jù)交換系統(tǒng)。

1 RocketMQ簡介

RocketMQ是阿里巴巴開發(fā)的一種基于隊(duì)列模型的消息中間件,能夠提供多樣化的消息獲取模式、嚴(yán)格的消息順序、實(shí)時(shí)的消息消費(fèi)機(jī)制和億級的消息堆積能力,具有高可靠、安全性、低延時(shí)、分布式等優(yōu)點(diǎn)。發(fā)送消息時(shí),Producer依次發(fā)送消息到各個(gè)隊(duì)列,隊(duì)列的集合稱為Topic。Consumer有2種消費(fèi)模式:廣播模式和集群模式。廣播模式中的Consumer實(shí)例可以消費(fèi)一個(gè)Topic下所有的隊(duì)列,而在集群模式中,一個(gè)Topic對應(yīng)的隊(duì)列集合要給多個(gè)Consumer實(shí)例平均消費(fèi)[8]。消費(fèi)模式如圖2所示。

圖2 RocketMQ消費(fèi)模式

圖3展示了RocketMQ的物理部署結(jié)構(gòu)圖。如圖3所示,RocketMQ由4種角色的集群組成,分別為NameServer集群、Broker集群、Producer集群和Consumer集群。NameServer集群是注冊中心,存儲活躍的Broker列表,記錄完整的路由信息,提供等效的讀寫服務(wù);Broker集群是具體提供業(yè)務(wù)的服務(wù)器,通過提供輕量級的Topic和Queue機(jī)制來處理消息存儲,同時(shí)支持推和拉模式以及主從結(jié)構(gòu)的容錯(cuò)機(jī)制;Producer集群產(chǎn)生消息的實(shí)例,通過與一個(gè)隨機(jī)選擇的NameServer節(jié)點(diǎn)建立長連接來獲取Topic的路由信息,再通過路由信息,與提供該Topic服務(wù)的Broker主節(jié)點(diǎn)建立長連接,并定期發(fā)送心跳,維護(hù)自己的連接狀態(tài);Consumer集群接收消息的實(shí)例,與Producer集群在節(jié)點(diǎn)屬性上基本相同,不同的是Consumer集對Broker主節(jié)點(diǎn)和Broker從節(jié)點(diǎn)都要建立長連接并發(fā)送心跳。

圖3 RocketMQ物理部署圖[7]

2 系統(tǒng)設(shè)計(jì)

2.1 系統(tǒng)結(jié)構(gòu)設(shè)計(jì)

本文所設(shè)計(jì)的認(rèn)知雷達(dá)對抗數(shù)據(jù)交換系統(tǒng)結(jié)構(gòu)如圖4所示。整個(gè)結(jié)構(gòu)以圖1中的認(rèn)知雷達(dá)對抗系統(tǒng)實(shí)現(xiàn)框架為基礎(chǔ),認(rèn)知雷達(dá)對抗系統(tǒng)各個(gè)模塊間的數(shù)據(jù)交換主要由RocketMQ總線負(fù)責(zé),由于RocketMQ的可重構(gòu)特點(diǎn),可快速更新模塊以滿足變化的認(rèn)知雷達(dá)對抗需求。模塊中的Producer節(jié)點(diǎn)發(fā)送數(shù)據(jù)到RocketMQ總線,Consumer節(jié)點(diǎn)從RocketMQ總線上接收數(shù)據(jù)。各個(gè)模塊交換的數(shù)據(jù)類型包括脈沖描述字(PDW)、輻射源描述字(EDW)、抗干擾狀態(tài)描述字(EPDW)、干擾效能和干擾樣式及參數(shù)[6]。以基于強(qiáng)化學(xué)習(xí)的干擾決策模塊為例,該模塊中的Consumer節(jié)點(diǎn)接收雷達(dá)狀態(tài)識別模塊發(fā)送的EDW、EPDW和干擾效能評估模塊發(fā)送的干擾效能,這些數(shù)據(jù)作為干擾決策算法的輸入,訓(xùn)練后算法輸出的干擾樣式及參數(shù)由該模塊中的Producer節(jié)點(diǎn)負(fù)責(zé)發(fā)送到RocketMQ總線上。

圖4 認(rèn)知雷達(dá)對抗數(shù)據(jù)交換系統(tǒng)結(jié)構(gòu)

2.2 系統(tǒng)功能設(shè)計(jì)

基于RocketMQ的認(rèn)知雷達(dá)對抗數(shù)據(jù)交換系統(tǒng)的功能主要包括集群管理、消息隊(duì)列管理、客戶端連接和消息監(jiān)控。如圖5所示,集群管理包括集群信息管理和節(jié)點(diǎn)管理。集群信息管理負(fù)責(zé)顯示本系統(tǒng)中的所有集群信息,包括集群名、集群內(nèi)節(jié)點(diǎn)、集群生產(chǎn)/消費(fèi)的吞吐量、節(jié)點(diǎn)地址等;節(jié)點(diǎn)管理負(fù)責(zé)顯示和修改Broker節(jié)點(diǎn)及NameServer節(jié)點(diǎn)中的信息。消息隊(duì)列管理包括注冊隊(duì)列、修改隊(duì)列、查詢隊(duì)列和刪除隊(duì)列,負(fù)責(zé)對消息隊(duì)列(Topic)的信息進(jìn)行注冊、修改、查詢和刪除,消息隊(duì)列信息包括Topic名稱、Toipc數(shù)量、Topic權(quán)限等?？蛻舳诉B接包括生產(chǎn)者連接和消費(fèi)者連接。生產(chǎn)者連接負(fù)責(zé)ProducerGroup的注冊及刪除和節(jié)點(diǎn)網(wǎng)絡(luò)連接信息(IP 地址,組名,Topic等)的查詢;消費(fèi)者連接的內(nèi)容與生產(chǎn)者連接類似。消息監(jiān)控包括終端查詢和Web界面監(jiān)控。終端查詢采用RocketMQ自帶的命令行管理工具,可基于時(shí)間、key、消息ID等屬性來查詢特定的消息;Web界面監(jiān)控負(fù)責(zé)監(jiān)控集群、Topic、Producer和Consumer等的狀態(tài)。

圖5 認(rèn)知雷達(dá)對抗數(shù)據(jù)交換系統(tǒng)功能

3 系統(tǒng)實(shí)現(xiàn)

3.1 集群部署

數(shù)據(jù)交換系統(tǒng)提供的服務(wù)依賴于 RocketMQ,因此實(shí)現(xiàn)數(shù)據(jù)交換系統(tǒng)首先要部署 RocketMQ 集群,集群部署方案采用雙主雙從,保證系統(tǒng)的高可用性。集群架構(gòu)的角色分配如表1所示。物理部署如圖3所示,此處不再贅述。

表1 集群角色分配表

3.2 系統(tǒng)功能實(shí)現(xiàn)

數(shù)據(jù)交換功能是該系統(tǒng)最基本的功能,因此需要首先實(shí)現(xiàn)消息傳遞的功能,包括產(chǎn)生消息實(shí)例的生產(chǎn)者Producer節(jié)點(diǎn)和接收指定Topic下消息的消費(fèi)者Consumer節(jié)點(diǎn)。Producer和Consumer節(jié)點(diǎn)的工作流程如圖6所示。

圖6 Producer和Consumer節(jié)點(diǎn)的工作流程圖

為了便于監(jiān)控整個(gè)集群的運(yùn)行狀態(tài),該系統(tǒng)使用Web界面來查詢各個(gè)節(jié)點(diǎn)和指定的消息。由于篇幅有限,本文只展示了其中的消息查詢功能,能夠選擇按 Topic、Message Key和Message ID來查詢指定的消息。如圖7所示,指定Topic和時(shí)間段,則可以查詢到滿足條件的所有消息。

4 系統(tǒng)測試及應(yīng)用

為了在實(shí)驗(yàn)條件下構(gòu)建一個(gè)貼近實(shí)戰(zhàn)的認(rèn)知雷達(dá)對抗模擬環(huán)境,雷達(dá)方和干擾方采用半實(shí)物模擬系統(tǒng)。為滿足基于強(qiáng)化學(xué)習(xí)的干擾決策算法的訓(xùn)練和自主學(xué)習(xí)需求,數(shù)據(jù)交換系統(tǒng)需要在保證可靠性的前提下,能夠?qū)崟r(shí)處理雷達(dá)對抗過程中產(chǎn)生的海量數(shù)據(jù)流。因此,本文從性能和可靠性2個(gè)角度對數(shù)據(jù)交換系統(tǒng)進(jìn)行測試,并成功應(yīng)用于工程實(shí)際。

4.1 系統(tǒng)性能測試

對于系統(tǒng)測試所需的硬件開發(fā)環(huán)境,由于采用了雙主雙從的集群部署方案,需要至少4臺機(jī)器。為了保證RocketMQ的高效運(yùn)行,系統(tǒng)內(nèi)存至少需要16 GByte。對于軟件開發(fā)環(huán)境,考慮到系統(tǒng)穩(wěn)定性,RocketMQ中的機(jī)器需要安裝Ubuntu16.04操作系統(tǒng)。

為了選取在認(rèn)知雷達(dá)對抗系統(tǒng)中性能更好的消息中間件,本文選取了2種當(dāng)前常用的消息中間件RabbitMQ[9]和Kafka[10],在多Topic多消費(fèi)端的認(rèn)知雷達(dá)對抗場景下,與RocketMQ對比單位時(shí)間內(nèi)的消息處理能力。由于認(rèn)知雷達(dá)對抗系統(tǒng)中的干擾決策算法訓(xùn)練需要長時(shí)間運(yùn)行,需要構(gòu)建消息持久化場景。本文在系統(tǒng)正常運(yùn)行1 h后,不斷增加Producer端發(fā)送的數(shù)據(jù)量,直到系統(tǒng)吞吐量不再上升,而響應(yīng)時(shí)間拉長。這時(shí)Consumer端已出現(xiàn)性能瓶頸,從而可以得到相應(yīng)的系統(tǒng)最佳吞吐量。將系統(tǒng)最佳吞吐量作為消息處理能力的指標(biāo),3個(gè)消息中間件的消息處理能力對比如圖8所示。

圖8 消息處理能力對比

從圖7可以看出,RabbitMQ的吞吐量最低,只有3.35×104/s,這是由于它為了保證消息的可靠性,在吞吐量上做了取舍。Kafka和RocketMQ的吞吐量較為接近,分別為6.79×104/s和6.93×104/s,RocketMQ在消息持久化、多Topic多消費(fèi)端的認(rèn)知雷達(dá)對抗場景下,消息處理能力略優(yōu)于Kafka。

4.2 系統(tǒng)可靠性測試

系統(tǒng)的可靠性是指在極端情況下,如宿主宕機(jī)、應(yīng)用程序閃退等,系統(tǒng)有相應(yīng)的保護(hù)和應(yīng)對措施。對于數(shù)據(jù)交換系統(tǒng),可靠性的標(biāo)準(zhǔn)是消息在傳遞過程中不會丟失、消息不重復(fù)投遞和集群支持多主多從等。Broker進(jìn)程是RocketMQ的核心,本文通過殺死Broker進(jìn)程來查看在極端情況下,該數(shù)據(jù)交換系統(tǒng)的可靠性。

在該系統(tǒng)中的消息收發(fā)保持正常的情況下,于Broker節(jié)點(diǎn)的宿主機(jī)終端上執(zhí)行了“Kill-9”命令,則可以殺死RocketMQ框架下的Broker進(jìn)程。重新啟動該系統(tǒng)后,分析得到的系統(tǒng)可靠性數(shù)據(jù)如表2所示。在RocketMQ采用異步刷盤、單位時(shí)間內(nèi)發(fā)送的數(shù)據(jù)量陡增、Broker進(jìn)程中斷的極端情況下,依然能夠保證消息不丟失,消息不重復(fù),證明了該系統(tǒng)的可靠性。

表2 Broker進(jìn)程中斷后的系統(tǒng)可靠性

綜合考慮上述系統(tǒng)性能和可靠性測試,RocketMQ在消息處理能力上優(yōu)于其它消息中間件,滿足可靠性要求。因此,本文選擇RocketMQ為基礎(chǔ)構(gòu)建認(rèn)知雷達(dá)對抗數(shù)據(jù)交換系統(tǒng)。

4.3 系統(tǒng)應(yīng)用

考慮到雷達(dá)對抗外場試驗(yàn)費(fèi)用高昂、試驗(yàn)裝備困難、試驗(yàn)場地要求高且布陣復(fù)雜、受天氣和環(huán)境影響大等不利因素,在實(shí)驗(yàn)室條件下搭建了一個(gè)貼近實(shí)戰(zhàn)的認(rèn)知雷達(dá)對抗系統(tǒng)。其中,雷達(dá)方和干擾方采用半實(shí)物模擬系統(tǒng),雷達(dá)方能夠逼真模擬典型多功能雷達(dá)的功能和信息處理流程,并能發(fā)射雷達(dá)射頻信號波形;干擾方能夠逼真模擬電子戰(zhàn)系統(tǒng)的偵察和干擾流程,并能依據(jù)干擾決策算法輸出的干擾樣式及參數(shù)發(fā)射對應(yīng)的干擾波形。

本文提出的數(shù)據(jù)交換系統(tǒng)作為認(rèn)知雷達(dá)對抗系統(tǒng)中的分系統(tǒng),主要負(fù)責(zé)在保證可靠性的前提下,實(shí)時(shí)處理雷達(dá)對抗過程中產(chǎn)生的海量數(shù)據(jù)流。如圖9所示,該界面可實(shí)時(shí)顯示數(shù)據(jù)交換系統(tǒng)傳輸過程中的各類數(shù)據(jù),從而保障了數(shù)據(jù)交換系統(tǒng)的正常運(yùn)行。

圖9 偵察與干擾信息顯控界面

5 結(jié)束語

本文在認(rèn)知雷達(dá)對抗系統(tǒng)實(shí)現(xiàn)框架的基礎(chǔ)上,設(shè)計(jì)并實(shí)現(xiàn)了一種基于RocketMQ的認(rèn)知雷達(dá)對抗數(shù)據(jù)交換系統(tǒng)。認(rèn)知雷達(dá)對抗系統(tǒng)各個(gè)模塊間的數(shù)據(jù)交換主要由RocketMQ總線負(fù)責(zé),由于RocketMQ的可重構(gòu)特點(diǎn),可快速更新模塊以滿足變化的認(rèn)知雷達(dá)對抗需求。數(shù)據(jù)交換系統(tǒng)的功能主要包括集群管理、消息隊(duì)列管理、客戶端連接和消息監(jiān)控,對數(shù)據(jù)交換系統(tǒng)的性能和可靠性進(jìn)行測試,根據(jù)測試結(jié)果可以看出,RocketMQ在消息處理能力上優(yōu)于其它消息中間件,滿足可靠性要求,驗(yàn)證了該系統(tǒng)的優(yōu)越性。