微服務(wù)平臺(tái)設(shè)計(jì)在軌道交通智能運(yùn)維產(chǎn)品中的應(yīng)用

賀嘉貝，黃 鋮，王 朵

（株洲中車時(shí)代電氣股份有限公司，湖南 株洲 412001）

0 引言

“十三五”規(guī)劃實(shí)施以來，我國軌道交通行業(yè)發(fā)展迅猛，隨著該領(lǐng)域數(shù)據(jù)量的不斷增長，運(yùn)維人員數(shù)量缺口越來越大，日常運(yùn)維質(zhì)量保持面臨極大的挑戰(zhàn)[1]。智能運(yùn)維是近幾年來在軌道交通行業(yè)內(nèi)興起的一種新的運(yùn)維模式，其利用傳感裝置獲取車輛運(yùn)行時(shí)各設(shè)備的實(shí)時(shí)狀態(tài)和故障數(shù)據(jù)，并借助大數(shù)據(jù)、云計(jì)算和人工智能等技術(shù)對設(shè)備系統(tǒng)進(jìn)行故障診斷和狀態(tài)管理[2]。

FORESEE是中車株洲電力機(jī)車研究所有限公司研發(fā)的一套軌道交通智能運(yùn)維產(chǎn)品，本文以此為例介紹微服務(wù)平臺(tái)設(shè)計(jì)在軌道交通智能運(yùn)維產(chǎn)品中的應(yīng)用。FORESEE以WEB（網(wǎng)頁）端軟件為主，涉及城軌及干線鐵路領(lǐng)域項(xiàng)目眾多，涵蓋業(yè)務(wù)場景包括遠(yuǎn)程監(jiān)視、健康管理、專家知識(shí)庫、列車履歷、應(yīng)急處置、車載軟件管理、BI（商務(wù)智能）分析、能耗分析、移動(dòng)終端及系統(tǒng)管理等各類型需求；其特點(diǎn)在于業(yè)務(wù)場景多、技術(shù)跨度廣、需求變化快，這就使得系統(tǒng)結(jié)構(gòu)龐大且復(fù)雜，對可維護(hù)性、可擴(kuò)展性要求日益增加。在以往傳統(tǒng)的煙囪式開發(fā)模式下，存在大量重復(fù)建設(shè)和可擴(kuò)展性問題，這無疑給運(yùn)維系統(tǒng)研發(fā)效率和成本帶來了持續(xù)性的挑戰(zhàn)[3]。因此，系統(tǒng)需要優(yōu)化技術(shù)架構(gòu)，提高可擴(kuò)展性，使得項(xiàng)目開發(fā)及時(shí)響應(yīng)外部市場的快速變化；同時(shí)，需要保證在大數(shù)據(jù)場景下運(yùn)維服務(wù)變得更加可靠，而微服務(wù)技術(shù)為此提供了幫助。

早在2010年前，國外互聯(lián)網(wǎng)企業(yè)如Amazon,Uber, Net flix等就已經(jīng)完成了由單體應(yīng)用向微服務(wù)框架的全面轉(zhuǎn)型，從而解決了日益龐大的系統(tǒng)中所存在的上述問題。約2012年之后，國內(nèi)互聯(lián)網(wǎng)企業(yè)（如百度，阿里，騰訊等）逐步開展微服務(wù)化。到2018年，微服務(wù)被寫入了工業(yè)互聯(lián)網(wǎng)平臺(tái)標(biāo)準(zhǔn)化需求[4]，白皮書首次提出了應(yīng)用系統(tǒng)應(yīng)該建立“微服務(wù)框架”的要求。2020年8月，國家標(biāo)準(zhǔn)計(jì)劃20203865-T-469《工業(yè)互聯(lián)網(wǎng)平臺(tái) 微服務(wù)參考框架》[5]正式立項(xiàng)?？梢娪梦⒎?wù)框架思想進(jìn)行大型軟件工程化已經(jīng)成為大勢所趨。

微服務(wù)平臺(tái)設(shè)計(jì)核心是分離解耦，在此基礎(chǔ)上做到共性能力的抽象沉淀和共享復(fù)用[6]，從而解決傳統(tǒng)架構(gòu)下的交叉依賴、重復(fù)建設(shè)等問題，以開放服務(wù)的形式被不同業(yè)務(wù)調(diào)用。

本文闡述的微服務(wù)平臺(tái)設(shè)計(jì)，一方面，通過運(yùn)用目前主流的SpringCloud(開源微服務(wù)編程框架)、Docker(應(yīng)用容器引擎)及中間件技術(shù)等進(jìn)行了基礎(chǔ)架構(gòu)設(shè)計(jì)；另一方面，通過結(jié)合實(shí)際軌道交通業(yè)務(wù)場景，設(shè)計(jì)了一套可復(fù)用的微服務(wù)集群，以此構(gòu)建一個(gè)擴(kuò)展性強(qiáng)、可靠性高的系統(tǒng)層來適配業(yè)務(wù)需求差異。

1 總體架構(gòu)設(shè)計(jì)

