基于數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器的車輛監(jiān)控管理系統(tǒng)升級方法

周 霞，張 馳，曹鑫亮，于大為

(1.蘇州信息職業(yè)技術(shù)學(xué)院 大數(shù)據(jù)與互聯(lián)網(wǎng)學(xué)院，江蘇 蘇州 215200; 2.南通大學(xué) 地理科學(xué)學(xué)院，江蘇 南通 226007)

0 引言

車輛監(jiān)控管理平臺[1-3]是以因特網(wǎng)、大數(shù)據(jù)[4-5]及云計算為基礎(chǔ)，結(jié)合4G通信技術(shù)、地理信息技術(shù)、泛在技術(shù)，將不斷運動的人、車和靜態(tài)的路、橋等對象結(jié)合[6]。在運轉(zhuǎn)過程中，平臺采用車輛傳感設(shè)備，實時獲取車輛行駛過程中的位置、速度、狀態(tài)等信息，將這些數(shù)據(jù)進行存儲，并進行相關(guān)的智能分析[7-11]。對車輛管理系統(tǒng)來說，所需要解決的一個核心問題是大量汽車同時在線所帶來的高并發(fā)情況。針對該問題，對數(shù)據(jù)的采集、處理等相關(guān)的問題進行了優(yōu)化[12-16]處理，使得系統(tǒng)能夠?qū)Ω卟l(fā)數(shù)據(jù)實現(xiàn)管理。

目前的車輛管理系統(tǒng)大多采用交通部部標808協(xié)議，該協(xié)議能夠很好地對車輛的狀態(tài)進行跟蹤并與車輛進行有效交互。然而，目前也存在著大量不采用808協(xié)議的舊系統(tǒng)。為了將舊系統(tǒng)中的車輛進行統(tǒng)一管理，有必要將這些系統(tǒng)升級到808協(xié)議平臺。但在升級過程中，會遇到如下問題：在新系統(tǒng)開發(fā)完成之后，往往不能直接替換，而是需要試運行一段時間。在此期間，舊系統(tǒng)仍然需要繼續(xù)運行，如何讓新、舊系統(tǒng)同時接入實時數(shù)據(jù)進行運行，是需要解決的核心問題[17]。

針對上述問題，本文提出一種服務(wù)器抓包轉(zhuǎn)發(fā)的方式來構(gòu)建一個中轉(zhuǎn)服務(wù)器，以該中轉(zhuǎn)服務(wù)器為核心，將所接收到的數(shù)據(jù)分別轉(zhuǎn)發(fā)給新舊系統(tǒng)，實現(xiàn)新舊系統(tǒng)的同時運行。

要實現(xiàn)傳感器數(shù)據(jù)的中轉(zhuǎn)，需要解決以下幾個問題：

1)大規(guī)模數(shù)據(jù)并發(fā)問題。車輛管理系統(tǒng)要實現(xiàn)數(shù)據(jù)中轉(zhuǎn)，大規(guī)模并發(fā)數(shù)據(jù)的壓力都會集中在中轉(zhuǎn)服務(wù)器上。服務(wù)器需要同時承擔數(shù)據(jù)的匯聚和轉(zhuǎn)發(fā)，很容易形成數(shù)據(jù)瓶頸。

2)協(xié)議轉(zhuǎn)換問題。新系統(tǒng)統(tǒng)一采用部標808協(xié)議，而舊系統(tǒng)所采用的數(shù)據(jù)傳輸協(xié)議與新系統(tǒng)不同。因此中轉(zhuǎn)服務(wù)器還需要解決的一個問題，即不同協(xié)議之間的兼容問題。

3)數(shù)據(jù)持久化問題。車輛管理系統(tǒng)運行中數(shù)據(jù)量較大，若每收到一幀數(shù)據(jù)就立即連接數(shù)據(jù)庫進行入庫處理，將會造成數(shù)據(jù)庫的頻繁開、關(guān)操作，從而造成數(shù)據(jù)庫崩潰的后果。但如果不能對數(shù)據(jù)實時地進行處理，客戶端的數(shù)據(jù)顯示則會產(chǎn)生延遲。

