外卖平台高并发架构实战：从微服务到分布式事务-育师

1. 项目背景与核心价值

"苍穹外卖"作为典型的互联网餐饮配送平台，其技术架构和业务逻辑蕴含着丰富的实战经验。这个复盘系列的价值在于：将看似常规的外卖业务流程拆解为可复用的技术模块，帮助开发者理解高并发分布式系统在真实场景中的落地细节。

我曾参与过多个O2O平台的后端架构设计，发现外卖业务虽然表面简单，但涉及订单状态机设计、实时位置追踪、智能派单算法等十余个关键技术点。本系列将用"问题驱动"的方式，还原这些技术决策背后的思考过程。

2. 技术架构全景解析

2.1 微服务拆分原则

苍穹外卖采用Spring Cloud Alibaba体系，其服务划分值得借鉴：

用户服务：独立处理认证授权，采用JWT+Redis实现无状态会话
订单服务：核心领域服务，包含状态机引擎和事务消息表
配送服务：集成第三方地图API，实现骑手路径规划
支付服务：封装多种支付渠道的差异，提供统一接口

关键经验：按业务能力而非数据表划分服务，配送服务之所以独立，是因为其需要单独扩展地理位置计算资源。

2.2 分布式事务方案选型

订单创建涉及多个服务调用，我们最终选用Seata的AT模式而非TCC，主要考虑：

业务容忍短时不一致（如支付状态延迟更新）
开发效率优先，AT模式对代码侵入性低
配合RocketMQ事务消息保证最终一致性

实测在200TPS压力下，采用异步补偿机制后事务成功率从92%提升至99.6%。

3. 核心业务逻辑实现

3.1 订单状态机设计

采用状态模式封装业务规则，关键状态转换包括：

// 简化的状态枚举定义 public enum OrderStatus { PENDING_PAYMENT, // 待支付 PAID, // 已支付 MERCHANT_CONFIRMED, // 商家接单 DISPATCHED, // 已派单 DELIVERING, // 配送中 COMPLETED, // 已完成 CANCELLED // 已取消 }

状态变更通过Spring StateMachine实现，配合规则引擎处理特殊场景：

用户取消订单需校验是否已出餐
骑手接单超时触发自动改派
支付超时自动关闭订单

3.2 实时位置追踪方案

使用MongoDB存储骑手轨迹数据，其地理空间索引支持高效查询：

// 地理位置数据格式 { "riderId": "RD2023001", "location": { "type": "Point", "coordinates": [116.404, 39.915] // [经度, 纬度] }, "timestamp": ISODate("2023-07-20T14:30:00Z") }

前端通过WebSocket每秒推送位置，结合GeoNear查询实现：

3km内最优骑手匹配
预计送达时间动态计算
配送热力图生成

4. 性能优化实战记录

4.1 缓存策略设计

采用多级缓存架构应对高峰流量：

本地缓存（Caffeine）：存储商家菜单等变更频率低的数据
Redis集群：缓存用户会话、优惠券库存等
防穿透方案：对NULL值设置短过期时间

缓存Key设计规范：

业务前缀:数据类别:唯一标识 例：user:session:u123456

4.2 数据库分库分表

订单表按用户ID哈希分片，配置示例：

# ShardingSphere配置 spring: shardingsphere: datasource: names: ds0,ds1 sharding: tables: t_order: actual-data-nodes: ds$->{0..1}.t_order_$->{0..15} table-strategy: inline: sharding-column: user_id algorithm-expression: t_order_$->{user_id % 16}

配合MyBatis-Plus实现透明访问，需要注意：

避免跨分片JOIN
分布式ID采用雪花算法
定期执行数据归档

5. 典型问题排查手册

5.1 订单重复支付问题

现象：用户点击支付按钮后因网络延迟重复提交解决方案：

前端防重提交（按钮禁用+Loading状态）
后端幂等设计（支付流水号去重）
对账系统定时修复异常状态

5.2 骑手位置更新延迟

根本原因：WebSocket消息堆积优化措施：

客户端位置采样（从1秒调整为3秒）
服务端使用Netty替代Tomcat WebSocket
重要状态变更走独立高优先级队列

6. 监控体系建设方案

6.1 指标埋点设计

核心监控指标包括：

指标类别	具体指标	报警阈值
业务指标	订单创建TPS	>5000/分钟
系统指标	Redis内存使用率	>85%
用户体验	列表页加载P99耗时	>800ms

6.2 日志收集架构

采用ELK+Filebeat方案：

Filebeat轻量采集
Logstash添加业务标签
Elasticsearch按天分索引
Grafana配置关键仪表盘

关键日志字段：

{ "traceId": "a1b2c3d4", "service": "order-service", "level": "INFO", "message": "订单状态变更", "orderId": "ORD202307200001", "fromStatus": "PAID", "toStatus": "MERCHANT_CONFIRMED" }

7. 安全防护实践

7.1 常见攻击防御

短信轰炸防护：
- 同一手机号60秒内限1次
- 图形验证码二次校验
接口防刷：
- 基于用户ID的令牌桶限流
- 敏感操作强制二次认证

7.2 数据安全措施

敏感数据加密：

// 手机号脱敏存储 @Column(columnDefinition = "varchar(64)") @Convert(converter = CryptoConverter.class) private String phone;

数据库审计：
- 开启Binlog记录
- 使用Druid监控SQL注入尝试

8. 持续交付流水线

8.1 代码质量控制

SonarQube检测规则示例：

圈复杂度 >15 的代码块必须重构
单元测试覆盖率 >=80%
不允许System.out日志

8.2 自动化部署

基于Jenkins的多环境发布流程：

开发环境：合并即部署
测试环境：Tag触发部署
生产环境：人工确认+蓝绿发布

Docker镜像构建要点：

# 多阶段构建示例 FROM maven:3.8-jdk-11 AS build COPY . /app RUN mvn package -DskipTests FROM openjdk:11-jre-slim COPY --from=build /app/target/*.jar /app.jar ENTRYPOINT ["java","-jar","/app.jar"]