微服務(wù)架構(gòu)與面向服務(wù)的架構(gòu)類似，但有別于傳統(tǒng)的單體式方案，其將應(yīng)用拆分成多個(gè)核心功能，每個(gè)功能為獨(dú)立服務(wù)，可單獨(dú)構(gòu)建和部署[7]。微服務(wù)間可相互通信，且遵循無狀態(tài)通信，其優(yōu)勢具體突顯在以下幾點(diǎn)：

（1）敏捷開發(fā)性。開發(fā)周期縮短，有助于實(shí)現(xiàn)敏捷部署和更新。

（2）高度可擴(kuò)展。服務(wù)間耦合度低，可以任意組合，且支持多服務(wù)器分布式部署。

（3）出色彈性。微服務(wù)彼此互不影響，一個(gè)服務(wù)出現(xiàn)故障不會(huì)導(dǎo)致整個(gè)應(yīng)用下線。

（4）易于運(yùn)維。微服務(wù)模塊化且小巧，易定位問題。

本文介紹的FORESEE微服務(wù)平臺(tái)基于分布式架構(gòu)構(gòu)建了一系列微服務(wù)，除了共用的業(yè)務(wù)功能之外，還包括通用技術(shù)能力、服務(wù)運(yùn)維能力和安全可靠能力等，且在眾多業(yè)務(wù)場景中被集成?？傮w而言，微服務(wù)平臺(tái)架構(gòu)包括以下4個(gè)組成部分：微前端應(yīng)用層、微服務(wù)平臺(tái)層、技術(shù)中間件層和運(yùn)維支撐層（圖1）。

圖1 FORESEE微服務(wù)平臺(tái)整體架構(gòu)設(shè)計(jì)Fig.1 Architectural design of FORESEE microservice platform

1.1 微前端應(yīng)用層

如圖1所示，微服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)是前后端分離的，最上層基于Angular（前端編程框架）并遵循Single-SPA（微前端技術(shù)規(guī)范）開發(fā)設(shè)計(jì)了一系列具有獨(dú)立業(yè)務(wù)的UI（用戶界面）子應(yīng)用，其目的是便于和后臺(tái)微服務(wù)一起進(jìn)行靈活組合部署，形成可擴(kuò)展的前端服務(wù)框架和UI組件庫。

微前端應(yīng)用層用來支撐各類軌交業(yè)務(wù)展示需求，如大屏展示、司機(jī)屏顯示、地圖實(shí)時(shí)監(jiān)控車輛狀態(tài)、各類軌交BI分析圖表生成、數(shù)據(jù)回放等。設(shè)計(jì)采用了主從模式，將上述定制化展示需求封裝為子應(yīng)用，由主工程基座應(yīng)用，動(dòng)態(tài)加載和管理若干子應(yīng)用，使其具備高度靈活性。

1.2 微服務(wù)平臺(tái)層

微服務(wù)平臺(tái)層指的是后端數(shù)據(jù)服務(wù)，概念與前端對應(yīng)，基于Spring Cloud微服務(wù)技術(shù)架構(gòu)和Docker容器化部署，形成一系列通用業(yè)務(wù)微服務(wù)集群和一系列具有領(lǐng)域特征的業(yè)務(wù)微服務(wù)集群，以此作為整個(gè)系統(tǒng)的數(shù)據(jù)后臺(tái)。前后端分離設(shè)計(jì)的意義不僅在于工程化上，同時(shí)，本系統(tǒng)的后臺(tái)可以單獨(dú)提供數(shù)據(jù)服務(wù)，借助 API（application programming interface）網(wǎng)關(guān)供第三方系統(tǒng)調(diào)用。其數(shù)據(jù)范圍除了系統(tǒng)和用戶基本信息外，還覆蓋城市軌道交通和干線鐵路軌道交通領(lǐng)域的各類數(shù)據(jù)，如線路、站點(diǎn)、軌旁、車輛、故障、預(yù)警、應(yīng)急事件、故障及信號(hào)量等，宏觀上實(shí)現(xiàn)了各類歷史數(shù)據(jù)的存儲(chǔ)和統(tǒng)計(jì)以及實(shí)時(shí)數(shù)據(jù)的推送，具體設(shè)計(jì)詳見第2節(jié)。

1.3 技術(shù)中間件層

為進(jìn)一步加強(qiáng)基礎(chǔ)技術(shù)的支撐，面向數(shù)據(jù)后臺(tái)設(shè)計(jì)了一套通用技術(shù)中間件庫，以集成業(yè)內(nèi)多類主流中間件，如Nginx（反向代理軟件）、RabbitMQ（消息代理軟件）、Redis（高性能數(shù)據(jù)庫軟件)和ElasticSearch(全文檢索引擎)等，從內(nèi)部提供底層技術(shù)組件支撐，涵蓋數(shù)據(jù)查詢、數(shù)據(jù)推送、性能負(fù)載、任務(wù)管理及應(yīng)用安全等功能。

1.4 運(yùn)維支撐層

如圖2所示，在FORESEE產(chǎn)品架構(gòu)中，本文面向編碼開發(fā)到部署的全生命周期，設(shè)計(jì)了一套工程化運(yùn)維管理模式，以達(dá)到流程化管控和少人化目的?；凇癎errit（代碼倉庫）+Jerkins CI（持續(xù)集成平臺(tái)）+Kubernetes（容器管理平臺(tái)）”的整體架構(gòu)，運(yùn)維支撐層具體設(shè)計(jì)包含以下4個(gè)方面：