本文接下來將對數(shù)據(jù)并發(fā)、數(shù)據(jù)入庫、協(xié)議轉(zhuǎn)換等問題進行解決，最終實現(xiàn)新舊車輛管理系統(tǒng)的有效銜接。

1 數(shù)據(jù)中轉(zhuǎn)服務(wù)器

1.1 并發(fā)數(shù)據(jù)的處理框架

傳統(tǒng)BIO在接受遠程用戶的連接請求之后，就會為遠程用戶建立一個線程并進行處理。服務(wù)器在處理過程中會一直保留該線程直至處理完畢后銷毀。該架構(gòu)中，系統(tǒng)為每個單獨的連接創(chuàng)建線程的處理方式，在面對大規(guī)模并發(fā)數(shù)據(jù)時，系統(tǒng)開銷將急劇增長。傳統(tǒng)BIO模型的處理方式，導(dǎo)致系統(tǒng)伸縮性較差，從而嚴重制約了整個系統(tǒng)的效率。在極端情況下，大量用戶在同一時間申請連接，服務(wù)器將會觸發(fā)線程創(chuàng)建失敗、堆棧溢出等情況，甚至可能出現(xiàn)系統(tǒng)崩潰等災(zāi)難性后果。

針對上述問題，本項目選擇中間件Netty作為高性能通信框架，它采用一種基于NIO的異步非阻塞通信框架。NIO框架與傳統(tǒng)的BIO框架存在較大的區(qū)別，它有很強的可擴展性與健壯性。該框架中相關(guān)核心組件如下：

1)Buffer。Buffer(緩沖區(qū))是包含一個數(shù)組的容器。通道(Channel)中的數(shù)據(jù)無論是讀取還是寫入都必須以緩沖區(qū)為基礎(chǔ)。

2)Channel。Channel(通道)與一般流數(shù)據(jù)最顯著的區(qū)別在于，傳統(tǒng)流數(shù)據(jù)是單向的，但對于通道來說，它可以進行雙向的讀取和寫入操作。

3)Selector。Selector(選擇器)作為NIO框架的核心部件，它能夠通過輪詢的模式檢測到注冊的通道是否發(fā)生了相關(guān)事件，如果有事件發(fā)生，則調(diào)用事件處理程序進行相應(yīng)處理。

本文設(shè)計的NIO的異步非阻塞通信架構(gòu)中，存在一個線程池，其中包含大量線程。這種情況下，就不需要為每個連接請求重新創(chuàng)建線程。采用線程池之后，用少量的線程就能為大量的遠程終端服務(wù)了。遠程終端建立連接之后，首先需要到選擇器上完成注冊(見圖1)，選擇器將對注冊在其上的通道輪詢，查詢是否觸發(fā)了相應(yīng)事件。發(fā)現(xiàn)查詢的通道有事件發(fā)生，便可截獲該事件并進行處理。當涉及讀或?qū)懙氖录|發(fā)時，線程池會調(diào)用線程來對其進行處理。該操作模式將原有的同步阻塞式通信方式變?yōu)楫惒椒亲枞酵ㄐ欧绞剑到y(tǒng)維護成本得以大幅度降低，系統(tǒng)效率也得以大幅度提高。通過該框架，數(shù)據(jù)中轉(zhuǎn)服務(wù)器就可以對大規(guī)模并發(fā)數(shù)據(jù)實現(xiàn)很好的接收。

圖1 NIO內(nèi)部執(zhí)行圖

1.2 數(shù)據(jù)中轉(zhuǎn)服務(wù)器框架

