針對(duì)載荷/載荷艙監(jiān)控的固定碼率數(shù)據(jù)非阻塞模式實(shí)時(shí)解析與展示方法①

李雪松,李子揚(yáng),朱家佳,竇 帥,楊 光,陳賓賓,李傳榮

(中國(guó)科學(xué)院 空天信息創(chuàng)新研究院,北京 100094)

1 引言

鑒于臨近空間探測(cè)的復(fù)雜性和探測(cè)數(shù)據(jù)的多樣性及重大的應(yīng)用價(jià)值,中國(guó)科學(xué)院設(shè)立了臨近空間探測(cè)科學(xué)實(shí)驗(yàn)項(xiàng)目.臨近空間探測(cè)數(shù)據(jù)實(shí)時(shí)可視化展示是臨近空間探測(cè)項(xiàng)目的重要組成部分,通過(guò)實(shí)時(shí)監(jiān)控探測(cè)數(shù)據(jù)的變化,為飛行任務(wù)決策提供支撐,有利于提升臨近空間探測(cè)任務(wù)安全、穩(wěn)定的開展.JavaScript是目前最流行的客戶端編程語(yǔ)言,自2016年起就有逐漸取代Java和PHP 的趨勢(shì)[1].NodeJS 本質(zhì)上是采用了谷歌瀏覽器V8 引擎的JavaScript 運(yùn)行環(huán)境,其非阻塞模式的I/O 處理帶來(lái)了相對(duì)低系統(tǒng)資源耗下的高性能與出眾的負(fù)載能力,非常適合用作依賴其他I/O 資源的中間服務(wù).因此,NodeJS 被認(rèn)為是數(shù)據(jù)密集型分布式部署環(huán)境下的實(shí)時(shí)應(yīng)用系統(tǒng)的完美解決方案[2,3].載荷/載荷艙監(jiān)控系統(tǒng)實(shí)現(xiàn)需要考慮在有限帶寬的高比特率條件下系統(tǒng)與臨空飛行器實(shí)時(shí)通信,同時(shí)保障數(shù)據(jù)展示的實(shí)效性.使用UDP 無(wú)狀態(tài)協(xié)議連接,使得資源消耗小,數(shù)據(jù)傳遞快,同時(shí)可以分配到不同機(jī)器處理,做到完全無(wú)狀態(tài)的橫向處理[4].臨近空間探測(cè)試驗(yàn)是高寒野外環(huán)境下開展,其具有網(wǎng)絡(luò)可靠性不高、數(shù)據(jù)流大的特點(diǎn),傳統(tǒng)的同步阻塞I/O 處理模式在對(duì)數(shù)據(jù)流進(jìn)行處理時(shí),數(shù)據(jù)下傳效率與數(shù)據(jù)處理能力很難同時(shí)得到效率上的提升,線程很容易在做數(shù)據(jù)處理過(guò)程中阻塞數(shù)據(jù)傳輸?shù)倪M(jìn)行,造成系統(tǒng)內(nèi)資源的浪費(fèi),進(jìn)而導(dǎo)致在過(guò)程中無(wú)法處理其他任務(wù),例如數(shù)據(jù)塊寫入文件,或者讀取其他數(shù)據(jù)[5,6].因此需要設(shè)計(jì)一種改進(jìn)的數(shù)據(jù)解析與展示方法,在不阻塞數(shù)據(jù)下傳的同時(shí)提高軟件的數(shù)據(jù)處理能力.

2 基于非阻塞模式的數(shù)據(jù)解析與展示方法

2.1 NodeJS I/O與Java I/O 處理模式比較

理論上在處理計(jì)算方面,NodeJS 單條主線程并沒有太多優(yōu)勢(shì),然而如果涉及IO 密集型任務(wù),由于NodeJS在每個(gè)級(jí)別強(qiáng)制支持非阻塞API 規(guī)范,因此能更高效地利用CPU和內(nèi)存資源.表1對(duì)比了NodeJS與Java在I/O 處理中的特點(diǎn).

表1 NodeJS與Java I/O 處理模式特點(diǎn)比較[6–11]

近年來(lái)不少知名互聯(lián)網(wǎng)公司包括阿里、騰訊、蘇寧,都有嘗試用NodeJS 代替Java 應(yīng)用于自身I/O 密集型業(yè)務(wù)場(chǎng)景的成功案例[9].

2.2 NodeJS 異步非阻塞I/O 處理基本原理