圖2 工程化運(yùn)維支撐Fig.2 Operation support in engineering development

（1）源碼管理。為保證源碼的質(zhì)量和安全，由內(nèi)網(wǎng)Gerrit倉庫進(jìn)行統(tǒng)一管理，面向編碼開發(fā)人員，倉庫記錄每一次代碼提交歷史，可回溯和回滾，具備審核流程控制，通過審閱后才能合入項(xiàng)目。

（2）編譯打包管理。為實(shí)現(xiàn)自動(dòng)編譯和打包，代碼合入后，將觸發(fā)Jerkins CI拉取代碼，并執(zhí)行編譯及預(yù)檢查，內(nèi)容包括語法錯(cuò)誤、單元測試等。測試通過后，將編譯后的程序打包成容器化Docker鏡像，推送（push）到Docker倉庫存儲(chǔ)。在此過程中，將完成一次測試環(huán)境的系統(tǒng)集成部署，以代替人工操作，減少人力。

（3）軟件包管理。為了集中管理軟件包并實(shí)現(xiàn)版本控制，編譯后的每個(gè)微服務(wù)，通過Docker容器化技術(shù)進(jìn)行鏡像封裝，并通過內(nèi)網(wǎng)的中央鏡像倉庫進(jìn)行集中式存儲(chǔ)。所有軟件包都是高度封裝的Docker鏡像，以確保運(yùn)行隔離性和源碼安全[8]。軟件版本管理人員通過標(biāo)識(shí)標(biāo)簽（tag）描述其版本信息。

（4）部署運(yùn)維管理。為達(dá)到部署后系統(tǒng)的高效持續(xù)運(yùn)維，通過Kubernetes技術(shù)，運(yùn)維人員可基于圖形化頁面或命令行實(shí)現(xiàn)遠(yuǎn)程運(yùn)維監(jiān)控，提供系統(tǒng)日志收集、存儲(chǔ)、分析以及系統(tǒng)實(shí)時(shí)狀態(tài)監(jiān)測、升級(jí)部署、更新/回滾、自動(dòng)重啟、自動(dòng)伸縮/擴(kuò)展等。這樣的技術(shù)設(shè)計(jì)，替代了傳統(tǒng)運(yùn)維中面向底層的Linux服務(wù)器和文件系統(tǒng)，取代大量使用命令行進(jìn)行人工操作的場景，降低了時(shí)間成本和技術(shù)門檻。

2 微服務(wù)集群設(shè)計(jì)

在實(shí)現(xiàn)平臺(tái)復(fù)用性上，本節(jié)介紹了通過微服務(wù)劃分建立的一系列通用型微服務(wù)及框架中的SDK（軟件開發(fā)工具包）。

2.1 微服務(wù)劃分

業(yè)內(nèi)主流的后端微服務(wù)框架有SpringCloud及Dubbon（阿里巴巴的國產(chǎn)微服務(wù)編程框架）兩種。本方案選用了SpringCloud，因其具有更加開放、良好的發(fā)展生態(tài)。其設(shè)計(jì)思路是對后臺(tái)數(shù)據(jù)服務(wù)進(jìn)行拆分，抽離其通用能力。根據(jù)職責(zé)的不同，微服務(wù)被劃分為基礎(chǔ)微服務(wù)、數(shù)據(jù)微服務(wù)和業(yè)務(wù)微服務(wù)3類，后兩類被統(tǒng)稱為應(yīng)用微服務(wù)（圖3）。由于業(yè)務(wù)微服務(wù)是面向特定開發(fā)項(xiàng)目的特定業(yè)務(wù)表現(xiàn)形式，而本文聚焦于平臺(tái)設(shè)計(jì)本身，故不會(huì)對此展開介紹。

圖3 微服務(wù)劃分Fig.3 Microservice division

基礎(chǔ)微服務(wù)為應(yīng)用微服務(wù)提供了通用性技術(shù)功能。作為基礎(chǔ)建設(shè)部分，其包括注冊中心、網(wǎng)關(guān)及認(rèn)證中心等。

應(yīng)用微服務(wù)區(qū)分了業(yè)務(wù)微服務(wù)和數(shù)據(jù)微服務(wù)兩類，并存在前者依賴于后者的關(guān)系。例如，司機(jī)屏和機(jī)車健康評(píng)估這些項(xiàng)目中的具體業(yè)務(wù)板塊都依賴于底層數(shù)據(jù)接口，這些接口以Http（超文本傳輸）或WebSocket(全雙工通信)協(xié)議形式被封裝在數(shù)據(jù)微服務(wù)集群中，集群包括

（1）用于提供各類靜態(tài)配置數(shù)據(jù)的主數(shù)據(jù)微服務(wù)，例如線網(wǎng)級(jí)基礎(chǔ)碼表。

（2）用于統(tǒng)計(jì)信息和實(shí)時(shí)信息的大數(shù)據(jù)服務(wù)，例如車輛實(shí)時(shí)信號(hào)量。

（3）用于存儲(chǔ)文件的文件數(shù)據(jù)微服務(wù)，例如車輛日檢的離線文件。