基于Netty框架，本文設(shè)計了數(shù)據(jù)中轉(zhuǎn)服務(wù)器，數(shù)據(jù)中轉(zhuǎn)服務(wù)器主要解決大規(guī)模數(shù)據(jù)的并發(fā)接收、中轉(zhuǎn)以及協(xié)議轉(zhuǎn)換問題。其工作原理如圖2所示，遠程傳感器終端發(fā)送大量并發(fā)數(shù)據(jù)到達中轉(zhuǎn)服務(wù)器的網(wǎng)卡之后，中轉(zhuǎn)服務(wù)器對數(shù)據(jù)包進行抓取，并基于NIO框架的線程組向目標主機實現(xiàn)轉(zhuǎn)發(fā)。在此期間，中轉(zhuǎn)主機可對所抓取的數(shù)據(jù)不經(jīng)過處理，直接轉(zhuǎn)發(fā)；也可以在進行簡要處理后再向目標服務(wù)器進行轉(zhuǎn)發(fā)。由于本文的中轉(zhuǎn)服務(wù)器需要實現(xiàn)新舊系統(tǒng)之間的協(xié)議轉(zhuǎn)換，因此采取上述第二種模式，在接收到遠程終端發(fā)來的數(shù)據(jù)后，首先對其進行解析，在此基礎(chǔ)上，根據(jù)所對接的新、舊系統(tǒng)所使用的協(xié)議進行協(xié)議轉(zhuǎn)換，最后將轉(zhuǎn)換后的數(shù)據(jù)通過線程組發(fā)送給相應(yīng)的模塊。

圖2 數(shù)據(jù)中轉(zhuǎn)模塊示意圖

通過高性能NIO框架以及數(shù)據(jù)中轉(zhuǎn)服務(wù)器，就能很好地解決數(shù)據(jù)的高并發(fā)問題以及新舊系統(tǒng)之間的協(xié)議轉(zhuǎn)換問題，使得在系統(tǒng)更替、試運行時，能夠?qū)崿F(xiàn)雙系統(tǒng)的同步運行，有效降低系統(tǒng)升級所帶來的不確定性。

2 數(shù)據(jù)持久化

2.1 數(shù)據(jù)持久化框架

作為一個大型服務(wù)系統(tǒng)，在系統(tǒng)運行過程中，經(jīng)常出現(xiàn)大量傳感器同時發(fā)送數(shù)據(jù)的情況，在此影響下，后臺數(shù)據(jù)庫服務(wù)器在特定時刻或時段將會收到大規(guī)模并發(fā)數(shù)據(jù)。

在接收到數(shù)據(jù)之后，需要綜合考慮兩個問題。首先數(shù)據(jù)能夠?qū)崟r地在客戶端進行顯示；其次數(shù)據(jù)能夠完整地進行持久化，為以后的歷史數(shù)據(jù)反演(如軌跡回放)做準備。

這就帶來一個矛盾，對于規(guī)模巨大的數(shù)據(jù)，如果每收到一個數(shù)據(jù)就進行處理的話，由于數(shù)據(jù)并發(fā)量太大，頻繁地開、關(guān)后臺數(shù)據(jù)庫必然會使得數(shù)據(jù)庫崩潰；與此同時，頻繁的數(shù)據(jù)庫開、關(guān)操作也將導(dǎo)致數(shù)據(jù)庫的開、關(guān)時間要高于原始的數(shù)據(jù)處理時間。因此倘若接到一幀數(shù)據(jù)就進行數(shù)據(jù)庫入庫操作，不管從性能上還是技術(shù)上都不具備可操作性。但如果等收集到一定數(shù)據(jù)之后集中進行處理的話，又會面臨一個問題，即數(shù)據(jù)不能夠?qū)崟r地在客戶端進行顯示。考慮上述問題，本文采用圖3所示的框架實現(xiàn)數(shù)據(jù)的持久化。

