基于“知天氣”APP 數(shù)據(jù)全流程的移動(dòng)端監(jiān)控系統(tǒng)設(shè)計(jì)

林孔杰，陳云，郭昌松，汪春輝

（福建省氣象服務(wù)中心，福建 福州 350100）

福建“知天氣”APP 作為移動(dòng)公共氣象服務(wù)平臺(tái)，向公眾展示實(shí)時(shí)的氣象信息。為了滿足氣象服務(wù)的時(shí)效性與準(zhǔn)確性，針對(duì)“知天氣”的監(jiān)控系統(tǒng)必不可少。本文提出一種基于數(shù)據(jù)全流程的移動(dòng)端監(jiān)控系統(tǒng)。主要是針對(duì)“知天氣”APP 產(chǎn)品數(shù)據(jù)全流程進(jìn)行監(jiān)控，能第一時(shí)間追溯數(shù)據(jù)問題所在。

隨著氣象事業(yè)的不斷發(fā)展，氣象觀測(cè)數(shù)據(jù)日益龐大，氣象部門的數(shù)據(jù)傳輸以及應(yīng)用脈絡(luò)錯(cuò)綜復(fù)雜，國(guó)內(nèi)氣象工作者提出許多監(jiān)控方法。吳貴義等[1]提出一種全鏈路氣象數(shù)據(jù)監(jiān)控系統(tǒng)，解決數(shù)據(jù)異常定位問題。王力等[2]提出基于Message Queuing 消息中間件技術(shù)實(shí)現(xiàn)一種氣象數(shù)據(jù)采集與監(jiān)控系統(tǒng)。郭昌松等[3]通過模擬客戶端請(qǐng)求“知天氣”的接口數(shù)據(jù)實(shí)現(xiàn)一種數(shù)據(jù)主動(dòng)監(jiān)控系統(tǒng)。目前福建“知天氣”產(chǎn)品數(shù)已達(dá)100 多個(gè)，日處理數(shù)據(jù)量達(dá)萬兆。單純的數(shù)據(jù)主動(dòng)監(jiān)控已無法滿足運(yùn)行需求。一旦數(shù)據(jù)出現(xiàn)未及時(shí)更新的情況，業(yè)務(wù)人員需要對(duì)各個(gè)生產(chǎn)環(huán)節(jié)逐一排查。各個(gè)數(shù)據(jù)系統(tǒng)監(jiān)控環(huán)節(jié)分散且不連續(xù)，出現(xiàn)問題不能及時(shí)定位，很難滿足實(shí)時(shí)業(yè)務(wù)對(duì)監(jiān)控的需求。

因此，為解決實(shí)際問題，應(yīng)提升數(shù)據(jù)監(jiān)控水平，及時(shí)恢復(fù)數(shù)據(jù)。本研究提出了全鏈路氣象數(shù)據(jù)監(jiān)控系統(tǒng)的設(shè)計(jì)思路，能快速定位數(shù)據(jù)更新異常的具體節(jié)點(diǎn)，達(dá)到及時(shí)、高效的業(yè)務(wù)保障能力。

1 “知天氣”產(chǎn)品數(shù)據(jù)特點(diǎn)分析

“知天氣”APP 作為福建省氣象手機(jī)客戶端服務(wù)系統(tǒng)，匯聚了全省氣象服務(wù)數(shù)據(jù)。主要有自動(dòng)站實(shí)時(shí)數(shù)據(jù)，逐日預(yù)報(bào)、逐時(shí)預(yù)報(bào)、旅游氣象預(yù)報(bào)，天氣綜述、雷達(dá)圖、衛(wèi)星云圖、數(shù)值預(yù)報(bào)、氣象視頻、生活指數(shù)、空氣質(zhì)量等氣象數(shù)據(jù)。系統(tǒng)針對(duì)每種數(shù)據(jù)的更新周期特性，將數(shù)據(jù)分四大類，如表1 所示，同時(shí)針對(duì)更新特性制定相關(guān)的采集頻次與監(jiān)控邊界時(shí)間（指當(dāng)前時(shí)間與文件時(shí)間的最大差值）。

表1 “知天氣”產(chǎn)品數(shù)據(jù)信息表

2 關(guān)鍵技術(shù)介紹

2.1 移動(dòng)端框架Uni-app

