基于微服務(wù)架構(gòu)的橋梁健康監(jiān)測(cè)系統(tǒng)研發(fā)與應(yīng)用

李 濤，朱自強(qiáng)，魯光銀，白冬鑫

(1.中南大學(xué)地球科學(xué)與信息物理學(xué)院，湖南 長(zhǎng)沙 410083;2.湖南省有色資源與地質(zhì)災(zāi)害勘查重點(diǎn)實(shí)驗(yàn)室，湖南 長(zhǎng)沙 410083;3.中南大學(xué)，有色金屬成礦預(yù)測(cè)與地質(zhì)環(huán)境監(jiān)測(cè)教育部重點(diǎn)實(shí)驗(yàn)室，湖南 長(zhǎng)沙 410083)

1 介 紹

橋梁是交通設(shè)施中重要的組成部分，需要充分保證其安全。據(jù)2019年6月統(tǒng)計(jì)結(jié)果顯示，中國(guó)已建成運(yùn)行的公路橋梁超過80萬座，鐵路橋梁超過20萬座，是世界上橋梁最多的國(guó)家之一。而其中有超過10萬座的病橋、危橋，因此需要對(duì)運(yùn)營(yíng)的橋梁進(jìn)行定期的安全評(píng)價(jià)。

目前對(duì)橋梁進(jìn)行安全評(píng)價(jià)的常用手段為橋梁檢測(cè)，主要包括無損檢測(cè)和荷載試驗(yàn)兩種。無損檢測(cè)整體花費(fèi)較少但效果較差；橋梁荷載試驗(yàn)效果較好但是花費(fèi)巨大，同時(shí)需要在封閉交通的情況下才能進(jìn)行。無論哪種檢測(cè)方式都具有檢測(cè)頻率低，不能實(shí)時(shí)性的提供數(shù)據(jù)的缺點(diǎn)，而橋梁健康監(jiān)測(cè)系統(tǒng)作為實(shí)時(shí)監(jiān)測(cè)工具，能夠全天候監(jiān)測(cè)橋梁運(yùn)營(yíng)狀況，分析橋梁運(yùn)營(yíng)狀態(tài)下結(jié)構(gòu)響應(yīng)，對(duì)問題橋梁進(jìn)行及時(shí)的安全預(yù)警，同時(shí)提供豐富的數(shù)據(jù)依據(jù)。因此對(duì)橋梁建立健康監(jiān)測(cè)系統(tǒng)是一種經(jīng)濟(jì)有效的保障橋梁運(yùn)營(yíng)安全的方式。

在過去的幾十年，不同的學(xué)者在橋梁健康監(jiān)測(cè)的技術(shù)難點(diǎn)和研究熱點(diǎn)上開展了大量的研究，主要集中于決策設(shè)計(jì)、傳感器、信號(hào)處理、模態(tài)識(shí)別、狀態(tài)評(píng)估等方面，取得了大量的研究成果。而在監(jiān)測(cè)系統(tǒng)架構(gòu)領(lǐng)域研究的比較少。目前大多數(shù)橋梁健康監(jiān)測(cè)系統(tǒng)主要通過B/S(瀏覽器/服務(wù)端)和C/S(客戶機(jī)/服務(wù)器)模式實(shí)現(xiàn)主要的訪問功能，而無論哪種模式，后端服務(wù)始終是web程序的核心，因此對(duì)服務(wù)器體系結(jié)構(gòu)的研究應(yīng)該獲得更多的關(guān)注。

