秦小明，陳景誠

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

0 引言

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

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

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

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

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

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

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

2 基于微服務(wù)的交通信息化

2.1 微服務(wù)架構(gòu)概述

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

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

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

圖1 交通信息系統(tǒng)微服務(wù)架構(gòu)

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

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

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

圖2 JSON WEB TOKEN鑒權(quán)流程

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

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

2.3.1 信息采集

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

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

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

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

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

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

2.4 微服務(wù)集群部署

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

3 結(jié)語

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