微服務(wù)架構(gòu)下平臺(tái)具備很強(qiáng)的擴(kuò)展性，可根據(jù)不同項(xiàng)目的特殊需求來定制增加新的內(nèi)容，可能是一個(gè)，也可能是多個(gè)。新的部分仍然以微服務(wù)形式加入，保證了服務(wù)之間的隔離和解耦[9]。因此，在此分布式架構(gòu)下，只要地鐵公司或機(jī)務(wù)段內(nèi)的硬件條件允許，便可提供高效、高性能的微服務(wù)擴(kuò)展以及負(fù)載均衡，在多節(jié)點(diǎn)/單節(jié)點(diǎn)多種方式下靈活運(yùn)行。下面對基礎(chǔ)微服務(wù)和數(shù)據(jù)微服務(wù)中的關(guān)鍵設(shè)計(jì)進(jìn)行詳細(xì)介紹。

2.1.1 基礎(chǔ)微服務(wù)的API網(wǎng)關(guān)

各機(jī)務(wù)段和地鐵公司對WEB應(yīng)用安全存在基本要求，即GB/T 22239-2019《信息安全技術(shù) 網(wǎng)絡(luò)安全等級(jí)保護(hù)基本要求》[10]規(guī)范，以達(dá)到防范各類外部攻擊的能力。本架構(gòu)下主要以網(wǎng)關(guān)微服務(wù)配合Nginx反向代理進(jìn)行防治。

網(wǎng)關(guān)是微服務(wù)集群的入口，本身也是一種特殊的微服務(wù)；但作為系統(tǒng)流量的瓶頸，網(wǎng)關(guān)的底層設(shè)計(jì)是實(shí)現(xiàn)異步非阻塞的，用于實(shí)現(xiàn)后臺(tái)程序?qū)ν馊肟诘穆酚赊D(zhuǎn)發(fā)以及安全防線。圖4展示了認(rèn)證過程中網(wǎng)關(guān)微服務(wù)、認(rèn)證中心微服務(wù)以及其他微服務(wù)之間的協(xié)作關(guān)系。

圖4 網(wǎng)關(guān)中的認(rèn)證流程Fig.4 Authentication process in gateway

網(wǎng)關(guān)跨一個(gè)或多個(gè)內(nèi)部API提供統(tǒng)一、規(guī)范的多種API入口點(diǎn)，并抽離大多數(shù)通信層邏輯，其目的是降低內(nèi)部微服務(wù)自身的復(fù)雜性。以下功能被設(shè)計(jì)用以支撐內(nèi)部集群的使用：

（1）路由功能。其將外部公共接口與內(nèi)部微服務(wù)接口分開，支持Http和Websocket多協(xié)議代理轉(zhuǎn)發(fā)規(guī)則，允許添加微服務(wù)和更改邊界；為所有微服務(wù)提供單一入口點(diǎn)，對客戶端隱藏服務(wù)發(fā)現(xiàn)和版本控制詳細(xì)信息；實(shí)現(xiàn)前后端分離架構(gòu)下的前端獲取數(shù)據(jù)標(biāo)準(zhǔn)入口，同時(shí)亦支持對外單獨(dú)提供第三方API的服務(wù)。

（2）額外的安全層。其提供統(tǒng)一的JWT（JSON web token）鑒權(quán)認(rèn)證攔截。此外，API網(wǎng)關(guān)通過提供一個(gè)額外的保護(hù)層來防止惡意攻擊，包括SQL（結(jié)構(gòu)化查詢語言）注入、DoS（拒絕服務(wù)）攻擊、CSRF（跨站請求偽造）攻擊及XSS（跨站腳本）攻擊。

（3）負(fù)載均衡功能。其對接口請求進(jìn)行負(fù)載均衡，包括7種類型策略，即隨機(jī)、輪詢、重試、最低并發(fā)、可用過濾、響應(yīng)時(shí)間加權(quán)和區(qū)域權(quán)衡。

2.1.2 基礎(chǔ)微服務(wù)的認(rèn)證中心

根據(jù)各機(jī)務(wù)段和地鐵公司對權(quán)限管控的需求，針對不同種類用戶（如指揮調(diào)度，檢修作業(yè)人員等）設(shè)置不同的操作權(quán)限，根據(jù)角色決定具體資源是否可見。

