企业官网建设流程全解析

背景

代驾系统最核心的技术难点是“实时性”：用户下单后要秒级通知附近司机，司机行程中位置要实时同步给管理平台。传统 HTTP 轮询延迟高、耗资源，这套开源代驾系统选择了 Netty WebSocket 长连接方案，本文拆解它的实现思路。

源码地址（Gitee）：
https://gitee.com/zhoujian6666/biaoma-ride-car-service

整体架构

系统包含两个 API 服务：管理端 API（后台管理）和用户端 API（用户与司机业务）。Netty 服务端内嵌在用户端 API 中，司机端 App 和用户端通过 WebSocket 与之保持长连接。

消息流转：用户下单 → 业务服务写库 → 通过 RabbitMQ 通知推送链路 → Netty 通道定向推送给附近司机 → 司机抢单 → 推送结果给用户端。

为什么用 Netty 而不是 Servlet 容器的 WebSocket

• 单机需要支撑上千司机同时在线，NIO 模型资源占用远低于“一连接一线程”模型
• 心跳、断线重连、编解码都可定制
• 推送能力与业务服务解耦，可独立扩容

核心实现要点

1. 连接管理：司机端登录后建立 WebSocket 连接，服务端用 ConcurrentHashMap 维护“司机 ID 到 Channel”的映射，连接断开自动清理
2. 心跳机制：IdleStateHandler 检测空闲连接，客户端定时发心跳包，防止 NAT 超时断连
3. 定向推送：派单时按地理位置筛选附近司机，从连接表取出对应 Channel 批量写入订单消息
4. 位置上报：司机端每隔数秒通过 WebSocket 上报 GPS 坐标，写入 Redis 供派单筛选和后台实时地图展示
5. 消息可靠：派单、取消等关键消息配合 RabbitMQ 做异步确认，推送失败可补偿

管理后台的实时视图

后台首页的“司机在线视图”数据同样来自这条链路：Redis 中的在线司机与位置数据，配合 ECharts 可视化，运营可以实时看到城市运力分布。

项目其他模块

除实时推送外，系统还包含完整业务闭环：智能派单、计价引擎（起步价 + 里程费 + 时长费 + 夜间溢价）、微信与支付宝支付、订单分润、财务对账。后端 + 管理后台 + 数据库脚本已开源（Java 17 + Spring Boot 2.7 + Vue），可直接部署。

Gitee：https://gitee.com/zhoujian6666/biaoma-ride-car-service

用户端小程序可在仓库 README 扫码体验。觉得有用欢迎 Star，也欢迎评论区交流实时推送相关的技术问题。