基于微服務及大數據的通號智能維護系統的研發及其應用

宋 揚

(1．北京全路通信信號研究設計院集團有限公司，北京 100070；2．北京市高速鐵路運行控制系統工程技術研究中心，北京 100070)

1 概述

本文所介紹的智能維護系統，主要用于對通號各類設備的維護提供幫助，如對設備故障的上報，設備生命周期的追蹤，以及設備臺賬管理等，使售后部門能完全準確掌握通號各產品情況。本文著重對整個智能維護系統的服務設計及服務架構進行闡述：系統各模塊采用SpringBoot作為服務基礎框架，采用SpringCloud實現微服務架構；工作流使用Activiti,其支持使用Bpmn流程圖進行流程的修改與維護，并且各個流程環節采用表單視圖和表單數據分離存儲的方式（采用非關系數據庫Mongodb進行存儲），從而實現工作流程的動態可配置；該系統在數據存儲及分析方面，應用了一系列大數據工具，采用HDFS分布式存儲框架實現文件的上傳及存儲管理，采用HBase對流程的各個歷史狀態進行存儲，便于后期進行對流程的追溯調查，采用Kafka及Hive進行系統日志的收集及持久化，便于后期對數據進行分析，為實現后期的大數據分析提供了服務支撐。

2 系統各微服務模塊設計

2.1 系統微服務架構組成

本系統的微服務架構，主要采用SpringBoot及SpringCloud等框架，分為微服務注冊中心(Eureka)，微服務網關模塊(Zuul)，通用服務模塊，工作流服務模塊，設備臺賬模塊。網關模塊、工作流模塊、通用服務模塊及設備臺賬模塊均向注冊中心注冊，同時它們可以拉取其他微服務模塊信息，也可以通過Feign接口調用其他模塊服務，實現RPC調用，客戶端和網頁直接訪問網關模塊，進而訪問各業務模塊，系統結構如圖1所示。

圖1 總系統架構圖Fig.1 Overview of system architecture

2.2 微服務注冊中心及網關服務

Eureka是Netflix開發的服務發現框架，本身是一個基于REST的服務，用以達到負載均衡和中間層服務故障轉移的目的。SpringCloud將它集成在其子項目中，以實現SpringCloud的服務發現功能。在本系統中，Eureka部署為兩個節點，互相注冊并合并各模塊注冊信息，其他模塊也進行雙節點高可用部署，作為Consumer注冊在Eureka上。運維人員可以通過Eureka相關接口查看各節點的健康情況，并進行節點的啟用或移除處理，進而實現節點平滑的下線或是升級處理。

Zuul是Netflix開源的微服務網關，可以和Eureka、Ribbon、Hystrix等組件配合使用。SpringCloud對Zuul進行了整合與增強，主要功能是路由轉發和過濾器，在本系統中，客戶端直接訪問Zuul模塊,網關模塊與注冊中心進行通信，將用戶請求路由到各個子模塊，方便了客戶端的訪問。同時，Zuul可以配置多個Filters,進行用戶的權限判斷及控制，進而實現返回數據的定制，如各個角色用戶不同客戶端功能頁面的展示，方便了不同角色的用戶使用。

2.3 各具體業務模塊介紹

通用服務模塊主要用于用戶的注冊，注冊用戶的審核等功能。用戶登錄驗證通過后，獲取一定有效時間的令牌，其存儲于Redis實現各模塊間的共享，并且可以通過令牌從Redis中獲取用戶的相關權限信息。此外，通用服務也集成了文件上傳和下載的功能，獲取用戶信息的功能，其他模塊可以通過Feign接口調用這些服務，實現服務間的RPC調用。

