【摘要】：車聯(lián)網(wǎng)業(yè)務除傳統(tǒng)的車載信息服務,比如安全保障、遠程控制和語音導航等功能,還包括不斷創(chuàng)新的服務,比如車隊管理、駕駛行為分析、車輛鑒定評估等基于大數(shù)據(jù)分析的業(yè)務。車輛數(shù)據(jù)的采集與分發(fā)是所有這些業(yè)務的基石。隨著車輛日益增多,需要采集的車輛數(shù)據(jù)的種類不斷增加,車輛數(shù)據(jù)以億級數(shù)量增加,亟待解決車輛數(shù)據(jù)采集與存儲的性能、按業(yè)務服務類型管理采集及分發(fā)任務等問題。針對上述問題,本文以國內(nèi)占領先地位的某車聯(lián)網(wǎng)信息服務公司的實際項目為背景,在對微服務架構(gòu)、微服務監(jiān)控、Kafka消息中間件等相關技術進行分析研究的基礎上,設計并實現(xiàn)了一個基于微服務的車輛數(shù)據(jù)采集與分發(fā)系統(tǒng)(以下簡稱VDCDS系統(tǒng))。該系統(tǒng)的核心功能包括基于Kafka的車輛數(shù)據(jù)采集及分發(fā)、基于Cassandra的車輛數(shù)據(jù)存儲、基于Spring Cloud Sleuth的任務服務監(jiān)測等。測試情況表明,該系統(tǒng)是可行和有效的。本文的工作要點如下:1)基于Kafka的車輛數(shù)據(jù)采集與分發(fā)。車聯(lián)網(wǎng)的車輛數(shù)據(jù)采集需支持數(shù)以千計的數(shù)據(jù)類型和諸如SOAP、REST、JMS等多種傳輸協(xié)議,采集后的車輛數(shù)據(jù)需根據(jù)業(yè)務類型分發(fā)給多個下游業(yè)務系統(tǒng)。本文提出了一種基于微服務的車輛數(shù)據(jù)采集與分發(fā)任務管理方案,采用Spring Cloud和Kafka框架實現(xiàn)了該方案。測試情況表明,VDCDS系統(tǒng)能夠支持百萬車輛每秒10萬條近50MB車輛數(shù)據(jù)的采集。2)基于Cassandra的車輛數(shù)據(jù)存儲。車聯(lián)網(wǎng)的車輛數(shù)據(jù)存儲需支持百萬活躍車輛早晚高峰時高并發(fā)量的數(shù)據(jù)上傳和以億級增加的車輛數(shù)據(jù)數(shù)量,支持按照車輛、時間和業(yè)務類型的秒級數(shù)據(jù)查詢。本文設計并實現(xiàn)了一個基于Cassandra的分布式車輛數(shù)據(jù)存儲模塊。測試情況表明,VDCDS系統(tǒng)可支持每秒10萬級的混合讀寫場景,寫入和讀取的延遲99.9%情況下都在300毫秒以內(nèi)。3)基于Spring Cloud Sleuth的服務監(jiān)測。車輛數(shù)據(jù)采集、分發(fā)和存儲服務需支持高可用,需監(jiān)測服務請求的生命周期時長。本文采用Spring Cloud Sleuth和Zipkin等開源框架設計并實現(xiàn)了服務監(jiān)測功能。測試情況表明,當服務監(jiān)測的采樣率設置為0.1時,服務的吞吐量約降低0.5%,響應的延遲約增加1%。VDCDS系統(tǒng)可應用在所有需要使用車輛數(shù)據(jù)的車聯(lián)網(wǎng)業(yè)務中。例如支持車隊管理的歷史軌跡等基于車輛位置數(shù)據(jù)的服務;支持駕駛行為分析等基于車輛點/熄火和速度數(shù)據(jù)的服務;支持車輛鑒定和評估等基于車輛故障診斷和碰撞數(shù)據(jù)的服務。VDCDS系統(tǒng)的設計和構(gòu)建能夠增強車聯(lián)網(wǎng)平臺各個系統(tǒng)內(nèi)聚性的同時,保持各個系統(tǒng)之間的松散耦合,從而可以降低各個系統(tǒng)開展新業(yè)務功能及維護的成本,增強整個車聯(lián)網(wǎng)平臺的健壯性和可用性。
【圖文】：

圖 2-1 單體架構(gòu)與微服務架構(gòu)Figure 2-1 Monolithic architecture and Microservices architecture例如，系統(tǒng)由訂單管理服務，用戶管理服務組成等。服務之間通信使用同步的HTTP/REST 協(xié)議，或者使用異步的 AMQP 協(xié)議。每個服務可以獨立的開發(fā)和部署。每個服務擁有自己的數(shù)據(jù)庫，從而和其他的服務解耦。數(shù)據(jù)的一致性可以使用數(shù)據(jù)復制機制或者服務間的事件來維護。使用上述架構(gòu)解決方案有如下優(yōu)點：每個服務相對來說代碼規(guī)模小，易于開發(fā)人員理解。集成開發(fā)速度較快，利于開發(fā)人員提高生產(chǎn)率，部署和啟動速度快，利于維護和測試，以及加快部署的頻率。服務之間相互較為獨立，利于單個服務的升級。每個小組可以負責單個服務，利于開發(fā)團隊的擴充。開發(fā)小組可以對服務的開發(fā)，部署和擴展做出獨立決策，從而利于開發(fā)團隊的組織和協(xié)作。利于錯誤隔離，比如某個服務有嚴重的內(nèi)存泄漏，只有那個服務會受到影響，其他服務可以正常處理請求。而在單體架構(gòu)中，單個服務組件有可能拖垮整個系統(tǒng)。服務可以獨立開發(fā)和部署。消除了對特定技術棧的長期捆綁和依賴。

基于微服務的車聯(lián)網(wǎng)車輛數(shù)據(jù)采集與分發(fā)系統(tǒng)單體系統(tǒng)分解為多個服務，每個服務需要隔離，需要使用單獨的應用服務器實例，其消耗的硬件和軟件資源必然會增加。何時選擇何種架構(gòu)是需要慎重考量的。當開發(fā)系統(tǒng)的早期版本時，使用單體架構(gòu)通常不會面臨很多問題，此時如果使用需要精細的分布式架構(gòu)則會拖慢開發(fā)進度。對于初創(chuàng)公司，或者急需開展新業(yè)務的時候，單體架構(gòu)就較為合理，選擇分割服務即微服務架構(gòu)會使迭代速度變慢，對業(yè)務模型的進化產(chǎn)生不良影響，有可能得不償失。如果采用單體架構(gòu)，業(yè)務規(guī)模增長后，需要使用功能分解來擴展系統(tǒng)時，軟件組件之間模糊并且錯綜復雜的依賴關系，使得把單體架構(gòu)轉(zhuǎn)變?yōu)橐幌盗蟹⻊盏睦щy就大大增加。2.1.2 基礎設施服務微服務架構(gòu)中業(yè)務服務通常依賴基礎設施服務，來完成所需要的集中化或自動化工作[22]。如圖 2-2 所示。
【學位授予單位】：上海交通大學
【學位級別】：碩士
【學位授予年份】：2018
【分類號】：U495;TP274.2

【相似文獻】

相關期刊論文 前10條

1 薛寧;;財務數(shù)據(jù)采集的統(tǒng)一處理框架設計與應用[J];審計月刊;2019年08期

2 陽澤;韓睿婷;林曉婷;;教育實證研究中數(shù)據(jù)采集的基本規(guī)范、現(xiàn)實困境及其改進[J];教育測量與評價;2019年08期

3 管宇e，

本文編號：2698588