目前來說，相關(guān)的研究總體上經(jīng)歷了三層架構(gòu)、面向服務(wù)架構(gòu)以及微服務(wù)架構(gòu)的發(fā)展過程。早期的三層架構(gòu)基于面向?qū)ο?OOP)設(shè)計(jì)，主要包括應(yīng)用層、數(shù)據(jù)訪問層以及業(yè)務(wù)邏輯層.系統(tǒng)通過數(shù)據(jù)訪問層與數(shù)據(jù)庫(kù)連接，而相關(guān)的業(yè)務(wù)邏輯封裝一個(gè)包內(nèi)構(gòu)成業(yè)務(wù)邏輯層，實(shí)現(xiàn)系統(tǒng)的主要功能.控制器是一個(gè)特殊的類，通過“控制器”可以實(shí)現(xiàn)數(shù)據(jù)的前后端交互。這種架構(gòu)最大特點(diǎn)就是簡(jiǎn)單，適合業(yè)務(wù)量小，邏輯簡(jiǎn)單，對(duì)性能要求低的web應(yīng)用程序，但是隨著業(yè)務(wù)量的增多，它的弊端就漸漸顯露，這主要體現(xiàn)在三個(gè)方面：一是響應(yīng)緩慢，該架構(gòu)將整個(gè)服務(wù)放在同一個(gè)內(nèi)存空間，無法實(shí)現(xiàn)分布式部署，而單臺(tái)機(jī)器的處理能力有限，當(dāng)業(yè)務(wù)量增大到這個(gè)極限時(shí)，服務(wù)器響應(yīng)就會(huì)變慢，用戶體驗(yàn)就會(huì)急劇下降；二是維護(hù)難度大，業(yè)務(wù)量增加往往伴隨著編碼復(fù)雜度增加，相應(yīng)的代碼膨脹問題以及兼容性問題會(huì)增大后期的維護(hù)成本。三是系統(tǒng)容錯(cuò)性差，某個(gè)模塊出現(xiàn)問題可能會(huì)導(dǎo)致整個(gè)系統(tǒng)宕機(jī)。

為了解決三層架構(gòu)的瓶頸問題，提出了基于面向服務(wù)理念的框架(SOA)，這種架構(gòu)要求開發(fā)者從服務(wù)集成的角度出發(fā)，考慮復(fù)用現(xiàn)有的服務(wù)。SOA架構(gòu)將整個(gè)web應(yīng)用拆成一個(gè)一個(gè)的業(yè)務(wù)單元(稱之為服務(wù))每個(gè)服務(wù)可以基于不同的技術(shù)棧、編程語言開發(fā)，各個(gè)服務(wù)之間通過統(tǒng)一的接口或者協(xié)議進(jìn)行通信，以Restful API和Json協(xié)議為代表。這種架構(gòu)可以降低系統(tǒng)的耦合性，每個(gè)服務(wù)部署在不同的服務(wù)器上，便于實(shí)現(xiàn)分布式集群部署，解決單臺(tái)服務(wù)器瓶頸問題。但是SOA架構(gòu)同樣也存在一定的缺陷，首先耦合度越低，系統(tǒng)開發(fā)難度越大，同時(shí)維護(hù)成本也相應(yīng)增加。其次就是整個(gè)系統(tǒng)的性能受到各個(gè)服務(wù)之間數(shù)據(jù)通信效率的影響。最后一個(gè)常見的問題是一旦某個(gè)服務(wù)宕機(jī)，可能會(huì)拖累整個(gè)系統(tǒng)的性能。

目前，大多數(shù)的橋梁健康監(jiān)測(cè)系統(tǒng)都基于三層架構(gòu)，也有一部分是基于SOA架構(gòu)的，當(dāng)監(jiān)測(cè)的橋梁數(shù)量少，監(jiān)測(cè)時(shí)間較短時(shí)能夠滿足監(jiān)測(cè)預(yù)警需求，但是當(dāng)橋梁監(jiān)測(cè)數(shù)量以及接收的數(shù)據(jù)量快速增大的時(shí)候，系統(tǒng)整體的性能就會(huì)受到挑戰(zhàn)，出現(xiàn)響應(yīng)不及時(shí)等問題，因此就需要一個(gè)更加健壯和靈活的系統(tǒng)。

采用微服務(wù)架構(gòu)設(shè)計(jì)開發(fā)的橋梁健康監(jiān)測(cè)系統(tǒng)，將功能拆分成多個(gè)微服務(wù)，實(shí)現(xiàn)了分布式存儲(chǔ)和分布式部署，各個(gè)服務(wù)實(shí)例通過注冊(cè)中心將各個(gè)分布式微服務(wù)連接起來，采用輪詢策略實(shí)現(xiàn)負(fù)載均衡，應(yīng)用實(shí)例表明采用微服務(wù)架構(gòu)的橋梁監(jiān)測(cè)系統(tǒng)提供了海量數(shù)據(jù)的處理能力，分散了計(jì)算和服務(wù)壓力，有效的解決了分布式系統(tǒng)單點(diǎn)故障和模塊兼容性問題，提高了系統(tǒng)的穩(wěn)定性和可擴(kuò)展性。