工作流服務模塊用于流程的創建及管理，設備故障的上報等具體流程業務的實現。該模塊的工作流功能主要通過BPM框架Activiti實現。SpringBoot也提供Activiti對應的支持庫，在項目中導入編輯好的工作流程圖（Bpmn文件）即可將對應的工作流數據結構導入，其示例如圖2所示。流程的每一個環節的表單視圖在后期可能根據實際需求有多次修改，本系統在設計時為了縮減開發及后期維護成本，通過表單視圖和表單數據分離儲存的方式（儲存于Mongodb中），實現了各表單視圖的動態可配置。業務原理為：工作流服務啟動后，Activiti相關類實例化并自動注入，掃描項目路徑下的Bpmn文件并將其轉換為工作流結構對應的數據結構存儲于內存中，Bpmn文件示例如圖2所示；客戶端可以通過接口獲取流程數據結構，包括流程的各環節名稱以及環節ID，管理員通過客戶端對各環節的表單視圖進行定制及上傳，視圖中的各個輸入項具有唯一的ID以及權限配置；用戶獲取空的表單視圖后填入數據并上傳，各輸入項數據中也包含輸入項視圖ID；表單數據回顯時，數據通過輸入項ID和流程實例ID和表單視圖進行綁定，并且根據各輸入項的權限配置對數據進行讀寫權限控制，進而實現了數據回顯，客戶端顯示效果如圖3所示。

圖2 流程圖示例Fig.2 An example of flowchart

圖3 流程表單示例Fig.3 An example of flowchart form

設備臺賬模塊主要用于通號設備的管理，包括設備的錄入，生命周期追溯及管理等。由于每一類設備具有不同的屬性，屬性名和屬性個數以及錄入展示形式均有不同，采用傳統的關系型數據庫（如MySQL）實現該需求難度較高，故而采用非關系型數據庫Mongodb將設備屬性分為固定屬性（固定字段）和擴展屬性（可變字段）進行存儲。其中固定屬性與傳統關系型數據庫字段類似，擴展屬性采用json格式進行序列化后以字符串形式進行存儲，進而實現不同設備不同屬性的定制。

3 大數據工具在系統中的應用

3.1 HBase在系統中的應用

HBase是一個分布式的、面向列的開源數據庫,以HDFS作為底層的存儲服務。它與傳統的面向行的關系型數據庫不同，在水平方向有一個或多個列簇組成，每個列簇可以有任意多個列組成。HBase的每一單元由一個唯一的Row Key確定，但其更新數據時，不會刪除原有的數據，而是增加一個新的版本。在本系統中，以流程名稱和流程實例ID作為RowKey,一個流程在提交數據到數據庫后，也提交相應的數據到HBase,作為該流程的一個新的版本，新版本的數據和上一版本的數據可以進行對比，生成一條對比日志并存儲于Mongodb上。流程的處理人員或是處理人員可以查看流程的處理記錄，進行流程后期的朔源及調查。

3.2 Kafka以及Hive在系統中的應用

當本系統投入使用后，會產生大量的可用數據，如各地區電務段用戶、各工廠用戶、各分部用戶使用智能維護系統的活躍數據，又比如各類產品設備的故障情況，對于這些數據的分析，可以產生很多具有價值的結論，如哪類產品或是哪個電務段的產品故障較多，又或是出現最多的故障類型等。這就需要將數據收集，供以后分析。

考慮到上述需求，采用Kafka作為數據收集的消息隊列，其具有高吞吐量，高可用的特點，本系統所搭建的Kafka具有3個Broker節點，建立Topic時可以將消息備份設置為3，當一臺Broker宕機后，還有2個備份可以使用，不會丟失消息。在實際使用時，本系統在需要收集數據的每一個接口上進行切面增強，獲取提交的數據信息，將其發送到對應的Kafka消息主題，避免了過多的編程工作及代碼耦合。在數據存儲方面，采用Hive作為數據倉庫，其采用HDFS作為底層存儲服務，可以對海量數據進行離線的處理及分析，除了支持MapReduce進行數據計算外，也支持類sql語句對數據進行分析計算。

消息到達Kafka后，需要將消息進行消費并儲存。在本系統中，采用Flume消費Kafka的消息數據并下沉到Hive,對后期數據分析進行數據支持。數據收集服務架構如圖4所示。

圖4 數據收集服務架構圖Fig.4 Architecture of data collection service

4 結論

本智能維護系統在投入使用以來，實現設備故障上報，設備管理，工程進度管理，資料維護等多種功能，支持了電務段人員以及工廠人員的相關工作的電子信息化，推進了相關工作的進展，同時也對相關使用數據進行有效收集，為后期的數據分析和大數據賦能提供了數據支撐，具有豐富的實際使用價值及經濟意義。