基于微服務架構的地震站網全流程一體化監控平臺設計與實現

王 坦 師宏波 黃經國 王 軍 韓宇飛 代光輝 劉艷瓊 姬運達楊 陳 祝 杰 王東孝

1）中國北京 100045 中國地震臺網中心

2）中國杭州 310023 杭州敘簡科技股份有限公司

0 引言

微服務的核心思想是，將應用功能盡可能細地劃分成獨立的服務，每個服務專注于單一具體的業務功能實現，服務之間采用輕量級的通信機制（通常是基于HTTP 的Restful API）互相協調、互相配合，最終為用戶提供符合不同需求的功能服務（龍新征等，2017）。微服務架構是一種架構風格，目的是將大型的、復雜的、長期運行的系統拆分為一組相互配合的服務。系統中每個微服務均可被獨立部署，各個微服務之間松耦合，每個微服務僅關注于完成一件任務并較好地完成該任務。與傳統的面向服務的架構（SOA）相比，微服務架構降低了系統的耦合性，提高了系統容錯性、伸縮性及可擴展性，具有易于迭代開發、業務擴展與持續交付的能力。

本文基于中國地震臺網中心地震臺站監控運維平臺現狀，對平臺架構進行調整設計，在實現平臺架構的服務拆分粒度細化的同時，與具體業務相結合，達到各管理服務的內部高內聚、之間低耦合的效果。按照地震站網監控對象，系統包括測震、強震、GNSS、重力、形變、流體、地電和地磁等不同手段，從服務類型和服務對象進行劃分設計，進而加工處理、分別劃分成微服務。劃分后，各服務之間彼此獨立，可根據業務需求進行服務調用，從而實現地震臺站監控運維平臺由綜合運維單體架構向微服務架構的轉變。新的架構，系統升級靈活性更強，服務功能更加豐富，系統維護成本更低。

1 現狀及存在的問題

隨著互聯網技術的高速發展及企業信息化水平的顯著提升，以往地震臺站監控運維平臺應用的SOA 架構面臨系統擴展困難、成本比較高的問題，難以滿足互聯網環境下應用的高并發請求以及海量數據交互的要求。傳統架構下的應用模塊依賴關系復雜，功能的完善和擴展困難，同時增加了測試和部署的工作難度。任何一個模塊中的一個bug（比如內存泄露等）均有可能摧垮整個進程，構建部署和啟動時間較長，配置較復雜，在開發環境中的效果與運行環境中的效果難以保持一致，當業務流出現錯誤和異常時，無法快速定位，需要花費大量時間來查找和定位問題，最終導致運維工作處于被動狀態，不利于快速上線、頻繁部署的應用場景，阻礙了持續交付。

在云計算、大數據、物聯網等新技術日趨普及和成熟的情況下，微服務架構逐漸進入人們的視線。微服務架構的本質是把整體業務拆分成諸多有特定明確功能的服務，通過諸多分散的小服務之間的配合，去解決更大、更復雜的問題。其特點決定了每個服務是分布式部署、獨立運行的無狀態服務（崔蔚等，2016）?；谖⒎占軜嫷膽帽O控系統可將調用鏈路及調用鏈路上的每個節點作為監控對象，對二者性能進行監控和跟蹤，并對出現的異常進行報警，方便運維人員對系統的日常運維和優化。微服務技術架構見圖1。

圖1 微服務技術架構（晉榮等，2019）Fig.1 Microservice technology architecture diagram（JIN Rong et al，2019）

地震站網全流程一體化監控平臺微服務架構設計是，將耦合度高的應用劃分成一組細粒度的、業務邏輯單一的以及能夠高度自治的服務，服務之間互相配合、共同協作，向用戶提供最終業務功能。由分布式MySQL 數據庫集群、HBase 集群、HDFS 分布式存儲文件系統、分布式對象存儲系統OSS 結合Elastic Search 的分布式索引系統提供基礎數據支撐，將面向不同服務應用的地震站網監控產品微服務功能封裝到可虛擬化部署的Docker容器中，通過Spring Cloud 實現服務發現與注冊、配置管理、服務調用、服務網關、負載均衡、熔斷、數據監控等功能，構建生產級的靈活擴展微服務應用，方便進行地震站網監控服務的持續開發和集成（譚一鳴，2017）。從而以松散的服務方式，實現平臺獨立化部署各個服務；另一方面，可以基于Docker 容器技術，實現平臺的初始化部署，并在此過程中完成服務的冗余備份，以保障地震站網全流程一體化監控平臺整體的高可用性。

2 系統架構設計

為滿足平臺資源按需使用、可擴展性要求，地震站網全流程一體化監控平臺基于Spring Cloud 的微服務架構，結合Docker 容器技術，按服務數據類型與服務對象開發集成面向不同應用領域的站網監控管理功能，實現服務業務的可伸縮、可靈活擴展（王方旭，2018），以滿足為不同服務對象提供可伸縮、可擴展、靈活定制的個性化站網數據服務的需求。

