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

李 濤，朱自強，魯光銀，白冬鑫

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

1 介 紹

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

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

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

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

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

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

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

2 監(jiān)測系統(tǒng)設計

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

2.1 感知層

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

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

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

2.3 服務層

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

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

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

2.4 應用層

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

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

2.5 性能測試

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

3 結(jié) 果

3.1 性能分析

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

圖2 JMeter性能測試

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

3.2 赤石特大橋概況

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

3.3 監(jiān)測方案

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

表2 固定傳感器布設一覽表

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

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

表3 監(jiān)測點閾值表

圖3 應用實例圖

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

4 結(jié) 論

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