网约车项目实战：online-taxi-public源码解析与派单系统搭建

简介这份资源是飞滴网约车项目 online-taxi-public 的完整源码包面向希望深入理解网约车平台架构的 Java 开发者与学习者。项目围绕在线打车核心业务展开涵盖用户注册登录、位置定位与地图集成、车辆与司机管理、订单匹配与计费、支付结算、异常处理及安全合规等模块适合研究分布式系统、高并发与实时数据处理的中高级开发者参考。压缩包共 163 个文件以 132 个 Java 源码为主体辅以 19 个 XML 配置、9 个 YML 配置文件及少量说明文档整体约 137KB目录结构清晰便于按业务模块检索。已有 689 人学习下载。通过阅读源码读者可掌握订单状态流转、司机匹配算法、计费规则与验证码服务等具体实现理解服务分层与接口定义方式并借鉴其数据库模型与业务逻辑组织思路为构建类似平台或参与相关项目提供可复用的参考。1. 从一份网约车源码包说起online-taxi-public.zip 到底能跑出什么如果你正在找一个能完整跑通「乘客下单 → 司机接单 → 行程计费 → 订单结算」全链路的练手项目online-taxi-public.zip大概率会出现在你的候选清单里。它是一套网约车业务的后端源码包覆盖了订单、派单、计价、司机管理、乘客端接口等核心模块适合想从 CRUD 项目跳到「有状态、有并发、有实时交互」场景的后端开发者。我拿到这份包的第一反应不是急着跑而是先看目录结构和依赖清单——因为网约车这类项目最容易翻车的地方从来不是业务逻辑写不出来而是环境跑不起来、模块之间对不上。这份源码的价值在于它把「一个订单从创建到完成」的完整状态流转摊开给你看而不是只给你一个孤立的接口 demo。适合谁适合已经会写 Spring Boot 单体、想理解分布式派单和状态机设计的同学也适合需要一份可改造的业务底座来做二次开发的人。2. 拆包先看骨架模块划分与依赖关系怎么理2.1 目录结构里藏着架构意图解压之后别急着mvn install先花十分钟把顶层目录过一遍。常见的网约车后端源码包顶层一般会按职责切成几个独立模块比如taxi-common公共工具与常量、taxi-order订单服务、taxi-driver司机服务、taxi-passenger乘客服务、taxi-gateway网关入口。这个切法不是随便分的它对应的是「谁在什么时机调用谁」的问题。订单服务是核心它要同时被乘客端和司机端触发司机服务管的是司机状态和车辆信息网关负责鉴权和路由转发。我一般会先画一张调用关系草图纸上画就行不用工具确认三件事订单创建走哪个入口、派单逻辑落在哪个模块、计价规则是独立服务还是嵌在订单里。这三件事决定了你后面调试时该盯哪个日志文件。如果目录里还有taxi-schedule或taxi-dispatch这类命名那派单大概率是独立模块调试时要单独起。提示不同版本的包目录名可能不一样但职责划分逻辑是相通的。看到-api结尾的通常是接口定义-service结尾的是实现别搞反依赖方向。2.2 依赖版本对齐是第一步硬仗网约车项目常见的依赖组合是 Spring Boot MyBatis-Plus Redis MySQL RabbitMQ或 RocketMQ。版本不对齐是新手最容易卡住的地方。比如 Spring Boot 2.7 配 MyBatis-Plus 3.5.2 是稳的但如果你本地 JDK 是 17 而项目写的是 1.8编译期就会报一堆module相关错误。先看根pom.xml里的properties段把 JDK 版本、Spring Boot 版本、MyBatis-Plus 版本记下来。然后检查你本地的环境# 确认 JDK 版本项目要求 1.8 就别用 17 硬跑 java -version # 确认 Maven 版本建议 3.6 mvn -v # 确认 MySQL 和 Redis 是否在跑 mysql --version redis-cli ping逻辑说明java -version看的是编译和运行的基础环境网约车这类老项目很多还锁在 JDK 8mvn -v确认构建工具没太旧redis-cli ping返回PONG才说明 Redis 通了因为派单和司机状态缓存强依赖 Redis。参数上没什么可调的重点是「版本匹配」——JDK 不匹配就换 JDK别想着改项目源码去适配那是给自己挖坑。2.3 数据库脚本先跑通再谈业务源码包里一般会带一个sql目录里面是建库建表语句和初始数据。我习惯先把库建好、数据灌进去再启动服务。顺序反了的话服务启动时连表都找不到日志里全是Table xxx doesnt exist排查起来浪费时间。-- 先建库字符集用 utf8mb4网约车项目里司机姓名、地址可能有特殊字符 CREATE DATABASE taxi_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 切库 USE taxi_db; -- 然后执行包里的建表脚本注意脚本里如果有 DROP TABLE 要先确认是不是测试数据 SOURCE /path/to/online-taxi-public/sql/schema.sql; -- 灌初始数据比如计价规则、城市配置 SOURCE /path/to/online-taxi-public/sql/data.sql;逻辑说明utf8mb4是为了兼容 emoji 和生僻字网约车场景里乘客备注可能带表情SOURCE命令在 MySQL 客户端里执行本地脚本比复制粘贴稳。参数上注意schema.sql里如果有外键约束灌数据顺序不能乱先主表后从表。如果脚本里用了ENGINEInnoDB确认你的 MySQL 默认引擎也是 InnoDB否则事务会失效——订单状态流转全靠事务撑着。3. 核心链路跑通订单创建、派单与状态流转3.1 订单创建接口的入参与校验逻辑订单创建是整个系统的入口也是最容易出并发问题的地方。乘客点「呼叫用车」时后端要做的第一件事不是插库而是校验乘客有没有未完成订单、上车点是否在服务范围、预估价格是否算得出来。源码里这部分通常写在OrderController或OrderService的createOrder方法里。// 伪代码示意实际方法名以源码为准 public OrderVO createOrder(CreateOrderDTO dto) { // 1. 校验乘客是否有进行中的订单防止重复下单 Long count orderMapper.countActiveByPassengerId(dto.getPassengerId()); if (count 0) { throw new BizException(您有未完成的行程请先完成或取消); } // 2. 校验上车点是否在运营区域常见做法是查城市配置表 CityConfig config cityConfigMapper.selectByCityCode(dto.getCityCode()); if (config null || !config.getServiceEnabled()) { throw new BizException(当前城市暂未开通服务); } // 3. 调用计价服务预估价格写入订单快照 BigDecimal estimatePrice priceService.estimate(dto.getStartPoint(), dto.getEndPoint()); // 4. 落库状态置为「待派单」 Order order buildOrder(dto, estimatePrice); orderMapper.insert(order); // 5. 发消息触发派单解耦订单创建和派单逻辑 mqProducer.sendDispatchMessage(order.getId()); return convertToVO(order); }逻辑说明第 1 步的countActiveByPassengerId是防重关键没有这层校验用户连点两次就会生成两个订单第 2 步的城市配置校验决定了服务边界调试时如果一直提示未开通去city_config表里把service_enabled改成 1第 3 步的计价快照要落库因为后续实际费用可能因堵车、绕路变化快照是纠纷时的依据第 5 步用消息队列解耦订单创建和派单不在一个事务里这是分布式系统的常见做法但也意味着派单失败要有补偿机制。参数上重点关注CreateOrderDTO里的经纬度字段如果传的是字符串而库里是 decimal记得在 DTO 里做类型转换。3.2 派单算法的简化实现与可调参数派单是网约车项目里最有「技术含量」的部分但源码包里的实现通常是简化版查附近司机 → 按距离排序 → 依次推送 → 司机接单则锁定超时则换下一个。核心逻辑在DispatchService里。public void dispatch(Long orderId) { Order order orderMapper.selectById(orderId); // 1. 从 Redis GEO 里查附近 3 公里的司机 ListDriverLocation nearbyDrivers redisGeoService.nearby( order.getStartLng(), order.getStartLat(), 3.0, 10 ); if (nearbyDrivers.isEmpty()) { // 扩大范围到 5 公里常见做法是逐级扩大 nearbyDrivers redisGeoService.nearby( order.getStartLng(), order.getStartLat(), 5.0, 10 ); } // 2. 过滤掉状态不是「空闲」的司机 ListDriverLocation available nearbyDrivers.stream() .filter(d - IDLE.equals(d.getStatus())) .collect(Collectors.toList()); // 3. 按距离升序依次推送 for (DriverLocation driver : available) { boolean accepted pushToDriver(driver.getDriverId(), orderId); if (accepted) { // 锁定司机更新订单状态为「已接单」 lockDriver(driver.getDriverId(), orderId); orderMapper.updateStatus(orderId, OrderStatus.ACCEPTED); return; } } // 4. 没人接订单回到待派单池等待下一轮 orderMapper.updateStatus(orderId, OrderStatus.WAITING_DISPATCH); }逻辑说明第 1 步用 Redis 的 GEO 数据结构查附近司机比 MySQL 的经纬度计算快得多这是网约车项目的标配3.0是初始搜索半径公里10是最多返回条数这两个参数可以根据城市密度调一线城市可以缩到 1 公里郊区可以放到 5 公里第 2 步的状态过滤很重要没有这步会把已经载客的司机也推一遍第 3 步的pushToDriver通常是发消息或长连接推送返回司机是否接单第 4 步的兜底逻辑保证订单不会「消失」调试时如果订单一直卡在待派单先看 Redis 里有没有司机位置数据。注意派单的超时时间一般配在配置文件里比如dispatch.timeout15秒。这个值太短会导致司机来不及反应太长会让乘客等太久。我一般调到 15 到 20 秒之间。3.3 订单状态机与幂等处理订单状态流转是网约车项目的「黑匣子」状态多了之后很容易出现「订单既显示已完成又显示进行中」的玄学问题。源码里通常会用枚举定义状态WAITING_DISPATCH、ACCEPTED、ARRIVED、IN_TRIP、COMPLETED、CANCELLED。每次状态变更都要校验「当前状态能不能转到目标状态」。public void updateStatus(Long orderId, OrderStatus target) { Order order orderMapper.selectById(orderId); // 校验状态流转是否合法 if (!order.getStatus().canTransferTo(target)) { throw new BizException(非法状态流转: order.getStatus() - target); } // 用乐观锁更新version 字段防并发 int rows orderMapper.updateStatusWithVersion(orderId, target, order.getVersion()); if (rows 0) { // 更新失败说明有并发重试或抛异常 throw new BizException(订单状态更新冲突请重试); } // 状态变更后发消息通知其他服务 mqProducer.sendStatusChangeMessage(orderId, target); }逻辑说明canTransferTo是状态机的核心比如COMPLETED不能再转到IN_TRIPCANCELLED不能再转到ACCEPTED乐观锁的version字段防止两个请求同时改同一订单状态变更后发消息是为了让计价、结算、通知等服务感知。参数上注意version字段在表里要是int或bigint每次更新加 1。调试时如果频繁报「状态更新冲突」说明有重复请求或消息重投去查上游是不是没做幂等。4. 避坑与排查跑这份源码最容易卡住的五个地方4.1 服务启动报「找不到配置中心」现象启动时日志报Could not resolve placeholder xxx或连接配置中心超时。原因源码里用了 Nacos 或 Apollo 做配置管理但包里没带配置中心的搭建说明或者配置文件里的地址是作者本地的。解决先看bootstrap.yml里的配置中心地址改成你本地的或者直接把配置项挪到application.yml里临时跑通。我一般会先把配置中心依赖注释掉用本地配置验证业务逻辑跑通后再接回去。4.2 Redis 连接不上导致派单直接挂现象订单创建成功但一直不派单日志里刷RedisConnectionFailureException。原因Redis 没启动或者密码、端口不对。解决redis-cli -h 127.0.0.1 -p 6379先确认能连上如果设了密码在application.yml里补spring.redis.password。另外注意 Redis 的 GEO 命令需要 3.2 以上版本老版本不支持。4.3 消息队列没起订单状态卡住不动现象订单创建后状态一直是「待派单」但派单服务的日志没有任何输出。原因订单创建后发消息到 MQ但 MQ 没启动或队列没创建消息丢了。解决先确认 RabbitMQ 或 RocketMQ 在跑然后检查队列是否自动创建很多源码包依赖RabbitListener自动声明队列但需要配置spring.rabbitmq.listener.simple.auto-startuptrue。如果消息已经丢了手动调一次派单接口补数据。4.4 数据库时区不对订单时间差 8 小时现象订单创建时间是凌晨但库里存的是前一天下午。原因MySQL 的time_zone是 UTCJava 应用用的是东八区写入时没做转换。解决在 JDBC URL 里加serverTimezoneAsia/Shanghai或者把 MySQL 全局时区改成8:00。这个坑很隐蔽因为业务逻辑没错只是时间显示不对但对账时会出大问题。4.5 司机位置不更新派单永远查不到人现象Redis 里GEO集合是空的派单查附近司机返回空列表。原因源码里司机位置上报的接口没被调用或者模拟数据没灌。解决找一下有没有DriverLocationController之类的上报接口用 Postman 手动调几次往 Redis 里写几个司机坐标。常见做法是写个定时任务模拟司机移动每 5 秒更新一次位置。5. 进阶改造把派单从「能跑」调到「像真的」跑通基础链路之后真正有意思的是调派单策略。源码里的简化版是「按距离排序依次推」但真实场景要考虑司机接单率、方向顺路度、乘客等待时长。我一般会先加一个「司机评分」维度在 Redis 里给每个司机维护一个score接单成功加 1拒单减 1派单时按score降序排同分再按距离。这样能避免总是推给同一个司机。// 在原有距离排序基础上加评分权重 ListDriverLocation sorted available.stream() .sorted(Comparator .comparing(DriverLocation::getScore).reversed() // 评分高的优先 .thenComparing(DriverLocation::getDistance)) // 同分按距离近的优先 .collect(Collectors.toList());另一个可调的是「派单轮次间隔」。源码里可能是一次性推完所有司机但真实场景是「推一个等 5 秒不接再推下一个」。改法是把for循环改成定时任务每 5 秒推一个用 Redis 的setnx做分布式锁防止重复推。参数上5秒可以调高峰期调到 3 秒平峰期 8 秒。验证改造效果的方法很简单写一个压测脚本模拟 100 个乘客同时下单看订单完成率和平均派单时长。如果完成率低于 80%说明派单半径或超时时间要调如果平均派单时长超过 30 秒说明司机池太小或评分策略太严。我习惯在改完派单逻辑后先把dispatch.timeout临时调到 60 秒观察日志里司机的接单行为确认逻辑对了再调回正常值。从那以后我每次拿到这类业务源码包都强制自己先跑通「一条订单的完整生命周期」再动任何一行派单代码。因为网约车的复杂度不在单个接口而在状态流转和并发边界上先把主干跑顺支线才不会越改越乱。希望帮到你。本文还有配套的精品资源点击获取