以層次化、組件化的方式進行平臺總體架構設計，集成元數據、中間件（包括Web中間件、消息中間件等）等多種技術，遵循統一的技術標準進行服務平臺開發。通過Hadoop 分布式處理框架，利用分布式MySQL 數據庫集群、HBASE（Hadoop Database）分布式存儲系統集群以及HDFS 分布式存儲文件系統，結合分布式對象存儲系統OSS，存儲管理各種結構化與非結構化數據與產品，實現分布式的高容錯數據存儲（張羽，2016）。同時以MapReduce 并行處理技術以及Spark 內存計算技術，實現多種并發數據的分布式處理。

基于Lucene 作為內部引擎的Elastic Search 分布式全文檢索系統，實現大規模地震站網監控數據的快速檢索，采用Impala 提供的基于HDFS 和OSS 的分布式快速查詢引擎，為整個系統提供基于分布式存儲的快速數據訪問服務。通過REDIS 數據緩存技術，將高頻訪問的實時服務數據以一定數據結構保存在REDIS 內存數據庫中，提高實時更新數據的查詢、頁面響應、顯示及應用效率，滿足實時數據服務的時效性要求。結合RabbitMQ高性能消息隊列，對多任務并發調度信息進行有序管理，實現高可用、多并發任務的高效調度管理。平臺整體設計見圖2。

圖2 整體設計Fig.2 Overall design drawing

平臺采用基于微服務架構開發，各個子模塊統一基于JavaEE 開發，采用IT 行業的主流開發框架Spring Boot，前端采用REACT 框架，實現前后端分離，并通過輕量級的REST 接口與服務網關交互，降低程序耦合性。

服務內部使用Zuul服務網關做負載均均衡和登錄鑒權；Eureka負責服務的注冊與發現，避免服務之間的直接調用，方便服務后續的水平擴展、故障轉移，將各服務連接起來并保持服務高可用；Hystrix 負責服務熔斷和降級，連續多次失敗進行熔斷保護，并按一定間隔時間檢查調用失敗的服務，若恢復將繼續提供服務；Spring Cloud Config提供統一的配置中心服務，實現分布式系統配置文件的統一管理。

結構化數據采用MySQL 數據庫進行存儲。非結構化數據基于內存或分布式緩存Redis、MongoDB 等，業務系統信息通過kafka、rabbitMQ 等消息中間件傳輸。

作為一種松散耦合、服務高度自治的架構模式，微服務架構將耦合度高的應用劃分成一組細粒度的、業務邏輯單一的服務，服務獨立部署并在各自進程中獨立運行，服務之間互相配合與共同協作，因此微服務架構本質上是分布式系統。對于服務節點之間的通信，無論是同步還是異步通信方式，本質上是一種服務依賴關系的體現（方志明，2018）。對于地震站網全流程一體化監控平臺的微服務，可篩選相互存在依賴關系的服務，并以此關系構建一個有向圖Dependency，因服務之間的依賴不存在環的情況，所以是一個有向無環圖。該有向圖以微服務作為節點，節點的入度表示服務的被依賴關系，即節點的入度越大，該微服務被越多其他微服務依賴。

3 系統功能實現

地震站網全流程一體化監控平臺應用微服務技術架構，橫向拆分運維系統功能和業務，實現注冊中心、告警管理、測試管理、性能監測、事件通知和值勤管理等微服務，向通信指揮和網絡運維人員提供穩定、可靠的監控服務集群。地震站網全流程一體化監控平臺的微服務組成見圖3。

圖3 微服務組成Fig.3 Microservice composition

地震站網全流程一體化監控平臺按照功能和業務維度劃分為多個微服務模塊，每個微服務單獨運行，單獨部署，各個微服務之間通過API 調用實現互聯互通。按照層次化設計思想，該平臺分為接入層、業務層和應用層進行功能設計。系統組成界面見圖4。

圖4 微服務組成界面Fig.4 The user interface of microservice composition

系統接入層實現被管系統的接入和數據采集能力（圖5）。實現與其他系統和設備的連接，并通過接口獲取狀態上報數據和采集數據，包括對觀測設備、通用設備、IP 網設備以及其他業務系統狀態數據的接入和數據采集。系統為每一種被管對象增加一個單獨的適配器服務，保證任何一個適配器服務的正?；虍惓２挥绊懫渌m配器服務模塊。

圖5 系統接入架構Fig.5 System access architecture diagram

業務層由一組實現不同業務的微服務組成，通過協同處理業務將接入層獲取的數據進行處理，綜合分析和挖掘，存儲并按需進行數據融合處理，包括對資源、設備、運維、流量和測試等相關數據的處理，實現告警監測、通信資源管理、故障分析及流程管理等功能（圖6）。