本文采用了Hbuilder 平臺(tái)下的Uni-app 框架。Uni-app 是一個(gè)使用vue.js 開發(fā)所有前端應(yīng)用的框架，是一個(gè)整合了小程序開發(fā)框架、APP 跨平臺(tái)框架和兼容性強(qiáng)的HTML5 開發(fā)框架。當(dāng)業(yè)務(wù)系統(tǒng)需要在不同的平臺(tái)展示時(shí)，針對(duì)不同的平臺(tái)編寫?yīng)氂械倪\(yùn)行代碼的成本顯然非常高，Uni-app 可以實(shí)現(xiàn)一次開發(fā)多端可拓展的技術(shù)框架，它可將代碼編譯成支持Android、iOS以及各種小程序等快應(yīng)用展示平臺(tái)，從而降低系統(tǒng)二次開發(fā)的不便性，因此為了能實(shí)時(shí)、不受平臺(tái)限制地監(jiān)控“知天氣”數(shù)據(jù)源，本系統(tǒng)使用Uni-app 框架開發(fā)前端應(yīng)用，能同時(shí)滿足電腦端、移動(dòng)端以及其他服務(wù)平臺(tái)的實(shí)時(shí)數(shù)據(jù)監(jiān)控。本系統(tǒng)使用Vue 框架來進(jìn)行平臺(tái)開發(fā)，主要涉及CSS 和JavaScript 語言的使用。

2.2 接口服務(wù)框架Flask

Flask 是一個(gè)輕量級(jí)的Python 語言Web 微框架。Flask 框架的主要優(yōu)點(diǎn)是核心簡(jiǎn)單且易于拓展。它只保留了Web 開發(fā)的核心功能，因此能夠輕松地結(jié)合MVC模式進(jìn)行系統(tǒng)開發(fā)。另外Flask 還具有很強(qiáng)的定制性，能根據(jù)自身業(yè)務(wù)需求來添加不同的組件滿足開發(fā)需求。針對(duì)Flask 框架這種特點(diǎn)，系統(tǒng)可以使用Python語言快速實(shí)現(xiàn)接口服務(wù)。并且針對(duì)不同數(shù)據(jù)源的監(jiān)控需求定制合理且普適的文本開發(fā)環(huán)境。

3 系統(tǒng)介紹

3.1 基于“知天氣”數(shù)據(jù)全流程監(jiān)控系統(tǒng)設(shè)計(jì)

福建“知天氣”APP 的數(shù)據(jù)源從生成到具體應(yīng)用涉及多個(gè)環(huán)節(jié)。其中包括氣象數(shù)據(jù)資源庫(kù)、公共數(shù)據(jù)支撐平臺(tái)、內(nèi)部數(shù)據(jù)源等。本研究介紹的數(shù)據(jù)全流程監(jiān)控系統(tǒng)，其功能是以APP 應(yīng)用產(chǎn)品為起點(diǎn)，逐級(jí)追溯到數(shù)據(jù)源頭的數(shù)據(jù)狀態(tài)。通過數(shù)據(jù)接口、文件狀態(tài)等監(jiān)控方法，實(shí)現(xiàn)對(duì)全流程數(shù)據(jù)的信息監(jiān)控。其次根據(jù)數(shù)據(jù)采集頻率、文件更新頻率進(jìn)一步設(shè)計(jì)各個(gè)數(shù)據(jù)階段的監(jiān)控規(guī)則與告警邊界。最后利用Vue 可視技術(shù)將監(jiān)控?cái)?shù)據(jù)塊整合成全流程監(jiān)控展示模塊。系統(tǒng)總體設(shè)計(jì)示意圖1 所示。

圖1 基于“知天氣”數(shù)據(jù)全流程監(jiān)控系統(tǒng)框架圖

3.2 功能設(shè)計(jì)

數(shù)據(jù)采集層：全流程監(jiān)控系統(tǒng)對(duì)各個(gè)數(shù)據(jù)源實(shí)現(xiàn)分布式數(shù)據(jù)采集。平臺(tái)采用APScheduler 調(diào)度框架處理數(shù)據(jù)采集調(diào)度任務(wù)，根據(jù)產(chǎn)品類型配置調(diào)度任務(wù)的采集頻率。再通過統(tǒng)一監(jiān)視信息采集接口，采用分布式采集匯聚，所需采集文件的信息包含報(bào)文名、資料類型、資料時(shí)次、生成時(shí)間、文件名、數(shù)據(jù)路徑等。由于平臺(tái)涉及多個(gè)數(shù)據(jù)平臺(tái)調(diào)度、跨網(wǎng)協(xié)同等問題。系統(tǒng)監(jiān)控策略為僅判定“知天氣”數(shù)據(jù)更新異常時(shí)，方能回溯采集數(shù)據(jù)源的數(shù)據(jù)狀態(tài)，具體策略如圖2 所示。此方法不僅能減少任務(wù)調(diào)度頻率，而且能減少監(jiān)控系統(tǒng)對(duì)數(shù)據(jù)平臺(tái)的負(fù)載壓力?？缇W(wǎng)協(xié)同采用“推”“拉”方式。主要針對(duì)不同數(shù)據(jù)源的系統(tǒng)以及網(wǎng)段的互通，通過推的方式將采集獲取監(jiān)測(cè)數(shù)據(jù)的狀態(tài)、事件等監(jiān)控信息推送至指定的中間服務(wù)器。再通過拉取的方式將獲得的數(shù)據(jù)信息同步至目標(biāo)服務(wù)器。系統(tǒng)使用Kafka技術(shù)通過將高吞吐量數(shù)據(jù)隊(duì)列等數(shù)據(jù)總線方式對(duì)數(shù)據(jù)進(jìn)行數(shù)據(jù)消峰和緩沖；系統(tǒng)讀取Kafka 隊(duì)列中緩沖的數(shù)據(jù)，并結(jié)合數(shù)據(jù)庫(kù)中的現(xiàn)存數(shù)據(jù)，通過SQL 語句將隊(duì)列的數(shù)據(jù)加載為Data Frame 形式，最后再利用Data Frame 上的API進(jìn)行查詢、轉(zhuǎn)換、計(jì)算，最終將生成的結(jié)果數(shù)據(jù)寫回存儲(chǔ)層。

