如果你平时关注的是“早盘、水下、换仓”这些词那么今天这个话题可能会有一点跨界。很多人提到网约车第一反应是盘面里的一个概念、一只股票、一个板块轮动的方向。但从一名后端开发者的角度看网约车三个字背后是一整套订单、派单、位置上报、状态机、高并发补偿的技术体系。这篇文章不讨论行情也不讨论个股只讨论技术问题如果要从零开始做一个网约车订单派发 Demo核心流程是什么选型怎么搭最容易踩的坑又在哪里。我的判断是网约车这类实时交易系统真正难的不在界面而在“状态一致性”和“并发冲突”。你可以在五分钟内跑通一个“创建订单”接口但要让订单、司机、乘客三个角色在任意时刻看到同一个状态并且在高并发下不丢单、不重复派单、不出现状态倒流这就涉及一套工程方法论。本文会用 Spring Boot 做一个最小可运行的订单派发示例带领你理解订单状态机、距离匹配、位置上报等核心概念并给出生产环境下常见的排查思路和最佳实践。如果你正在学习后端项目、准备面试、或者想自己搭一个类似打车/配送/预约类的小系统这篇文章的价值在于它不会给你一个动辄几十个微服务的复杂架构而是先用最简单的单体 Spring Boot 应用把业务主流程跑通。跑通之后你会更清楚哪些地方需要引入 Redis、消息队列、地理索引也知道每一步为什么要这样设计。1. 从“换网约车”到做网约车系统中间隔了哪些技术问题很多人以为网约车系统就是“乘客下单司机接单”这么简单。实际拆分下来你会发现这中间至少包含以下核心问题订单状态如何流转从创建、匹配、已接单、行程中、已完成到取消每一步都需要有明确状态机。司机位置如何上报司机端 App 会周期性上报经纬度但位置是不断变化的平台如何用这些最新位置去匹配乘客。派单如何设计是不是每个新订单都全局遍历所有司机司机量大的时候这种方式必然撑不住。并发下如何避免重复派单一个司机同时被两个订单匹配发生冲突怎么办。异常流程如何处理乘客下单后一直没司机接单司机接单后一直不出发订单超时后如何自动取消。这些问题的本质是“业务状态”和“外部位置数据”的交互。传统 To B 管理系统只需要保证数据录入正确而网约车系统还要保证状态流转的实时性和唯一性。拿订单匹配来说如果两个请求同时把同一个司机派给了不同订单哪怕代码逻辑写得再完整最终数据库里也会出现脏数据。所以说网约车系统的学习价值不在于“网约车”这三个字而在于它把常见的后端技术点聚合在了一起。一个看起来简单的业务要同时处理接口幂等、状态校验、并发控制、数据补偿、地图能力接入等复杂问题。这也是为什么很多后端开发者选择拿“打车项目”来练手而不是只做一个普通的 CRUD。2. 网约车订单系统的核心业务概念在写代码之前先把几个关键概念说清楚。如果这些概念没有对齐后面看代码就容易只看表面对不上下文。2.1 核心角色与业务流程网约车系统至少有三个角色乘客、司机、平台。乘客发起一个订单提交起点经纬度和终点经纬度司机维护自己的实时位置和接单状态平台负责把合适的订单推送给合适的司机并在司机接单后维护整个行程状态。从流程上看一个订单的生命周期大概是乘客发单 - 平台匹配司机 - 司机接单 - 司机到达起点 - 行程开始 - 到达终点 - 完成支付如果中间任何一步失败就会进入异常分支。比如没有司机接单订单会变成待转派状态司机接了单又取消订单会重新回到匹配池。2.2 订单状态机状态机是这类系统最容易忽略但最重要的部分。如果没有状态机约束一个订单可能被重复完成也可能在取消之后又被误接单。一个最小的订单状态机可以这样定义状态值含义允许流转到的状态CREATED已创建等待派单MATCHED, CANCELLEDMATCHED已匹配司机IN_PROGRESS, CANCELLEDIN_PROGRESS行程进行中COMPLETED, CANCELLEDCOMPLETED已完成无CANCELLED已取消无看这张表就会明白状态机解决的核心问题是“哪些状态能变到哪些状态”。在业务代码里每一次状态变更都要先判断当前状态是否合法再更新状态。如果省略这一步就会出现各种奇怪的线上问题。2.3 派单与位置上报派单模型有很多种比如抢单模式、派单模式、混合模式。本文示例采用最简单的“派单模式”新订单创建后平台找到距离最近的可用司机把订单派给该司机。这里涉及一个关键数据指标距离怎么计算。生产环境通常会接入地图服务商使用驾车距离计算和道路级导航。但在最小示例里为了便于理解可以使用经纬度之间的欧氏距离。欧氏距离的好处是计算简单、不依赖外部接口坏处是不符合真实路网所以仅用于学习。司机位置上报也是一个需要单独设计的功能。一般来说司机端不会每次位置变化都写数据库而是先发送到消息队列或内存缓存再由后台任务更新到数据库。本文的示例为了简单采用了内存 Map 存储并直接更新司机位置但我会在后面的工程建议里说明为什么生产环境不能这么干。3. 技术选型学习 Demo 和企业级架构的差异很多初学者一上来就想搞微服务把 Nacos、Gateway、Feign、Kafka 全堆上去。这个方向我不推荐原因是如果订单状态机还没有跑通引入分布式组件只会增加排查成本。学习阶段的核心目标应该是“用最小的成本把业务逻辑讲清楚”。我的建议是使用单体服务使用 Spring Boot 搭建 Rest API使用内存 Map 模拟数据库存储使用简单的距离计算模拟地图服务预留出 Redis、MySQL、消息队列的扩展位但不在本文运行依赖中引入。这样做的优势是环境简单、代码量可控、容易验证。等你把状态机和派单逻辑写明白之后再思考如何用 Redis 做司机位置缓存、用 MySQL 保证订单持久化、用 RocketMQ 或 Kafka 做订单事件通知会顺利得多。从工程角度看企业级网约车系统和这个 Demo 的差距主要体现在以下几点维度学习 Demo企业级系统司机位置内存 Map 直接保存高并发写入 Redis Geo异步落库派单算法遍历所有司机取最近基于地理网格、并行计算、优先级策略订单存储内存 MapMySQL 分库分表 订单归档状态变更代码内手动校验状态机框架 分布式锁 事务消息消息通知无MQ 推送、消息重试、消费者幂等地图服务欧氏距离第三方地图 API 费用预估看清这个对比你就知道本文要解决什么、不解决什么。本文帮你建立主流程认知和最小运行环境企业级问题留给后续继续深入。4. 环境准备与工程初始化4.1 环境要求本示例使用 Java 17 和 Spring Boot 3.x。如果你的本地环境是 JDK 8建议换成 Spring Boot 2.7.x示例代码不涉及 Jakarta 特有写法所以兼容性调整成本不大。你需要准备JDK 17 或更高版本Maven 3.6 或使用 IDE 自带的 MavenIntelliJ IDEA 或 EclipsePostman 或 curl 命令行工具。这里不写死具体小版本号因为 Spring Boot 版本更新较快建议以 Maven 中央仓库中的稳定版本为准。关键点是 JDK 版本和 Spring Boot 大版本必须匹配。4.2 创建 Maven 工程并添加依赖新建一个空白 Maven 工程在pom.xml中加入 Spring Boot Web 依赖和 Lombok 依赖。?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.3.5/version relativePath/ /parent groupIdcom.example/groupId artifactIdride-dispatch-demo/artifactId version1.0.0/version nameride-dispatch-demo/name description网约车订单派发学习示例/description properties java.version17/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId configuration excludes exclude groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /exclude /excludes /configuration /plugin /plugins /build /project如果你使用的是 IntelliJ IDEA需要确认 Lombok 插件已经启用。新版 IDEA 通常内置支持但旧版本可能需要手动安装插件。这个细节经常导致第一次启动时报“找不到 getter 方法”后面会在常见问题中说明。4.3 配置文件在src/main/resources/application.yml中写入以下配置server: port: 8080 spring: application: name: ride-dispatch-demo这里暂时不配置数据库和 Redis。使用内存存储时Spring Boot 启动后就是一个纯 Web 服务动手成本最低。5. 核心代码实现下面开始写业务代码。我建议严格按照包结构创建文件避免类名扫描不到的问题。5.1 启动类package com.example.ridedemo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; SpringBootApplication public class RideDemoApplication { public static void main(String[] args) { SpringApplication.run(RideDemoApplication.class, args); } }这个启动类是整个服务的入口。启动成功后Spring 容器会自动扫描com.example.ridedemo包下的组件。5.2 实体对象订单实体包含订单ID、乘客ID、起点终点经纬度、订单状态、司机ID、创建时间和更新时间。package com.example.ridedemo.entity; import lombok.Data; Data public class RideOrder { private String orderId; private String passengerId; private double pickupLat; private double pickupLng; private double dropoffLat; private double dropoffLng; private String status; private String driverId; private Long createTime; private Long updateTime; }司机实体包含司机ID、姓名、当前位置经纬度、是否可接单以及位置更新时间。package com.example.ridedemo.entity; import lombok.Data; Data public class Driver { private String driverId; private String name; private double lat; private double lng; private boolean available; private Long updateTime; }这里使用 Lombok 的Data自动生成 getter、setter、toString 等方法。它让代码更简洁但代价是 IDE 必须支持注解处理。5.3 内存仓库我们用ConcurrentHashMap模拟订单表和司机表。虽然启动后数据会丢失但它能保证示例中的并发读写不出现明显错误。package com.example.ridedemo.repository; import com.example.ridedemo.entity.RideOrder; import org.springframework.stereotype.Repository; import java.util.ArrayList; import java.util.List; import java.util.Map; import java.util.Optional; import java.util.concurrent.ConcurrentHashMap; Repository public class OrderRepository { private final MapString, RideOrder orders new ConcurrentHashMap(); public void save(RideOrder order) { orders.put(order.getOrderId(), order); } public OptionalRideOrder findById(String orderId) { return Optional.ofNullable(orders.get(orderId)); } public ListRideOrder findAll() { return new ArrayList(orders.values()); } }package com.example.ridedemo.repository; import com.example.ridedemo.entity.Driver; import org.springframework.stereotype.Repository; import java.util.ArrayList; import java.util.List; import java.util.Map; import java.util.Optional; import java.util.concurrent.ConcurrentHashMap; import java.util.stream.Collectors; Repository public class DriverRepository { private final MapString, Driver drivers new ConcurrentHashMap(); public void save(Driver driver) { drivers.put(driver.getDriverId(), driver); } public OptionalDriver findById(String driverId) { return Optional.ofNullable(drivers.get(driverId)); } public ListDriver findAvailable() { return drivers.values().stream() .filter(Driver::isAvailable) .collect(Collectors.toList()); } }为什么不用普通的HashMap因为订单创建、司机位置上报都是高频写操作多线程环境下HashMap可能出现 CPU 100% 的循环问题。ConcurrentHashMap对读多写少的场景更安全。这里先种下一颗种子后面最佳实践里会专门说并发。5.4 初始化司机数据为了让示例开箱即用我们在服务启动时初始化一个司机。这个司机 ID 固定为 D001位置定位在上海人民广场附近。package com.example.ridedemo.config; import com.example.ridedemo.entity.Driver; import com.example.ridedemo.repository.DriverRepository; import org.springframework.boot.CommandLineRunner; import org.springframework.stereotype.Component; Component public class DataInitializer implements CommandLineRunner { private final DriverRepository driverRepository; public DataInitializer(DriverRepository driverRepository) { this.driverRepository driverRepository; } Override public void run(String... args) { Driver driver new Driver(); driver.setDriverId(D001); driver.setName(张师傅); driver.setLat(31.2280); driver.setLng(121.4600); driver.setAvailable(true); driver.setUpdateTime(System.currentTimeMillis()); driverRepository.save(driver); } }生产环境当然不会把司机数据写死在启动类里但作为教学示例这样能让你在第一次运行时不需要手动插入数据直接把注意力放在核心业务逻辑上。5.5 订单服务和派单服务订单服务负责创建订单。创建订单时需要生成订单 ID、设置初始状态为 CREATED并记录时间。package com.example.ridedemo.service; import com.example.ridedemo.entity.RideOrder; import com.example.ridedemo.repository.OrderRepository; import org.springframework.stereotype.Service; import org.springframework.util.StringUtils; import java.util.UUID; Service public class RideOrderService { private final OrderRepository orderRepository; public RideOrderService(OrderRepository orderRepository) { this.orderRepository orderRepository; } public RideOrder createOrder(RideOrder request) { if (!StringUtils.hasText(request.getPassengerId())) { throw new IllegalArgumentException(乘客ID不能为空); } RideOrder order new RideOrder(); order.setOrderId(UUID.randomUUID().toString()); order.setPassengerId(request.getPassengerId()); order.setPickupLat(request.getPickupLat()); order.setPickupLng(request.getPickupLng()); order.setDropoffLat(request.getDropoffLat()); order.setDropoffLng(request.getDropoffLng()); order.setStatus(CREATED); order.setCreateTime(System.currentTimeMillis()); order.setUpdateTime(System.currentTimeMillis()); orderRepository.save(order); return order; } }派单服务是本文的核心。它从所有可用司机中找到距离乘客起点最近的司机把订单标记为 MATCHED同时把司机标记为不可接单。package com.example.ridedemo.service; import com.example.ridedemo.entity.Driver; import com.example.ridedemo.entity.RideOrder; import com.example.ridedemo.repository.DriverRepository; import com.example.ridedemo.repository.OrderRepository; import org.springframework.stereotype.Service; Service public class DispatchService { private final DriverRepository driverRepository; private final OrderRepository orderRepository; public DispatchService(DriverRepository driverRepository, OrderRepository orderRepository) { this.driverRepository driverRepository; this.orderRepository orderRepository; } public String matchDriver(String orderId) { RideOrder order orderRepository.findById(orderId) .orElseThrow(() - new IllegalArgumentException(订单不存在: orderId)); if (!CREATED.equals(order.getStatus())) { throw new IllegalStateException(只有 CREATED 状态才能派单当前状态: order.getStatus()); } Driver bestDriver null; double minDistance Double.MAX_VALUE; for (Driver driver : driverRepository.findAvailable()) { double distance calculateDistance( order.getPickupLat(), order.getPickupLng(), driver.getLat(), driver.getLng()); if (distance minDistance) { minDistance distance; bestDriver driver; } } if (bestDriver null) { return null; } bestDriver.setAvailable(false); bestDriver.setUpdateTime(System.currentTimeMillis()); driverRepository.save(bestDriver); order.setDriverId(bestDriver.getDriverId()); order.setStatus(MATCHED); order.setUpdateTime(System.currentTimeMillis()); orderRepository.save(order); return bestDriver.getDriverId(); } private double calculateDistance(double lat1, double lng1, double lat2, double lng2) { double dx lat1 - lat2; double dy lng1 - lng2; return Math.sqrt(dx * dx dy * dy); } }请注意这里的两个关键点。第一派单前置校验了订单状态必须是 CREATED。如果没有这一步一个已经取消的订单也可能被派单。第二司机被匹配后available会立即变成 false。这是为了避免同一个司机被下一次派单再次选到。5.6 司机位置上报服务司机位置上报的接口逻辑比较简单就是根据司机 ID 更新经纬度和可接单状态。package com.example.ridedemo.service; import com.example.ridedemo.entity.Driver; import com.example.ridedemo.repository.DriverRepository; import org.springframework.stereotype.Service; Service public class DriverService { private final DriverRepository driverRepository; public DriverService(DriverRepository driverRepository) { this.driverRepository driverRepository; } public Driver updateLocation(String driverId, Driver request) { Driver driver driverRepository.findById(driverId) .orElseThrow(() - new IllegalArgumentException(司机不存在: driverId)); driver.setLat(request.getLat()); driver.setLng(request.getLng()); driver.setAvailable(request.isAvailable()); driver.setUpdateTime(System.currentTimeMillis()); driverRepository.save(driver); return driver; } }这里有一个人为简化直接把 body 里的available透传进去了。真实项目里司机能不能接单还涉及人车合规、计费状态、服务中状态等判断通常不会由 App 直接修改。你在自己做项目时可以加上这些约束。5.7 控制器最后是暴露 HTTP 接口的 Controller。package com.example.ridedemo.controller; import com.example.ridedemo.entity.Driver; import com.example.ridedemo.entity.RideOrder; import com.example.ridedemo.service.DispatchService; import com.example.ridedemo.service.DriverService; import com.example.ridedemo.service.RideOrderService; import org.springframework.web.bind.annotation.*; import java.util.HashMap; import java.util.Map; RestController RequestMapping(/api) public class RideController { private final RideOrderService rideOrderService; private final DriverService driverService; private final DispatchService dispatchService; public RideController(RideOrderService rideOrderService, DriverService driverService, DispatchService dispatchService) { this.rideOrderService rideOrderService; this.driverService driverService; this.dispatchService dispatchService; } PostMapping(/orders) public RideOrder createOrder(RequestBody RideOrder request) { return rideOrderService.createOrder(request); } PostMapping(/drivers/{driverId}/location) public Driver updateLocation(PathVariable String driverId, RequestBody Driver request) { return driverService.updateLocation(driverId, request); } PostMapping(/orders/{orderId}/match) public MapString, Object match(PathVariable String orderId) { String driverId dispatchService.matchDriver(orderId); MapString, Object result new HashMap(); result.put(orderId, orderId); result.put(matched, driverId ! null); result.put(driverId, driverId); return result; } }到这里一个可以启动的最小网约车订单派发服务就完成了。它支持创建订单、司机位置上报、订单派单三个核心操作。6. 运行与接口验证代码写完后按照下面的步骤验证整个流程是否正常。6.1 启动服务在项目根目录执行mvn spring-boot:run如果端口被占用会看到Port 8080 was already in use之类的错误。这时可以改成其他端口或者杀掉占用进程。启动日志正常会包含类似下面的内容Tomcat started on port 8080 Started RideDemoApplication in 2.5 seconds看到Started说明 Spring 容器加载成功。6.2 创建订单打开新终端执行curl -X POST http://localhost:8080/api/orders \ -H Content-Type: application/json \ -d { passengerId: P001, pickupLat: 31.2304, pickupLng: 121.4737, dropoffLat: 31.2204, dropoffLng: 121.4800 }预期会返回一个包含orderId的 JSON。例如{ orderId: 2d0f8a5a-4e6a-4f0c-9e0f-1f1a2b3c4d5e, passengerId: P001, pickupLat: 31.2304, pickupLng: 121.4737, dropoffLat: 31.2204, dropoffLng: 121.48, status: CREATED, driverId: null, createTime: 1697630000000, updateTime: 1697630000000 }把返回的orderId保存下来下一步派单需要使用。6.3 司机位置上报模拟司机 D001 从初始位置移动到了离乘客更近的位置curl -X POST http://localhost:8080/api/drivers/D001/location \ -H Content-Type: application/json \ -d { lat: 31.2300, lng: 121.4730, available: true }返回结果中name应该是张师傅available为 true经纬度更新成新值。6.4 触发派单使用刚才创建订单的orderId执行派单curl -X POST http://localhost:8080/api/orders/2d0f8a5a-4e6a-4f0c-9e0f-1f1a2b3c4d5e/match预期返回{ orderId: 2d0f8a5a-4e6a-4f0c-9e0f-1f1a2b3c4d5e, matched: true, driverId: D001 }此时订单状态已经变为 MATCHED司机 D001 也会被标记为不可接单。如果你再次执行派单会看到matched: false或状态校验异常因为订单已经不再是 CREATED 状态。6.5 如何判断运行成功判断标准有三条创建订单后返回状态为 CREATED派单后返回matched: true数据库内存中的司机available从 true 变为 false。如果第二条没有成功最常见的原因是订单 ID 写错或者司机位置距离乘客太远。你可以调整司机位置数据后重新尝试。7. 常见问题与排查思路下面整理的是我在类似项目里经常遇到的几个问题。这些问题在你的本地运行中也可能出现。问题现象可能原因排查方式解决方案启动失败提示 Port 8080 already in use本地端口被占用查看启动日志中的端口报错修改 application.yml 中的 server.port启动失败提示 Lombok 找不到 getter 方法IDEA 未启用注解处理检查编译错误详情安装并启用 Lombok 插件开启 Annotation Processing请求订单时返回 400 Bad RequestJSON 字段名与实体属性不匹配检查请求体字段名确保 body 里的字段名是 passengerId 而不是 passenger_id派单时返回 500 IllegalStateException订单状态不是 CREATED先查一次订单当前状态确认订单没有被重复派单或已取消匹配到的司机不对距离计算使用的是欧氏距离打印司机位置和乘客位置生产环境接入地图服务使用真实道路距离并发派单时同一个司机被派给两个订单缺少分布式锁观察日志中的操作顺序引入 Redis 分布式锁或数据库乐观锁服务重启后订单和司机数据丢失使用了内存 Map 存储查看是否接了数据库学习阶段可接受生产环境必须持久化到 MySQL如果你按照示例步骤操作后还是没跑通建议按下面的顺序排查先看编译是否通过再看启动日志是否出现Started RideDemoApplication然后看接口返回的 HTTP 状态码最后看异常堆栈的类名。大部分问题都集中在依赖和注解处理上而不是业务逻辑本身。8. 最佳实践与工程建议跑通 Demo 只是第一步。如果要把这个项目继续扩展成可上线的服务下面这些建议值得留意。8.1 订单状态机必须集中管理示例里的状态校验散落在 Service 里一旦业务复杂很容易漏掉某一条流转路径。更好的做法是把状态机单独抽出来定义合法的流转映射每次变更前统一做校验甚至可以在数据库层加入订单状态字段的条件更新语句。例如更新订单状态时可以使用带状态条件的 SQLUPDATE ride_order SET status ? WHERE order_id ? AND status ?。如果更新行数为 0说明当前状态已经不是预期状态需要走异常流程。这就是乐观锁的思路。8.2 位置数据不能直接写业务库司机位置是高并发写入的数据。如果每两秒写入一次 MySQL数据库压力会非常大。生产环境常用的方案是先用 Redis GEO 保存司机实时位置再异步把位置快照写入历史表。派单时直接查询 Redis 中某个坐标附近的司机而不是遍历全量司机。Redis GEO 的核心优势是支持基于经纬度的范围查询性能远高于应用层遍历。你需要思考的是“如何把司机实时位置做成一个可查询的索引”而不是“如何把司机位置存进一张表”。8.3 幂等和重试机制必须有乘客有可能连续点了两次“立即叫车”如果前端没有做防抖后端就会创建两笔订单。处理方式有两种前端生成请求唯一 ID后端根据唯一 ID 做幂等或者后端在短时间内对同一乘客的重复请求直接返回已创建订单。司机接单、乘客取消这类操作也一样。取消请求可能因为网络问题被重试如果后台没有幂等处理一份订单可能被取消两次状态机的结果虽然一样但会产生多余的事件记录。8.4 派单并发控制派单场景的并发控制非常关键。当一个订单正在匹配司机时其他线程不能同时修改这个订单当一个司机正在被派单时其他订单也不能选中这个司机。解决方案可以分几个层次最简单的是在方法上加 JVM 锁但只对单机有效引入 Redis 分布式锁可以让多个实例安全竞争再进一步可以利用数据库行锁或乐观锁来保证状态一致。8.5 接口安全与数据合规乘客下单、司机上报位置都会涉及用户隐私。生产环境必须使用 HTTPS 传输并对用户敏感信息做脱敏处理。司机端接口要有鉴权至少需要校验 token不能像本文示例这样直接通过接口修改司机的可用状态。如果接口涉及资金支付还需要考虑支付幂等、金额计算、退款、对账等环节。这些内容往往比派单逻辑更复杂也是面试中经常深挖的方向。8.6 测试与回滚在本地跑通后如果要继续做数据库迁移或消息队列改造建议先备份当前可用版本记录好依赖版本和关键配置。不要一次性把内存 Map 改为 MySQL Redis而是分步骤验证先接 MySQL 保存订单再引入 Redis 存司机位置最后再加入消息队列。每做一步都要确认订单创建、派单、状态更新这三个核心链路没有被破坏。9. 总结与后续学习方向这篇文章从一个网约车话题切入但真正想讲清楚的是订单类系统的开发难点不在接口而在状态、匹配和并发控制。你用本文的代码可以快速构建一个最小可运行的网约车订单派发 Demo并通过创建订单、上报位置、触发派单三个接口走通一个完整业务闭环。下一步你可以按照这个顺序继续深入先把订单状态机扩展成独立类加入 CANCELLED 状态的完整流程然后把内存 Map 替换成 MySQL并验证重启后数据不丢失再引入 Redis Geo 保存司机位置模拟多个司机同时在线的情况最后尝试用消息队列异步处理派单结果体验从同步调高并发架构的演变过程。如果你正准备拿网约车、外卖派单、物流调度这类项目练手建议先收藏这篇文章把基础框架跑通后再一点点加复杂度。这样比一开始就梭哈微服务要稳得多。
