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