2 監(jiān)測(cè)系統(tǒng)設(shè)計(jì)

橋梁健康監(jiān)測(cè)系統(tǒng)層次架構(gòu)，主要包含四個(gè)部分：感知層、數(shù)據(jù)層、服務(wù)層和應(yīng)用層。感知層由現(xiàn)場(chǎng)的各種監(jiān)測(cè)傳感器、采集儀、傳輸設(shè)備、供電系統(tǒng)和保護(hù)裝置組成；數(shù)據(jù)層由分布式數(shù)據(jù)庫(kù)、數(shù)據(jù)接收與解析服務(wù)構(gòu)成；服務(wù)層是采用微服務(wù)架構(gòu)搭建的管理與分析系統(tǒng)，主要實(shí)現(xiàn)對(duì)數(shù)據(jù)、用戶、項(xiàng)目和設(shè)備的管理，同時(shí)在此基礎(chǔ)上還實(shí)現(xiàn)數(shù)據(jù)的處理、預(yù)警、和評(píng)估等功能；應(yīng)用層由web端應(yīng)用構(gòu)成。

2.1 感知層

感知層主要負(fù)責(zé)實(shí)時(shí)采集橋梁監(jiān)測(cè)的各類數(shù)據(jù)并傳輸?shù)綌?shù)據(jù)層，當(dāng)某座橋梁需要建立健康監(jiān)測(cè)系統(tǒng)后首先要制定監(jiān)測(cè)方案，在橋梁有限元分析結(jié)果的基礎(chǔ)上，結(jié)合大橋的靜、動(dòng)力計(jì)算結(jié)果、確定監(jiān)測(cè)參數(shù)、測(cè)點(diǎn)數(shù)量、布置位置以及設(shè)備選型。并在此基礎(chǔ)上也會(huì)根據(jù)經(jīng)驗(yàn)、成本以及現(xiàn)場(chǎng)實(shí)際情況進(jìn)行調(diào)整，力爭(zhēng)以最少的傳感器獲取最完整的監(jiān)測(cè)數(shù)據(jù)。傳感器通過有線或者無線與采集儀進(jìn)行相連，采集儀是整個(gè)感知層的核心，向下可實(shí)現(xiàn)對(duì)傳感器采樣間隔的控制，當(dāng)監(jiān)測(cè)數(shù)據(jù)不良好的時(shí)候，縮短采樣周期和增大采樣頻率，向上可通過其內(nèi)置的DTU和現(xiàn)場(chǎng)的網(wǎng)絡(luò)將數(shù)據(jù)發(fā)送到數(shù)據(jù)層。通常整個(gè)現(xiàn)場(chǎng)使用生活用電作為供電源，對(duì)于現(xiàn)場(chǎng)條件惡劣的橋使用太陽能、風(fēng)能和蓄電池組合提供。

2.2 數(shù)據(jù)層

對(duì)于感知層發(fā)來的數(shù)據(jù)包，首先通過數(shù)據(jù)解析服務(wù)進(jìn)行接收和解析，該服務(wù)是一個(gè)利用c#語言編寫的微服務(wù)，可單獨(dú)進(jìn)行部署，當(dāng)監(jiān)測(cè)的橋梁數(shù)目增多、采集頻率加快時(shí)，該服務(wù)承接的數(shù)據(jù)壓力增大，很容易造成擁擠和過載，因此該部分采用多個(gè)實(shí)例服務(wù)器分散壓力。數(shù)據(jù)解析完成以后不僅僅要存入數(shù)據(jù)庫(kù)，還要轉(zhuǎn)發(fā)給其他服務(wù)進(jìn)行下一步處理或者進(jìn)行實(shí)時(shí)數(shù)據(jù)分析，因此用消息隊(duì)列Rabbit MQ進(jìn)行消息的發(fā)布，不同的服務(wù)只要訂閱消息隊(duì)列就能夠?qū)崟r(shí)獲得采集的數(shù)據(jù)，從而進(jìn)行下一步操作。為了防止消息隊(duì)列擁堵或者網(wǎng)絡(luò)中斷等原因造成的數(shù)據(jù)丟失，采用Redis進(jìn)行緩存。

