基于微服務(wù)架構(gòu)的管道地質(zhì)災(zāi)害監(jiān)測(cè)預(yù)警系統(tǒng)①

郇 凱,黃佳為,王 鑫,凌 誠(chéng)

(北京化工大學(xué) 信息科學(xué)與技術(shù)學(xué)院,北京 100029)

中國(guó)地貌類型多樣、地質(zhì)環(huán)境復(fù)雜、災(zāi)害性天氣頻發(fā),是世界上地質(zhì)災(zāi)害最嚴(yán)重的國(guó)家之一[1].災(zāi)害種類主要包括滑坡、崩塌、泥石流、危巖、河道水毀、地裂縫、地面沉降等.據(jù)自然資源部地調(diào)局環(huán)境監(jiān)測(cè)院發(fā)布的《環(huán)境監(jiān)測(cè)院發(fā)布2019年全國(guó)地質(zhì)災(zāi)害通報(bào)》顯示,2019年,全國(guó)共發(fā)生地質(zhì)災(zāi)害6 181 起,共造成211 人死亡、13 人失蹤、75 人受傷,直接經(jīng)濟(jì)損失27.7 億元.

隨著我國(guó)油氣管道建設(shè)里程的不斷增長(zhǎng),越來(lái)越多的油氣管道穿越復(fù)雜的地質(zhì)環(huán)境.管道鋪設(shè)地點(diǎn)大多位置偏僻、自然環(huán)境差,在復(fù)雜地質(zhì)條件地區(qū),地質(zhì)災(zāi)害頻發(fā)會(huì)對(duì)管道的運(yùn)行狀態(tài)產(chǎn)生重要影響[2-5].長(zhǎng)距離運(yùn)輸管道具有運(yùn)輸距離長(zhǎng)、運(yùn)行壓力高、易燃易爆、點(diǎn)多、線長(zhǎng)等特點(diǎn),沿線地質(zhì)災(zāi)害類型繁多、成因復(fù)雜,且危及范圍廣.發(fā)生地質(zhì)災(zāi)害的區(qū)域往往交通不便,人跡罕至,隱蔽性高,災(zāi)害點(diǎn)地理信息難以精準(zhǔn)掌握.暴露于地表外的管道還將會(huì)遭到第三方破壞或空氣腐蝕;重則造成管道變形、破裂、斷裂,甚至介質(zhì)泄漏等緊急情況[6,7].利用現(xiàn)代信息技術(shù)手段建立具有良好實(shí)用性與可擴(kuò)展性的信息化集成平臺(tái),對(duì)災(zāi)害點(diǎn)監(jiān)測(cè)數(shù)據(jù)進(jìn)行自動(dòng)化分析與預(yù)警,并進(jìn)行數(shù)據(jù)可視化呈現(xiàn),能夠?yàn)榉罏?zāi)救災(zāi)提供輔助決策,對(duì)提升地質(zhì)災(zāi)害防治工作的信息化水平具有積極意義[8-10].

1 系統(tǒng)架構(gòu)概述

1.1 系統(tǒng)業(yè)務(wù)需求

2019年12 月國(guó)家管網(wǎng)成立,對(duì)中石油、中石化、中海油三大公司油氣輸送業(yè)務(wù)進(jìn)行資源整合.隨著地質(zhì)災(zāi)害系統(tǒng)接入部門不斷增多,原有單服務(wù)器架構(gòu)已不足以應(yīng)對(duì)業(yè)務(wù)需求.

