基于微服務(wù)及大數(shù)據(jù)的通號(hào)智能維護(hù)系統(tǒng)的研發(fā)及其應(yīng)用

宋 揚(yáng)

(1．北京全路通信信號(hào)研究設(shè)計(jì)院集團(tuán)有限公司，北京 100070；2．北京市高速鐵路運(yùn)行控制系統(tǒng)工程技術(shù)研究中心，北京 100070)

1 概述

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

2 系統(tǒng)各微服務(wù)模塊設(shè)計(jì)

2.1 系統(tǒng)微服務(wù)架構(gòu)組成

本系統(tǒng)的微服務(wù)架構(gòu)，主要采用SpringBoot及SpringCloud等框架，分為微服務(wù)注冊(cè)中心(Eureka)，微服務(wù)網(wǎng)關(guān)模塊(Zuul)，通用服務(wù)模塊，工作流服務(wù)模塊，設(shè)備臺(tái)賬模塊。網(wǎng)關(guān)模塊、工作流模塊、通用服務(wù)模塊及設(shè)備臺(tái)賬模塊均向注冊(cè)中心注冊(cè)，同時(shí)它們可以拉取其他微服務(wù)模塊信息，也可以通過Feign接口調(diào)用其他模塊服務(wù)，實(shí)現(xiàn)RPC調(diào)用，客戶端和網(wǎng)頁直接訪問網(wǎng)關(guān)模塊，進(jìn)而訪問各業(yè)務(wù)模塊，系統(tǒng)結(jié)構(gòu)如圖1所示。

圖1 總系統(tǒng)架構(gòu)圖Fig.1 Overview of system architecture

2.2 微服務(wù)注冊(cè)中心及網(wǎng)關(guān)服務(wù)

Eureka是Netflix開發(fā)的服務(wù)發(fā)現(xiàn)框架，本身是一個(gè)基于REST的服務(wù)，用以達(dá)到負(fù)載均衡和中間層服務(wù)故障轉(zhuǎn)移的目的。SpringCloud將它集成在其子項(xiàng)目中，以實(shí)現(xiàn)SpringCloud的服務(wù)發(fā)現(xiàn)功能。在本系統(tǒng)中，Eureka部署為兩個(gè)節(jié)點(diǎn)，互相注冊(cè)并合并各模塊注冊(cè)信息，其他模塊也進(jìn)行雙節(jié)點(diǎn)高可用部署，作為Consumer注冊(cè)在Eureka上。運(yùn)維人員可以通過Eureka相關(guān)接口查看各節(jié)點(diǎn)的健康情況，并進(jìn)行節(jié)點(diǎn)的啟用或移除處理，進(jìn)而實(shí)現(xiàn)節(jié)點(diǎn)平滑的下線或是升級(jí)處理。

Zuul是Netflix開源的微服務(wù)網(wǎng)關(guān)，可以和Eureka、Ribbon、Hystrix等組件配合使用。SpringCloud對(duì)Zuul進(jìn)行了整合與增強(qiáng)，主要功能是路由轉(zhuǎn)發(fā)和過濾器，在本系統(tǒng)中，客戶端直接訪問Zuul模塊,網(wǎng)關(guān)模塊與注冊(cè)中心進(jìn)行通信，將用戶請(qǐng)求路由到各個(gè)子模塊，方便了客戶端的訪問。同時(shí)，Zuul可以配置多個(gè)Filters,進(jìn)行用戶的權(quán)限判斷及控制，進(jìn)而實(shí)現(xiàn)返回?cái)?shù)據(jù)的定制，如各個(gè)角色用戶不同客戶端功能頁面的展示，方便了不同角色的用戶使用。

2.3 各具體業(yè)務(wù)模塊介紹

通用服務(wù)模塊主要用于用戶的注冊(cè)，注冊(cè)用戶的審核等功能。用戶登錄驗(yàn)證通過后，獲取一定有效時(shí)間的令牌，其存儲(chǔ)于Redis實(shí)現(xiàn)各模塊間的共享，并且可以通過令牌從Redis中獲取用戶的相關(guān)權(quán)限信息。此外，通用服務(wù)也集成了文件上傳和下載的功能，獲取用戶信息的功能，其他模塊可以通過Feign接口調(diào)用這些服務(wù)，實(shí)現(xiàn)服務(wù)間的RPC調(diào)用。

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

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

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

設(shè)備臺(tái)賬模塊主要用于通號(hào)設(shè)備的管理，包括設(shè)備的錄入，生命周期追溯及管理等。由于每一類設(shè)備具有不同的屬性，屬性名和屬性個(gè)數(shù)以及錄入展示形式均有不同，采用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)（如MySQL）實(shí)現(xiàn)該需求難度較高，故而采用非關(guān)系型數(shù)據(jù)庫(kù)Mongodb將設(shè)備屬性分為固定屬性（固定字段）和擴(kuò)展屬性（可變字段）進(jìn)行存儲(chǔ)。其中固定屬性與傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)字段類似，擴(kuò)展屬性采用json格式進(jìn)行序列化后以字符串形式進(jìn)行存儲(chǔ)，進(jìn)而實(shí)現(xiàn)不同設(shè)備不同屬性的定制。

3 大數(shù)據(jù)工具在系統(tǒng)中的應(yīng)用

3.1 HBase在系統(tǒng)中的應(yīng)用

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

3.2 Kafka以及Hive在系統(tǒng)中的應(yīng)用

當(dāng)本系統(tǒng)投入使用后，會(huì)產(chǎn)生大量的可用數(shù)據(jù)，如各地區(qū)電務(wù)段用戶、各工廠用戶、各分部用戶使用智能維護(hù)系統(tǒng)的活躍數(shù)據(jù)，又比如各類產(chǎn)品設(shè)備的故障情況，對(duì)于這些數(shù)據(jù)的分析，可以產(chǎn)生很多具有價(jià)值的結(jié)論，如哪類產(chǎn)品或是哪個(gè)電務(wù)段的產(chǎn)品故障較多，又或是出現(xiàn)最多的故障類型等。這就需要將數(shù)據(jù)收集，供以后分析。

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

消息到達(dá)Kafka后，需要將消息進(jìn)行消費(fèi)并儲(chǔ)存。在本系統(tǒng)中，采用Flume消費(fèi)Kafka的消息數(shù)據(jù)并下沉到Hive,對(duì)后期數(shù)據(jù)分析進(jìn)行數(shù)據(jù)支持。數(shù)據(jù)收集服務(wù)架構(gòu)如圖4所示。

圖4 數(shù)據(jù)收集服務(wù)架構(gòu)圖Fig.4 Architecture of data collection service

4 結(jié)論

本智能維護(hù)系統(tǒng)在投入使用以來，實(shí)現(xiàn)設(shè)備故障上報(bào)，設(shè)備管理，工程進(jìn)度管理，資料維護(hù)等多種功能，支持了電務(wù)段人員以及工廠人員的相關(guān)工作的電子信息化，推進(jìn)了相關(guān)工作的進(jìn)展，同時(shí)也對(duì)相關(guān)使用數(shù)據(jù)進(jìn)行有效收集，為后期的數(shù)據(jù)分析和大數(shù)據(jù)賦能提供了數(shù)據(jù)支撐，具有豐富的實(shí)際使用價(jià)值及經(jīng)濟(jì)意義。