基于微服務的交通信息化框架構建

秦小明，陳景誠

（1.江西省公路投資有限公司，江西 南昌 330000；2.江西路通科技有限公司，江西 南昌 330002）

0 引言

隨著我國交通建設事業(yè)的快速推進，交通發(fā)展面臨新的機遇和挑戰(zhàn)，為此，必須在推進路網(wǎng)基礎設施建設的過程中，引入科學高效的管理技術，提升交通基礎設施資源分配及利用效率。交通信息化系統(tǒng)是“互聯(lián)網(wǎng)+交通”的具體體現(xiàn)，是充分利用互聯(lián)網(wǎng)、物聯(lián)網(wǎng)、自動化控制技術所構建的人、車、路、環(huán)境等核心要素信息化、智能化運行的交通信息管理系統(tǒng)，可實現(xiàn)交通運行數(shù)據(jù)信息的高效整合和路網(wǎng)統(tǒng)籌管理，增強路網(wǎng)節(jié)點之間通行信息流轉，實現(xiàn)路網(wǎng)負載均衡，提升路網(wǎng)通行能力，并向人們提供多層次、多渠道、多維度的交通決策支持，提升交通運行效率。

1 交通信息化發(fā)展存在的問題

當前交通信息傳統(tǒng)單體式架構主要存在以下突出問題：

（1）復雜程度高。隨著數(shù)據(jù)及業(yè)務規(guī)模的持續(xù)增大，外部依賴增多，多模塊間耦合性增強，代碼結構也愈加復雜，在團隊合作過程中因代碼理解難度增加，使得代碼復用率降低，甚至引發(fā)外部依賴版本沖突。此外，因傳統(tǒng)單體式架構下代碼互相依賴，某個模塊代碼修改或重構后，其影像范圍很難明確界定，從而使代碼修改及重構的復雜程度增大；任何一個小的改動都需要重新進行應用的構建和部署，溝通成本高，開發(fā)效率低。

（2）交付效率低。傳統(tǒng)單體式架構下，當代碼量較為龐大時會延長編譯時間和重新編譯難度，增大定位故障，降低開發(fā)效率；代碼合并過程中還會面臨代碼沖突以及較大的代碼邏輯關系理解難度。

（3）可擴展性差。交通信息單體結構只能橫向擴展，無法分模塊垂直擴展，也不能獨立進行I/O和CPU密集型模塊的升級與擴容。此外，因不同業(yè)務模塊集成為一體，進行功能擴展時必須停止或重新部署整個項目。全部模塊均耦合式部署于一個實例中，容錯率低，即使是某個非核心模塊故障就能引起整個應用系統(tǒng)崩潰。

（4）不利于技術創(chuàng)新。在技術棧的約束下，必須使用同一種框架和語言，傳統(tǒng)單體式架構必然面臨較大的重構成本和風險，故不利于框架及語言的重構和創(chuàng)新。

2 基于微服務的交通信息化

2.1 微服務架構概述

微服務架構屬于互聯(lián)網(wǎng)應用服務型軟件架構，該架構主要在面向服務架構SOA的基礎上發(fā)展而來，康威定律中有關組織結構和其設計系統(tǒng)結構關系的描述是微服務架構的核心理論基礎[1]。Martin Fowler與James Lewis在2014年率先提出微服務的概念，微服務作為一種能夠獨立部署、伸縮及測試的小型應用程序，職責較為單一，這種小型應用程序主要根據(jù)業(yè)務功能予以劃分，并通過自動化部署機制獨立部署運行，微服務之間則通過輕量級通信機制實現(xiàn)通信。微服務體系主要將單個應用程序拆分成小型服務，各服務均在HTTP資源API的輕量級通信機制下按照所屬進程運行，此類服務均圍繞業(yè)務功能構建，且通過自動化機制獨立部署，對服務進行集中化管理。

2.2 微服務與交通信息系統(tǒng)的融合

從邏輯上來看，交通信息系統(tǒng)主要由信息采集、處理及發(fā)布等模塊組成，交通信息化微服務架構中，不同類型交通信息所對應的微服務功能劃分不盡相同。針對信息垂直發(fā)布的情形，交通信息無需處理，能直接發(fā)布，信息采集微服務則由信息發(fā)布相關微服務直接調取。交通信息微服務框架中，不同功能模塊拆分成不同微服務，在接口定義完成的基礎上，微服務間接口可互相調用。所構建起的交通信息系統(tǒng)微服務架構具體見圖1，交通信息系統(tǒng)的主要目的在于為交通參與方提供交通信息服務，交通參與方可以通過移動客戶端、瀏覽器端等多種渠道獲取相關信息。雖然不同的信息獲取渠道數(shù)據(jù)展示形式不同，但都對應著同樣信息或信息組合，故后端只需提供統(tǒng)一數(shù)據(jù)格式及內容，數(shù)據(jù)視圖則通過客戶端形成并展示。