(1)地質(zhì)災(zāi)害數(shù)據(jù)呈現(xiàn)出多源性、多時(shí)相性、異構(gòu)性、多尺度、多分辨率等特點(diǎn),地質(zhì)災(zāi)害數(shù)據(jù)日益呈現(xiàn)出海量發(fā)展趨勢(shì)[11].隨著部門的不斷增多,系統(tǒng)接收的數(shù)據(jù)也成幾何級(jí)增長(zhǎng),導(dǎo)致服務(wù)器壓力陡增.2021年6月1日至2021年6月30日,僅一個(gè)公司就向平臺(tái)數(shù)據(jù)庫(kù)推送地質(zhì)災(zāi)害數(shù)據(jù)168 747 條,平均每天約5 625 條數(shù)據(jù).傳統(tǒng)單服務(wù)器架構(gòu)難以承受如此大的數(shù)據(jù)處理量.使用微服務(wù)架構(gòu),可以分區(qū)域部署多個(gè)數(shù)據(jù)庫(kù),對(duì)數(shù)據(jù)進(jìn)行拆分,可以顯著降低服務(wù)器的壓力.

(2)由于系統(tǒng)接入部門增多,部門業(yè)務(wù)不同,需求不斷變更,應(yīng)用規(guī)模不斷擴(kuò)大,在單體架構(gòu)下代碼會(huì)變得非常復(fù)雜且耦合度較高,同時(shí)不同人員開發(fā)代碼后會(huì)遺留不同問(wèn)題,維護(hù)模塊化結(jié)構(gòu)非常困難,不僅增加了開發(fā)難度,也影響代碼質(zhì)量.使用微服務(wù)架構(gòu),可以對(duì)業(yè)務(wù)進(jìn)行拆分,不同業(yè)務(wù)由不同微服務(wù)實(shí)現(xiàn),每個(gè)微服務(wù)相互獨(dú)立,互不影響.可以顯著提高團(tuán)隊(duì)之間的開發(fā)效率.

(3)由于系統(tǒng)一線應(yīng)用人員眾多,使用過(guò)程中難免出現(xiàn)問(wèn)題,在單體架構(gòu)下,某個(gè)功能的問(wèn)題可能會(huì)導(dǎo)致系統(tǒng)的崩潰.使用微服務(wù)架構(gòu),各個(gè)微服務(wù)之間相互獨(dú)立,同時(shí)可以采用斷路器、熔斷等方案降低系統(tǒng)崩潰的可能性.

(4)在單體架構(gòu)開發(fā)過(guò)程中,不同業(yè)務(wù)需要在同一份代碼中進(jìn)行修改、測(cè)試、部署,開發(fā)效率低.使用微服務(wù)架構(gòu),不同業(yè)務(wù)對(duì)應(yīng)不同模塊,可以分別開發(fā)測(cè)試與部署,全自動(dòng)化,提高效率.

1.2 系統(tǒng)業(yè)務(wù)拆分

微服務(wù)架構(gòu)將業(yè)務(wù)邊界進(jìn)行服務(wù)微化拆分,根據(jù)業(yè)務(wù)需求將業(yè)務(wù)拆分為多個(gè)獨(dú)立運(yùn)行、部署的子服務(wù).從地質(zhì)災(zāi)害監(jiān)測(cè)預(yù)警需求角度分析可將服務(wù)拆分為地質(zhì)災(zāi)害服務(wù)、巡查巡測(cè)服務(wù)、專業(yè)監(jiān)測(cè)服務(wù)、預(yù)警預(yù)報(bào)服務(wù)、文件處理服務(wù)、用戶管理服務(wù)、用戶鑒權(quán)服務(wù)共7 個(gè)微服務(wù)模塊.其中,由于微服務(wù)相互調(diào)用之間需要用戶權(quán)限進(jìn)行配合,因此增加用戶鑒權(quán)服務(wù),可以保證各微服務(wù)之間接口調(diào)用、數(shù)據(jù)傳遞安全性.

1.3 系統(tǒng)技術(shù)選取

管道地質(zhì)災(zāi)害預(yù)報(bào)預(yù)警系統(tǒng)使用前后端分離開發(fā)、獨(dú)立部署的微服務(wù)架構(gòu).

(1)數(shù)據(jù)庫(kù)

