前阵子把一套基于Spring Boot Vue的交通感知与车路协同系统整理完成正好借这篇博客把完整的设计思路和落地过程做一个复盘。这套系统不是那种纯演示的CRUD项目而是把车端定位、路侧设备接入、信号灯控制、数据可视化串成一条完整业务链路的全栈方案。如果你正在做智能交通方向的毕业设计或者想了解车路协同V2X业务到底是怎么跑通的这篇文章应该能帮你省不少事。我重点会讲清楚三件事数据库表为什么这么设计、后端实时数据处理链路怎么搭、前端大屏怎么做到不卡顿。每一段都有可以直接抄走的建表语句、接口设计和踩坑记录不是教科书式的代码堆砌而是我实际编译运行验证过的方案。1. 思路上先理清楚车路协同系统到底在解决什么问题1.1 单车智能的盲区正是车路协同的价值点先说一个背景。现在很多车都装了摄像头、毫米波雷达、激光雷达这是单车智能。但单车智能有一个物理上的天花板看得再远也会被遮挡而且看不到红绿灯的实时状态更不知道下一个路口的拥堵情况。车路协同的思路是把“眼睛”和“大脑”的一部分从车上搬到路上路侧设备RSU、摄像头、雷达把周围环境感知完再通过车路通信告诉车辆或者云端平台车辆就知道路口有没有行人、前方是不是红灯、哪条车道正在拥堵。如果这个概念不好理解可以想象一个场景你在一条被大货车完全挡住视线的车道上行驶前方200米是路口信号灯马上要变灯。单车智能看不到这个情况但路侧感知设备能完整看到车路协同系统就能把“前方路口绿灯还剩2秒建议减速停车”这条信息下发到车上。这就是这个系统最核心的业务价值。所以我在设计的时候始终把“感知数据采集 - 云端实时分析 - 结果下发展示”这条链路放在第一位。前端展示的是结果后端的核心是链路数据库则是整条链路的记忆载体。1.2 技术选型为什么是Spring Boot Vue这个组合在高校项目和企业内部系统里都很常见选它有几个实际的好处。第一生态成熟。Spring Boot 2.7.x搭配JDK 1.8是目前最稳妥的组合网上能搜到的资料最多遇到问题几乎都能找到解决方案。第二前后端分离的开发模式更贴近真实团队协作。我这边负责前端的同学在写页面后端接口只要定好契约两边可以并行开发联调时间大幅缩短。第三Vue的响应式数据绑定、组件化开发做地图大屏、表格、表单这类管理界面非常顺。Element Plus的表格、表单、弹窗组件开箱即用能把大量开发时间省下来。整个系统我设计成四层结构展示层Vue 3 Vite Element Plus负责地图监控、数据大屏、设备管理界面。接入层Spring Boot提供的REST接口和WebSocket服务接收车辆轨迹上报、路侧设备状态心跳同时向前端推送实时数据。数据层MySQL存储业务数据Redis缓存信号灯状态和热点实时数据。通信层HTTP/HTTPS负责普通业务请求WebSocket长连接负责高频率的实时数据推送。这四层合在一起基本覆盖了一个车路协同业务系统的完整闭环。2. 数据库设计一张轨迹表引发的思考2.1 先确定要存哪些数据车路协同系统里数据结构大概分五类车辆信息车牌、车型、所属单位、联系方式这是基础主数据。路侧设备RSU设备编码、安装位置、经纬度、在线状态、最后心跳时间。车辆轨迹车辆的经纬度、速度、方向角、上报时间这是实时感知的原始数据。交通事件事故、拥堵、异常停车、施工占道等事件信息。信号灯状态路口设备编号、当前相位红灯/绿灯/黄灯、倒计时秒数、状态更新时间。明确了要存什么之后建表之前还有一个关键决策到底用不用空间数据库。MySQL本身就支持Geometry类型和空间索引但国内做地图业务的同学更习惯直接用double类型存经纬度原因有两个一是空间索引的查询语法比较冷门团队学习成本高二是很多Java代码在封装Geometry类型时容易出序列化问题。我这里选择了最简单直接的方式lng、lat两个double字段配合普通B树索引。数据量在百万级以下这种方案性能完全够用而且代码可读性更好。2.2 核心表设计细节车辆轨迹表是所有表里增长最快的设计时花了最多心思。基本结构如下CREATE TABLE vehicle_trajectory ( id BIGINT AUTO_INCREMENT PRIMARY KEY, vehicle_id BIGINT NOT NULL COMMENT 车辆ID, lng DECIMAL(10,6) NOT NULL COMMENT 经度, lat DECIMAL(10,6) NOT NULL COMMENT 纬度, speed DECIMAL(5,2) DEFAULT 0 COMMENT 瞬时速度 km/h, direction SMALLINT DEFAULT 0 COMMENT 方向角 0-359, create_time DATETIME NOT NULL, KEY idx_vehicle_time (vehicle_id, create_time) ) COMMENT 车辆轨迹表;我这里用DECIMAL存经纬度而不是double因为经纬度的精度直接关系到地图上点的位置。DECIMAL(10,6)能保证小数点后6位精度大约0.1米对于城市交通的展示和路况计算完全够用而且不会出现double类型在某些场景下的小数误差。车辆表和设备表的字段设计相对常规但有一个容易被新手忽略的问题设备在线状态。如果每次查询都一次性扫设备表效率不稳定。我当时的做法是增加一个online_status字段和一个last_heartbeat_time字段同时用Spring的定时任务每隔30秒扫一遍把心跳超时超过90秒的设备批量更新为离线状态。这个逻辑放数据库层面做也行但放后端做更灵活后面接真实设备时可以随时调整心跳阈值。2.3 数据增长估算与存储策略轨迹表的数据膨胀速度估计很多第一次做这类系统的同学没有概念。我算一笔账假设接入1万辆车每5秒上报一条轨迹那么一天的轨迹量就是10000×86400/5约1.728亿条。就算每条记录压缩到100字节一天也要17GB以上。这个量级MySQL单表是扛不住的查询会慢到不可用。所以这个系统在设计上报策略时做了两层控制演示环境默认每30秒上报一次车辆数量控制在几百到几千台方便在单机环境跑通。预留了分区表扩展方案按天做RANGE分区查询时自动裁剪到单日分区再配合索引就能在千万级数据下保持不错的查询性能。如果是生产环境建议直接把轨迹数据放到时序数据库比如TDengine或者用Kafka做缓冲再落库。但在毕业设计和课程项目这个层面MySQL加分区表是完全够用的选择。我的建议是可以拍胸脯把分区表写在文档里但本地跑的时候用普通表就够了避免分区表带来的SQL语法兼容问题。3. Spring Boot后端实时数据处理链路的实现3.1 设备数据上报接口交通感知的第一步是接收车端和路侧设备上报的数据。设备上报接口设计得是否健壮直接决定了后续所有功能的数据质量。我这里的核心接口是PostMapping(/api/v1/device/report) public ResultVoid report(RequestBody Valid DeviceReportDTO dto) { // 1. 设备鉴权 DeviceDevice device deviceService.checkAndGetDevice(dto.getDeviceCode(), dto.getToken()); // 2. 按设备类型分发处理 if (device.getType() DeviceType.RSU) { rsuService.handleRsuData(device.getId(), dto.getPayload()); } else if (device.getType() DeviceType.VEHICLE_OBU) { trajectoryService.saveTrajectory(device.getVehicleId(), dto.getPayload()); } // 3. 更新设备心跳时间 deviceService.updateHeartbeat(device.getId()); return Result.success(); }接口在鉴权之后按设备类型把业务分发到不同的处理服务里。车辆OBU上报的是轨迹数据RSU上报的则是感知范围内的车辆或者行人信息它们的处理逻辑完全不同。这里有一个很值得注意的细节设备上报接口的返回体设计。真实设备和服务器之间的连接经常不稳定设备端需要知道服务端到底有没有成功处理。我在这个接口里规定只有返回success时设备才会继续上报下一包否则设备端会做本地缓存并在下个周期重发。这样虽然让接口响应稍微重了一点但大幅提高了数据链路可靠性这个设计思路放在生产环境是标配。3.2 实时路况计算从轨迹到路况等级的转换路况不是直接上报来的而是后端根据一段时间的轨迹数据算出来的。实现思路是把地图路网按固定距离切分成路段每个路段统计当前窗口内的车辆平均速度再根据速度阈值划分畅通、缓行、拥堵。public RoadStatus calcRoadStatus(Long roadId) { // 查询最近5分钟内通过该路段的所有轨迹 ListTrajectory trajectories trajectoryMapper.selectRecent(roadId, 5, TimeUnit.MINUTES); // 过滤异常数据并计算平均速度 double avgSpeed trajectories.stream() .map(Trajectory::getSpeed) .filter(speed - speed 0 speed 150) .mapToDouble(Double::doubleValue) .average() .orElse(0); return RoadStatus.fromSpeed(avgSpeed); }注意我在代码里加了一个过滤条件速度大于0且小于150km/h。这个过滤非常重要因为设备上报的数据经常有噪声比如GPS漂移会把一辆静止的车坐标跳出去几十米产生一个瞬间80km/h的速度。如果不过滤一段拥堵的路可能因为两台漂移车辆被误判成畅通。3.3 WebSocket实时推送路况、车辆位置、信号灯状态这些数据如果每次变化都用前端轮询接口拉取效率和体验都很差。正确的方案是WebSocket长连接后端一旦有新数据就直接推给前端。我实现了两个WebSocket端点一个是设备端命令下发通道车路协同平台需要给RSU或OBU下发指令时使用。一个是前端监控大屏的数据通道推送路况更新、车辆位置、告警事件。前端的推送通道用的协议格式是JSON每个消息带type字段。比如typeroad_status时payload是路况数据typetrajectory时payload是轨迹点集合。前端收到消息后根据type分发给不同的渲染模块。这里有一个非常容易踩坑的技术细节WebSocket的session不是线程安全的。如果多个线程同时往同一个session发送消息会抛出IllegalStateException。我当时用一个ConcurrentHashMap管理所有前端连接同时在推送方法上加syncsynchronized锁确保每个session的任何时刻只有一个线程在发送问题才彻底解决。3.4 信号灯联动与特殊车辆优先信号灯联动是这个系统里最有车路协同味道的功能。逻辑并不复杂系统发现救护车、消防车这类特殊车辆接近路口时远端感知设备上报车辆类型、位置和速度后端计算出预计到达路口的时间然后调整信号灯相位。这个功能的代码核心是状态机和Redis锁public void processPriorityVehicle(PriorityVehicleRequest req) { String lockKey signal_lock: req.getIntersectionId(); boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 3, TimeUnit.SECONDS); if (!locked) { // 拿不到锁说明另一台优先车辆正在协调信号灯直接返回 return; } try { SignalPhase current signalService.getCurrentPhase(req.getIntersectionId()); int countdown signalService.getCountdown(req.getIntersectionId()); int estimatedArrivalSeconds estimateArriveTime(req.getLng(), req.getLat(), req.getSpeed()); if (estimatedArrivalSeconds countdown 5) { // 延长当前相位让优先车辆通过 signalService.extendPhase(req.getIntersectionId(), 10); } } finally { redisTemplate.delete(lockKey); } }用Redis的分布式锁主要解决并发问题两个方向同时来优先车辆信号灯只能被协调一次。刚开始做这个功能时没加锁结果测试时发现两辆交叉方向的救护车同时到达路口信号灯直接在两个相位之间疯狂跳把值班的同事都看傻了。4. Vue前端大屏可视化与实时渲染优化4.1 监控大屏与地图组件搭建前端最核心的画面是监控大屏。左边是实时路况统计中间是地图右边是设备在线率和告警列表。地图组件我用了高德地图JS API相比其他地图高德在浏览器端的文档和社区资料最齐全碰到问题搜索很容易找到答案。地图的封装有一个重要的细节坐标系转换。车辆上报的经纬度通常是GPS原始的WGS-84坐标系而国内地图用的是GCJ-02火星坐标系。如果不转换车辆位置在地图上会偏移几十米到几百米不等。高德的JS API提供了坐标转换工具但批量转换有量级限制所以我前后端各做了一层后端在转发轨迹数据的时候用高德坐标转换API完成批量转码前端只负责渲染。后端转一次前端所有页面共享转换结果效率高很多。地图上除了画车辆位置还要画路况颜色、信号灯状态、事件标记。路况线段我用高德的多边形覆盖物事件用Marker加信息窗体整块逻辑封装成一个MapView组件。页面其他部分只是定时收到WebSocket推送的数据再调用组件暴露出来的setData方法更新地图实现业务逻辑和UI渲染的解耦。4.2 实时车流渲染的性能优化刚开始测试时地图上同时渲染2000辆车的Marker页面直接掉到十几帧拖动地图卡得不行。优化的过程分了三步第一把普通Marker换成海量点组件AMap.MassMarks。海量点组件用Canvas渲染点一屏上千个点也能保持流畅。第二按当前可视范围过滤车辆。高德地图有bounds属性监听地图moveend事件只请求可视区域内的车辆数据超出范围的先不渲染。第三对轨迹点做抽稀。如果两辆车经纬度完全相同或者距离小于5米只保留一个点因为地图上根本看不出差别。这三步下来同样2000辆车的场景帧率恢复了60帧。大屏开发时这个性能问题几乎一定会遇到我建议在项目一开始就把海量点组件和范围过滤的代码写好不要等帧率掉下来再去补。ECharts图表部分相对简单。实时路况折线图每5秒接收一次WebSocket推送用setOption更新路口拥堵排行用横向柱状图。需要注意的是ECharts实例在组件销毁时要调用dispose方法否则Vue路由切换几次之后会报内存泄漏。4.3 视频监控接入m3u8播放的坑系统里还有一个视频监控页面用来查看看路侧摄像头的实时画面。摄像头输出的原始流基本都是RTSP协议但浏览器不能直接播放RTSP。标准做法是后端用FFmpeg把RTSP流转封装成HLS的m3u8切片前端再用video.js播放。前端播放m3u8比较简单在网上搜vue播放m3u8能搜到一堆现成代码核心就两步// 引入videojs-contrib-hls插件后 this.player videojs(this.$refs.videoPlayer, { autoplay: true, controls: true, sources: [{ src: http://192.168.1.100:8080/hls/camera_001.m3u8, type: application/x-mpegURL }] });实际项目中容易出问题的是两个点一是m3u8对应的.ts切片默认延迟有好几秒页面显示的画面会跟真实时间有明显滞后。如果项目对低延迟有要求单纯的HLS方案不够需要换成WebRTC。二是跨域问题。如果FFmpeg处理视频的服务和前端页面不在同一域名下m3u8请求会被浏览器拦截此时需要给视频服务加CORS响应头。4.4 前后端接口联调的细节联调阶段最烦人的是跨域配置。Spring Boot后端端口是8080Vue开发服务器是5173前端直接请求后端接口会被CORS拦截。我的解决方案分环境开发环境在Vite的vite.config.js里配置代理把/api前缀的请求转发到localhost:8080后端不需要额外配置就能工作。生产环境把Vue打包成静态文件由nginx统一承接页面和接口请求通过nginx的location配置转发到后端服务天然避免跨域。axios的封装也做了统一处理。所有请求注入token到header响应拦截器统一处理业务错误码。还有一个容易忽略的点后端返回的LocalDateTime如果默认序列化成ISO格式前端拿到是一段带T的字符串显示不太友好。我统一让后端Jackson配置全局时间格式为yyyy-MM-dd HH:mm:ss前端就不用每处都格式化时间了。5. 部署环境、联调与问题排查实录5.1 开发环境配置与启动顺序项目依赖的软件版本如下JDK 1.8、Maven 3.8、MySQL 8.0、Redis 5或以上、Node 16以上。第一次启动最好按这个顺序来先启动MySQL和Redis确认端口能被连接。再启动Spring Boot后端。配置文件里的数据库连接串、Redis连接配置要先改成本地地址。最后启动前端开发服务器。执行npm install时如果速度慢记得临时切一下国内镜像源。启动后端之后先检查控制台有没有报错。大部分数据库连接问题都会在启动阶段直接抛异常早发现早处理。5.2 常见问题速查表现象原因处理方法后端启动报连接数据库失败MySQL没启动或连接串参数少启动MySQL检查url、用户名、密码查询到的日期比实际时间晚8小时MySQL连接串没指定serverTimezoneurl参数加serverTimezoneAsia/Shanghai前端请求接口报CORS错误开发环境没配代理在vite.config.js配置proxy地图上的车辆位置偏移马路对面偏了几十米WGS-84和GCJ-02坐标系混用后端统一调用坐标转换服务再推送WebSocket能连上但推送异常断开session被多线程并发写推送机加锁session用ConcurrentHashMap管理大屏上千辆车拖动卡成幻灯片普通Marker渲染开销太大改用AMap.MassMarks按可视范围过滤m3u8视频画面或黑屏跨域或被防盗链拦截给视频服务加CORS头检查Referer如果数据库用的是MySQL 8.0JDBC驱动版本要注意和Spring Boot 2.7.x匹配。直接用mysql-connector-java的5.1.49版本容易报tinyInt类型转换异常我推荐用mysql-connector-j的8.0.x版本两者在pom里的groupId和artifactId不一样别抄错。5.3 服务器部署部署到服务器时Spring Boot项目打成可执行jar包即可用Maven执行package。Vue项目执行npm run build产物在dist目录用nginx托管。需要提醒的是Spring Boot如果也想用打包的方式在服务器上跑后端服务里有上传文件或者读取本地路径的功能要注意jar包目录和配置文件路径的关系。我当时写了一个Dockerfile来固化部署环境基础镜像用的是eclipse-temurin:8-jre。如果服务器上还没有Docker也可以直接用systemd管理java -jar进程两条路都能走通只是Docker在环境一致性上更省心。还有一个部署细节轨迹数据在有外网地址的服务器上运行后地图上看到的坐标和本地联调时并不是同一套。原因是高德地图GCJ-02坐标在国内和海外服务有差异部署到海外服务器上时坐标转换直接用了高德海外接口返回的坐标可能和国内地图不匹配。这个问题跟服务器所在区域强相关不在本次讨论范围但真遇到时要能想到是坐标服务在作怪。6. 如果后面要接真实设备你需要提前知道的事这个项目虽然是演示性质但你会发现它的接口设计已经按生产逻辑来做了。如果后续真要接真实的路侧设备有几个经验值得提前说第一是设备协议不统一。不同厂商的RSU接口报文格式千奇百怪有的用JSON有的用Protobuf有的甚至有私有二进制协议。建议项目里把设备消息解析层独立出来每接一个厂商就写一个Adapter适配器不要把所有解析逻辑都堆在Controller里。第二是设备上报频率远比演示环境高。真实路侧摄像头的感知结果每秒钟能爆出几十条目标数据车端OBU的上报频率也远比我演示环境里的30秒一次高。这种量级下Kafka或类似的消息队列基本是必需品后端服务不要直接面对突发的报表流量。第三是设备和平台之间的安全认证。演示系统里可以只用一个token生产环境必须有双向认证、消息签名防篡改。车路协同直接关系到行车安全数据被篡改的后果非常严重。第四是设备的离线容错。路侧设备经常因为断电、网络故障掉线平台要能快速感知设备离线并且把离线期间的感知数据做缓存或者标记异常。平台的风控意识某种程度上比功能多寡更重要。最后再分享一个小技巧做这类系统时一定要把每个模块之间的数据契约固定下来再动手写代码。比如车辆轨迹上报JSON的字段命名是camelCase还是snake_case经纬度字段是lng还是longitude这些细节如果一开始不统一前后端联调时来回改JSON格式一晚的时间就搭进去了。我这次项目过程中前20%的时间都花在定义接口契约和数据库表结构上后80%的开发基本没返过工这个时间分配非常划算。