該模塊同樣采用支持NIO框架的Netty來進行實現(xiàn)。該框架由數(shù)據(jù)接收主線程、數(shù)據(jù)處理模塊、數(shù)據(jù)緩存、數(shù)據(jù)隊列及持久化模塊等組成。在數(shù)據(jù)接入之后，首先由主線程進行接收，并分派給子線程。子線程中，短事務(wù)線程先進行接收。短事務(wù)線程所做的操作主要包括數(shù)據(jù)接收、協(xié)議解析等。如遇到需要處理的長事務(wù)，如文件讀寫、數(shù)據(jù)庫讀寫等，則將其包裝成一個“任務(wù)”，交給長事務(wù)線程進行調(diào)用。

2.2 延遲入庫與數(shù)據(jù)緩存策略

要想使得數(shù)據(jù)庫能夠容納大規(guī)模并發(fā)數(shù)據(jù)的入庫，則必須采用集中入庫的方式，即服務(wù)器再接收到一定的數(shù)據(jù)之后，統(tǒng)一入庫。集中入庫帶來一個問題即數(shù)據(jù)延遲，考慮到該問題，本文采用的核心思路是數(shù)據(jù)緩存與延遲入庫。該框架在收到遠程終端發(fā)來的一條數(shù)據(jù)后，首先將其存儲在數(shù)據(jù)緩存中，不直接進行入庫操作。等待一定的時間后，再將之前存儲在緩存中的數(shù)據(jù)進行批量入庫，通過這種方式，來避免數(shù)據(jù)庫的頻繁斷、連操作，從而提高平臺的運行效率。對于緩存的容量以及延遲入庫的時間，也必須要根據(jù)具體情況進行合理設(shè)置。一般情況下為5 s或8 s，即每隔5 s或8 s將把緩存中的數(shù)據(jù)批量寫入數(shù)據(jù)庫。但是假如在一個時間點接收到大量數(shù)據(jù)，那么即使入庫時間并未到達，由于數(shù)據(jù)緩存已經(jīng)用完，也需要立刻對暫存在緩存中的數(shù)據(jù)進行批量入庫操作。

在這種方式下，短事務(wù)線程在接收到數(shù)據(jù)之后，同時對數(shù)據(jù)緩存服務(wù)器與數(shù)據(jù)隊列進行寫入，并以相應(yīng)的策略對緩存服務(wù)器進行維護。以保證延遲入庫不對數(shù)據(jù)的實時性產(chǎn)生影響。

該框架在清空原有數(shù)據(jù)緩存空間以及數(shù)據(jù)批量入庫的過程中，仍有可能會有大規(guī)模傳感器數(shù)據(jù)接入。如果不進行相應(yīng)處理，將會丟失大量數(shù)據(jù)。針對該問題，本文重新設(shè)置一個數(shù)據(jù)緩存來與現(xiàn)有的數(shù)據(jù)緩存進行配合。即系統(tǒng)中同時使用兩個數(shù)據(jù)緩存——緩存X和緩存Y。當緩存X容量已滿，系統(tǒng)將暫時不再對緩存X進行寫入，而是轉(zhuǎn)而對緩存Y進行寫入；相應(yīng)地，當緩存Y容量已滿，而緩存X被清空之后，系統(tǒng)將重新對緩存X進行寫入。當系統(tǒng)批量入庫時間到后，緩存中的數(shù)據(jù)被寫入數(shù)據(jù)庫，緩存也將被清空。在某些特殊的應(yīng)用場景下，需要對某傳感器進行單獨跟蹤，這就需要對原始入庫的時間進行調(diào)整，加大入庫頻率(如設(shè)置3 s的入庫間隔時間)。由于該要求比較特殊，不同于其他一般的入庫信息，所以需要設(shè)置一個單獨的線程來獨立負責接收該車載傳感器的數(shù)據(jù)，從而確保對該車載傳感器的持續(xù)跟蹤。