PostgreSQL 有豐富的幾何類型,如點(diǎn)、線、面等,PostGIS 在對(duì)象關(guān)系型數(shù)據(jù)庫(kù)PostgreSQL 上增加了存儲(chǔ)管理空間數(shù)據(jù)的能力,符合并且實(shí)現(xiàn)了OpenGIS的一些規(guī)范,多年來(lái)在GIS 領(lǐng)域處于優(yōu)勢(shì)地位.由于地質(zhì)災(zāi)害數(shù)據(jù)一般都攜帶有空間地理數(shù)據(jù)信息,具有空間關(guān)系、空間位置、分類編碼、非結(jié)構(gòu)化、海量數(shù)據(jù)等特征,因此系統(tǒng)采用了PostgreSQL 數(shù)據(jù)庫(kù).

(2)客戶端

相較于Angular和React 兩個(gè)流行框架,Vue.js 參考了React的組件化和虛擬DOM 技術(shù),借鑒了Angular的模板與雙向數(shù)據(jù)綁定技術(shù),同時(shí)擁有更加簡(jiǎn)潔的代碼與更小的體積,運(yùn)行效率更高.因此采用Vue.js 實(shí)現(xiàn)監(jiān)測(cè)預(yù)警系統(tǒng)前端界面.

(3)服務(wù)器

Spring Cloud與Dubbo是目前兩款主流微服務(wù)框架,Dubbo 作為一款輕量開源Java RPC 框架,提供服務(wù)注冊(cè)、調(diào)用與不完善的斷路器功能,僅實(shí)現(xiàn)了服務(wù)治理.Spring Cloud 則提供了更多的微服務(wù)解決方案,包括服務(wù)注冊(cè)、調(diào)用、服務(wù)網(wǎng)關(guān)、斷路器等,但目前部分組件停止維護(hù)與更新,且環(huán)境搭建與配置較為復(fù)雜.Spring Cloud Alibaba是阿里推出的Spring Cloud第二代實(shí)現(xiàn)標(biāo)準(zhǔn),擁有更完善的解決方案,其整合了目前流行的技術(shù),包括配置管理、服務(wù)發(fā)現(xiàn)、智能路由、負(fù)載均衡、熔斷器、控制總線、集群狀態(tài)等功能.可以協(xié)調(diào)分布式環(huán)境中各個(gè)系統(tǒng),為各個(gè)服務(wù)提供模板配置.因此采用Spring Cloud Alibaba 進(jìn)行后臺(tái)服務(wù)器開發(fā)實(shí)現(xiàn),并提供RESTful 風(fēng)格接口,便于各端進(jìn)行數(shù)據(jù)獲取與調(diào)用.

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

系統(tǒng)劃分為4 個(gè)層級(jí)結(jié)構(gòu)(如圖1所示).

圖1 系統(tǒng)體系結(jié)構(gòu)圖

(1)基礎(chǔ)設(shè)施層:數(shù)據(jù)采集包括管道本體監(jiān)測(cè)、野外監(jiān)測(cè)設(shè)備、一線員工采集等方式.物理組件包括服務(wù)器、防火墻、網(wǎng)絡(luò)設(shè)備等物理組件.

(2)數(shù)據(jù)資源層:主要包括PostgreSQL 數(shù)據(jù)與Redis 緩存數(shù)據(jù).

(3)平臺(tái)服務(wù)層:主要包括業(yè)務(wù)需求各個(gè)微服務(wù)模塊實(shí)現(xiàn)、應(yīng)用層請(qǐng)求服務(wù)從網(wǎng)關(guān)實(shí)現(xiàn)以及各微服務(wù)組件實(shí)現(xiàn).

(4)系統(tǒng)應(yīng)用層:用戶通過(guò)電腦Web 端與移動(dòng)APP端對(duì)系統(tǒng)進(jìn)行訪問(wèn).

1.5 系統(tǒng)架構(gòu)設(shè)計(jì)

