基于微服務架構的管道地質災害監測預警系統①

郇 凱,黃佳為,王 鑫,凌 誠

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

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

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

1 系統架構概述

1.1 系統業務需求

2019年12 月國家管網成立,對中石油、中石化、中海油三大公司油氣輸送業務進行資源整合.隨著地質災害系統接入部門不斷增多,原有單服務器架構已不足以應對業務需求.

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

(2)由于系統接入部門增多,部門業務不同,需求不斷變更,應用規模不斷擴大,在單體架構下代碼會變得非常復雜且耦合度較高,同時不同人員開發代碼后會遺留不同問題,維護模塊化結構非常困難,不僅增加了開發難度,也影響代碼質量.使用微服務架構,可以對業務進行拆分,不同業務由不同微服務實現,每個微服務相互獨立,互不影響.可以顯著提高團隊之間的開發效率.

(3)由于系統一線應用人員眾多,使用過程中難免出現問題,在單體架構下,某個功能的問題可能會導致系統的崩潰.使用微服務架構,各個微服務之間相互獨立,同時可以采用斷路器、熔斷等方案降低系統崩潰的可能性.

(4)在單體架構開發過程中,不同業務需要在同一份代碼中進行修改、測試、部署,開發效率低.使用微服務架構,不同業務對應不同模塊,可以分別開發測試與部署,全自動化,提高效率.

1.2 系統業務拆分

微服務架構將業務邊界進行服務微化拆分,根據業務需求將業務拆分為多個獨立運行、部署的子服務.從地質災害監測預警需求角度分析可將服務拆分為地質災害服務、巡查巡測服務、專業監測服務、預警預報服務、文件處理服務、用戶管理服務、用戶鑒權服務共7 個微服務模塊.其中,由于微服務相互調用之間需要用戶權限進行配合,因此增加用戶鑒權服務,可以保證各微服務之間接口調用、數據傳遞安全性.

1.3 系統技術選取

管道地質災害預報預警系統使用前后端分離開發、獨立部署的微服務架構.

(1)數據庫

PostgreSQL 有豐富的幾何類型,如點、線、面等,PostGIS 在對象關系型數據庫PostgreSQL 上增加了存儲管理空間數據的能力,符合并且實現了OpenGIS的一些規范,多年來在GIS 領域處于優勢地位.由于地質災害數據一般都攜帶有空間地理數據信息,具有空間關系、空間位置、分類編碼、非結構化、海量數據等特征,因此系統采用了PostgreSQL 數據庫.

(2)客戶端

相較于Angular和React 兩個流行框架,Vue.js 參考了React的組件化和虛擬DOM 技術,借鑒了Angular的模板與雙向數據綁定技術,同時擁有更加簡潔的代碼與更小的體積,運行效率更高.因此采用Vue.js 實現監測預警系統前端界面.

(3)服務器

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

1.4 系統結構設計

系統劃分為4 個層級結構(如圖1所示).

圖1 系統體系結構圖

(1)基礎設施層:數據采集包括管道本體監測、野外監測設備、一線員工采集等方式.物理組件包括服務器、防火墻、網絡設備等物理組件.

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

(3)平臺服務層:主要包括業務需求各個微服務模塊實現、應用層請求服務從網關實現以及各微服務組件實現.

(4)系統應用層:用戶通過電腦Web 端與移動APP端對系統進行訪問.

1.5 系統架構設計

如圖2所示.系統分為外網部署與內網部署兩部分,外網部署為對應系統應用層,包括PC 端、Web 服務與移動端APP 服務.內網部署對應平臺服務層與數據資源層,主要包括網關服務、注冊、配置中心、全文檢索與日志存儲.

圖2 系統架構圖

網關服務是外界請求微服務接口的唯一入口,常用功能包括路由轉發、路由過濾、權限校驗、限流控制等.注冊中心用于記錄各微服務地址并進行服務健康監測,配置中心用于將項目中繁瑣的配置文件進行集中管理,提供統一的請求接口,并提供動態更新方案.全文檢索可以快速存儲、搜索并分析海量數據.日志存儲用于記錄系統日志并處理.