一般情況下,異步非阻塞I/O 處理流程是發(fā)送方向接收方發(fā)送請(qǐng)求后,不等待響應(yīng)可以繼續(xù)其他工作.接收方收到請(qǐng)求后,進(jìn)行I/O 操作時(shí)如果不能返回結(jié)果.其不是等待,而是立刻返回去做其他工作.當(dāng)I/O操作完成時(shí),再將完成狀態(tài)或結(jié)果通知接收方,接收方再響應(yīng)發(fā)送方[5–15].

異步非阻塞處理是基于應(yīng)用程序重復(fù)調(diào)用I/O 操作輪詢線程池來(lái)完成[8–11].NodeJS 使用的是單線程異步非阻塞模型,對(duì)所有的I/O 都采用異步請(qǐng)求方式,這種設(shè)計(jì)的底層依托的是C++高性能事件驅(qū)動(dòng)libuv 庫(kù),該驅(qū)動(dòng)庫(kù)提供了線程池,事件池,跨平臺(tái),異步I/O 處理能力等[1].如圖1所示,NodeJS 的主程序只有一個(gè)主線程作為執(zhí)行棧執(zhí)行程序代碼.主線程通過(guò)libuv 庫(kù)對(duì)事件隊(duì)列與系統(tǒng)線程池進(jìn)行維護(hù),從事件隊(duì)列取出相應(yīng)的事件,再?gòu)木€程池中分配一個(gè)線程去執(zhí)行該事件.主線程會(huì)通過(guò)libuv 庫(kù)不斷對(duì)事件隊(duì)列輪詢從而檢查未執(zhí)行的事件.當(dāng)子線程對(duì)事件執(zhí)行完畢,主線程執(zhí)行回調(diào),子線程被釋放歸還給線程池.因此基于NodeJS異步非阻塞I/O 處理操作實(shí)際上是通過(guò)libuv 維護(hù)的線程池完成的.由于主線程將所有的事件通過(guò)libuv 分配給了線程池中的子線程,因此主線程基本只負(fù)責(zé)事件調(diào)度,沒有進(jìn)行真正的I/O 操作,從而實(shí)現(xiàn)了異步非阻塞I/O.

圖1 NodeJS 異步非阻塞IO 處理流程

2.3 數(shù)據(jù)實(shí)時(shí)解析與展示

在臨近空間科學(xué)探測(cè)試驗(yàn)過(guò)程中,載荷/載荷艙通過(guò)專用測(cè)控鏈路與地面測(cè)控艙通信,數(shù)據(jù)通過(guò)服務(wù)端存儲(chǔ)并通過(guò)UDP 廣播分發(fā)數(shù)據(jù).本文針對(duì)載荷/載荷艙下傳的單幀數(shù)據(jù)的特征,設(shè)計(jì)了針對(duì)載荷/載荷艙監(jiān)控的異步非阻塞I/O 模式處理方法[16–20].處理流程如圖2所示.

圖2 固定碼率數(shù)據(jù)非阻塞解析與展示流程

客戶端通過(guò)UDP 協(xié)議與數(shù)據(jù)發(fā)送端建立連接,并接收數(shù)據(jù)包數(shù)據(jù)流.在該套接字模塊中使用了數(shù)據(jù)報(bào)dgram 模塊,dgram 提供了UDP 數(shù)據(jù)包實(shí)時(shí)通信Socket的實(shí)現(xiàn)方法.該模塊的API 包括事件和方法兩大類,事件類在UDP 連接狀態(tài)發(fā)生改變時(shí)觸發(fā),包含關(guān)閉(close),錯(cuò)誤(error),監(jiān)聽(listening),消息(message);方法類包含綁定端口主機(jī)(bind),返回對(duì)象地址(address),關(guān)閉實(shí)時(shí)通信(close),廣播發(fā)送數(shù)據(jù)報(bào)(send)等[21].

程序套接字處理部分通過(guò)引用NodeJS 中的dgram模塊建立基于UDP 的網(wǎng)絡(luò)通信,模塊通信流程如圖3所示.該模塊可對(duì)服務(wù)端的發(fā)送地址和端口進(jìn)行綁定,注冊(cè)監(jiān)聽事件.在客戶端連接服務(wù)端監(jiān)聽狀態(tài)發(fā)生改變時(shí),客戶端可接收服務(wù)端發(fā)送的數(shù)據(jù).客戶端獲取數(shù)據(jù)后,會(huì)觸發(fā)NodeJS 的異步非阻塞I/O 處理流程,主程序會(huì)通過(guò)libuv 使用事件隊(duì)列維護(hù)接收的數(shù)據(jù)[1].