如圖2所示.系統(tǒng)分為外網(wǎng)部署與內(nèi)網(wǎng)部署兩部分,外網(wǎng)部署為對(duì)應(yīng)系統(tǒng)應(yīng)用層,包括PC 端、Web 服務(wù)與移動(dòng)端APP 服務(wù).內(nèi)網(wǎng)部署對(duì)應(yīng)平臺(tái)服務(wù)層與數(shù)據(jù)資源層,主要包括網(wǎng)關(guān)服務(wù)、注冊(cè)、配置中心、全文檢索與日志存儲(chǔ).

圖2 系統(tǒng)架構(gòu)圖

網(wǎng)關(guān)服務(wù)是外界請(qǐng)求微服務(wù)接口的唯一入口,常用功能包括路由轉(zhuǎn)發(fā)、路由過(guò)濾、權(quán)限校驗(yàn)、限流控制等.注冊(cè)中心用于記錄各微服務(wù)地址并進(jìn)行服務(wù)健康監(jiān)測(cè),配置中心用于將項(xiàng)目中繁瑣的配置文件進(jìn)行集中管理,提供統(tǒng)一的請(qǐng)求接口,并提供動(dòng)態(tài)更新方案.全文檢索可以快速存儲(chǔ)、搜索并分析海量數(shù)據(jù).日志存儲(chǔ)用于記錄系統(tǒng)日志并處理.

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

管道地質(zhì)災(zāi)害監(jiān)測(cè)預(yù)警系統(tǒng)功能模塊如圖3分為后臺(tái)服務(wù)器、前端客戶端和后臺(tái)管理系統(tǒng)3 部分.

圖3 管道地質(zhì)災(zāi)害監(jiān)測(cè)預(yù)警系統(tǒng)功能模塊

2.1 微服務(wù)架構(gòu)實(shí)現(xiàn)

2.1.1 服務(wù)注冊(cè)與服務(wù)發(fā)現(xiàn)

隨著系統(tǒng)業(yè)務(wù)量的不斷增加,系統(tǒng)功能變得更加復(fù)雜,微服務(wù)的數(shù)量也會(huì)同步增加.微服務(wù)的架構(gòu)決定了整個(gè)系統(tǒng)的業(yè)務(wù)功能是由大量的服務(wù)結(jié)構(gòu)支撐的,若采用手動(dòng)管理和維護(hù)服務(wù)目錄的方式則無(wú)法保證系統(tǒng)的穩(wěn)定運(yùn)行,因此需要引入服務(wù)注冊(cè)中心[12,13].微服務(wù)將自身的服務(wù)名稱與服務(wù)地址注冊(cè)到注冊(cè)中心中,其他服務(wù)可以通過(guò)查詢注冊(cè)中心中信息發(fā)現(xiàn)服務(wù),并獲取其接口進(jìn)行遠(yuǎn)程調(diào)用.Spring Cloud 中提供Eureka Server 注冊(cè)中心,Spring Cloud Alibaba 中提供Spring Cloud Alibaba-Nacos 作為注冊(cè)中心.

相較于Eureka Server,Nacos 擁有更好的負(fù)載均衡策略,支持DNS 訪問(wèn)協(xié)議和動(dòng)態(tài)更新,同時(shí)支持配置中心,便于將配置統(tǒng)一集中管理.在部署方面,Eureka需要?jiǎng)?chuàng)建單獨(dú)的Spring Boot 項(xiàng)目并加載Eurake 服務(wù),Nacos 只需要在官網(wǎng)下載Jar 包即可啟動(dòng)服務(wù),無(wú)須創(chuàng)建新的應(yīng)用實(shí)例.Eureka 2.0 不再開源,開發(fā)者無(wú)法得到更好的技術(shù)支持.綜合考慮選擇Spring Cloud Alibaba-Nacos 作為系統(tǒng)的注冊(cè)中心.

啟動(dòng)Nacos 并運(yùn)行項(xiàng)目后,可以在Nacos 監(jiān)控界面查看各個(gè)微服務(wù)的注冊(cè)、使用情況,如圖4所示.

