05 · 技术架构设计

1. 总体架构

┌─────────────────────────────────────────────────────────────────────┐
│                          客户端层                                    │
│   乘客 App / 小程序    司机 App / 小程序    运力方开放平台   管理端     │
└──────────────────────────────┬──────────────────────────────────────┘
                               │ HTTPS / WebSocket / QUIC
┌──────────────────────────────▼──────────────────────────────────────┐
│                       接入层：API 网关                              │
│   鉴权(JWT) · 限流(令牌桶) · 灰度路由 · 参数校验 · 风控前置 · 日志     │
└──────────────────────────────┬──────────────────────────────────────┘
┌──────────────────────────────▼──────────────────────────────────────┐
│                         业务服务层（微服务）                          │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐       │
│  │ 用户服务 │ │ 运力服务 │ │ 订单服务 │ │ 调度服务 │ │ 计价服务 │       │
│  └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘       │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐       │
│  │ 结算清分 │ │ 支付服务 │ │ LBS服务 │ │ 消息服务 │ │ 营销服务 │       │
│  └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘       │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────────────────┐       │
│  │ 风控服务 │ │ 客服工单 │ │ 数据服务 │ │   开放平台(qz-open)   │       │
│  └─────────┘ └─────────┘ └─────────┘ └─────────────────────┘       │
│  ┌─────────┐ ┌─────────┐ ┌───────────────────────────────┐        │
│  │智能体调度│ │ 人工核查 │ │       决策日志(可审计/可回放)     │        │
│  └─────────┘ └─────────┘ └───────────────────────────────┘        │
└──────┬───────────────┬───────────────┬───────────────┬──────────────┘
       │               │               │               │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────────────┐
│  数据层      │ │  缓存/消息   │ │  搜索/日志   │ │  外部依赖            │
│ MySQL(分库) │ │ Redis       │ │ ES          │ │ 高德/腾讯地图        │
│ 轨迹库      │ │ Kafka       │ │ OSS         │ │ 微信/支付宝支付       │
│ (Mongo/TSDB)│ │ MQ(削峰)    │ │ ClickHouse  │ │ 短信/推送/OCR        │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────────────┘

2. 技术选型

层次	选型	理由
客户端	小程序（微信/支付宝）+ Flutter App	一套代码双端，MVP 快
后端	Go（核心链路）/ Java Spring Cloud（业务中台）	Go 高并发低延迟，Java 生态成熟
数据库	MySQL 8.0（分库分表）+ TiDB（可选）	订单/用户强一致
缓存	Redis Cluster	热 key、分布式锁、会话
消息	Kafka + RocketMQ	事件驱动、订单状态解耦、削峰
轨迹	MongoDB / TDengine	高吞吐时序写入
搜索/日志	Elasticsearch + Filebeat	订单检索、日志检索
分析	ClickHouse	亿级订单聚合报表
部署	K8s（多可用区）+ Service Mesh（Istio）	弹性伸缩、灰度、可观测
地图	高德/腾讯企业版 API	定位、路径、ETA、围栏；不自建
支付	微信支付/支付宝（聚合收单 + 清分）	合规清分，不碰资金池
推送/IM	极光/个推 + 自建轻量 IM	订单通知、乘客司机沟通

3. 核心服务职责

服务	职责
用户服务	乘客/司机账号、实名、紧急联系人、隐私授权（PIPL）
运力服务	运力方档案、司机车辆档案、双证状态、服务分
订单服务	订单状态机、生命周期、取消/改单、费用快照
调度服务	订单广播、报价聚合、比价排序、指派/抢单、热力图
计价服务	市场价基准 + 让利 10% 计算（实付）+ 1% 佣金计算（实付口径）+ 比价数据 + 优惠券试算（详见 14 文档）
结算清分服务	T+1 对账、清分指令、差异处理、发票
支付服务	收单、免密、退款、退款冲正、企业月结
LBS 服务	定位纠偏、POI 吸附、围栏、ETA、路径优化
消息服务	订单事件通知、司机接单推送、行程 IM
营销服务	券、会员、活动、邀请裂变、A/B
风控服务	反作弊规则引擎、设备指纹、黑名单、处置
智能体调度服务	AI 感知/决策/谈判/解释多智能体，派单方案生成与置信度分级（HITL，详见 13 文档）
人工核查服务	核查队列、核查工作台、双人核查、改派、人工修正反馈回流
决策日志	全量决策留痕（输入快照/候选/决策/置信度/结果/人工修正），审计与训练用
客服工单	工单、先行赔付、追偿
开放平台	运力方 API 网关、签名验签、沙箱、对账单
数据服务	埋点、实时/离线数仓、BI