圖3 dgram 模塊通信流程

非阻塞I/O 模式處理方法利用NodeJS 中的Buffer類來(lái)創(chuàng)建專用的二進(jìn)制數(shù)據(jù)緩存區(qū),并利用其提供的一系列API 接口對(duì)數(shù)據(jù)進(jìn)行操作.如圖3中服務(wù)端send()與客戶端recv()方法中傳遞的數(shù)據(jù)類型.Buffer類的內(nèi)存申請(qǐng)并不是通過(guò)NodeJS V8 引擎完成,而是由C++實(shí)現(xiàn).底層是通過(guò)slab 機(jī)制對(duì)碎片進(jìn)行管理.當(dāng)數(shù)據(jù)小于8 KB 時(shí),通過(guò)new Buffer(8000)申請(qǐng)一個(gè)可用空間為8000 字節(jié)的slab.在對(duì)服務(wù)端發(fā)送端口監(jiān)聽的過(guò)程中,可直接對(duì)內(nèi)存進(jìn)行密集的I/O 操作.在這個(gè)過(guò)程中slab 機(jī)制進(jìn)行了預(yù)先申請(qǐng)和事后分配,這使得JavaScript 到操作系統(tǒng)之間沒有過(guò)多的關(guān)于內(nèi)存申請(qǐng)的系統(tǒng)調(diào)用,提高了數(shù)據(jù)處理的效率.

非阻塞I/O 模式處理方法利用dgram 模塊會(huì)將接收的二進(jìn)制字節(jié)流封裝成Buffer 類,根據(jù)預(yù)先約定的協(xié)議,利用數(shù)據(jù)處理函數(shù),對(duì)Buffer 按位解碼.再將十進(jìn)制明碼數(shù)據(jù)集合逐個(gè)賦給原型JSON 數(shù)組.表2是JSON 數(shù)組的主要字段描述.

表2 解碼后的JSON 數(shù)組字段表

非阻塞I/O 模式處理方法對(duì)二進(jìn)制字節(jié)流解碼時(shí)會(huì)讀取原型JSON 數(shù)組中的length 屬性,該屬性標(biāo)識(shí)了二進(jìn)制字節(jié)流中每個(gè)字段所占字節(jié)長(zhǎng)度,通過(guò)該長(zhǎng)度對(duì)字節(jié)流逐位解碼.再將解碼后的值返回給原型JSON 數(shù)組.最后將獲得一維數(shù)組供后續(xù)模塊使用.

頁(yè)面渲染模塊在獲取一維數(shù)組前,數(shù)據(jù)流傳入驗(yàn)證函數(shù),數(shù)據(jù)通過(guò)有效性驗(yàn)證后,再利用ECharts 組件對(duì)數(shù)據(jù)進(jìn)行可視化圖表展示.這里JavaScript 類庫(kù)ECharts其底層依賴輕量級(jí)的Canvas 類庫(kù)ZRender,可以流暢的運(yùn)行在 PC和移動(dòng)設(shè)備上,并兼容當(dāng)前絕大部分瀏覽器,可提供直觀的數(shù)據(jù)可視化圖表[22].由于第三方開源組件ECharts 對(duì)DOM 的渲染效率不可控,同時(shí)系統(tǒng)解碼速率遠(yuǎn)高于圖形渲染速率.所以在獲取等待展示的一維數(shù)組后,系統(tǒng)采用了響應(yīng)式處理方法,使解碼模塊與DOM 渲染模塊解耦并通過(guò)異步數(shù)據(jù)流構(gòu)建處理關(guān)系.當(dāng)渲染模塊出現(xiàn)阻塞時(shí),不影響數(shù)據(jù)獲取與解析,以保障下傳數(shù)據(jù)的完整和準(zhǔn)確性.

載荷/載荷艙監(jiān)控客戶端的開發(fā)還引入了由Github發(fā)布的跨平臺(tái)桌面應(yīng)用工具ElectronJS.該應(yīng)用工具封裝了谷歌的Chromium 瀏覽器引擎作為圖形應(yīng)用界面,允許基于NodeJS 的載荷/載荷艙監(jiān)控客戶端通過(guò)ElectronJS在沒有部署NodeJS 開發(fā)環(huán)境的任意操作系統(tǒng)中使用NodeJS API,從而實(shí)現(xiàn)了NodeJS 網(wǎng)頁(yè)應(yīng)用到桌面應(yīng)用的轉(zhuǎn)換.圖4為載荷/載荷艙監(jiān)控客戶端在MacOS 系統(tǒng)下的軟件界面.

