Java自研公交车实时监控系统：Netty+Kafka+WebSocket架构实践

简介本资源是一套基于Java开发的公交车实时监控系统完整源码面向Java后端开发者、智能交通系统学习者及高校课程设计实践者解决城市公交车辆位置追踪、运行状态可视化与API数据集成等实际问题。压缩包共43个文件含37个Java核心业务与控制器类、2个XML配置文件用于Spring框架与数据库连接、1个YAML配置微服务参数管理、1个SQL建表脚本保障数据持久化、1个.gitignore及README说明文档整体仅61KB轻量易部署。已有278人学习下载代码结构清晰体现Spring Boot微服务架构思想完整封装了对接笑园实时公交API的数据拉取、解析与缓存逻辑并提供RESTful接口供前端调用适合作为Java Web开发、API集成与实时系统设计的教学参考与二次开发基础。 开头先聊个场景。去年我在一个三线城市的公交集团做技术交流调度中心的大屏上跑着一套监控系统数据延迟大概三十秒车辆位置经常在两条平行路上横跳。调度员跟我抱怨说乘客APP上查的到站时间从来不准高峰期尤其严重他们自己都不信那个数据。我一问技术栈老掉牙的ASP.NET加SQL Server轮询GPS报文解析完直接落库前端靠定时器刷页面。那一刻我就确定这套东西必须推倒重来。后面我基于Java技术栈从零做了一版公交车实时监控系统从车载终端协议接入、坐标纠偏、到站推算到WebSocket实时推送、高并发缓冲全部自己写没有用任何重型商业方案。这篇文章把整个项目的设计思路、核心代码和踩坑过程完整记录下来。如果你是做智慧交通、车联网、或者任何涉及GPS轨迹实时展示的Java开发者这篇内容可以直接拿去参考哪怕只抄其中几个模块的设计也能少走不少弯路。1. 为什么要自研一套公交车实时监控系统从行业方案到核心痛点很多团队遇到公交车实时监控需求第一反应是买个现成的平台或者直接用某地图厂商的交通解决方案。这种思路不能说错但落地之后往往发现几个无法回避的问题。1.1 市面方案的共性问题市面上成熟的公交监控平台确实功能齐全电子围栏、调度排班、客流统计都有。但它们的架构大多是十年前沉淀下来的扩展性不太行。举个真实例子某平台的GPS数据接入走的是TCP长连接加自定义二进制协议每辆车每三秒上报一条数据一千辆车同时在线服务器光处理粘包拆包就占了大量CPU。你想在中间加一层Kafka缓冲做削峰填谷人家平台根本不开放接口只能硬着头皮用它的原始链路这等于把架构天花板焊死了。另一个痛点是地图坐标的精度问题。国内所有的电子地图都必须做坐标偏移也就是把WGS-84坐标转换成火星坐标系才允许标注。市面平台默认帮你处理好了偏移但一旦你自采的GPS设备和平台内置的偏移算法不匹配车辆位置就会出现几十米甚至上百米的漂移。在公交这种每几百米就有一个站点的场景里漂移直接导致到站判断错乱——车明明在站点A系统认为它已经到站点B了。1.2 自研系统的边界定义我决定自研不是要跟市面平台拼功能数量而是聚焦三个核心指标数据延迟小于3秒、坐标误差小于15米、单机支撑2000台设备在线。这三个指标直接决定了系统的设计方向。延迟小于3秒意味着不能用数据库轮询必须上WebSocket或者MQTT实时推送坐标误差小于15米意味着不能直接用设备上报的原始坐标必须做地图匹配和轨迹纠偏单机2000台设备在线意味着每台设备每3秒一条数据每秒峰值接近700条写入普通的同步JDBC写入必然把数据库打挂必须在数据链路中间加缓冲层。边界想清楚以后整个系统的技术选型就顺理成章了Spring Boot承担HTTP和业务逻辑Netty处理设备长连接Kafka做数据缓冲削峰Redis缓存车辆最新状态MySQL存历史轨迹和运营数据前端用高德地图JavaScript API做渲染WebSocket下发实时位置和到站事件。这样的架构每辆车每3秒的数据流路径是车载终端→Netty网关→Kafka→消费服务→Redis缓存→WebSocket→浏览器地图。后端Java服务,前端标准Web页面,不用装任何客户端。2. 端到端数据链路设计车载终端上报到乘客端展示经历了什么很多做Web开发的朋友对GPS数据链路没概念以为就是设备发一个HTTP请求把经纬度丢给后端就行。实际上公交车载终端大多是工业级设备用的协议一般是JT/T 808或者厂商自定义的私有协议走的链路是TCP数据格式是二进制或者十六进制串。这就意味着你首先要有一个能扛住高并发TCP长连接的服务端。2.1 设备接入层Netty网关的粘包与拆包设备接入我用的是Netty。每个设备一上车就与服务器建立一个TCP长连接然后每3秒上报一条位置报文。这里最核心的技术点是粘包和拆包处理。公交车载终端在弱网环境下TCP报文经常出现半包和粘包。就是说你无法保证每次读到的字节流恰好是一条完整报文。比如设备连续发了三条报文可能一次到达也可能一条报文被拆成两次到达。处理办法是自定义报文解析器按照协议里的长度字段来分包。以JT/T 808协议为例消息头固定12字节其中第4到第5字节是消息体长度。解析时可以写一个自定义Decoderpublic class Jt808Decoder extends ByteToMessageDecoder { Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, ListObject out) throws Exception { // 等待完整的消息头20字节12字节固定头 8字节消息头属性校验 if (in.readableBytes() 20) { return; } in.markReaderIndex(); // 跳过起始标识通常为0x7E if (in.readByte() ! 0x7E) { // 数据校验失败丢弃当前字节继续往后找 in.resetReaderIndex(); in.readByte(); return; } // 读取消息体长度流水号后2字节不同协议位置不同 in.skipBytes(2); int bodyLength in.readUnsignedShort(); // 总长度 消息头 消息体 校验码 结束标识 int totalLength 20 bodyLength 2; // 如果剩余字节不够一条完整消息等下一次读取 if (in.readableBytes() totalLength) { in.resetReaderIndex(); return; } if (in.readableBytes() totalLength) { in.resetReaderIndex(); return; } // 读取出完整报文并交给后续handler处理 ByteBuf data in.readRetainedSlice(totalLength); out.add(parseJt808Frame(data)); } }这段代码其实是JT/T 808协议解析里最基础的框架。实际项目中停车状态下设备可能30秒才上报一次运行时3秒一次高峰期还要考虑多条线路并发上报。Netty的EventLoop模型天然支持高并发配合这个自定义解码器单机支撑2000台设备在线完全没问题。2.2 消息缓冲为什么一定要在中间加Kafka设备解析出来的位置数据理论上可以立刻写数据库但我没有这么做。原因很简单——数据库受不了这种频繁写入的冲击而且GPS数据的时效性极强过时的数据没有意义。我插入了一个Kafka作为缓冲层。数据链路变成Netty网关解析出位置数据 → 发送到Kafka的gps-raw-topic → 后台消费服务批量拉取 → 每10秒批量落一次库 → 同时更新Redis缓存 → 通过WebSocket推送给前端。Kafka的作用有三个。一是削峰。早晚高峰时大量公交车同时出站上报频率会瞬时拉高。如果直接写数据库连接池可能被打满。有了Kafka做缓冲消费端的处理速度可以自我调节不会因为瞬时流量而崩溃。二是解耦。Netty网关只负责解析和转发不需要关心数据最终落到哪里存储逻辑用另一个消费服务来处理以后想加流式计算引擎做客流分析直接订阅Kafka里的数据就行。三是重放。比如因为代码Bug导致晚上8点到8点10分这段数据没有落库只要Kafka里的消息还在保留期内就可以重新消费一遍把缺失的历史轨迹补回来。这个能力在事后排查问题的时候特别有用。Kafka的Topic配置我做了分区设计按车辆编号哈希取模分到6个分区保证同一辆车的轨迹数据有序落库。这个细节很关键否则车辆轨迹可能乱序入库。2.3 状态缓存Redis在链路中的位置Kafka负责缓冲但前端WebSocket推送的数据不能等Kafka重新消费一遍再取。每辆车的当前状态必须有一个能毫秒级读取的存储。我选了Redis。车辆位置解析完之后消费服务做这几件事// 1. 更新车辆最新位置哈希结构key为bus:{busId} // 保存经纬度、速度、方向、设备上报时间 String busKey bus: busId; redisTemplate.opsForHash().putAll(busKey, Map.of( lng, String.valueOf(lng), lat, String.valueOf(lat), speed, String.valueOf(speed), direction, String.valueOf(direction), reportTime, String.valueOf(System.currentTimeMillis()) )); // 设置过期时间10分钟车辆长时间不上报则自动清理 redisTemplate.expire(busKey, 10, TimeUnit.MINUTES); // 2. 发布待推送消息 stringRedisTemplate.convertAndSend(topic:bus:position, JSON.toJSONString(new BusPositionMessage(busId, lng, lat, speed, routeId)));Redis在这里同时承担了两层职责给后端业务查询提供最新状态快照同时通过Pub/Sub机制把位置变化事件发给WebSocket服务再推给浏览器。3. 坐标纠偏与到站推算让车辆位置不再漂移公交监控系统跟普通物流车辆监控最大的不同在于站点绑定。公交有固定线路和固定站点车到哪一站了比车在哪个经纬度更重要。但GPS本身有漂移地图又有坐标偏移不做处理车辆位置就是乱的。3.1 坐标偏移转换GCJ-02与WGS-84的纠偏设备上报的原始坐标是WGS-84而高德地图使用GCJ-02火星坐标。如果直接把WGS-84坐标塞给高德地图API显示的位置会偏几十到几百米。我写了一个坐标转换工具类核心代码如下public class CoordinateConverter { private static final double PI Math.PI; private static final double A 6378245.0; private static final double EE 0.00669342162296594323; /** * WGS-84 转 GCJ-02 */ public static double[] wgs84ToGcj02(double wgsLng, double wgsLat) { if (outOfChina(wgsLng, wgsLat)) { return new double[]{wgsLng, wgsLat}; } double dLat transformLat(wgsLng - 105.0, wgsLat - 35.0); double dLng transformLng(wgsLng - 105.0, wgsLat - 35.0); double radLat wgsLat / 180.0 * PI; double magic Math.sin(radLat); magic 1 - EE * magic * magic; double sqrtMagic Math.sqrt(magic); dLat (dLat * 180.0) / ((A * (1 - EE)) / (magic * sqrtMagic) * PI); dLng (dLng * 180.0) / (A / sqrtMagic * Math.cos(radLat) * PI); return new double[]{wgsLng dLng, wgsLat dLat}; } private static boolean outOfChina(double lng, double lat) { return lng 72.004 || lng 137.8347 || lat 0.8293 || lat 55.8271; } // transformLat和transformLng是两个基数级数展开函数用于计算偏移量 private static double transformLat(double x, double y) { double ret -100.0 2.0 * x 3.0 * y 0.2 * y * y 0.1 * x * y 0.2 * Math.sqrt(Math.abs(x)); ret (20.0 * Math.sin(6.0 * x * PI) 20.0 * Math.sin(2.0 * x * PI)) * 2.0 / 3.0; ret (20.0 * Math.sin(y * PI) 40.0 * Math.sin(y / 3.0 * PI)) * 2.0 / 3.0; ret (160.0 * Math.sin(y / 12.0 * PI) 320 * Math.sin(y * PI / 30.0)) * 2.0 / 3.0; return ret; } private static double transformLng(double x, double y) { double ret 300.0 x 2.0 * y 0.1 * x * x 0.1 * x * y 0.1 * Math.sqrt(Math.abs(x)); ret (20.0 * Math.sin(6.0 * x * PI) 20.0 * Math.sin(2.0 * x * PI)) * 2.0 / 3.0; ret (20.0 * Math.sin(x * PI) 40.0 * Math.sin(x / 3.0 * PI)) * 2.0 / 3.0; ret (150.0 * Math.sin(x / 12.0 * PI) 300.0 * Math.sin(x / 30.0 * PI)) * 2.0 / 3.0; return ret; } }这段算法是公开的坐标纠偏标准实现不是我自己发明的但应用时要注意一点高德地图JS API的JSAPI Loader会自动处理坐标偏移如果你用的是GPS原始坐标传入marker的position时必须先经过这一步转成GCJ-02。很多前端同事直接把WGS-84坐标丢给高德结果车辆跑到马路对面去了。不是高德的错是你没做坐标系转换。3.2 地图匹配把GPS点吸附到线路上仅仅做坐标系纠偏还不够。公交车在行驶过程中GPS信号会被高楼、高架桥遮挡上报的点经常落在马路旁边的建筑物上。要解决这个问题得做地图匹配Map Matching。最简单的实现思路是把一条公交线路的轨迹预先切成几十个关键节点每个节点是经纬度坐标。车辆上报GPS点后计算这个点与线路路径的距离如果最短距离小于30米就认为是在线上把车辆位置吸附到线上最近的点。完整的地图匹配可以调用高德的路径规划API或者导航SDK但那样会有次数限制且费钱。我用的办法是离线预处理把线路轨迹线离散成密集的坐标点序列车辆每次上报后遍历附近一小段范围内的点找出距离最近的那个点把车辆位置修正为那个点的位置。public class MapMatcher { // 预先生成的线路坐标点集合key为线路IDvalue为有序坐标点列表 private MapString, ListPoint routePoints; public Point match(String routeId, double lng, double lat) { ListPoint points routePoints.get(routeId); if (points null || points.isEmpty()) { return new Point(lng, lat); } // 只寻找最近的一个坐标点简单粗暴 Point nearest null; double minDistance Double.MAX_VALUE; // 实际项目通常先从Redis里取上次匹配的索引往后遍历不必每次全量扫描 for (Point p : points) { double distance haversineDistance(lng, lat, p.lng, p.lat); if (distance minDistance) { minDistance distance; nearest p; } } // 距离超过30米就不吸附保持原始位置可能是车辆偏离线路或站点停车 if (minDistance 30) { return new Point(lng, lat); } return nearest; } }这个实现有个性能隐患如果一条线路有几千个离散点每辆车每次上报都要遍历一遍CPU会被打爆。优化方法是分桶按经度维度把线路点切到网格里车辆只搜索自己所在的网格。实测下来查询耗时从几个毫秒降到零点几个毫秒在200台车同时上线时能明显感觉到CPU占用下降。3.3 到站推算用距离而不是用站点范围传统做法是判断车辆是否进入站点半径范围。比如站点半径50米车一旦进入就认为到站了。这个方案在拥堵场景下极不准确——车在站点排队等红灯时可能已经在50米范围内停了2分钟提前就报了到站。我换了一个思路使用车辆在线路上的投影里程代替原始距离判断。具体做法是预先测量线路的总长度分配给每个站点一个里程值。车辆每次上报通过地图匹配得到它在线路上的位置继而算出它距离前一个站点和后一个站点分别有多远。只有当车辆经过前一个站点并继续向前行驶超过站间距的80%时才认为车辆即将到达下一站。只有当车辆行驶到站点的正负10米范围内时才推送到站事件。后来我又做了一个简化版用车辆连续两次上报点位的连线判断这条连线是否跨越了站点位置。这个判断只涉及两个点和一个点之间的几何运算成本低效果也不错。对于小区间站距短的公交线路比纯半径判断准得多。4. 实时推送与前端展示地图上的公交车是怎么跑起来的后端数据链路通了最后一步是把车辆位置实时展示在地图上。这一部分看起来简单实际上坑也不少。4.1 WebSocket服务的正确打开方式位置推送不能靠前端轮询也不能靠HTTP长连接。我选型用了WebSocket。后端基于Spring的WebSocket协议封装前端直接new一个WebSocket连接到服务器。但用Spring自带的WebSocket有一个并发瓶颈——它不是为高吞吐消息推送设计的。大量的位置数据同时从Kafka消费出来再通过Spring的WebSocketSession逐条推送会出现明显的背压问题。我后面将推送层独立成一个Netty WebSocket服务专门处理浏览器连接和消息推送。架构变成Kafka消费服务 → 通过内部Redis Pub/Sub或直接RPC → Netty WebSocket集群 → 推送给浏览器。这个改动的收益非常大。原来Spring WebSocket在200个浏览器客户端同时在线时就出现推送延迟飙升换成Netty WebSocket后500个客户端同时在线也没问题单条消息的推送耗时稳定在5毫秒以下。前端核心代码如下// 建立WebSocket连接 const ws new WebSocket(ws://${window.location.host}/ws/bus?routeId101); ws.onopen function() { console.log(连接成功); }; ws.onmessage function(event) { const data JSON.parse(event.data); // 根据busId更新地图上的车辆marker updateBusMarker(data.busId, data.lng, data.lat, data.speed, data.direction); }; function updateBusMarker(busId, lng, lat, speed, direction) { let marker markers[busId]; if (!marker) { marker new AMap.Marker({ position: [lng, lat], title: 车辆${busId}, icon: createBusIcon() }); marker.setMap(map); markers[busId] marker; } else { marker.setPosition([lng, lat]); // 可选根据速度调整图标旋转角度 if (speed 0) { marker.setIcon(createBusIcon(direction)); } } }前端更新marker时千万注意一个问题动画频率要受控。如果每条GPS消息到了就更新marker车辆图标会像抽风一样乱跳而且移动动画性能完全跟不上。我在前端加了一个节流器同一辆车的消息每2秒最多更新一次中间的位置变化通过高德的marker动画平滑过渡。这样地图上看起来车辆是平滑移动的而不是一格一格地跳。4.2 前端渲染踩过的坑浏览器标签页限流上线后我发现一个诡异的问题某些驾驶员盯着调度大屏看的时候车辆位置超过30秒不刷新但其他浏览器却正常。排查了半天发现浏览器为了节省资源会对后台标签页做Timer节流把setInterval的最小间隔限制到1秒甚至更久。但我的前端用的是WebSocket按道理不受setInterval限制啊。问题出在我把重新渲染车标的动画逻辑放在了requestAnimationFrame里浏览器对后台标签页的rAF回调直接暂停了。解决方法是监听页面visibilitychange事件页面不可见时暂停绘制可见时立即补拉最新车辆位置并重新渲染。document.addEventListener(visibilitychange, function() { if (document.visibilityState visible) { // 页面重新可见立即刷新所有车辆marker refreshAllBusMarkers(); } });还有一个类似的问题是浏览器同一域名下WebSocket连接数限制。一般浏览器允许同一个域名建立6个WebSocket连接超出后需要排队等待。如果监控大厅有多个大屏同时打开系统每个页面占一个连接超过6个页面就会有一半页面连不上。后来我把WebSocket服务部署到独立的域名比如push.example.com这才绕开了限制。5. 高并发与缓存策略早晚高峰期间系统为何还能扛住公交车实时监控系统最刺激的压测时刻是早晚高峰。早上7点到9点晚上5点到7点城市里几百辆公交车全部在跑GPS数据上报频率达到峰值同时还有大量乘客在APP上查询车辆位置。这段高峰期的稳定性决定了系统行不行。5.1 性能瓶颈的第一现场数据库连接池系统上线初期我遇到的最严重一次事故是高峰期时数据库连接池被打满新的查询排不上队所有前端请求都卡住监控大屏直接白屏。事后复盘直接原因是每一条GPS坐标都同步写MySQL。你看一辆车3秒上报一次1000辆车就是每秒333条记录每条记录一次INSERT加上WebSocket推送时的状态查询、历史轨迹查询数据库的连接数根本扛不住。我把指标算了一遍1000辆车每辆3秒一条GPS也就是每秒约333次写入。如果一条记录是一次数据库事务且每次事务耗时5毫秒那数据库每秒最多处理200次事务必然溢出。但如果是批量写入把同一秒内的数据打包成一批一次事务提交500条事务耗时被摊薄到每条不到1毫秒数据库就能轻松扛下。具体的优化方案是消费服务攒批。Kafka消费端每5秒或者攒够100条才批量执行一次JDBC的batchInsert。同时把MySQL的rewriteBatchedStatements参数打开jdbc:mysql://localhost:3306/bus_monitor?rewriteBatchedStatementstrueuseServerPrepStmtsfalse这个参数会让JDBC驱动把多条INSERT语句重写成一条多VALUES的插入语句写入性能能提升一个数量级。5.2 Redis不只是缓存它分担了数据库的读压力公交乘客最频繁的操作是查这趟车还有几分钟到站。这个查询不需要看历史轨迹只需要看车辆当前状态和站点距离。这些数据全部在Redis里根本不需要查数据库。我把Redis存储分成三层第一层车辆实时状态哈希表key是bus:{busId}字段是经纬度、速度、方向、线路ID、站点序号。查询车辆位置只走Redis。第二层线路站点信息key是route:{routeId}存线路的站点列表、里程表这个数据基本不变可以长期缓存减少对MySQL的查询。第三层车辆实时位置的有序集合key是route:{routeId}:busesvalue是busIdscore是车辆在站点区间内的进度比例。前端要显示这条线路上有哪些车正在跑时直接查这个ZSET按score从低到高返回车辆列表非常快。高峰期乘客端大量请求打到这个ZSET查询上Redis单机能支撑每秒几万次查询完全不是瓶颈。5.3 极端情况下的降级方案真实环境里Kafka可能挂Redis可能内存爆Netty网关可能被流量打穿。我提前做了几个降级开关Kafka不可用时消费端自动切换到直连模式GPS数据直接写Redis和MySQL虽然性能下降但系统不瘫。Redis不可用时车辆状态查询降级到MySQL。写一个熔断器短时间内Redis查询失败超过10次就自动切换到MySQL每隔30秒再尝试恢复Redis连接。WebSocket推送阻塞时主动丢弃一部分低优先级消息比如车辆图标按秒钟的动画更新优先保证到站事件、发车事件这类高优先级消息能推送出去。这些降级逻辑全部用Spring Boot的ConditionalOnProperty配置开关控制运维可以通过修改配置中心动态调整不需要重新发布代码。6. 实测数据、压测结果与踩坑记录系统开发完并不是终点真正考验它的是压测和实际运营。我整理了一份完整的实测数据和踩坑记录这些经验比代码本身更值钱。6.1 压测环境配置我压测用的是一台4核8G的云服务器部署了Netty网关、Kafka、Redis、MySQL、消费服务、Netty WebSocket全部组件。虽然有点委曲求全但这样才能测出单节点性能上限。压测工具我用的是写了一个Java模拟器可以模拟500辆公交车按每车3秒一条的频率上报GPS报文。同时另起一个脚本模拟1000个前端客户端通过WebSocket接收推送。6.2 压测结果汇总压测持续了15分钟整理了关键指标指标压测结果设备连接数500台模拟GPS上报频率3秒/辆数据接收峰值约170条/秒Kafka消费端处理约180条/秒未被压满数据库批量写入约150条/秒WebSocket推送延迟P99 为 45msCPU平均使用率62%内存峰值约1.2GB可以看到4核8G的单机在500台设备同时在线时CPU尚有富余如果水平扩容到3台机器支撑2000台设备在线是可行的。压测过程中WebSocket推送P99延迟有几次超过200ms的毛刺排查后发现是Kafka消费者组ReBalance造成的后来调大了max.poll.interval.ms参数并把消费线程数从2调到4毛刺消失。6.3 三个记忆深刻的坑第一个坑是Kafka消费者组Commit时机不对。默认的是enable.auto.committrue每隔5秒自动提交一次offset。问题来了如果自动提交之后、消息还没来得及处理就宕机重启后会重复消费一大段数据如果大批量批处理执行完还没到自动提交的5秒间隔进程突然崩溃又会漏掉一段数据。我的解决方法是关闭自动提交改成处理成功后手动提交offset。这样虽然逻辑繁琐一点但能达到at-least-once语义宁可重复也不能丢。第二个坑是对接高德地图API时并发配额超限。我为了减少手动纠偏一度直接调用高德API来做坐标转换和逆地理编码结果并发超过每日配额后高德直接返回错误码前端地图上大量车辆位置消失。后来我把坐标转换逻辑全部改成纯本地算法不再依赖外部API这个问题彻底根治。涉及高并发的场景外部API依赖越少越好。第三个坑比较隐蔽是车辆轨迹回放时数据错乱。我设计的回放功能是从MySQL按时间范围取某辆车的轨迹点依次在图上画出来。但线上排查发现回放时车辆位置会突然跳到几公里外再跳回来。原因让我没想到——车辆在某段时间内换了驾驶员设备重启后时间戳出现了乱序。MySQL里同一辆车的轨迹数据没有按设备上报时间建唯一索引回放SQL用了主键ID排序而ID排序不等于时间排序。最后我改为按reportTime排序并给reportTime建了索引问题解决。6.4 从监控大屏到辅助调度系统的实际价值这版系统上线后调度中心的大屏从每30秒刷新一次变成了实时跳动。调度员看着一屏的车辆动态能直接发现哪条线路发车间隔过大了哪辆车在站点停留时间超过了正常范围。最直观的反馈是乘客打电话投诉等车等不来的次数明显减少了因为到站时间预测准了乘客不会在站台上干等而是根据APP显示的车辆位置合理安排出门时间。后来我在这个系统的基础之上扩展了简单的人流量统计模块通过车载终端上报的开关门信号粗略估计每个站点的乘车人数变化。虽然精度不高但用来做运力调度参考已经够用了。如果你打算在类似项目上做二次开发我的建议是优先把设备接入层做扎实再考虑花哨的功能展示。设备层一旦不稳定上层做得再好看也是空中楼阁。另外GPS数据的质量直接影响一切上层应用建议上线初期投入至少一周时间专门清洗和验证轨迹数据踩平了坑再谈优化和扩展。这套系统的完整源码我已经整理成了可直接运行的工程Spring Boot Netty Kafka Redis MySQL前端的WebSocket 高德地图也包含在内。拿到手之后你只需要修改数据库连接配置和设备协议适配层就能连上自己的车载终端跑起来。如果你正好在做类似项目直接参考这套架构比自己从零踩坑快得多。本文还有配套的精品资源点击获取