為了提高車輛管理系統(tǒng)的整體運行效率，在數(shù)據(jù)入庫過程中，需要將接收數(shù)據(jù)和寫數(shù)據(jù)庫的功能分開。在本文所述框架中，若將數(shù)據(jù)接收和數(shù)據(jù)批量入庫功能整合在同一個線程，不僅會使當前系統(tǒng)的運行效率大幅度下降，而且很可能會造成服務(wù)器的崩潰。所以本文設(shè)定接收數(shù)據(jù)的線程只負責數(shù)據(jù)接收，與此同時，單獨啟動一個線程，專門負責數(shù)據(jù)庫的寫入操作。這種操作模式不僅可以更好地提升整個系統(tǒng)的運轉(zhuǎn)效率，還能在極大程度上加強系統(tǒng)的可維護性與穩(wěn)定性。

3 實驗結(jié)果與分析

3.1 實驗思路

為了驗證本文基于上述提出的一系列方法的有效性。為了保證數(shù)據(jù)的安全性，在新系統(tǒng)上線之后，舊系統(tǒng)將和新系統(tǒng)同步運行一段時間，等新系統(tǒng)完全穩(wěn)定之后，再將舊系統(tǒng)停止。考慮到該需求，本系統(tǒng)采用數(shù)據(jù)轉(zhuǎn)發(fā)的方式對新舊車輛管理系統(tǒng)進行銜接。在數(shù)據(jù)到達轉(zhuǎn)發(fā)服務(wù)器后，一路數(shù)據(jù)由轉(zhuǎn)發(fā)服務(wù)器轉(zhuǎn)入舊系統(tǒng)，另一路數(shù)據(jù)則轉(zhuǎn)入新系統(tǒng)。舊系統(tǒng)為如東市出租車管理信息系統(tǒng)，采用非部標808協(xié)議。新系統(tǒng)為江蘇太平洋通訊科技有限公司開發(fā)的支持部標808協(xié)議的車輛通訊管理系統(tǒng)，如圖4所示。

圖4 實驗思路

主要從兩個方面來驗證本文方法：1)數(shù)據(jù)轉(zhuǎn)接后，新系統(tǒng)對協(xié)議轉(zhuǎn)接與大規(guī)模并發(fā)車輛數(shù)據(jù)的支持。這就要求新系統(tǒng)能夠順利的實現(xiàn)數(shù)據(jù)轉(zhuǎn)接，從舊系統(tǒng)協(xié)議轉(zhuǎn)換到部標808協(xié)議，且支持10 000以上級別的大規(guī)模并發(fā)車輛同時在線；2)新系統(tǒng)對數(shù)據(jù)批量入庫的支持。這就要求新系統(tǒng)能夠支持歷史數(shù)據(jù)的存儲和訪問，支持類似歷史軌跡回放等功能的使用。

3.2 實驗步驟

實驗步驟如下：第一步，將如東出租車系統(tǒng)數(shù)據(jù)接入數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器；第二步，將數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器所獲取的數(shù)據(jù)劃分為兩組數(shù)據(jù)轉(zhuǎn)出。一組為如東市出租車系統(tǒng)，另一組為江蘇太平洋通訊科技有限公司的新系統(tǒng)。將接入新系統(tǒng)的數(shù)據(jù)做預(yù)處理，即數(shù)據(jù)協(xié)議轉(zhuǎn)換，將舊系統(tǒng)的協(xié)議轉(zhuǎn)化為部標808協(xié)議；第三步，將新系統(tǒng)采用數(shù)據(jù)持久化框架進行處理，實現(xiàn)大規(guī)模并發(fā)數(shù)據(jù)的批量入庫與實時可視化。最后，訪問歷史數(shù)據(jù)庫，實現(xiàn)車輛的歷史軌跡回放功能，驗證數(shù)據(jù)入庫的有效性。

3.3 實驗結(jié)果

經(jīng)過上述步驟，本文實驗結(jié)果如下：