因此，在鑒權(quán)方面，通過認(rèn)證中心服務(wù)管理進(jìn)行集群內(nèi)所有服務(wù)的各類鑒權(quán)操作，采用用戶-角色-權(quán)限3層設(shè)計(jì)邏輯，即RBAC(role-based access control）。底層權(quán)限又設(shè)計(jì)了兩類，包括前端資源（模塊、路由、頁面、按鈕）和后端資源（API及其參數(shù)約束）。這使得無論是頁面訪問還是接口數(shù)據(jù)訪問，都是根據(jù)不同角色、不同用戶進(jìn)行制約的。

在底層認(rèn)證實(shí)現(xiàn)上，考慮到分布式架構(gòu)特點(diǎn)，選用了Token（令牌）模式認(rèn)證，而非傳統(tǒng)Session（會(huì)話）模式；基于“Oauth2（授權(quán)開放標(biāo)準(zhǔn)） + JWT +SpringSecurity（安全管理編程框架）”進(jìn)行底層認(rèn)證管理，具備4類認(rèn)證模式，即授權(quán)碼模式、簡化模式、密碼模式和客戶端模式。此外，設(shè)計(jì)時(shí)對認(rèn)證相關(guān)的元數(shù)據(jù)進(jìn)行了Bcrypt（不可逆的加密算法）加密，以保證持久層的安全。

如圖4所示，認(rèn)證中心具備對操作用戶的全局認(rèn)證和令牌發(fā)放功能，并支持供第三方的認(rèn)證登錄API以接入系統(tǒng)。通過這種認(rèn)證中心的抽離解耦，可以靈活接入業(yè)主的人力資源（human resource, HR）原始數(shù)據(jù)，以面向不同組織架構(gòu)的機(jī)務(wù)段和地鐵公司需求。

除了前文提到的鑒權(quán)和認(rèn)證基本功能之外，認(rèn)證中心還設(shè)計(jì)了用戶行為日志的功能。對于用戶的頁面操作，通過前端埋點(diǎn)和后端微服務(wù)埋點(diǎn)兩種方式向認(rèn)證中心服務(wù)進(jìn)行數(shù)據(jù)傳遞，并記錄到日志表中。其信息包含源IP、用戶名、功能板塊、事件類型、操作內(nèi)容、操作事件及操作結(jié)果，為后期的分析統(tǒng)計(jì)及記錄追溯提供基礎(chǔ)。

2.1.3 基礎(chǔ)微服務(wù)的注冊中心

注冊中心主要用于微服務(wù)集群管理，管理平臺(tái)內(nèi)各微服務(wù)的注冊上線和離線。目前業(yè)內(nèi)主流技術(shù)是ZooKeeper（Apache分布式協(xié)調(diào)工具）或Eureka（Netflix服務(wù)發(fā)現(xiàn)框架）。在分布式架構(gòu)的CAP（consistency，availability，partition tolerance）理論下，ZooKeeper偏向于CP（consistency，availability），Eureka定位則是為了保證服務(wù)高可用,用來保證AP（availability，partition tolerance）。本文選用了Eureka，因?yàn)樽鳛閱渭兊姆?wù)注冊中心，Eureka更加專一，注冊服務(wù)更重要的是可用性，可以接受短期內(nèi)達(dá)不到一致性的狀況。

本設(shè)計(jì)基于Eureka的服務(wù)發(fā)現(xiàn)、服務(wù)注冊和服務(wù)監(jiān)視能力，通過Spring Actuator（服務(wù)健康審計(jì)工具）接口，對集群中所有微服務(wù)進(jìn)行數(shù)據(jù)交互和通信；并將數(shù)據(jù)發(fā)送至注冊中心，實(shí)現(xiàn)實(shí)時(shí)監(jiān)控及輔助運(yùn)維，使得注冊中心服務(wù)具備面向微服務(wù)的觀察工具平臺(tái)以及可視化UI界面。注冊中心功能包括微服務(wù)列表、微服務(wù)啟停日志、環(huán)境參數(shù)查看、性能監(jiān)控、微服務(wù)運(yùn)行日志、Http請求跟蹤及JVM（Java虛擬機(jī)）監(jiān)視等。

2.1.4 數(shù)據(jù)微服務(wù)的實(shí)時(shí)數(shù)據(jù)

按照目前城市軌道交通和機(jī)車的智能運(yùn)維系統(tǒng)具體業(yè)務(wù)功能劃分，其主要實(shí)現(xiàn)與故障、應(yīng)急事件及狀態(tài)預(yù)警等相關(guān)的常用業(yè)務(wù)的實(shí)時(shí)數(shù)據(jù)服務(wù)。故設(shè)計(jì)了一種統(tǒng)一提供實(shí)時(shí)數(shù)據(jù)的微服務(wù)，其底層數(shù)據(jù)均由此服務(wù)提供，而依賴的具體微服務(wù)只需實(shí)現(xiàn)具體業(yè)務(wù)功能即可，如故障業(yè)務(wù)中故障新增、故障消除、故障過濾、原生及次生故障分類等相關(guān)業(yè)務(wù)。

根據(jù)業(yè)務(wù)實(shí)現(xiàn)模塊化開發(fā)，基于配置實(shí)現(xiàn)業(yè)務(wù)模塊彈性部署。采用業(yè)務(wù)實(shí)現(xiàn)接口模式開發(fā)、定義標(biāo)準(zhǔn)接口參數(shù)，保證前端業(yè)務(wù)方法調(diào)用統(tǒng)一。實(shí)時(shí)數(shù)據(jù)微服務(wù)設(shè)計(jì)如圖5所示。

圖5 實(shí)時(shí)數(shù)據(jù)微服務(wù)Fig.5 Microservice of real-time data

