李雪松,李子揚,朱家佳,竇 帥,楊 光,陳賓賓,李傳榮

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

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖3 dgram 模塊通信流程

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

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

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

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

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

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

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

3 性能測試

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

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

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

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

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

4 總結(jié)

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