賀嘉貝，黃 鋮，王 朵

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

0 引言

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

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

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

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

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

1 總體架構設計

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

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

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

（3）出色彈性。微服務彼此互不影響，一個服務出現(xiàn)故障不會導致整個應用下線。

（4）易于運維。微服務模塊化且小巧，易定位問題。

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

圖1 FORESEE微服務平臺整體架構設計Fig.1 Architectural design of FORESEE microservice platform

1.1 微前端應用層

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

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

1.2 微服務平臺層

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

1.3 技術中間件層

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

1.4 運維支撐層

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

圖2 工程化運維支撐Fig.2 Operation support in engineering development

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

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

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

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

2 微服務集群設計

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

2.1 微服務劃分

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

圖3 微服務劃分Fig.3 Microservice division

基礎微服務為應用微服務提供了通用性技術功能。作為基礎建設部分，其包括注冊中心、網關及認證中心等。

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

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

（2）用于統(tǒng)計信息和實時信息的大數據服務，例如車輛實時信號量。

（3）用于存儲文件的文件數據微服務，例如車輛日檢的離線文件。

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

2.1.1 基礎微服務的API網關

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

網關是微服務集群的入口，本身也是一種特殊的微服務；但作為系統(tǒng)流量的瓶頸，網關的底層設計是實現(xiàn)異步非阻塞的，用于實現(xiàn)后臺程序對外入口的路由轉發(fā)以及安全防線。圖4展示了認證過程中網關微服務、認證中心微服務以及其他微服務之間的協(xié)作關系。

圖4 網關中的認證流程Fig.4 Authentication process in gateway

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

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

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

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

2.1.2 基礎微服務的認證中心

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

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

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

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

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

2.1.3 基礎微服務的注冊中心

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

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

2.1.4 數據微服務的實時數據

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

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

圖5 實時數據微服務Fig.5 Microservice of real-time data

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

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

（2）提供平臺或第三方實時數據Websocket接入和轉發(fā)能力，面向軌道交通實時故障信號、信號量等數據。

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

2.1.5 數據微服務的大數據

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

圖6 大數據微服務Fig.6 Microservice of big data

設計實現(xiàn)包括

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

（2）基于時間、信號量、車輛號及故障碼等關鍵信息查詢；

（3）關鍵信號數據轉化，包括數據格式轉換及數據單位轉換等；

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

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

2.1.6 數據微服務的主數據

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

（1）線網級主數據，包含線路、站點、軌旁、車輛等的基礎數據。

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

（3）客戶主數據，包含用戶數據、權限數據及組織部門數據等。

2.2 面向微服務的SDK類庫

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

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

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

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

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

后者對當前業(yè)務范圍內項目中的邏輯進行抽離，供各微服務依賴使用?；谶@些JAVA類，根據面向對象語言的特性，可進行繼承、方法重載等靈活使用。為了覆蓋大量的常見編碼開發(fā)場景，進行如下設計：

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

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

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

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

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

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

（7）任務調度類。其包含Quartz(定時任務編程框架)定時任務調度服務類和XXL-JOB（輕量級分布式任務調度平臺）。

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

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

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

3 微服務平臺實際應用情況

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

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

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

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

4 結語

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

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