复杂的混合协议, 将808协议指令和报警文件数据流混合在一起, 给开发者造成了不小的麻烦, 有点烧脑. 同时由于其本身业务的复杂度, 使得开发人员必须要有一定的开发经验, 结合比较好的设计模式才能构建出来性能良好的网

关. 一般需要几个版本的迭代, 必须要在实际的大规模车辆接入, 运营一段时间积累足够多的设备经验, 才能逐步的成熟稳定下来. 没有一定规模的设备接入, 就能做出高性能的网关是不可能的事情.单纯的采用SpringBoot + Netty,

只是一个基础, 后面的代码我们仍然要有扎实良好的设计功底,才能做出一个优秀的主动安全平台. 如需购买苏标或粤标主动安全平台源码,请联系2379423771@qq.com

        作为开发者我们必须要解决一下五个设计挑战:

        1) 高性能的主动安全协议通信网关通信框架设计

        2) 苏标主动安全协议和粤标主动安全协议的兼容性设计;

        3) 大数据量高并发存储设计;

        4) 及时的报警推送和处理;

 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中获取, 而不从存储服务中获取.

(5771)