圖6 告警監測業務流程Fig.6 Alarm monitoring business flowchart

應用層主要面向用戶提供操作入口和全景監視視圖。在系統開發階段，一是基于開源軟件，快速構建了服務注冊中心服務網關、服務負載均衡、服務容錯和分布式緩存等中間件，自主研發了服務監控平臺，為系統開發提供了運行基礎。抽取分布式調度服務作為基礎服務，采用任務“統一調度管理、分布式執行”模式，提供各應用的統一管理和應用件協作服務，并可為其他項目建設重用?；贛aven 開源工具，定制了開發環境，包括開發工具、開發模板、構建倉庫等，實現了開箱即用、免系統環境配置、一鍵啟動及快速構建等特點（趙樂樂等，2016）。在開發過程中，通過微服務架構設計，提高了系統的靈活性和可擴展性，在業務需求漸清晰的情況下，實現功能快速迭代，應用敏捷開發。

4 平臺部署與測試

基于微服務架構的地震站網全流程一體化監控平臺由于松散耦合的構建模式，平臺中包含數量眾多、業務邏輯各異的微服務。面對該情景，采用傳統手動部署或腳本部署是相對低效的方式。為了維護地震站網全流程一體化監控平臺的高可用性，通過對容器實行冗余備份，構建容器集群。

在進行微服務架構設計時，將系統劃分為應用層、業務服務層、基礎服務層、微服務中間件層和監視層。其中，應用層和業務層是業務價值體現的關鍵。應用層“以用戶為中心”，專注于用戶體驗與業務功能；服務層通過將系統專業化分工，采用服務化方式，提供“去中心化”服務調用，并通過服務編排組合，可快速滿足多應用多前端的功能實現（辛園園等，2018）。微服務平臺主要包含基礎服務層、微服務中間件層和監控層等功能。

（1）基礎服務層。該層是服務重用和系統快速搭建的基礎。微服務劃分本質上是對業務功能進行解耦并獨立部署而具有共性業務特征的功能進一步內聚和抽取，形成基礎服務中心，在系統內或系統間的多個微服務中共享使用?；A服務中心包括認證中心、調度中心、日志中心等公共服務應用。

（2）微服務中間件層。微服務中間件層主要實現服務的統一管理，為服務間的互相協作運行提供技術保障，是架構實現的技術支撐。服務注冊中心通過集中地注冊管理機制，統一管理服務名稱與服務調用地址之間的映射關系，實現服務的自動注冊和發現，幫助服務調用者獲取服務提供者的地址信息。服務網關實現請求轉發、動態路由等功能，可以降低服務演進過程中地址變動和增長帶來的更新成本；也可以實現協議轉發，能提高基礎服務中心的協議擴展性。服務負載均衡通過水平伸縮實現服務調用請求的負載均衡，有效分散單節點的計算負載，實現服務的彈性擴展。服務容錯構建流量控制、故障隔離、斷路器等容錯與修復機制，避免某個服務不可用時，導致故障蔓延，并最終造成整個系統癱瘓的風險（李春陽等，2017）。分布式緩存利用鍵值數據庫基于多臺PC 服務器，為分布式環境下應用對象緩存、狀態緩存等場景提供統一的分布式緩存解決方案。

（3）監控層。監控層是系統穩定運行的保障，隨著系統服務數量逐步增多，服務之間的調用關系越來越復雜，這也對微服務架構下如何保障系統可靠運行提出了新挑戰。通過對應用服務、資源服務調用鏈路等進行監控，能夠實現微服務架構下請求可追溯、問題可預警、伸縮有依據（張晶等，2017）。其主要功能包括站網應用概覽、數據監測詳情、環境參數、應用軟件服務狀況、數據庫監控、服務調用鏈分析等，同時也為監控運維一體化提供了重要支撐工具（圖6）。

系統調整后，項目組對1 036 個用例進行了測試，通過1 028 個，未通過8 個，修復后最終通過測試，能夠正常運行。模塊中的功能均已正確實現，性能、壓力測試指標均達到要求。

5 結束語

本文結合實際開發項目，針對地震站網全流程一體化監控平臺中存在的諸多難題和相應的解決策略進行分析?；赟pring Cloud 的微服務架構提供靈活可擴展的數據服務，將面向不同服務應用的地震臺站監控管理微服務功能封裝到可虛擬化快速部署的Docker 容器中，構建高伸縮性的數據服務，方便地進行地震臺站監控管理服務的持續開發和集成，滿足不斷拓展的多種多樣的地震臺站管理服務需求。通過實驗證明了微服務架構的服務系統可以提高用戶體驗，降低開發成本，實現高可用性，具有可持續發展的潛力。隨著互聯網思維和云平臺部署越來越趨勢化，微服務架構在地震臺站監控管理應用系統的建設中將體現出越來越大的價值。