基于車聯(lián)網(wǎng)的物流信息監(jiān)控平臺的研究與設計*

張愛玲，曹 磊

(1.西安理工大學，陜西 西安 710082；2.河南科技大學，河南 洛陽 471023)

0 引言

自從我國將“互聯(lián)網(wǎng)+物流”劃入重點規(guī)劃后，“互聯(lián)網(wǎng)+物流”便乘上了大眾創(chuàng)業(yè)、萬眾創(chuàng)新的東風，物流業(yè)得到飛速發(fā)展?？傮w來看，中國物流產(chǎn)業(yè)的總體規(guī)模目前還比較小，發(fā)展水平也比較低，這一方面是由我國經(jīng)濟發(fā)展的水平和階段所決定的，另一方面，也是更為重要的是我國經(jīng)濟中還存在著許多影響和制約物流產(chǎn)業(yè)健康發(fā)展的因素[1]。李克強總理提出“要推動互聯(lián)網(wǎng)、大數(shù)據(jù)、云計算等信息技術與物流深度融合，推動物流業(yè)乃至中國經(jīng)濟的轉型升級，這是物流業(yè)的供給側改革?！庇纱俗C明了“互聯(lián)網(wǎng)+物流”已成為我國未來物流業(yè)發(fā)展的大趨勢[2]。

通過分析大件物流行業(yè)中存在的問題，本文將互聯(lián)網(wǎng)、大數(shù)據(jù)、云計算等信息技術與物流產(chǎn)業(yè)進行深度融合，構建出一個獨立的車輛軌跡監(jiān)控平臺，通過全球定位系統(tǒng)(Global Positioning System, GPS)、APP(即智能手機的第三方應用程序)及電子圍欄等技術進行車輛軌跡上傳，實現(xiàn)物流全流程節(jié)點配裝到簽收的精確展現(xiàn)，實現(xiàn)物流配送精準，達到了物流平臺對物流運輸配送過程中的可視化業(yè)務管理，滿足了大件物流行業(yè)要求的物流信息透明化戰(zhàn)略要求[3]。

1 設計思路

大件物流信息監(jiān)控平臺主要的監(jiān)控對象是車輛，本系統(tǒng)通過車輛軌跡監(jiān)控來實現(xiàn)物流的跟蹤。平臺采用基于消息機制的線程隊列技術來實現(xiàn)任務之間的事件驅動；采用分布式集群作為具有高并發(fā)能力的終端接入層的實現(xiàn)模式；采用緩存與數(shù)據(jù)庫集群以及數(shù)據(jù)庫的垂直與水平切分作為數(shù)據(jù)存儲層，從而提升系統(tǒng)整體數(shù)據(jù)I/O能力；選取JSP+Action+Delegate+Webservice+Domain+Dao的典型設計模式作為Web層的實現(xiàn)模式；采用Spring+JDBC+Mongo+MySQL作為后端的框架。

圖1 車輛軌跡監(jiān)控平臺總體架構

2 總體設計

車輛軌跡監(jiān)控平臺應用架構完全基于JavaEE的系統(tǒng)體系，使用Spring MVC為整體Web框架，使用Spring為核心業(yè)務模型層，使用JDBC為數(shù)據(jù)訪問層，使用MySQL為數(shù)據(jù)庫持久層，使用MongoDB為緩存與非結構化存儲層，以ActiveMQ為消息中間件。本平臺針對數(shù)據(jù)量大、并發(fā)大和業(yè)務功能本身的要求，選擇基于Spring、SpringMVC、ORM、MongoDB、Netty、ActiveMQ的整套技術體系架構，整體結構支持基于虛擬化技術的進行云服務的規(guī)?；渴稹?/p>

2.1 應用框架

系統(tǒng)的應用架構采用分層設計的理念[4]，基于JavaEE的整體技術體系，結合本系統(tǒng)的特點，將系統(tǒng)分為前端展示層、終端接入層、服務總線層、基礎設施層等多層體系，如圖1所示。

2.2 數(shù)據(jù)流

本平臺在數(shù)據(jù)流轉維護時，采用圖2所示的處理方案。在圖2中，GPS上行數(shù)據(jù)流是APP通過數(shù)據(jù)移動網(wǎng)絡將GPS數(shù)據(jù)發(fā)送至服務器，接收數(shù)據(jù)的為平臺的終端接入層，終端接入層將數(shù)據(jù)進行實時的大數(shù)據(jù)存儲，之后進行相關的業(yè)務邏輯判斷。將終端接入層產(chǎn)生的業(yè)務事件通過MQ集群發(fā)送至平臺服務層，之后由平臺服務層進行業(yè)務邏輯處理。APP業(yè)務處理數(shù)據(jù)流是司機端應用APP通過移動網(wǎng)絡調(diào)用本平臺的對外接口服務，接口服務將請求數(shù)據(jù)分發(fā)至平臺服務層，進行相關的業(yè)務邏輯處理，平臺服務層處理完成之后通過接口服務將響應結果數(shù)據(jù)返回至APP端。