圖4 Nacos Server 查看微服務(wù)注冊(cè)列表

服務(wù)注冊(cè)到配置中心后,可以通過(guò)Spring Cloud OpenFeign 進(jìn)行遠(yuǎn)程調(diào)用.Spring Cloud Feign 在Netflix-Feign的基礎(chǔ)上擴(kuò)展了對(duì) Spring MVC 注解的支持,使用@FeignClient 注解聲明接口為遠(yuǎn)程客戶端,并配置遠(yuǎn)程接口地址,即可對(duì)其他微服務(wù)進(jìn)行遠(yuǎn)程調(diào)用.

2.1.2 網(wǎng)關(guān)服務(wù)與負(fù)載均衡

微服務(wù)是由很多服務(wù)組合而成的系統(tǒng),每個(gè)服務(wù)都需要鑒權(quán)、限流、權(quán)限校驗(yàn)等功能[14].Spring Cloud Gateway是替代Netflix Zuul的一套解決方案.網(wǎng)關(guān)是系統(tǒng)的唯一入口,其核心是一系列過(guò)濾器,不管是來(lái)自于客戶端的請(qǐng)求,還是服務(wù)器內(nèi)部調(diào)用,都需要經(jīng)過(guò)網(wǎng)關(guān),通過(guò)過(guò)濾器將請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)的微服務(wù).

網(wǎng)關(guān)的核心為路由(route)、斷言(predicate)、過(guò)濾器(filter)組成.路由信息由ID、目的URL、一組斷言工廠與一組過(guò)濾器組成,如果當(dāng)前斷言為真,說(shuō)明請(qǐng)求URL與配置路由匹配,進(jìn)行路由轉(zhuǎn)發(fā)至目的URL.斷言為Spring 5.0 中的ServerWebExchange 判定請(qǐng)求URL是否正確的一組參數(shù),允許開發(fā)者定義任何匹配信息,如請(qǐng)求路徑、匹配時(shí)間、Cookie 信息等.過(guò)濾器為標(biāo)準(zhǔn)的Spring WebFilter,匹配成功后對(duì)請(qǐng)求和響應(yīng)進(jìn)行修改處理.

在微服務(wù)架構(gòu)中,相同微服務(wù)可能部署在不同服務(wù)器上,為了更好地選擇不同服務(wù)器使用,保證服務(wù)器不會(huì)出現(xiàn)阻塞與閑置,可以負(fù)載均衡地調(diào)用每一個(gè)服務(wù)器,提高系統(tǒng)健壯性.常見的負(fù)載均衡算法包括:

(1)輪詢:為第一個(gè)請(qǐng)求選擇健康池中的第一個(gè)后端服務(wù)器,然后按順序往后依次選擇,直到最后一個(gè)選擇完繼續(xù)循環(huán).

(2)最小連接:優(yōu)先選擇連接數(shù)最少,也就是壓力最小的后端服務(wù)器.

(3)散列:根據(jù)請(qǐng)求源的IP的散列(hash)來(lái)選擇要轉(zhuǎn)發(fā)的服務(wù)器,可以一定程度上保證特定用戶能連接到相同的服務(wù)器.

Spring Cloud Gateway 可以結(jié)合Ribbon 實(shí)現(xiàn)負(fù)載均衡,由于不同服務(wù)器之間性能存在差異,因此對(duì)輪詢進(jìn)行優(yōu)化,根據(jù)硬件性能配置實(shí)例負(fù)載的權(quán)重,從何更好地利用服務(wù)器資源.對(duì)于每個(gè)請(qǐng)求,遍歷集群中的所有可用后端,同時(shí)累加所有服務(wù)器的權(quán)重,從集群中選取最大的服務(wù)器,作為本次選定的后端.

2.1.3 全文搜索

