麦文学1. 项目背景与核心目标
"苍穹外卖"这个命名很有意思，让我想起去年参与过的一个餐饮SaaS系统重构项目。这类外卖平台的核心诉求其实非常明确：如何在高峰时段保障系统稳定性，同时优化骑手调度算法降低配送成本。从日记第六天这个时间节点来看，项目应该已经进入关键的功能联调阶段。
我接触过的餐饮系统开发，第六天通常要解决三个核心问题：订单状态的实时同步、骑手路径规划的准确性、以及突发流量下的系统容灾能力。这三个痛点直接关系到用户体验和平台收益，也是技术团队最需要攻坚的地方。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 订单状态同步方案设计
2.1 状态机模型设计
外卖订单的状态流转比普通电商复杂得多。从技术实现来看，需要建立包含至少12个状态节点的状态机：
- 待支付 → 已支付 → 餐厅接单 → 备餐中 → 待取餐
- → 骑手已接单 → 取餐中 → 已取餐 → 配送中
- → 即将送达 → 已送达 → 已完成/已取消
我们在实际开发中发现，最容易出问题的环节是"骑手已接单"到"已取餐"这个阶段。很多团队会用简单的数据库字段更新来实现，这会导致：
- 状态覆盖问题（后到的更新覆盖先到的）
- 状态回退风险（比如已取餐被意外改回待取餐）
推荐方案：
java复制// 使用事件溯源模式
public class OrderStatusEvent {
private String orderId;
private Status newStatus;
private LocalDateTime timestamp;
private String operator; // 操作人：系统/骑手/商家
private String remark;
}
// 状态变更时先持久化事件，再更新聚合根
2.2 实时推送技术选型
经过对比测试，我们最终放弃了传统的轮询方案，采用WebSocket+MQTT混合方案：
- WebSocket维持长连接（适合APP端）
- MQTT协议保障弱网环境可达性（特别是骑手端）
- 消息压缩采用Protocol Buffers而非JSON（节省60%流量）
重要提示：一定要在协议头里加入sequence字段，我们曾因网络抖动导致消息乱序，出现"已送达"早于"配送中"推送给用户的重大事故。
3. 智能调度系统实现
3.1 路径规划算法优化
早期版本使用Dijkstra算法计算最短路径，实测发现两个致命缺陷：
- 未考虑餐馆出餐速度（导致骑手过早到达）
- 忽略实时路况（特别是学校周边的时段性拥堵）
改进后的算法框架：
- 基础路径计算：A*算法（比Dijkstra快40%）
- 动态权重因子：
- 实时交通数据（接入高德API）
- 历史出餐速度（餐厅维度）
- 天气影响系数（雨天+15%时间）
- 批量调度优化：
- 每30秒全量计算一次区域订单
- 采用贪心算法做初始分配
- 用遗传算法做二次优化
3.2 容灾方案设计
去年双十一我们遇到机房断电，总结了这套应急方案：
- 分级降级策略：
- 一级降级：关闭智能调度，切换人工派单
- 二级降级：停止非核心区服务
- 三级降级：仅保障KA商家订单
- 数据补偿机制：
- 本地事件日志+定时重试
- 使用LSTM预测丢失时段的数据
- 演练方案：
- 每月强制断网测试
- 随机kill节点进程
4. 性能压测与调优
4.1 测试环境搭建
建议使用真实硬件而非云主机，我们吃过亏：
- 云磁盘的IOPS虚标严重
- 网络带宽存在突发限制
硬件配置参考：
| 组件 | 最低配置 | 推荐配置 |
|---|---|---|
| 数据库 | 16C32G + NVMe SSD | 32C64G + RAID 10 |
| Redis | 哨兵模式3节点 | Cluster模式6节点 |
| MQ | RocketMQ 4C8G | Kafka 8C16G + 三副本 |
4.2 关键指标优化
订单创建接口的优化过程值得分享：
- 初始性能：TPS 120，平均耗时230ms
- 第一轮优化：
- 去掉不必要的@Transactional
- 改用批量插入
→ TPS 350，耗时90ms
- 第二轮优化：
- 本地缓存餐厅信息
- 异步写日志
→ TPS 800，耗时45ms
- 最终方案：
- 引入CQRS模式
- 事件溯源存储
→ TPS 1500+，耗时<20ms
5. 典型问题排查实录
5.1 幽灵订单问题
现象：偶尔会出现未支付订单自动完成
根因：状态机校验遗漏了支付状态
解决方案：
- 增加状态变更的前置校验：
java复制if(currentStatus == UNPAID && newStatus == COMPLETED) {
throw new IllegalStateException();
}
- 添加定时对账任务
5.2 骑手位置漂移
现象：APP显示骑手在河里/楼顶
排查过程：
- 确认不是GPS信号问题
- 发现坐标加密算法在部分机型兼容性问题
- 最终采用WGS84转GCJ02的改进算法
6. 项目演进建议
如果继续迭代这个项目，我会优先做三个改进：
- 引入强化学习优化调度（美团已公开的方案显示能降低8%配送成本）
- 实现订单的动态优先级调整（例如VIP用户/紧急医疗订单）
- 构建预测性扩容系统（基于时间序列预测负载）
这套架构经过618、双十一的考验，核心是保持各个组件的独立演进能力。最近我们在尝试用Wasm优化算法模块的计算效率，初步测试能减少20%的CPU占用。