通過建立實(shí)時(shí)消息服務(wù)中心，對接外部第三方平臺(tái)的數(shù)據(jù)，支持消息隊(duì)列，實(shí)時(shí)數(shù)據(jù)及REST（表述性狀態(tài)轉(zhuǎn)移原則）數(shù)據(jù)，提供統(tǒng)一標(biāo)準(zhǔn)的實(shí)時(shí)接口和REST接口，保障提供到后端和前端應(yīng)用數(shù)據(jù)結(jié)構(gòu)一致。這樣設(shè)計(jì)的好處是，如有定制內(nèi)容，只需變更消息封裝模塊即可實(shí)現(xiàn)中臺(tái)處理和外部數(shù)據(jù)的解耦。其具體實(shí)現(xiàn)包括

（1）提供第三方應(yīng)用或第三方消息隊(duì)列數(shù)據(jù)接入和緩存能力，消息數(shù)據(jù)可作為計(jì)算引擎或微服務(wù)的數(shù)據(jù)源，用來面向異步的數(shù)據(jù)（如下發(fā)的軌道交通檢修計(jì)劃）。

（2）提供平臺(tái)或第三方實(shí)時(shí)數(shù)據(jù)Websocket接入和轉(zhuǎn)發(fā)能力，面向軌道交通實(shí)時(shí)故障信號(hào)、信號(hào)量等數(shù)據(jù)。

（3）提供第三方RESTAPI數(shù)據(jù)接入和緩存能力，主要面向歷史數(shù)據(jù)查詢。

2.1.5 數(shù)據(jù)微服務(wù)的大數(shù)據(jù)

大數(shù)據(jù)微服務(wù)面向的數(shù)據(jù)來源是大數(shù)據(jù)平臺(tái)的場景，其可實(shí)現(xiàn)數(shù)據(jù)轉(zhuǎn)化、數(shù)據(jù)過濾及應(yīng)用封裝，并提供統(tǒng)一的大數(shù)據(jù)接口供其他業(yè)務(wù)微服務(wù)使用，包括大數(shù)據(jù)相關(guān)的數(shù)據(jù)查詢、數(shù)據(jù)轉(zhuǎn)化、數(shù)據(jù)過濾及數(shù)據(jù)封裝，如圖6所示。

圖6 大數(shù)據(jù)微服務(wù)Fig.6 Microservice of big data

設(shè)計(jì)實(shí)現(xiàn)包括

（1）支持HBASE(分布式數(shù)據(jù)庫)、KUDU（新型列式存儲(chǔ)系統(tǒng)）等大數(shù)據(jù)存儲(chǔ)系統(tǒng)；

（2）基于時(shí)間、信號(hào)量、車輛號(hào)及故障碼等關(guān)鍵信息查詢；

（3）關(guān)鍵信號(hào)數(shù)據(jù)轉(zhuǎn)化，包括數(shù)據(jù)格式轉(zhuǎn)換及數(shù)據(jù)單位轉(zhuǎn)換等；

（4）實(shí)現(xiàn)數(shù)據(jù)過濾，包括時(shí)間數(shù)據(jù)、信號(hào)量大小、故障碼及自定義規(guī)則等；

（5）實(shí)現(xiàn)數(shù)據(jù)按具體格式封裝，包括JSON,XML等數(shù)據(jù)格式。

2.1.6 數(shù)據(jù)微服務(wù)的主數(shù)據(jù)

面向靜態(tài)的基礎(chǔ)數(shù)據(jù)，形成通用化主數(shù)據(jù)管理服務(wù)，提供統(tǒng)一對外的服務(wù)接口；主數(shù)據(jù)服務(wù)設(shè)計(jì)范圍包括車輛及相關(guān)設(shè)備的基礎(chǔ)數(shù)據(jù)。提供平臺(tái)級(jí)的基礎(chǔ)服務(wù)集成服務(wù)，對線網(wǎng)級(jí)、單車級(jí)的基礎(chǔ)數(shù)據(jù)進(jìn)行數(shù)據(jù)集成，提供統(tǒng)一的對外主數(shù)據(jù)服務(wù)接口。內(nèi)容如下：

（1）線網(wǎng)級(jí)主數(shù)據(jù)，包含線路、站點(diǎn)、軌旁、車輛等的基礎(chǔ)數(shù)據(jù)。

（2）單車級(jí)主數(shù)據(jù)，包含基礎(chǔ)故障碼表數(shù)據(jù)、預(yù)警碼表數(shù)據(jù)、應(yīng)急事件碼表、自定義故障規(guī)則數(shù)據(jù)及版本數(shù)據(jù)等。

（3）客戶主數(shù)據(jù)，包含用戶數(shù)據(jù)、權(quán)限數(shù)據(jù)及組織部門數(shù)據(jù)等。

2.2 面向微服務(wù)的SDK類庫

雖然利用通用型微服務(wù)的可復(fù)用特征，新項(xiàng)目設(shè)計(jì)時(shí)可以直接復(fù)用上述基礎(chǔ)服務(wù)和部分?jǐn)?shù)據(jù)服務(wù)，減少了大量的重復(fù)開發(fā)工作，提高了開發(fā)效率，但目前仍面臨著其他方面挑戰(zhàn)。例如，在協(xié)作開發(fā)過程中，易出現(xiàn)組件兼容性問題以及因開發(fā)人員技術(shù)水平的差異性而導(dǎo)致的難以統(tǒng)一把控問題。為進(jìn)一步提高開發(fā)效率，使開發(fā)趨于規(guī)范化，從編碼開發(fā)角度入手，采用模板工程和依賴類庫軟件開發(fā)工具包（software development kit，SDK）的模式，面向開發(fā)人員提供充分的二次開發(fā)支持。如圖7所示，開發(fā)人員將按照模板工程，引入SDK中大量JAVA類，將更多精力聚焦于純粹的業(yè)務(wù)開發(fā)內(nèi)容。

