本系统面向车联网车载实时数据采集场景，构建一套由车载终端、Netty 接入服务、消息中间件与实时计算引擎组成的分层数据采集架构。数据源为多台车辆的 TBOX 车载通信盒，TBOX 采集整车 CAN 总线输出的原始报文，报文底层为二进制字节流，在传输阶段采用十六进制格式封装，借助 4G/5G 移动通信网络，基于 HTTP 协议以 TCP 长连接方式向服务端上报数据；数据传输前完成安全验证，对报文进行鉴权与验签，抵御伪造报文、非法接入等安全风险。
后端采用 Netty 框架搭建高性能 HTTP 接入服务，支撑海量车载终端并发长连接接入。Netty 通过 Channel 管道接收网络报文，完成请求头 Header 与请求体 Body 解析，Channel 作为数据通道临时缓存数据流，同时处理网络传输中的粘包、拆包问题。服务端读取 Body 内部的十六进制原始报文，依据整车 CAN 通信协议进行解码，将原始编码转换为车速、电池电压、故障码等十进制物理量，封装为 JSON 结构化消息。
解析完成后的 JSON 数据采用轮询策略分发至 Kafka 集群的多个分区，Kafka 承担消息缓冲与系统解耦作用，实现流量削峰填谷，隔离车载上报端与实时计算端，避免车辆并发流量冲击计算服务。Flink 集群消费 Kafka 中的车载 JSON 数据，执行 ETL 数据清洗、指标统计、故障实时告警、驾驶行为分析等实时业务计算，计算结果可同步推送至其他业务服务集群，完成整套车载数据采集与实时分析闭环。
Q1：简述这套车载数据采集整体流程？
A：多车 TBOX 采集 CAN 总线十六进制原始报文，通过 4G/5G 网络以 TCP 长连接、HTTP 协议上报 Netty 服务。Netty 接收报文，通过 Channel 管道解析 body 内十六进制数据，按照车辆协议解码，转换成 JSON 结构化数据。JSON 消息轮询写入 Kafka 多分区做消息缓冲，最后 Flink 消费 Kafka 数据，完成 ETL 清洗与车辆实时业务分析，传输全程前置安全校验。
Q2：为什么车载 TBOX 上传的是十六进制原始报文？
A：车载 CAN 总线底层是二进制字节流，1 字节等于 2 位十六进制字符。十六进制是二进制的简写形式，方便日志打印、调试排错，可快速定位故障位标识；同时刚好适配 CAN 总线按字节传输的特性，不会产生进制转换精度损失。Netty 收到十六进制报文后，再解析转换成十进制物理量，封装 JSON 供后续业务分析。
Q3：Netty 在本方案中的作用是什么？Channel 的作用？
A：Netty 是高性能 NIO 网络框架，用来搭建 HTTP 服务，支持上万台 TBOX 高并发长连接接入，接收车辆上报报文。 Channel 是 Netty 的数据管道，负责接收、临时缓存网络数据流，同时处理 TCP 粘包拆包，完成报文的读取与传递。
Q4：Kafka 在这里起到什么作用？为什么轮询写入多分区？
A：Kafka 作为消息中间件，核心作用解耦、削峰填谷。车辆上报流量波动大，Kafka 可以缓存峰值报文，保护 Flink 计算集群不被突发流量压垮，同时把采集层和计算层解耦，两边可以独立扩容。 轮询分发到多个分区，实现负载均衡，提升 Kafka 的吞吐能力，并行消费提升处理速度。
Q5：TCP 长连接相比短连接有什么优势？
A：TBOX 和 Netty 维持长连接，不需要每次上报数据都重新建立 TCP 握手，减少网络开销，降低数据上报延迟，适合车辆状态、故障信息的实时上报场景。
Q6：这套方案存在哪些风险？如何优化？
A：
- TCP 粘包拆包：Netty 增加自定义报文解码器，使用分隔符 / 定长协议处理；
- 4G/5G 弱网丢包：TBOX 本地缓存报文，增加断线重连、报文重传机制；
- 多车型协议差异：解析模块做协议版本管理，支持多车型 CAN 协议适配；
- 安全风险：报文增加签名、加密，传输前做身份安全验证，防止伪造报文攻击。
Q7：Flink 在这个架构里做什么？
A：Flink 作为实时计算引擎，消费 Kafka 中的车载 JSON 数据，做 ETL 清洗（过滤脏数据、补全字段）、实时指标计算、车辆故障告警、驾驶行为分析等实时业务。
本方案实现车载 TBOX 数据采集实时上云。TBOX 采集 CAN 总线十六进制报文，4G/5G 通过 HTTP+TCP 长连接上报 Netty。Netty 通过 Channel 接收报文，解析十六进制原始数据转为 JSON 结构化数据，轮询写入 Kafka 集群削峰解耦。Flink 消费 Kafka 数据，完成 ETL 与实时业务分析。传输前增加安全验证，整套架构支持海量车辆并发接入，实现车联网数据实时采集处理。