秦小明，陳景誠(chéng)

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

0 引言

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

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

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

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

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

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

（4）不利于技術(shù)創(chuàng)新。在技術(shù)棧的約束下，必須使用同一種框架和語(yǔ)言，傳統(tǒng)單體式架構(gòu)必然面臨較大的重構(gòu)成本和風(fēng)險(xiǎn)，故不利于框架及語(yǔ)言的重構(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ā)展而來(lái)，康威定律中有關(guān)組織結(jié)構(gòu)和其設(shè)計(jì)系統(tǒng)結(jié)構(gòu)關(guān)系的描述是微服務(wù)架構(gòu)的核心理論基礎(chǔ)[1]。Martin Fowler與James Lewis在2014年率先提出微服務(wù)的概念，微服務(wù)作為一種能夠獨(dú)立部署、伸縮及測(cè)試的小型應(yīng)用程序，職責(zé)較為單一，這種小型應(yīng)用程序主要根據(jù)業(yè)務(wù)功能予以劃分，并通過(guò)自動(dòng)化部署機(jī)制獨(dú)立部署運(yùn)行，微服務(wù)之間則通過(guò)輕量級(jí)通信機(jī)制實(shí)現(xiàn)通信。微服務(wù)體系主要將單個(gè)應(yīng)用程序拆分成小型服務(wù)，各服務(wù)均在HTTP資源API的輕量級(jí)通信機(jī)制下按照所屬進(jìn)程運(yùn)行，此類服務(wù)均圍繞業(yè)務(wù)功能構(gòu)建，且通過(guò)自動(dòng)化機(jī)制獨(dú)立部署，對(duì)服務(wù)進(jìn)行集中化管理。

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

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

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

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

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

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

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

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

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

2.3.1 信息采集

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

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

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

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

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

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

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

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

3 結(jié)語(yǔ)

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