圖2 監(jiān)控策略流程圖

告警規(guī)范層：該模塊功能是對(duì)數(shù)據(jù)進(jìn)行分析告警處理、指標(biāo)計(jì)算、統(tǒng)計(jì)分析。告警處理是指當(dāng)系統(tǒng)監(jiān)控到當(dāng)前文件超過監(jiān)控邊界時(shí)間時(shí)，系統(tǒng)會(huì)將采集到的異常環(huán)節(jié)告知值班人員。但異常處理完畢時(shí)需要值班人員登記備案處理情況。存儲(chǔ)相關(guān)的處理結(jié)果將有利于日后查詢，并且往后出現(xiàn)相關(guān)的異常可為值班人員提供參考，具體流程如圖3 所示。指標(biāo)計(jì)算與統(tǒng)計(jì)分析2 個(gè)模塊是系統(tǒng)將“知天氣”產(chǎn)品到報(bào)時(shí)間、異常節(jié)點(diǎn)等數(shù)據(jù)做統(tǒng)計(jì)分析，形成圖表等進(jìn)行可視化，為改善監(jiān)控系統(tǒng)提供數(shù)理分析。

圖3 告警處置流程圖

存儲(chǔ)層：采用基于mysql 數(shù)據(jù)庫(kù)，文件日志的方式實(shí)現(xiàn)較靈活的基礎(chǔ)設(shè)施資源配置管理數(shù)據(jù)庫(kù)的存儲(chǔ)。

展示層：系統(tǒng)使用Uni-app 框架實(shí)現(xiàn)了監(jiān)視系統(tǒng)的數(shù)據(jù)監(jiān)控、告警處置、數(shù)據(jù)查詢等界面展示。介于Uni-app的便利性，系統(tǒng)生成了Android 與iOS 這2 個(gè)版本。

3.3 性能測(cè)試

為測(cè)驗(yàn)APP 功能模塊的響應(yīng)性能，在相同網(wǎng)絡(luò)環(huán)境下，分別使用性能相近的安卓版手機(jī)與蘋果版手機(jī)驗(yàn)證其響應(yīng)性能。對(duì)異常監(jiān)控模塊與產(chǎn)品查詢模塊加載時(shí)長(zhǎng)進(jìn)行統(tǒng)計(jì)記錄，每個(gè)功能模塊均進(jìn)行10 次測(cè)試實(shí)驗(yàn)，記錄模塊加載時(shí)間（以加載全部數(shù)據(jù)時(shí)間為準(zhǔn)）。

打開“異常處理模塊”響應(yīng)時(shí)間對(duì)比如圖4（a）所示。測(cè)試結(jié)果：安卓端打開該模塊的平均響應(yīng)時(shí)長(zhǎng)為1.1 s，蘋果端的平均響應(yīng)時(shí)長(zhǎng)為1.0 s。打開“產(chǎn)品查詢模塊”響應(yīng)時(shí)間結(jié)果如圖4（b）所示。測(cè)試結(jié)果：安卓端打開該模塊的平均響應(yīng)時(shí)長(zhǎng)為1.56 s，蘋果端的平均響應(yīng)時(shí)長(zhǎng)為1.61 s。測(cè)試證明APP 主要功能模塊響應(yīng)時(shí)長(zhǎng)均在1 s 左右，基本滿足用戶體驗(yàn)。

圖4 測(cè)驗(yàn)APP 功能模塊的響應(yīng)性能對(duì)比情況

4 應(yīng)用效果

該系統(tǒng)能滿足“知天氣”的日常數(shù)據(jù)保障的需求，系統(tǒng)多次主動(dòng)告警提醒值班人員數(shù)據(jù)異常，能快速定位異常數(shù)據(jù)節(jié)點(diǎn)，極大提高了“知天氣”數(shù)據(jù)保障的效率。該系統(tǒng)在監(jiān)控方面仍存在不足，監(jiān)控策略配置上無法達(dá)到快速發(fā)現(xiàn)故障。后續(xù)將分析數(shù)據(jù)更新時(shí)間進(jìn)行合理統(tǒng)計(jì)分析，制定更加精細(xì)的數(shù)據(jù)監(jiān)控策略，進(jìn)一步提高數(shù)據(jù)保障的及時(shí)性。