2 系統實現

管道地質災害監測預警系統功能模塊如圖3分為后臺服務器、前端客戶端和后臺管理系統3 部分.

圖3 管道地質災害監測預警系統功能模塊

2.1 微服務架構實現

2.1.1 服務注冊與服務發現

隨著系統業務量的不斷增加,系統功能變得更加復雜,微服務的數量也會同步增加.微服務的架構決定了整個系統的業務功能是由大量的服務結構支撐的,若采用手動管理和維護服務目錄的方式則無法保證系統的穩定運行,因此需要引入服務注冊中心[12,13].微服務將自身的服務名稱與服務地址注冊到注冊中心中,其他服務可以通過查詢注冊中心中信息發現服務,并獲取其接口進行遠程調用.Spring Cloud 中提供Eureka Server 注冊中心,Spring Cloud Alibaba 中提供Spring Cloud Alibaba-Nacos 作為注冊中心.

相較于Eureka Server,Nacos 擁有更好的負載均衡策略,支持DNS 訪問協議和動態更新,同時支持配置中心,便于將配置統一集中管理.在部署方面,Eureka需要創建單獨的Spring Boot 項目并加載Eurake 服務,Nacos 只需要在官網下載Jar 包即可啟動服務,無須創建新的應用實例.Eureka 2.0 不再開源,開發者無法得到更好的技術支持.綜合考慮選擇Spring Cloud Alibaba-Nacos 作為系統的注冊中心.

啟動Nacos 并運行項目后,可以在Nacos 監控界面查看各個微服務的注冊、使用情況,如圖4所示.

圖4 Nacos Server 查看微服務注冊列表

服務注冊到配置中心后,可以通過Spring Cloud OpenFeign 進行遠程調用.Spring Cloud Feign 在Netflix-Feign的基礎上擴展了對 Spring MVC 注解的支持,使用@FeignClient 注解聲明接口為遠程客戶端,并配置遠程接口地址,即可對其他微服務進行遠程調用.

2.1.2 網關服務與負載均衡

微服務是由很多服務組合而成的系統,每個服務都需要鑒權、限流、權限校驗等功能[14].Spring Cloud Gateway是替代Netflix Zuul的一套解決方案.網關是系統的唯一入口,其核心是一系列過濾器,不管是來自于客戶端的請求,還是服務器內部調用,都需要經過網關,通過過濾器將請求轉發到對應的微服務.

網關的核心為路由(route)、斷言(predicate)、過濾器(filter)組成.路由信息由ID、目的URL、一組斷言工廠與一組過濾器組成,如果當前斷言為真,說明請求URL與配置路由匹配,進行路由轉發至目的URL.斷言為Spring 5.0 中的ServerWebExchange 判定請求URL是否正確的一組參數,允許開發者定義任何匹配信息,如請求路徑、匹配時間、Cookie 信息等.過濾器為標準的Spring WebFilter,匹配成功后對請求和響應進行修改處理.

在微服務架構中,相同微服務可能部署在不同服務器上,為了更好地選擇不同服務器使用,保證服務器不會出現阻塞與閑置,可以負載均衡地調用每一個服務器,提高系統健壯性.常見的負載均衡算法包括:

(1)輪詢:為第一個請求選擇健康池中的第一個后端服務器,然后按順序往后依次選擇,直到最后一個選擇完繼續循環.

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

(3)散列:根據請求源的IP的散列(hash)來選擇要轉發的服務器,可以一定程度上保證特定用戶能連接到相同的服務器.

Spring Cloud Gateway 可以結合Ribbon 實現負載均衡,由于不同服務器之間性能存在差異,因此對輪詢進行優化,根據硬件性能配置實例負載的權重,從何更好地利用服務器資源.對于每個請求,遍歷集群中的所有可用后端,同時累加所有服務器的權重,從集群中選取最大的服務器,作為本次選定的后端.

2.1.3 全文搜索