4. 核心链路设计

4.1 叫车链路（聚合比价）

乘客下单
 └─ 订单服务创建订单(状态=待分配) → 发事件到 Kafka
    └─ 调度服务消费事件
       ├─ 按城市/围栏筛选运力方集合
       ├─ 并行广播(带超时5s) → 运力方 qz-open 接口
       │    └─ 各家报价(价格/接驾时长/可用车)
       ├─ 报价聚合 → 比价排序(价格0.4+时长0.3+服务0.2+品牌0.1)
       ├─ 缓存报价快照(Redis, TTL 30s) → 推送乘客端展示
       └─ 乘客选定 → 派单指令 → 运力方接单回调
            └─ 订单状态: 已接单 → 接驾中 → 上车 → 行程中 → 完成

容错：任一家报价超时/失败不影响整体；全部失败 → 自动降级"出租车直连"或提示重试。

4.2 支付与清分链路

行程完成 → 订单服务计算费用快照(车费[司机到手] + 1%佣金)
 └─ 发支付请求(微信/支付宝 预下单, 金额=乘客实付)
 └─ 支付成功回调 → 清分服务
     ├─ 指令1: 车费(99%) → 运力方结算户(由收单机构清分)
     ├─ 指令2: 佣金(1%) → 平台结算户
     └─ 写入清分明细 → T+1 对账任务

合规要点：平台不沉淀资金，清分由持牌收单机构执行（"四方分离"：乘客—支付机构—运力方/平台），避免支付牌照风险。

4.3 消息推送链路

订单状态变更 → 订单服务发领域事件(Kafka)
  → 消息服务组装模板 → 多渠道触达(推送/短信/IM)
  → 送达/已读回执 → 监控到达率

5. 调度与比价引擎（核心算法）

5.1 候选运力筛选

城市 + GeoHash（9 位网格）→ 检索网格内在线运力方 → 按运力方覆盖区域取交集。
热度缓存：各网格在线运力数实时计数（Redis HyperLogLog 近似 + 精确计数降级）。

5.2 报价聚合与排序

score = w1 * price_norm + w2 * eta_norm + w3 * service_norm + w4 * brand_norm
价格分: 按"乘客预估实付"归一化(最低价=1.0)
ETA 分: 按"预估接驾时长"归一化(最短=1.0)
服务分: 运力方/司机服务质量分归一化
品牌分: 合作深度/补贴贡献(平台可控)

约束：无论排序如何，价格必须可见；不得出现"显示低价实际高价"（监管透明化要求）。
乘客侧缓存 30s 报价；司机侧抢单竞态用 Redis 分布式锁 + 状态机 CAS 保证一单一司机。

5.3 指派单（出租车/自营运力）

目标函数: min(接驾时间×α + 空驶里程×β − 顺路度×γ − 服务分加成)
约束: 司机在线、接单率>阈值、无拒载记录、服务分>70
实现: 时空索引(GeoHash+时间桶) 近邻搜索 → Top-K 评分 → 单司机推送(10s) → 失败转抢单池

5.4 ETA 预估

首阶段：直接调地图厂商 ETA API。
数据积累后：用历史轨迹（分段路况 + 时段特征）训练轻量模型校准，误差 < 15%。

5.5 AI 智能体派单与人工核查（HITL）

常规决策（高置信度 A/B 级）由智能体自动执行：多运力方智能分流（预测响应概率后仅广播 Top-3）、指派评分、供需热区预测、异常自动检测与小额补偿。
低置信度/高风险（C 级）进入人工核查队列，人工确认或改派后执行；安全事件（D 级）立即执行预案、事后复盘。
每个决策写入决策日志（decision_log），含 model_version 与输入快照，供审计与模型回放训练；人工修正回流学习智能体。
分级、核查中心与反馈闭环的完整设计见 13 文档。