圖7 模板工程和SDK類庫Fig.7 Project template & SDK class library

面向JAVA語言，其代碼模板工程和依賴類庫（CRRC-SDK）以源碼形式供二次開發(fā)使用，存放于Girret代碼倉庫，具備版本管理。根據(jù)實(shí)際業(yè)務(wù)場景和量產(chǎn)需求，以支撐具體應(yīng)用場景的規(guī)范化和快速復(fù)用，代碼模板包含項(xiàng)目通用目錄結(jié)構(gòu)以及各類配套腳本及配置文件支持，作為項(xiàng)目開發(fā)的標(biāo)準(zhǔn)參照范例。

依賴類庫主要包含2個(gè)方面，一是統(tǒng)一化的依賴管理、編譯及打包腳本；二是公用類庫。

前者基于Gradle（項(xiàng)目自動(dòng)化構(gòu)建工具）包管理技術(shù)，利用Groovy（敏捷開發(fā)語言）進(jìn)行定制化腳本開發(fā)，形成一套兼容各類型項(xiàng)目的統(tǒng)一依賴管理、統(tǒng)一自動(dòng)化編譯流程、統(tǒng)一Docker打包的自動(dòng)化編譯打包程序，將底層依賴管理和編譯過程封裝在底層，開發(fā)人員是無感知的。

后者對當(dāng)前業(yè)務(wù)范圍內(nèi)項(xiàng)目中的邏輯進(jìn)行抽離，供各微服務(wù)依賴使用。基于這些JAVA類，根據(jù)面向?qū)ο笳Z言的特性，可進(jìn)行繼承、方法重載等靈活使用。為了覆蓋大量的常見編碼開發(fā)場景，進(jìn)行如下設(shè)計(jì)：

（1）統(tǒng)一異常處理類。封裝JAVA異常對象，面向接口層的監(jiān)聽捕獲器，統(tǒng)一常見的業(yè)務(wù)異常以及前后端通信異常、數(shù)據(jù)異常和認(rèn)證異常等。此類會(huì)捕獲所有常見的程序異常，開發(fā)人員無須編寫異常捕獲的邏輯。

（2）國際化支持類。對于后端數(shù)據(jù)返回的文本，進(jìn)行國際化翻譯。此類生效范圍是全局的，面向所有JSON返回值。開發(fā)人員面向一個(gè)JSON配置文件，無須關(guān)注其中邏輯。

（3）Websocket數(shù)據(jù)通信類。其為基于Netty（異步非阻塞網(wǎng)絡(luò)編程框架）的全雙工長連接Websocket協(xié)議通信工具類。此類通過JAVA注解實(shí)現(xiàn)功能。開發(fā)人員在編寫時(shí)加上此注解，重載相關(guān)函數(shù)，即可實(shí)現(xiàn)Websocket推送服務(wù)。

（4）數(shù)據(jù)庫類。其為基于JPA（JAVA持久層API）的再封裝。對于常見的查詢排序邏輯，其進(jìn)行接口和Java泛型的封裝；對于常見的增刪改查邏輯，開發(fā)人員可以全部無須編寫，這樣減少了低端重復(fù)勞動(dòng)。

（5）工具類。其包含時(shí)間操作、進(jìn)制計(jì)算、字符串操作及JSON解析等常見業(yè)務(wù)常見的工具類，便于開發(fā)人員在日常開發(fā)中直接調(diào)用。

（6）安全類。其包含SQL注入攔截器、XSS攔截器、CSRF攔截器、鑒權(quán)攔截器、認(rèn)證攔截器、Spirng Security及Oauth2安全配置類、JWT解析器、AES（advanced encryption standard）加密器、RSA(非對稱加密)加密器以及Jasypt(Java simplified encryption)加密器。以上功能在使用SDK包時(shí)將自動(dòng)注入程序中，為安全性提供支持。

（7）任務(wù)調(diào)度類。其包含Quartz(定時(shí)任務(wù)編程框架)定時(shí)任務(wù)調(diào)度服務(wù)類和XXL-JOB（輕量級(jí)分布式任務(wù)調(diào)度平臺(tái)）。

（8）FTP 類（ file transfer protocol）。其包含配置類以及服務(wù)類（上傳、下載等）。

（9）REST接口類。其對JSON請求體以及返回體進(jìn)行了封裝，包含REST接口收發(fā)器以及字段加密注解。此部分設(shè)計(jì)的主要目的是在前后端分離場景下對數(shù)據(jù)結(jié)構(gòu)進(jìn)行規(guī)范化。

（10）Excel（電子報(bào)表）解析類。為基于POI（微軟文檔解析技術(shù)）封裝的一系列Excel解析工具類。對于文檔解析邏輯，其可直接調(diào)用相關(guān)函數(shù)，開發(fā)人員無須學(xué)習(xí)POI技術(shù)，降低了開發(fā)門檻。