由于系統業務量不斷擴大,所產生的災害數據量也不斷增長,目前數據量已達百萬級別,單純依靠數據庫進行數據搜索查詢效率較低,同時無法很好地進行數據分析,快速準確查詢獲取數據成為提升系統性能的關鍵點.

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

圖5 全文搜索系統結構

2.2 前端客戶端與后臺管理系統實現

客戶端界面與后臺管理系統均采用Vue.js 進行開發實現,引入了UI 組件庫ElementUI、WebGIS 客戶端開發JavaScript 類庫Openlayer (2D)與Cesium (3D)、圖表組件(Highcharts)等前端開發組件庫.客戶端不同模塊通過Axios 向服務器網關發送網絡請求,服務器網關通過斷言將網絡請求轉發到對應微服務模塊中,并返回相應數據.

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

圖6 客戶端工作示意圖

2.3 持續集成、持續交付與自動化部署

傳統的項目開發中,每次新版本部署需要等全部需求功能完成后,才能統一進行部署,并且項目系統與所需軟件采用手動部署的方式,即每次都需要發布、更新并連接到服務器進行手動部署新版本,所需人力成本較高.

為了提高部署效率,節省人力成本,系統采用Docker 作為代碼與系統運行環境容器,建立K8S 集群,通過Jenkins Pipeline 實現持續集成、交付與自動化部署.其執行流程如圖7所示.

圖7 持續集成、交付與自動部署流程

如圖8所示,相較于傳統手動部署,自動部署時間從10 min 提升至20 s 以內,大大節省了部署時間成本.

圖8 部署成功效果圖

3 并發測試與系統展示

3.1 系統性能壓測

系統使用開源壓力測試工具Apache JMeter 對系統地質災害微服務模塊進行高并發性能測試.測試環境如表1所示.測試數據如圖9所示.

圖9 性能壓測測試數據

表1 測試環境

其中測試數據中線程數為虛擬用戶數.Ramp-Up Period為準備時長,即設置的虛擬用戶數需要多長時間全部啟動.循環次數為每個線程發送的請求次數.例如圖中測試數據為每個線程發送100 次請求,總請求數為50 000 次.

性能壓測結果如圖10,詳細信息如表2.

圖10 性能壓測結果

表2 測試結果

由性能壓測結果可以看出,采取微服務架構顯著提高了系統的高并發性能,并大大提高了接口吞吐量,可以讓更多部門參與到系統使用中.

由系統性能壓測結果可以看出,在相同硬件環境下,采用微服務架構顯著提高了高并發下接口的平均請求時間,并提高了系統的接口吞吐量,可以顯著提高用戶體驗,使得系統實現了高性能、高可用.

3.2 系統展示

3.2.1 綜合展示

綜合展示(如圖11所示),將系統分成不同模塊進行展示.可以縱覽系統所有監測數據,并對預警做出處理.具有高效、直觀、便于操作的優點.

圖11 綜合展示

3.2.2 地質災害展示

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

圖12 地質災害查詢

3.2.3 地災概覽展示

通過柱狀圖、餅圖與折線圖的形式,直觀展示當前部門與下屬部門的地質災害信息(如圖13所示),為日常監管提供有效數據支持.

圖13 地災概覽

3.2.4 綜合分析展示

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

圖14 綜合分析

4 系統應用效果

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

系統全年無間隔提供預報預警服務,2019-2021年期間接收預警數據如圖15所示,接收災害點數據如表3所示.地質災害上傳、文件上報等由之前的1-2 天縮短至5 min;實時監測系統與自動報警功能的存在,將事故處理時間由原來的1-2 h 縮短至15 min 以內,大大降低了事故發生的概率.同時,在每年4-9月汛期,系統為國有管道開展全國區域油氣管道、油氣田地質災害預報預警、區域地災預報預警服務,保障在汛期管道的正常運行.

表3 2019-2021年期間災害點信息

圖15 2019-2021年期間預警信息

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

同時,系統架構層面采用微服務架構,顯著提高了系統高并發訪問性能,并使用持續集成與自動部署,加速了系統開發迭代周期.