2.3 服務(wù)層

根據(jù)實(shí)際項(xiàng)目的需求，本系統(tǒng)共設(shè)計(jì)開發(fā)了7個(gè)微服務(wù)：數(shù)據(jù)解析、數(shù)據(jù)管理、用戶管理、橋梁項(xiàng)目管理、數(shù)據(jù)分析、預(yù)警預(yù)報(bào)和安全評(píng)估。相關(guān)部署見表1，其中數(shù)據(jù)解析、數(shù)據(jù)管理、數(shù)據(jù)分析和預(yù)警由于承擔(dān)大量的讀寫壓力和并發(fā)訪問，因此采用多實(shí)例分布式部署。數(shù)據(jù)解析服務(wù)主要進(jìn)行數(shù)據(jù)的解析以及推送；數(shù)據(jù)管理服務(wù)主要負(fù)責(zé)數(shù)據(jù)的增刪改查操作，基于SpringBoot框架編寫；數(shù)據(jù)分析服務(wù)主要提供數(shù)據(jù)的分析算法，例如對(duì)異常值的識(shí)別(肖維納準(zhǔn)則、拉依達(dá)準(zhǔn)則、四分位法)、數(shù)據(jù)去噪聲(小波、EMD、SVM等)、回歸(多項(xiàng)式回歸、貝葉斯回歸)以及預(yù)測(cè)(灰色模型)等算法，由于算法編寫難度較大，因此該部分采用python及其開源算法包從而降低開發(fā)難度；預(yù)警主要分為兩部分，一部分是對(duì)實(shí)時(shí)接收的數(shù)據(jù)進(jìn)行計(jì)算，如果滿足預(yù)警條件則發(fā)送通知，另一部分是對(duì)過往的數(shù)據(jù)進(jìn)行周期性分析，產(chǎn)生周期報(bào)告，同時(shí)根據(jù)之前的大量數(shù)據(jù)去修正有限元模型，使它更符合實(shí)際橋梁狀況，從而使閾值更準(zhǔn)確；用戶管理以及項(xiàng)目管理所承擔(dān)的壓力較小，訪問頻率不高，因此部署在一臺(tái)服務(wù)器上足以滿足實(shí)際需求。

表1 系統(tǒng)服務(wù)部署情況

每個(gè)微服務(wù)都有自己的網(wǎng)關(guān)，實(shí)現(xiàn)路由轉(zhuǎn)發(fā)以及充當(dāng)一個(gè)過濾器的功能。路由轉(zhuǎn)發(fā)是指接收外界請(qǐng)求，轉(zhuǎn)發(fā)到后端的微服務(wù)上去，而過濾器則是在服務(wù)網(wǎng)關(guān)中可以完成一系列的橫切功能，例如權(quán)限校驗(yàn)、限流以及監(jiān)控等。服務(wù)與服務(wù)之間需要彼此相互發(fā)現(xiàn)，這種機(jī)制稱為服務(wù)發(fā)現(xiàn)機(jī)制，通過注冊(cè)中心來實(shí)現(xiàn)，本系統(tǒng)的注冊(cè)中心為consul。注冊(cè)中心可抽象為一張注冊(cè)表，每個(gè)服務(wù)啟動(dòng)后會(huì)向注冊(cè)中心發(fā)送自己的IP和端口號(hào)，然后每隔一段時(shí)間刷新注冊(cè)中心，保證注冊(cè)中心知道每個(gè)注冊(cè)服務(wù)的運(yùn)行狀態(tài)。一個(gè)來自終端的請(qǐng)求，首先會(huì)先到達(dá)通過Nginx搭建的負(fù)載均衡，然后采用輪訓(xùn)策略發(fā)送到注冊(cè)中心的注冊(cè)執(zhí)行單元上，執(zhí)行單元執(zhí)行之后返回響應(yīng)，通過這種方式可以將請(qǐng)求進(jìn)行分?jǐn)偅軌蛴行Ы档头?wù)器壓力，同時(shí)又有很好的容錯(cuò)性。