1)新系統(tǒng)對協(xié)議轉(zhuǎn)換及大規(guī)模并發(fā)數(shù)據(jù)的支持。圖5展示了通過銜接系統(tǒng)中轉(zhuǎn)平臺并進行協(xié)議轉(zhuǎn)換之后新系統(tǒng)的運行界面。該系統(tǒng)可以支持50 000級別的車輛同時在線，上述車輛每隔5 s向服務(wù)器發(fā)送1 kB大小的數(shù)據(jù)幀，該系統(tǒng)能夠比較好地實現(xiàn)并發(fā)數(shù)據(jù)的接收，不出現(xiàn)異常情況。

圖5 車輛監(jiān)控系統(tǒng)界面圖

2)該系統(tǒng)很好地處理了數(shù)據(jù)實時顯示與數(shù)據(jù)入庫的問題。在接收到一條數(shù)據(jù)之后，系統(tǒng)能夠很好地對其進行響應(yīng)，并在界面上進行顯示。在積累一定的數(shù)據(jù)之后，數(shù)據(jù)會批量存入數(shù)據(jù)庫。圖6展示了軌跡回放功能，該功能需要基于歷史數(shù)據(jù)對車輛的位置進行查詢，并形成軌跡。該功能的正常運行表明了系統(tǒng)能夠?qū)v史數(shù)據(jù)完好的存入數(shù)據(jù)庫，為后期的數(shù)據(jù)分析提供支持。

圖6 車輛歷史軌跡回放

3.4 存在的問題

實驗表明，新系統(tǒng)能支持50 000級別的大規(guī)模并發(fā)數(shù)據(jù)的接入，實時表達與批量入庫。但依然存在一定的問題，主要體現(xiàn)在：一旦數(shù)據(jù)量突破50 000級別時，系統(tǒng)會出現(xiàn)CPU和內(nèi)存使用率上升的問題，并導(dǎo)致服務(wù)器數(shù)據(jù)丟失。這是因為單臺服務(wù)器的處理能力存在一定的上限，一旦達到這個上限，數(shù)據(jù)服務(wù)器將會成為整個系統(tǒng)的瓶頸。隨著CPU和內(nèi)存的占用率上升，系統(tǒng)接入大規(guī)模并發(fā)傳感器數(shù)據(jù)的能力逐步減弱，在達到一個閾值之后，將有可能產(chǎn)生服務(wù)器整體崩潰的情況。

在今后，將考慮對系統(tǒng)進一步升級。以數(shù)據(jù)中轉(zhuǎn)服務(wù)器為基礎(chǔ)，實現(xiàn)多臺服務(wù)器的負載均衡，進一步提高系統(tǒng)的吞吐量。

4 結(jié)束語

本文基于數(shù)據(jù)中轉(zhuǎn)框架，對新舊車輛管理系統(tǒng)進行了銜接，并有效解決了銜接過程中的相關(guān)問題，并得出以下結(jié)論：

1)基于Netty架構(gòu)構(gòu)建的數(shù)據(jù)轉(zhuǎn)發(fā)服務(wù)器，能夠很好地實現(xiàn)大規(guī)模并發(fā)車輛傳感器數(shù)據(jù)的轉(zhuǎn)發(fā)。在轉(zhuǎn)發(fā)服務(wù)器中進行協(xié)議轉(zhuǎn)換，就可以有效地實現(xiàn)新舊系統(tǒng)的銜接。

2)基于延遲入庫與數(shù)據(jù)緩存策略，本系統(tǒng)能夠有效實現(xiàn)大規(guī)模并發(fā)車載傳感數(shù)據(jù)批量入庫與實時顯示。

3)基于本文所提出的數(shù)據(jù)中轉(zhuǎn)框架，可以有效地實現(xiàn)基于不同協(xié)議的車輛管理系統(tǒng)的銜接，實現(xiàn)新舊系統(tǒng)的無縫過渡。