基于微服務架構的橋梁健康監測系統研發與應用

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

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

1 介 紹

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

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

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

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

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

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

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

2 監測系統設計

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

2.1 感知層

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

2.2 數據層

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

2.3 服務層

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

表1 系統服務部署情況

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

2.4 應用層

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

圖1 系統部分應用圖

2.5 性能測試

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

3 結 果

3.1 性能分析

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

圖2 JMeter性能測試

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

3.2 赤石特大橋概況

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

3.3 監測方案

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

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

3.4 監測結果

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

表3 監測點閾值表

圖3 應用實例圖

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

4 結 論

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