2.4 應(yīng)用層

應(yīng)用層為用戶提供一個(gè)交互的終端，本系統(tǒng)的終端為web應(yīng)用，基于瀏覽器提供UI與云服務(wù)器進(jìn)行交互，利用VUE前端框架搭配webpack4.0項(xiàng)目構(gòu)建工具進(jìn)行開發(fā)。VUE是一套用于構(gòu)建用戶界面的漸進(jìn)式框架，它的核心庫(kù)只關(guān)注視圖層，不僅便于與第三方庫(kù)或既有項(xiàng)目整合，而且當(dāng)與現(xiàn)代化的工具鏈以及各種支持類庫(kù)結(jié)合使用時(shí)，VUE也完全能夠?yàn)閺?fù)雜的單頁(yè)應(yīng)用提供驅(qū)動(dòng)。數(shù)據(jù)可視化方面采用echarts.js進(jìn)行開發(fā)，針對(duì)不同類型的數(shù)據(jù)選取最直觀合理的展示方式，部分系統(tǒng)頁(yè)面如圖1所示。

圖1 系統(tǒng)部分應(yīng)用圖

2.5 性能測(cè)試

為了保障系統(tǒng)在線上環(huán)境中穩(wěn)定運(yùn)行，需要對(duì)系統(tǒng)進(jìn)行性能測(cè)試。常用來考察系統(tǒng)性能的指標(biāo)有系統(tǒng)吞吐量和響應(yīng)時(shí)間。在本研究中，采用Apache JMeter壓力測(cè)試工具對(duì)三種架構(gòu)的橋梁健康監(jiān)測(cè)系統(tǒng)進(jìn)行測(cè)試。選取一個(gè)查詢數(shù)據(jù)的API接口進(jìn)行測(cè)試，改變線程組的數(shù)量為100、200、300、400、500、800、900、1 000、1 400、1 800、2 000、2 400、3 000、3 500，分別對(duì)三種架構(gòu)系統(tǒng)進(jìn)行測(cè)試，查看吞吐量以及響應(yīng)時(shí)間。

3 結(jié) 果

3.1 性能分析

圖2(a)是吞吐量曲線圖，可以看出三種架構(gòu)的系統(tǒng)隨著并發(fā)數(shù)的增加，吞吐量都在增大，并且都遵循先快速增長(zhǎng)然后緩慢增長(zhǎng)到飽和狀態(tài)后在快速下降的趨勢(shì)。相同并發(fā)數(shù)情況下，微服務(wù)架構(gòu)的吞吐量最大，其次是SOA，最后是三層架構(gòu)。同時(shí)在支持的并發(fā)數(shù)方面，微服務(wù)架構(gòu)支持更高的并發(fā)數(shù)，其次是SOA，最后是三層架構(gòu)。圖2(b)是平均響應(yīng)時(shí)間曲線，在并發(fā)數(shù)很小的情況下，三種架構(gòu)的響應(yīng)時(shí)間差距很小，隨著并發(fā)的增大差距也增大，三層架構(gòu)高于SOA，SOA高于微服務(wù)架構(gòu)。

圖2 JMeter性能測(cè)試

綜合吞吐量曲線和響應(yīng)時(shí)間曲線，在相同并發(fā)情況下微服務(wù)架構(gòu)的吞吐量更高，響應(yīng)時(shí)間更快，然后是SOA，最后是三層架構(gòu)。因此在性能方面，微服務(wù)架構(gòu)系統(tǒng)的性能更好。

3.2 赤石特大橋概況

赤石特大橋位于湖南省郴州市宜章縣赤石鎮(zhèn)下歐村、漁溪村之間的河流階地及河漫灘上，大橋橫跨青頭江河道，是一座四塔預(yù)應(yīng)力混凝土斜拉橋，于2019年6月布設(shè)相關(guān)監(jiān)測(cè)傳感器并接入基于微服務(wù)架構(gòu)研發(fā)的系統(tǒng)。

3.3 監(jiān)測(cè)方案

