本文主要做技术分享，如有侵权请通知作者删除
项目背景
该项目是d市的*项目，需要从n（n>10000）台公交车中收集车上数据，包括驱动、电池、发动机、报警等共计100余种车辆信息，需要基于国标32960协议完成数据的接收与应答，并基于海量的车上数据做大数据分析，报表展示，更需要车辆报警信息作应急处理，对实时性有很高的要求，基于此需要在车上安装车载终端（一种可以嵌入到车上的硬件设备，支持can协议读取数据，材料需要满足防火防水等要求），该车载终端我们暂且叫dbox(非真实名称)。
项目技术选型
Netty，Kafka，Redis，SpringCloud,SpringBoot，MySQL，FastDFS，Docker，K8s，Jekin，Nacos，Hadoop，HBase，Spark等等一些系列技术（本文重点在Netty）
系统整体架构
以上是整体系统架构图（图画的有点糙，博主是个粗人），整体的数据流向为：
- 车载终端通过平台登入与车辆登入（后面会详细解释该过程，读者暂时当做“黑盒”来理解）上报数据
- 车载终端上报数据由netty服务端接收并根据GB32960协议解码成POJO对象，并把解码对象放入kafka中
- 大数据平台通过kafka采集数据，做数据分析，统计，日志等处理（不是本文的重点）
- 数据检查模块需要检查解码数据是否有异常（协议中规定为异常，报警），把异常数据分析的结果再次放入到kafka,并把解码数据原封不动的放入到Redis中，供admin模块调用（4过程与3过程异步同时进行，互不影响）
- admin模块从kafka中获取到异常数据的分析结果，从Redis，Mysql数据库中获取数据，并做基本的添删该查等业务处理
协议简介
GB32960协议是根据有关电动汽车远程服务而设计的协议，通过该协议可以从车上获取指定车辆的数据，他的数据格式是以16进制0x230x23开头的协议（注：该部分读者不感兴趣可以直接跳过，该协议理解需要花一定时间，限于篇幅，只简单介绍数据格式，不影响后面的代码阅读），具体数据格式如下图：
一些重要的数据格式解读:
- 唯一识别码vin：车辆的vin识别码，由17个Byte字节组成，车辆的唯一标识
- 数据单元长度：描述数据单元的长度，后续涉及的半包读（粘包粘包）解码方案与该项有关
- 数据单元：这一包数据，包含各种数据来源，驱动电机，发动机，电池等种类数据
技术难点
在项目中需要解决的技术难点有很多，也涉及到一些技术解决方案，以下是该项目面临的部分难点
- 如何解决车载终端接入增多问题，如何解决海量的设备接入与实时性的要求
- 如何基于GB32960协议完成数据的粘包和粘包操作（半包读写问题）
- 如何处理大数据包的拆分情况，数据的分包与合包如何处理
- 如何更加高效的解码数据包，与应答车载终端
- 后端服务如何高可用高性能
- 数据检查过程中如何快速筛选异常数据，并解决高并发环境下的数据共享问题
- 车载终端如何升级车载程序与获取终端配置
- …
待续......