一、系统简介

OnlineTaxi 是一个基于 Spring Cloud 微服务架构的网约车项目，采用 Java 技术栈开发。项目将网约车核心业务拆分为多个独立微服务，涵盖乘客端、司机端、订单、派单、计价、支付、地图等模块，是学习 Spring Cloud 微服务架构和网约车业务逻辑的典型参考项目。

网约车系统的本质可以用一句话概括：一张不断变化的“活地图” + 一个秒级撮合供需的“实时匹配引擎”。系统需要实时掌握海量司机和乘客的位置，在几秒内把最合适的车和人匹配上，并全程跟踪行程。

二、核心功能模块

1. 服务拆分架构

OnlineTaxi 采用分层微服务设计：

业务层（面向用户端） ：

• api-passenger：乘客端接口
• api-driver：司机端接口
• api-listen-order：司机听单服务

能力层（核心业务逻辑） ：

• service-order：订单管理
• service-order-dispatch：派单服务（核心）
• service-passenger-user：乘客用户管理
• service-sms：短信服务
• service-valuation：计价服务
• service-verification-code：验证码服务
• service-wallet：钱包服务
• service-payment：支付服务
• service-map：地图服务

Spring Cloud 组件：

• cloud-eureka：注册中心
• cloud-config-server：配置中心
• cloud-zuul：API 网关
• cloud-hystrix-dashboard：熔断监控
• cloud-admin：健康检查
• cloud-zipkin-ui：链路追踪

2. 派单与匹配

派单是网约车系统的灵魂部件-3。匹配引擎的工作流程是：查附近候选司机 → 按距离、ETA、评分等条件挑选 → 派单。

匹配算法的演进方向：简单的“就近派单”虽然直观，但可能导致全局效率低下。以滴滴的实际案例为例：如果两个乘客同时叫车，完全按就近派单，1号乘客被最近的司机接单，但2号乘客可能因接驾距离过远而叫不到车；全局最优的解法是把2号车派给1号乘客、1号车派给2号乘客，这样两位乘客的平均等待时长反而缩短了1.5分钟。工业界通常采用运筹优化+机器学习方法，在1.5-2秒内搜索所有可能的司机乘客匹配，找出全局接驾时长最短的解法。

3. 地理空间索引

网约车系统区别于普通系统的核心能力是地理空间索引。二维经纬度通过 GeoHash、网格或四叉树等结构编码，使“查附近的车”从不可能变为毫秒级响应。位置接入服务承接司机/乘客的超高频位置上报，大部分位置只需放内存，无需逐条持久化。

4. 行程状态机

行程服务管理一单从“已派单 → 司机在路上 → 行程中 → 完成”的严格状态流转，关乎计费准确性。

5. 动态定价

用实时供需比调价，高峰时用价格杠杆平衡供需、削峰。

三、核心优缺点

✅ 核心优点

微服务架构教学价值高：项目完整展示了 Spring Cloud 全家桶的实践方式，包括 Eureka 注册中心、Zuul 网关、Hystrix 熔断、Zipkin 链路追踪等组件的集成方式，是学习微服务拆分的优质参考。

业务拆分清晰：将订单、派单、计价、支付、地图等能力层服务独立拆分，体现了“关注点分离”的设计原则。派单服务独立于订单服务，后续调整派单策略不会影响核心订单链路。

技术栈主流：Spring Boot + Spring Cloud + MyBatis + MySQL 的组合在国内企业应用广泛，学习成果可直接迁移到实际工作。

❌ 现存不足

项目定位为学习参考：GitHub 仓库未提供生产环境部署文档、压力测试报告或高可用方案，代码完整度和稳定性未经大规模验证。

派单算法相对基础：搜索结果中未展示项目的具体派单算法实现。工业级派单需要处理全局最优匹配、拥堵路况、司机口碑值等多维因素，这些在开源项目中通常不会完整实现。

文档和部署指南有限：项目 README 主要展示服务拆分结构，缺乏详细的部署步骤、环境配置说明和常见问题排查指南。