蘇標(biāo)主動(dòng)安全協(xié)議在2021年迎來一個(gè)新的版本粵標(biāo)主動(dòng)安全協(xié)議標(biāo)準(zhǔn), 這個(gè)標(biāo)準(zhǔn)是基于jt/t808-2019協(xié)議框架的. 作為一個(gè)面向全國的主動(dòng)安全平臺(tái)不可能只能接入粵標(biāo), 還要兼容蘇標(biāo).蘇標(biāo)主動(dòng)安全協(xié)議本身就是一個(gè)比較復(fù)雜的混合協(xié)議, 將808協(xié)議指令和報(bào)警文件數(shù)據(jù)流混合在一起, 給開發(fā)者造成了不小的麻煩, 有點(diǎn)燒腦. 同時(shí)由于其本身業(yè)務(wù)的復(fù)雜度, 使得開發(fā)人員必須要有一定的開發(fā)經(jīng)驗(yàn), 結(jié)合比較好的設(shè)計(jì)模式才能構(gòu)建出來性能良好的網(wǎng)關(guān). 一般需要幾個(gè)版本的迭代, 必須要在實(shí)際的大規(guī)模車輛接入, 運(yùn)營一段時(shí)間積累足夠多的設(shè)備經(jīng)驗(yàn), 才能逐步的成熟穩(wěn)定下來. 沒有一定規(guī)模的設(shè)備接入, 就能做出高性能的網(wǎng)關(guān)是不可能的事情.單純的采用SpringBoot + Netty,只是一個(gè)基礎(chǔ), 后面的代碼我們?nèi)匀灰性鷮?shí)良好的設(shè)計(jì)功底,才能做出一個(gè)優(yōu)秀的主動(dòng)安全平臺(tái).
作為開發(fā)者我們必須要解決一下五個(gè)設(shè)計(jì)挑戰(zhàn):
1) 高性能的主動(dòng)安全協(xié)議通信網(wǎng)關(guān)通信框架設(shè)計(jì)
2) 蘇標(biāo)主動(dòng)安全協(xié)議和粵標(biāo)主動(dòng)安全協(xié)議的兼容性設(shè)計(jì);
3) 大數(shù)據(jù)量高并發(fā)存儲(chǔ)設(shè)計(jì);
4) 及時(shí)的報(bào)警推送和處理;
如需購買源碼 , 請(qǐng)先聯(lián)系: 2379423771@qq.com, 詳細(xì)內(nèi)容請(qǐng)參考:
1.高性能的主動(dòng)安全協(xié)議通信網(wǎng)關(guān)通信框架設(shè)計(jì)
Netty框架當(dāng)然是首選, 這個(gè)不用多言, 作為基礎(chǔ)框架, 我們一般用SpringBoot2整合Netty4框架, 先為我們的平臺(tái)打下一個(gè)堅(jiān)實(shí)的基礎(chǔ).
基于Netty4進(jìn)行協(xié)議解析, 我們必須要清楚設(shè)備與服務(wù)器之間的通信協(xié)議, 及通信數(shù)據(jù)格式. 一個(gè)粵標(biāo)設(shè)備一次報(bào)警, 可能與平臺(tái)直接建立三個(gè)連接, 一個(gè)是指令連接, 兩個(gè)是數(shù)據(jù)傳輸?shù)倪B接.如下圖所示:
2. 蘇標(biāo)主動(dòng)安全協(xié)議和粵標(biāo)主動(dòng)安全協(xié)議的兼容性設(shè)計(jì);
兼容性設(shè)計(jì)主要是對(duì)于接入設(shè)備的報(bào)文,由程序自動(dòng)識(shí)別出協(xié)議的版本. 并以此來決定后續(xù)的報(bào)文數(shù)據(jù)解析和指令下發(fā), 如果是粵標(biāo)的設(shè)備,下發(fā)的指令亦應(yīng)是粵標(biāo)協(xié)議格式. 實(shí)際上蘇標(biāo)是采用jt/t 808-2013協(xié)議, 粵標(biāo)是采用jt/t 808-2019協(xié)議, 所以就是要區(qū)分是2013版本還是2019版本.
3.大數(shù)據(jù)量高并發(fā)存儲(chǔ)設(shè)計(jì)
粵標(biāo)主動(dòng)安全報(bào)警文件上傳,本質(zhì)上就是多個(gè)設(shè)備同時(shí)并發(fā)連續(xù)上傳多個(gè)文件,對(duì)磁盤的IO操作非常的頻繁.磁盤存儲(chǔ)的成本也非常的昂貴.在阿里云上面擴(kuò)容一個(gè)100G的硬盤每月的成本需要千元.而這對(duì)于海量的主動(dòng)安全報(bào)警文件來說都不夠塞牙縫.
一次報(bào)警如果平均是4個(gè)文件,1M大小,則如果在線有1000臺(tái)車, 則每天平均報(bào)警一次, 將會(huì)上傳1G的文件. 如果每個(gè)車平均上報(bào)10次, 則每日有10G的存儲(chǔ)需求. 如果有1萬臺(tái)車, 就自己算去吧.
而目前的主動(dòng)安全設(shè)備廠商來說芯片算法很多并不掌握, 報(bào)警的準(zhǔn)確性和誤報(bào)率非常的高. 如車道偏離報(bào)警, 車距過近報(bào)警等, 這些誤報(bào)的報(bào)警文件,基本上都是垃圾數(shù)據(jù), 卻會(huì)占用服務(wù)器大量的帶寬資源和存儲(chǔ)成本.
對(duì)于平臺(tái)不存也不行, 萬一里面真有一次車輛碰撞事故呢? 為了節(jié)省存儲(chǔ)成本, 采用云廠商提供的云存儲(chǔ)服務(wù), 阿里云,騰訊云,華為云的OSS云存儲(chǔ)費(fèi)用相對(duì)較低, 但是存儲(chǔ)容量也不能一直增長, 如果一直增長,阿里云也不是活菩薩, 也會(huì)有很多收費(fèi)陷阱. 最好30天的生命周期, 過期數(shù)據(jù)自動(dòng)銷毀,或者歸檔.
所以在設(shè)計(jì)的時(shí)候,要提供和支持本地存儲(chǔ),本地訪問,OSS存儲(chǔ)和OSS服務(wù).
4.報(bào)警消息的及時(shí)推送和報(bào)警數(shù)據(jù)的及時(shí)展現(xiàn).
這里用到及時(shí), 是因?yàn)橐淮沃鲃?dòng)安全的報(bào)警, 我們需要等待所有的報(bào)警附件全部上傳完畢后, 進(jìn)行報(bào)警消息的推送. 做不到實(shí)時(shí)的推送, 只能在前端能夠及時(shí)的展現(xiàn)出來, 這就要求我們不能等待數(shù)據(jù)存儲(chǔ)完畢才進(jìn)行消息推送, 我們在數(shù)據(jù)接收完畢后進(jìn)行消息推送. 這就用到redis框架. 接收到數(shù)據(jù)后,及時(shí)的放入redis當(dāng)中. 前端展現(xiàn)的時(shí)候, 從redis中獲取, 而不從存儲(chǔ)服務(wù)中獲取.