圖4 載荷/載荷艙監(jiān)控客戶端

3 性能測(cè)試

性能測(cè)試編譯工具使用的是ElectronJS 內(nèi)置的控制臺(tái).實(shí)驗(yàn)機(jī)器為MacBook Pro (Retina,15-inch,Mid 2015) CPU2.2 GHz intel corei7,顯卡Intel Iris Pro 1536 MB.

通過(guò)在試驗(yàn)機(jī)器搭建模擬服務(wù),通過(guò)UDP 協(xié)議連接客戶端并發(fā)送數(shù)據(jù),同時(shí)在數(shù)據(jù)解析模塊與Echarts 數(shù)據(jù)渲染模塊中設(shè)置計(jì)時(shí)函數(shù),對(duì)軟件解碼及渲染的能力進(jìn)行測(cè)試統(tǒng)計(jì).

如圖5所示,服務(wù)端以22 B/s 的速率向客戶端發(fā)送二進(jìn)制數(shù)據(jù)流.數(shù)據(jù)解析模塊完成二進(jìn)制字節(jié)流轉(zhuǎn)換一維數(shù)組耗時(shí)0.27 ms,代入公式PA≈計(jì)算解碼模塊單位時(shí)間內(nèi)的工作效率大約是80 MB/s.數(shù)據(jù)渲染模塊對(duì)一維數(shù)組渲染耗時(shí)72.27 ms,代入公式FPS≈計(jì)算每秒可渲染的幀數(shù)大約14 幀.使用MacOS 系統(tǒng)的任務(wù)管理器對(duì)軟件CPU 使用率監(jiān)控,CPU 使用率在3%～5%之間,無(wú)內(nèi)存泄露,滿足試驗(yàn)指標(biāo)要求.由此可以推斷當(dāng)數(shù)據(jù)流在80 MB/s 以下時(shí),解碼模塊工作無(wú)壓力,當(dāng)大于80 MB/s 時(shí)由于EchartsJS 渲染速率較慢,NodeJS 的事件隊(duì)列長(zhǎng)度會(huì)隨時(shí)間增加而增加,因此會(huì)造成執(zhí)行棧阻塞與內(nèi)存泄露.

圖5 模擬數(shù)據(jù)測(cè)試

該系統(tǒng)參加了臨空2019年7～9月在青海省海西蒙古族藏族自治州大柴旦地區(qū)的外場(chǎng)試驗(yàn).系統(tǒng)通過(guò)Electron-Package 打包為EXE 可執(zhí)行文件,并部署在CPU2.5 GHz intel corei7 Windows10 系統(tǒng)的移動(dòng)工作站中,數(shù)據(jù)傳輸率為100 Mb/s.在試驗(yàn)期間系統(tǒng)運(yùn)行34 小時(shí)19 分,獲取、解析并存儲(chǔ)數(shù)據(jù)12 萬(wàn)包,各項(xiàng)功能工作狀態(tài)穩(wěn)定,為各試驗(yàn)載荷及載荷艙系統(tǒng)的監(jiān)視與控制提供了可靠的數(shù)據(jù)支持.

4 總結(jié)

本文使用NodeJS+ElectronJS+EchartsJS 架構(gòu),采用固定碼率數(shù)據(jù)非阻塞模式實(shí)時(shí)解析與展示方法,實(shí)現(xiàn)了對(duì)臨空探測(cè)試驗(yàn)載荷/載荷艙的實(shí)時(shí)監(jiān)控,實(shí)時(shí)解析并展示數(shù)據(jù)理論可達(dá)80 MB/s.由于利用封裝好的libuv 庫(kù)維護(hù)線程池,因此相對(duì)于手動(dòng)維護(hù)多線程的方法能有效地節(jié)省開發(fā)成本,在保障下傳數(shù)據(jù)準(zhǔn)確性的同時(shí),能有效利用CPU和內(nèi)存資源.經(jīng)過(guò)臨空野外試驗(yàn)的驗(yàn)證,該解析與展示方法適用于資源受限環(huán)境下的野外科學(xué)試驗(yàn).在需要I/O 密集型場(chǎng)景下進(jìn)行可視化數(shù)據(jù)展示架構(gòu)中,本模式非常值得推廣.