由于系統(tǒng)業(yè)務(wù)量不斷擴(kuò)大,所產(chǎn)生的災(zāi)害數(shù)據(jù)量也不斷增長(zhǎng),目前數(shù)據(jù)量已達(dá)百萬(wàn)級(jí)別,單純依靠數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)搜索查詢效率較低,同時(shí)無(wú)法很好地進(jìn)行數(shù)據(jù)分析,快速準(zhǔn)確查詢獲取數(shù)據(jù)成為提升系統(tǒng)性能的關(guān)鍵點(diǎn).

ElasticSearch (ES)是一個(gè)基于Apache Lucene(TM)的開源分布式可擴(kuò)展實(shí)時(shí)搜索和分析引擎,可以快速地存儲(chǔ)、搜索和分析海量數(shù)據(jù),支持RESTful 風(fēng)格.相較于傳統(tǒng)數(shù)據(jù)庫(kù),ES 使用倒排索引技術(shù)優(yōu)化索引速度,采取用空間換時(shí)間的策略,使得搜索性能顯著提高.全文搜索系統(tǒng)結(jié)構(gòu)如圖5所示.

圖5 全文搜索系統(tǒng)結(jié)構(gòu)

2.2 前端客戶端與后臺(tái)管理系統(tǒng)實(shí)現(xiàn)

客戶端界面與后臺(tái)管理系統(tǒng)均采用Vue.js 進(jìn)行開發(fā)實(shí)現(xiàn),引入了UI 組件庫(kù)ElementUI、WebGIS 客戶端開發(fā)JavaScript 類庫(kù)Openlayer (2D)與Cesium (3D)、圖表組件(Highcharts)等前端開發(fā)組件庫(kù).客戶端不同模塊通過(guò)Axios 向服務(wù)器網(wǎng)關(guān)發(fā)送網(wǎng)絡(luò)請(qǐng)求,服務(wù)器網(wǎng)關(guān)通過(guò)斷言將網(wǎng)絡(luò)請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)微服務(wù)模塊中,并返回相應(yīng)數(shù)據(jù).

客戶端工作流程如圖6所示,在Vue 工程中,視圖、數(shù)據(jù)、結(jié)構(gòu)分離,使數(shù)據(jù)的更改更為簡(jiǎn)單,不需要進(jìn)行邏輯代碼的修改,只需要操作數(shù)據(jù)就能完成相關(guān)操作.所有視圖和組件均封裝在以.vue為后綴的文件中.每一個(gè).vue 文件中都由3 部分組成——＜template＞、＜script＞、＜style＞.其中,template 封裝HTML 界面視圖文件內(nèi)容;script 封裝JavaScript 腳本文件內(nèi)容;style 封裝CSS 樣式文件內(nèi)容.

圖6 客戶端工作示意圖

2.3 持續(xù)集成、持續(xù)交付與自動(dòng)化部署

傳統(tǒng)的項(xiàng)目開發(fā)中,每次新版本部署需要等全部需求功能完成后,才能統(tǒng)一進(jìn)行部署,并且項(xiàng)目系統(tǒng)與所需軟件采用手動(dòng)部署的方式,即每次都需要發(fā)布、更新并連接到服務(wù)器進(jìn)行手動(dòng)部署新版本,所需人力成本較高.

為了提高部署效率,節(jié)省人力成本,系統(tǒng)采用Docker 作為代碼與系統(tǒng)運(yùn)行環(huán)境容器,建立K8S 集群,通過(guò)Jenkins Pipeline 實(shí)現(xiàn)持續(xù)集成、交付與自動(dòng)化部署.其執(zhí)行流程如圖7所示.

圖7 持續(xù)集成、交付與自動(dòng)部署流程

如圖8所示,相較于傳統(tǒng)手動(dòng)部署,自動(dòng)部署時(shí)間從10 min 提升至20 s 以內(nèi),大大節(jié)省了部署時(shí)間成本.

圖8 部署成功效果圖

3 并發(fā)測(cè)試與系統(tǒng)展示