圖1 交通信息系統(tǒng)微服務架構

RESTful Web Services具有跨平臺、跨Internet接口調用等功能，并能有效利用HTTP協(xié)議，交通信息系統(tǒng)微服務架構前后端數(shù)據(jù)交換通過RESTful API進行，數(shù)據(jù)傳遞主要采用具備自解釋性的json格式，能有效避免前后端數(shù)據(jù)耦合[2]?？紤]到微服務數(shù)量較多，必須引入一套治理框架以實現(xiàn)微服務統(tǒng)一管理。當前應用較為普遍的是Spring Cloud微服務治理框架，該框架主要借助Spring Boot開發(fā)的便捷性使分布式系統(tǒng)基礎設施開發(fā)過程大幅簡化，通過Spring Boot開發(fā)風格實現(xiàn)了服務注冊、消息總線、配置中心、數(shù)據(jù)監(jiān)控、負載均衡等的一鍵式啟動與部署。此外，Spring Boot還將當前成熟的服務框架有機組合后，通過再封裝將復雜配置及實現(xiàn)原理予以屏蔽，向開發(fā)者呈現(xiàn)出一套部署、維護均較為簡便的分布式系統(tǒng)開發(fā)工具包。

微服務啟動后向Eureka注冊中心注冊，系統(tǒng)維護人員可同時通過Eureka Server進行微服務運行過程監(jiān)控；考慮到微服務部署并不使用固定IP，Spring Cloud的API GATEWAY等模塊通過Eureka Server發(fā)現(xiàn)其他微服務系統(tǒng)后可執(zhí)行相應邏輯。為實現(xiàn)負載均衡及動態(tài)部署，可通過注冊中心隱藏IP，使其余微服務主要通過固定名字調取相應的微服務，當其所承受壓力過大，還可同時啟動一個相同實例，注冊后達到橫向動態(tài)擴容的目的。

交通信息化微服務框架主要通過信息發(fā)布模塊面向用戶提供服務，其余模塊則用于微服務架構內部調用，故可通過統(tǒng)一網(wǎng)關API GATEWAY實現(xiàn)權限管理。微服務采用RESTful通信模式，其所采用的JSON WEB TOKEN引入方式會使請求均附帶權限信息，JSON WEB TOKEN為信息安全傳遞的表述性規(guī)范，其鑒權流程具體見圖2，從客戶端提交用戶名和密碼后，服務端調用權限予以驗證，并將所取得的用戶角色信息加載至JWT負載，服務端對JWT解析后驗鑒，通過后即可調用微服務權限。

圖2 JSON WEB TOKEN鑒權流程

2.3 微服務業(yè)務模塊

隨著我國交通運行規(guī)模的不斷擴大，各類交通信息設備廣泛應用，各類視頻、圖像、語音等高存儲密度數(shù)據(jù)不斷生成，交通運行數(shù)據(jù)不斷呈現(xiàn)出大數(shù)據(jù)屬性，交通信息系統(tǒng)也越來越多地面臨大數(shù)據(jù)承載問題。面對巨大的數(shù)據(jù)量，考慮到單臺機器存儲能力有限，I/O口性能也無法滿足數(shù)據(jù)集持續(xù)增長的需要，故大數(shù)據(jù)很難通過傳統(tǒng)技術存儲、管理、分析、使用。交通運行領域所產生的大數(shù)據(jù)主要為人、車、路、環(huán)境等方面的數(shù)據(jù)源，具體包括車輛運行、車輛檢測、道路養(yǎng)護、事故處理、收費、視頻檢測、GPS、基礎設施等方面的數(shù)據(jù)，交通運行大數(shù)據(jù)具有數(shù)據(jù)體量大、類型復雜、更新速度快、價值密度低等特征。

2.3.1 信息采集

基于微服務架構的交通信息化框架，信息采集層位于整個系統(tǒng)最底層，主要進行交通運行數(shù)據(jù)的采集和獲取，不同于傳統(tǒng)采集方式，微服務架構提供多樣化的交通運行服務，其所采集的數(shù)據(jù)主要包括靜態(tài)結構化異構數(shù)據(jù)和動態(tài)非結構化異構數(shù)據(jù)兩大類。前者主要來自不同管理部門的交通數(shù)據(jù)庫；后者則來自交通節(jié)點傳感器，考慮到傳感器形式的多樣性，其所采集到的數(shù)據(jù)信息在時間及空間粒度、數(shù)據(jù)格式及存儲方法等方面均存在一定差異。