考慮到橋梁類型、現(xiàn)場(chǎng)情況和成本控制，該橋的監(jiān)測(cè)參數(shù)類型主要為環(huán)境激勵(lì)，應(yīng)力應(yīng)變以及振動(dòng)和索力，詳細(xì)設(shè)備選型見表2。

表2 固定傳感器布設(shè)一覽表

3.4 監(jiān)測(cè)結(jié)果

本系統(tǒng)完成布設(shè)和調(diào)試后于2019年4月1日正式投入使用，截止到2021年12月1日共產(chǎn)生54 329條數(shù)據(jù)，其中應(yīng)力應(yīng)變數(shù)據(jù)17 076條，索力數(shù)據(jù)20 068條，撓度數(shù)據(jù)與傾角數(shù)據(jù)共15 074條，其他監(jiān)測(cè)類型數(shù)據(jù)2 111條。本文中選取2019年6月12到7月14的部分傳感器數(shù)據(jù)進(jìn)行分析，選取CH-S2截面中的梁端位移兩測(cè)點(diǎn)以及CH-S4中的兩個(gè)對(duì)稱索力測(cè)點(diǎn)、一個(gè)撓度測(cè)點(diǎn)和8個(gè)應(yīng)力測(cè)點(diǎn)數(shù)據(jù)進(jìn)行分析，數(shù)據(jù)曲線見圖3，對(duì)應(yīng)測(cè)點(diǎn)閾值見表3。

表3 監(jiān)測(cè)點(diǎn)閾值表

圖3 應(yīng)用實(shí)例圖

圖3中(a)是梁端位移曲線圖(CS-BD1，CS-BD2)，剔除由于載荷變化或者環(huán)境變化引起的數(shù)據(jù)波動(dòng)，選取穩(wěn)定段數(shù)據(jù)進(jìn)行觀察分析，梁端位移數(shù)據(jù)波動(dòng)較小，均在合理范圍內(nèi)，低于該測(cè)點(diǎn)的預(yù)警值，同時(shí)對(duì)稱位置傳感器數(shù)據(jù)一致性良好；(b)是索力數(shù)據(jù)圖(CS-CG1，CS-CG2)，索力值分布較為正常，上下游對(duì)稱位置的索力差別不大，大橋斜拉索受力狀態(tài)正常；(c)是撓度數(shù)據(jù)曲線圖(CS-PT1)，剔除外在環(huán)境引起的明顯數(shù)據(jù)毛刺變化，數(shù)據(jù)整體波動(dòng)范圍正常，呈現(xiàn)較好的波動(dòng)規(guī)律性；(d)是同一截面內(nèi)的應(yīng)力數(shù)據(jù)(CS-SG-4)，橋梁同一截面相近應(yīng)力測(cè)點(diǎn)數(shù)據(jù)波動(dòng)規(guī)律一致性較好，且波動(dòng)幅值在允許范圍內(nèi)。

4 結(jié) 論

微服務(wù)架構(gòu)是對(duì)傳統(tǒng)單體架構(gòu)以及SOA的一個(gè)升級(jí)，它具有小、獨(dú)、輕、松四個(gè)要素，性能穩(wěn)健，可擴(kuò)展性強(qiáng)，能夠滿足日益增長(zhǎng)的業(yè)務(wù)需求。采用微服務(wù)架構(gòu)開發(fā)橋梁健康監(jiān)測(cè)系統(tǒng)，并將各個(gè)服務(wù)進(jìn)行多實(shí)例部署，不僅分散了服務(wù)壓力，同時(shí)由于微服務(wù)架構(gòu)的自身特點(diǎn)降低了開發(fā)難度以及提升了系統(tǒng)的計(jì)算能力。在性能方面，通過測(cè)試三種不同架構(gòu)系統(tǒng)的性能實(shí)驗(yàn)發(fā)現(xiàn)，微服務(wù)架構(gòu)具有更高的吞吐量、支撐更多并發(fā)用戶數(shù)以及擁有更小的響應(yīng)時(shí)間。同時(shí)通過實(shí)際案例表明微服務(wù)的架構(gòu)健康監(jiān)測(cè)系統(tǒng)可以容納更多的傳感器和更快的計(jì)算速度。