3.1 系統(tǒng)性能壓測(cè)

系統(tǒng)使用開源壓力測(cè)試工具Apache JMeter 對(duì)系統(tǒng)地質(zhì)災(zāi)害微服務(wù)模塊進(jìn)行高并發(fā)性能測(cè)試.測(cè)試環(huán)境如表1所示.測(cè)試數(shù)據(jù)如圖9所示.

圖9 性能壓測(cè)測(cè)試數(shù)據(jù)

表1 測(cè)試環(huán)境

其中測(cè)試數(shù)據(jù)中線程數(shù)為虛擬用戶數(shù).Ramp-Up Period為準(zhǔn)備時(shí)長(zhǎng),即設(shè)置的虛擬用戶數(shù)需要多長(zhǎng)時(shí)間全部啟動(dòng).循環(huán)次數(shù)為每個(gè)線程發(fā)送的請(qǐng)求次數(shù).例如圖中測(cè)試數(shù)據(jù)為每個(gè)線程發(fā)送100 次請(qǐng)求,總請(qǐng)求數(shù)為50 000 次.

性能壓測(cè)結(jié)果如圖10,詳細(xì)信息如表2.

圖10 性能壓測(cè)結(jié)果

表2 測(cè)試結(jié)果

由性能壓測(cè)結(jié)果可以看出,采取微服務(wù)架構(gòu)顯著提高了系統(tǒng)的高并發(fā)性能,并大大提高了接口吞吐量,可以讓更多部門參與到系統(tǒng)使用中.

由系統(tǒng)性能壓測(cè)結(jié)果可以看出,在相同硬件環(huán)境下,采用微服務(wù)架構(gòu)顯著提高了高并發(fā)下接口的平均請(qǐng)求時(shí)間,并提高了系統(tǒng)的接口吞吐量,可以顯著提高用戶體驗(yàn),使得系統(tǒng)實(shí)現(xiàn)了高性能、高可用.

3.2 系統(tǒng)展示

3.2.1 綜合展示

綜合展示(如圖11所示),將系統(tǒng)分成不同模塊進(jìn)行展示.可以縱覽系統(tǒng)所有監(jiān)測(cè)數(shù)據(jù),并對(duì)預(yù)警做出處理.具有高效、直觀、便于操作的優(yōu)點(diǎn).

圖11 綜合展示

3.2.2 地質(zhì)災(zāi)害展示

地質(zhì)災(zāi)害信息包括信息展示、文件上傳、報(bào)告查詢、災(zāi)害管理組成,主要采用以表格Datagrid的方式進(jìn)行呈現(xiàn),具有多條件查詢、模糊查詢、分頁(yè)查詢的功能(如圖12所示).

圖12 地質(zhì)災(zāi)害查詢

3.2.3 地災(zāi)概覽展示

通過(guò)柱狀圖、餅圖與折線圖的形式,直觀展示當(dāng)前部門與下屬部門的地質(zhì)災(zāi)害信息(如圖13所示),為日常監(jiān)管提供有效數(shù)據(jù)支持.

圖13 地災(zāi)概覽

3.2.4 綜合分析展示

將數(shù)據(jù)以曲線形式展示,主要展示各個(gè)部門、測(cè)計(jì)歷史數(shù)據(jù)與數(shù)據(jù)變化規(guī)律(如圖14所示),并且可以觀察以“年”“月”“日”“總”為單位的不同時(shí)間段內(nèi)的信息,可以直觀有效掌握不同時(shí)間段內(nèi)數(shù)據(jù)變化情況.

圖14 綜合分析

4 系統(tǒng)應(yīng)用效果