對于外部系統(tǒng)請求數(shù)據(jù)流，是外部系統(tǒng)在某些場景下會請求本平臺的數(shù)據(jù)服務，由對外接口服務統(tǒng)一接入外部請求，之后將請求數(shù)據(jù)分發(fā)至平臺服務層，進行相關的業(yè)務邏輯處理，平臺服務層處理完成之后通過接口服務，將響應結果數(shù)據(jù)返回至外部系統(tǒng)。

2.3 拓撲結構

平臺采用分層分布式的軟件技術體系[5]，因此每一層軟件都采用集群的方式，集群下的每個節(jié)點分別運行在不同的物理服務器之上，采用交叉部署的方式進行。設備接入的總入口采用負載均衡設備(F5/A10)進行統(tǒng)一的負載接入，將負載數(shù)據(jù)分發(fā)至設備接入集群，此后數(shù)據(jù)進入系統(tǒng)內(nèi)部進行業(yè)務處理與前端展示。

3 系統(tǒng)模塊設計

本平臺基于JavaEE技術體系，采用系統(tǒng)模塊化分層設計，各個層所負責的職責不同，相互之間配合完成整體系統(tǒng)的業(yè)務功能流程，同時可以非常好地實現(xiàn)系統(tǒng)的擴展、性能的調(diào)優(yōu)、系統(tǒng)模塊化升級等。

3.1 終端接入層

終端接入層是APP的GPS數(shù)據(jù)上行下行的唯一通道，如圖3所示，終端接入層與APP端進行數(shù)據(jù)協(xié)議的制定，通過標準的通信協(xié)議與數(shù)據(jù)協(xié)議進行通信，終端接入層接收到APP上行來的數(shù)據(jù)，將進行初步的邏輯判斷，并將原始GPS數(shù)據(jù)存入大數(shù)據(jù)平臺，之后將初步判斷的結果性事件信息傳入數(shù)據(jù)通信層(MQ)。

圖3 APP終端接入層

為了保證終端接入層在未來能夠支撐10萬的并發(fā)，終端接入層采用了集群化的軟件管理模式，并通過前端負載設備將數(shù)據(jù)分發(fā)至不同的接入層節(jié)點，實現(xiàn)數(shù)據(jù)處理能力的負載分發(fā)，從而實現(xiàn)大并發(fā)的APP端數(shù)據(jù)上行的處理能力。終端接入層的解析適配器可以適配多種設備數(shù)據(jù)協(xié)議(XML、JSON)、多種通訊協(xié)議(HTTP、TCP/IP、UDP)，能夠達到無縫集成各類終端，如手機APP、GPS終端、外部系統(tǒng)等。

3.2 數(shù)據(jù)通信層

數(shù)據(jù)由終端接入到平臺之后，會路由到數(shù)據(jù)通信層。平臺的數(shù)據(jù)通信層采用相應的消息隊列中間件(MQ)進行數(shù)據(jù)的存儲與轉發(fā)，來提高系統(tǒng)對大量終端上報數(shù)據(jù)的處理能力、減少系統(tǒng)通信阻塞、提高協(xié)議適配等多方面功能。

平臺所采用的是Apache的ActiveMQ，可支持每秒數(shù)萬級的并發(fā)，同時可支持集群方式，能夠為后續(xù)的吞吐量擴充提供良好的保障。

3.3 服務總線層

平臺總線服務層是系統(tǒng)的核心業(yè)務單元，包括核心的業(yè)務模塊、流程、規(guī)則、數(shù)據(jù)訪問、系統(tǒng)集成、統(tǒng)計報表、組織架構、安全模塊、核心GPS算法等。平臺總線服務層最終是以Service的方式對外提供服務。服務總線層功能如表1所示。

表1 車輛軌跡監(jiān)控平臺數(shù)據(jù)通信層功能

3.4 Web展現(xiàn)層

Web展現(xiàn)層是整個系統(tǒng)平臺的UI展現(xiàn)部分，為用戶提供了所有的UI界面功能。UI層不做任何業(yè)務邏輯和數(shù)據(jù)存儲邏輯，它與服務總線層通過服務調(diào)用的方式進行通信，為系統(tǒng)用戶提供管理界面的使用。

Web展現(xiàn)層采用了JSP+Jquery+Ajax的技術框架，充分體現(xiàn)了Web2.0的良好交互體驗。

4 大數(shù)據(jù)平臺設計

本系統(tǒng)會產(chǎn)生海量的GPS數(shù)據(jù)，而同時GPS數(shù)據(jù)中的經(jīng)緯度又是空間數(shù)據(jù)，空間數(shù)據(jù)采用[經(jīng)度，緯度]的模型進行存儲，在系統(tǒng)中還會有大量的基于GPS信息的電子圍欄計算、距離計算等算法需要對空間數(shù)據(jù)進行解析計算，因此空間數(shù)據(jù)的海量數(shù)據(jù)存儲與訪問成為非常重要的設計環(huán)節(jié)，直接影響到系統(tǒng)的核心功能與性能實現(xiàn)。