6. 数据模型（核心表）

user                    用户表: id, phone, realname_status, member_level, referrer_id, created_at
driver                  司机表: id, user_id, carrier_id, name, license_no, service_score, status
vehicle                 车辆表: id, carrier_id, plate_no, type(经济/舒适/商务), transport_cert_status
carrier                 运力方表: id, name, license_no, status, fee_tier, cities(json), service_grade
order                   订单表: id, order_no, rider_id, carrier_id, driver_id, vehicle_id,
                         start_geo, end_geo, start_addr, end_addr, car_type,
                         status(0..9状态机), price_type, price_snapshot(json),
                         info_fee, discount_amount, paid_amount, timestamps
order_quote             报价表: id, order_id, carrier_id, price, eta_min, quote_at, is_chosen
gps_track               轨迹表: id, order_id, driver_id, lat, lng, speed, ts(时序, 分表/TSDB)
settlement              清分表: id, order_id, rider_id, carrier_id, amount, info_fee,
                         split_status, pay_flow_no, settle_date
pay_flow                支付流水: id, order_id, channel, amount, status, refund_no
coupon                  券表: id, user_id, type, amount, status, expire_at, use_order_id
membership              会员表: id, user_id, plan, expire_at, auto_renew
service_feedback        评价表: id, order_id, from_role, score, tags, content
blacklist               黑名单: id, target_type(user/driver/device), reason, level
decision_log            决策日志: id, order_id, model_version, scenario, input_snapshot(json,脱敏),
                         candidates(json), decision, confidence, risk_level, grade(A/B/C/D),
                         executed_by, corrected_by(json), result, ts
review_task             核查任务: id, order_id, grade, risk_score, amount, reviewer_id,
                         action(通过/修改/改派/升级/转客服), review_result, reviewed_at, sla_deadline
audit_log               审计日志: id, operator_id, module, action, before, after, ip, ts

分库分表策略：order、gps_track、settlement、pay_flow 按 order_id/时间 分片（ShardingSphere）；订单按 rider_id 取模分库。
订单状态机（不可逆跳转，仅允许合法迁移）：待分配 → 已接单 → 接驾中 → 行程中 → 已完成 / 已取消（各阶段取消原因编码）。

7. 高并发与容灾

场景	方案
早高峰下单洪峰	Kafka 削峰 + 订单服务水平扩容 + 限流（网关令牌桶按用户/设备/城市分级）
热 key（热门商圈）	Redis 热点探测 + 本地缓存（Caffeine）+ 读写分离
报价广播超时	异步化 + 超时熔断（Resilience4j），降级为单运力方直连
支付回调丢失	主动轮询对账（每 5 分钟拉取支付机构账单）
数据库故障	主从 + 跨可用区灾备；读库降级为缓存
全链路故障	核心链路（下单/支付）与辅助链路（营销/报表）物理隔离

可用性目标：核心链路 99.95%；账单对账每日自动跑批，差异 0 容忍。

8. 安全与隐私（技术侧）

传输：全站 HTTPS + 双向 TLS（内部服务 mTLS）。
数据加密：手机号/身份证 AES-256 加密存储；敏感字段脱敏展示。
权限：RBAC + 最小化；生产数据访问需审批 + 脱敏。
位置数据：仅服务期必要收集，提供单独授权与撤回；轨迹保存期限依法设置，到期自动清理。
接口安全：开放平台 HMAC 签名 + 时间戳防重放 + 频率限制 + 沙箱环境。
数据合规：境内存储；出境需评估（PIPL）；与运力方签署数据协议明确责任边界。
安全运营：漏洞扫描、渗透测试（上线前 + 季度）、SOC 告警、应急响应预案（含数据泄露 72h 报告义务）。

9. 监控与运维

可观测性三支柱：Prometheus 指标、SkyWalking 链路追踪、ELK 日志。
核心指标看板：订单 P99 延迟、完单率、接单率、支付成功率、推送到达率、服务可用性。
告警分级：P0（核心链路不可用）→ 电话+IM 即时；P1 → IM；P2 → 日报。
发布体系：CI/CD（GitLab CI + ArgoCD）、金丝雀发布、一键回滚、故障演练（季度混沌工程）。