地質(zhì)災(zāi)害監(jiān)測(cè)預(yù)警系統(tǒng)自2018年11月上線以來(lái),不斷進(jìn)行優(yōu)化升級(jí),目前穩(wěn)定運(yùn)行于某國(guó)有公司,供5 條分管道、55 個(gè)子公司與管理處部門、35 個(gè)巡線隊(duì)部門協(xié)同使用;設(shè)立監(jiān)測(cè)站203 個(gè),包含監(jiān)測(cè)測(cè)計(jì)595 個(gè);已經(jīng)開展含水率、地下水位等28 類要素檢測(cè),布置傳感器1 698 套;建設(shè)雨量站記錄地質(zhì)災(zāi)害誘發(fā)因子數(shù)據(jù),包括管道沿線2 411 處,滑坡、泥石流等災(zāi)害數(shù)據(jù),包括縣市災(zāi)害數(shù)據(jù)175 100 個(gè),預(yù)警反饋災(zāi)害點(diǎn)雨量站、水利行業(yè)提供的管道沿線江河汛期雨情數(shù)據(jù)及493 處水文站監(jiān)測(cè)數(shù)據(jù)、管道專用173 處雨量站;記錄各地崩塌2 個(gè)、管道沿線災(zāi)害點(diǎn)38 383 個(gè);累計(jì)接收各類災(zāi)害信息數(shù)據(jù)236 143 654 條.

系統(tǒng)全年無(wú)間隔提供預(yù)報(bào)預(yù)警服務(wù),2019-2021年期間接收預(yù)警數(shù)據(jù)如圖15所示,接收災(zāi)害點(diǎn)數(shù)據(jù)如表3所示.地質(zhì)災(zāi)害上傳、文件上報(bào)等由之前的1-2 天縮短至5 min;實(shí)時(shí)監(jiān)測(cè)系統(tǒng)與自動(dòng)報(bào)警功能的存在,將事故處理時(shí)間由原來(lái)的1-2 h 縮短至15 min 以內(nèi),大大降低了事故發(fā)生的概率.同時(shí),在每年4-9月汛期,系統(tǒng)為國(guó)有管道開展全國(guó)區(qū)域油氣管道、油氣田地質(zhì)災(zāi)害預(yù)報(bào)預(yù)警、區(qū)域地災(zāi)預(yù)報(bào)預(yù)警服務(wù),保障在汛期管道的正常運(yùn)行.

表3 2019-2021年期間災(zāi)害點(diǎn)信息

圖15 2019-2021年期間預(yù)警信息

由于管道地質(zhì)災(zāi)害大多發(fā)生在人跡較少的地區(qū),以往存在監(jiān)測(cè)難、統(tǒng)計(jì)難、管理難等問(wèn)題,使用系統(tǒng)后,可以實(shí)時(shí)監(jiān)測(cè)數(shù)據(jù)狀態(tài)、統(tǒng)計(jì)信息解決上述問(wèn)題.當(dāng)測(cè)站、測(cè)計(jì)發(fā)生故障報(bào)警時(shí),可以快速定位故障地點(diǎn),即刻派維修人員進(jìn)行搶修,確保管道運(yùn)行正常.管道地質(zhì)災(zāi)害監(jiān)測(cè)預(yù)警系統(tǒng)界面簡(jiǎn)潔,操作方便,實(shí)現(xiàn)了地質(zhì)災(zāi)害的預(yù)警預(yù)報(bào)與監(jiān)測(cè)的功能,使得地質(zhì)災(zāi)害工作在巡查勘測(cè)、災(zāi)害上報(bào)、災(zāi)害分析、災(zāi)害管理、預(yù)警預(yù)報(bào)等工作變得便捷高效.相較于傳統(tǒng)的Excel 表格辦公上報(bào)等方式,節(jié)省了大量人力成本、免去了專業(yè)人員信息上傳更新與查詢統(tǒng)計(jì)等瑣碎操作.

同時(shí),系統(tǒng)架構(gòu)層面采用微服務(wù)架構(gòu),顯著提高了系統(tǒng)高并發(fā)訪問(wèn)性能,并使用持續(xù)集成與自動(dòng)部署,加速了系統(tǒng)開發(fā)迭代周期.