3 微服務(wù)平臺(tái)實(shí)際應(yīng)用情況

中車FORESEE智能運(yùn)維微服務(wù)系列產(chǎn)品自2018年開始推廣到實(shí)際市場項(xiàng)目開發(fā)中，到目前為止，已經(jīng)被廣泛應(yīng)用在城市軌道交通和干線鐵路交通領(lǐng)域，囊括老項(xiàng)目改造和新開項(xiàng)目，涉及廣州地鐵2號(hào)線、寧波地鐵3號(hào)線、上海地鐵13號(hào)線及深圳地鐵11號(hào)線等23個(gè)城市軌道交通領(lǐng)域智能運(yùn)維項(xiàng)目，以及南寧機(jī)務(wù)段大數(shù)據(jù)系統(tǒng)、朔黃機(jī)務(wù)大數(shù)據(jù)智能運(yùn)維系統(tǒng)以及神朔大數(shù)據(jù)專家診斷系統(tǒng)等8個(gè)干線鐵路交通領(lǐng)域智能運(yùn)維項(xiàng)目，實(shí)現(xiàn)了基礎(chǔ)技術(shù)架構(gòu)100%復(fù)用，功能組件70%以上復(fù)用。通過微服務(wù)的高可用、高可靠、可擴(kuò)展及可持續(xù)演進(jìn)的特點(diǎn)，能快速響應(yīng)業(yè)主進(jìn)行持續(xù)業(yè)務(wù)擴(kuò)展的需求，并在實(shí)際應(yīng)用中集成了第三方的服務(wù)。

相較于以前的開發(fā)模式，得益于模塊復(fù)用，F(xiàn)ORESEE產(chǎn)品的數(shù)據(jù)后臺(tái)設(shè)計(jì)周期和前端設(shè)計(jì)周期大大縮短。以城市軌道交通系列產(chǎn)品編號(hào)開發(fā)為例，較2018年早期項(xiàng)目開發(fā)，2020年度單項(xiàng)目的平均開發(fā)人員數(shù)量投入削減了70%。在人員總數(shù)沒有增加的情況下，由最初的每年二十余人承接3～4個(gè)城軌項(xiàng)目并行開發(fā)，到如今每年十幾人支撐8～9個(gè)城軌項(xiàng)目并行開發(fā)。除此外，基礎(chǔ)技術(shù)的復(fù)用和封裝設(shè)計(jì)使得產(chǎn)品的質(zhì)量大大提升；在安全方面，使用微服務(wù)平臺(tái)構(gòu)建的所有項(xiàng)目已達(dá)到GB/T 22239-2019《信息安全技術(shù) 網(wǎng)絡(luò)安全等級(jí)保護(hù)基本要求》標(biāo)準(zhǔn)要求。

另一方面，從產(chǎn)品的部署調(diào)試運(yùn)維角度而言，使用“Docker+Kubernetes”容器化技術(shù)之后，現(xiàn)場部署和數(shù)據(jù)調(diào)試的時(shí)間大大縮短，以FORESEE上海地鐵13號(hào)線智能運(yùn)維項(xiàng)目為例，相較于2018年的老版本，如今進(jìn)行現(xiàn)場部署和數(shù)據(jù)調(diào)試的時(shí)間由1個(gè)多月縮短至1～2周左右；針對允許互聯(lián)網(wǎng)接入的業(yè)主，通過純粹的遠(yuǎn)程操作，現(xiàn)場部署和數(shù)據(jù)調(diào)試時(shí)間往往能控制在1周以內(nèi)，并可省去所有的差旅費(fèi)用。采用微服務(wù)平臺(tái)前后智能運(yùn)維產(chǎn)品的成本與效率對比如表1所示。

表 1 FORESEE產(chǎn)品中煙囪式工程與微服務(wù)工程的成本與效率對比Tab. 1 Cost and ef ficiency comparison between stovepiped engineering and microservice engineering in FORESEE products

4 結(jié)語

基于軌道交通智能運(yùn)維領(lǐng)域開發(fā)實(shí)際情況，針對目前所面臨的項(xiàng)目數(shù)量激增、開發(fā)周期短、定制化多及人手短缺等諸多挑戰(zhàn)，本文設(shè)計(jì)了一種微服務(wù)平臺(tái)，解決了傳統(tǒng)模式下煙囪式開發(fā)可擴(kuò)展性差、重復(fù)工作多以及高昂的運(yùn)維成本等問題。在該微服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)下，平臺(tái)本身即具備可靠運(yùn)維、符合等保規(guī)范、組裝式開發(fā)、集群可擴(kuò)展復(fù)制及快速發(fā)布等特點(diǎn)。這使得實(shí)際二次開發(fā)的時(shí)候，開發(fā)人員僅需聚焦于那些給不同種類軌道交通用戶定制的業(yè)務(wù)邏輯，而無須在基礎(chǔ)建設(shè)上花費(fèi)大量時(shí)間，從而大幅降低開發(fā)門檻和成本。

本設(shè)計(jì)基于分布式場景，故在有限的硬件資源下，存在一些性能上的限制，如何通過信息化技術(shù)提升后臺(tái)數(shù)據(jù)處理性能，是今后的研究方向。