采集交通運行信息的主要目的在于對道路運行狀況實施監(jiān)測，分析各個路段及道路交叉口運行狀態(tài)，預測交通運行趨勢等。隨著路網(wǎng)建設進程的不斷推進，交通運行信息采集方面過去所普遍面臨的采集設備覆蓋面不足、設備種類缺乏多元化等問題逐步得到解決，道路信息采集設備覆蓋面越來越廣泛、采集來源也更加多元化。多元化的信息來源所引起的數(shù)據(jù)異構化問題可以通過分類、歸納信息來源，拆分模塊，并通過不同微服務獨立承接、存儲數(shù)據(jù)的處理技術予以解決[3]。數(shù)據(jù)承載量不大的交通運行數(shù)據(jù)可以通過傳統(tǒng)數(shù)據(jù)庫，根據(jù)數(shù)據(jù)類型選擇關系型/非關系型數(shù)據(jù)庫，并結合硬盤raid以保證數(shù)據(jù)安全。數(shù)據(jù)承載量較大的交通運行數(shù)據(jù)，則應通過由低成本機器集群所構成的大容量、高容錯能力的分布式文件系統(tǒng)存儲，例如應用較為廣泛的HDFS分布式文件存儲系統(tǒng)等。

2.3.2 信息處理及發(fā)布

基于微服務架構的交通信息化框架中，交通信息處理是最核心業(yè)務層，該層主要根據(jù)服務需求對所采集到的異構數(shù)據(jù)集成化處理，同時執(zhí)行數(shù)據(jù)發(fā)布層所提出的查詢請求。

進行交通運行信息處理時，主要根據(jù)業(yè)務場景及數(shù)據(jù)類型進行微服務拆分，并在微服務間預留接口便于調用?？紤]到交通運行數(shù)據(jù)體量巨大、完成計算任務消耗資源多，故采用基于內存計算的Spark增量流處理框架，同時針對不同業(yè)務場景開發(fā)不同的微服務，構建起交通運行數(shù)據(jù)處理微服務群。

交通運行系統(tǒng)處理的最后環(huán)節(jié)是信息發(fā)布，具體包括推送和請求兩種方式。推送主要指將信息推進消息隊列，并對訂閱用戶終端實時發(fā)送；請求則是通過客戶端向服務端API發(fā)送資源請求，經(jīng)過合法性驗證后從服務端向客戶端發(fā)送數(shù)據(jù)。

2.4 微服務集群部署

將單體服務拆分成微服務后，內部耦合性降低，可擴展性明顯增強，實例數(shù)量也因此從單個擴展成多個，項目部署及啟動面臨的挑戰(zhàn)也因此增大，為此，交通信息化微服務集群部署必須引入容器化方法。Docker開源項目能夠提供系統(tǒng)方式以利于可移植容器內Linux程序的自動化部署，其內核及應用程序的API實現(xiàn)了LXC的擴展，能保證CPU、內存及I/O、網(wǎng)絡等API的獨立運行。此外，Docker還能通過名稱空間將進程樹、用戶ID、網(wǎng)絡及文件系統(tǒng)等應用程序對底層操作環(huán)境的視圖完全隔離。在進行交通信息化微服務集群部署時，通過Docker將各微服務打包成獨立運行容器，借助Docker-compose進行其鏡像間依賴關系的描述，并通過統(tǒng)一入口一鍵啟動微服務集群，還能在確保后端微服務協(xié)調調用的情況下將對外提供服務端口映射至物理機端口，達到對外隱藏端口及保證微服務集群安全的效果。

3 結語

綜上所述，交通信息化是未來交通運行管理發(fā)展的必然趨勢，當前交通信息系統(tǒng)單體式結構主要存在復雜程度高、交付效率低、可靠性和可擴展性不足、維護難度高等技術難題，基于微服務的交通信息系統(tǒng)架構是解決當前單體結構問題的可行之策，該系統(tǒng)架構主要面臨交通信息收集、處理及發(fā)布等方面的微服務業(yè)務優(yōu)化方案。實踐證明，采用分立的微服務承接、持久化處理不同類型的交通運行信息數(shù)據(jù)，并通過專門的微服務發(fā)布，能有效解決傳統(tǒng)單體式架構存在的弊端，提升交通運行數(shù)據(jù)信息處理效率，推進交通信息化的發(fā)展。