本模塊采用基于MongoDB進行GPS海量數(shù)據(jù)的存儲，結合MapReduce技術實現(xiàn)數(shù)據(jù)的分布式存儲與讀取，從而大大地提高了大數(shù)據(jù)的處理能力，為后續(xù)的數(shù)據(jù)挖掘、大數(shù)據(jù)分析、高性能的軌跡查詢、軌跡分析等提供非常有力的支撐。大數(shù)據(jù)處理平臺如圖4所示。

5 接口設計

本系統(tǒng)會與外部系統(tǒng)及其他相關業(yè)務系統(tǒng)進行對接，由于系統(tǒng)多元化，系統(tǒng)的接口方式不確定，因此本系統(tǒng)實現(xiàn)了幾乎所有的接口方式，包括Web/HTTP Service、消息隊列、接口表等各種服務，如圖5所示。此外，本系統(tǒng)也會適配各種外部系統(tǒng)所提供的接口，從而實現(xiàn)全部的請求、響應流程，更好地使本系統(tǒng)在內(nèi)部無縫地與其他系統(tǒng)進行集成。

除了通信模式的多元化，系統(tǒng)還能夠提供不同級別的數(shù)據(jù)協(xié)議，更好地實現(xiàn)系統(tǒng)間數(shù)據(jù)傳遞的便捷、高效。

圖4 大數(shù)據(jù)處理平臺

圖5 車輛軌跡監(jiān)控平臺接口設計

6 核心技術問題

6.1 大并發(fā)量的承載能力

本系統(tǒng)中的大并發(fā)量主要體現(xiàn)在APP終端接入量在初期要支撐2萬，未來要達到10萬。在架構設計上，系統(tǒng)采用了分布式的終端接入層集群架構，采用統(tǒng)一的入口負載均衡機制將APP上行的GPS數(shù)據(jù)進行分發(fā)處理，通過擴充終端接入層的實例節(jié)點來增加系統(tǒng)的并發(fā)處理能力，從而為擴充GPS上行并發(fā)量提供了穩(wěn)定擴展的技術架構體系。

6.2 海量GPS數(shù)據(jù)讀寫處理

本系統(tǒng)所管理的目標車輛將會超過10萬甚至更多，因此對于車輛頻繁上報的GPS數(shù)據(jù)量將會非常大。因此系統(tǒng)平臺將采用海量存儲技術來實現(xiàn)大數(shù)據(jù)量的存儲，同時能夠高性能地對海量數(shù)據(jù)進行存儲、查詢等數(shù)據(jù)操作。主要有以下幾個方面的體現(xiàn)：(1)上報GPS數(shù)據(jù)寫入大數(shù)據(jù)存儲；(2)管理用戶端要支撐5 000用戶對軌跡大數(shù)據(jù)進行并發(fā)查詢操作。

本系統(tǒng)在大數(shù)據(jù)處理方面，通過MongoDB進行GPS空間大數(shù)據(jù)的存儲，通過MapReduce進行分布式非結構化文件的管理與讀寫，非常好地解決了TB級乃至PB級數(shù)據(jù)量的存儲、查詢。

6.3 軌跡優(yōu)化與飛點處理

本系統(tǒng)為了精準車輛軌跡信息，一是采用道路匹配算法，該算法結合圖商的路網(wǎng)信息，通過對部分精度不準的GPS數(shù)據(jù)進行道路匹配，使應該在路上的GPS數(shù)據(jù)全面地匹配到地圖道路之上，更友好地展示GPS的軌跡；二是采用智能飛點糾正算法，該算法結合路網(wǎng)信息，針對飛點的前后GPS數(shù)據(jù)的定位情況，對飛點進行精準糾正，讓軌跡更加平滑，避免由于GPS漂移所帶來的軌跡展示的誤差，如圖6所示。

圖6 車輛軌跡監(jiān)控平臺軌跡優(yōu)化與飛點處理

7 結論

本平臺基于JavaEE的成熟、安全、穩(wěn)定、可維護、可擴展的技術特性，通過分層體系進行架構設計，支持靈活的模塊開發(fā)，能夠支持大量的設備終端的接入，并有良好的性能體現(xiàn)，對GPS海量數(shù)據(jù)的讀寫有明顯優(yōu)勢，能夠支撐TB級大數(shù)據(jù)的管理。系統(tǒng)部署后，用戶反饋良好。本平臺還能夠對工業(yè)控制、人工智能、公共交通、設備監(jiān)管、智能家居提供強大的平臺支撐，充分體現(xiàn)了平臺基于物聯(lián)網(wǎng)整體架構的處理能力，可為各行業(yè)提供較為細分的行業(yè)云平臺管理監(jiān)控綜合解決方案。

可以預知，如果能夠在兩客一危(指大客車、大型旅游客車以及危險品車)、個人用車管理、大眾用車服務、租車云監(jiān)控、政企用車等方面提供更加細化的行業(yè)解決方案，就會使基于GPS+北斗和移動APP的多元化終端接入到本平臺，形成更具擴展性和管理能力的行業(yè)解決方案。