当前位置：首页 > news >正文

《从单体到分布式：一个订单系统的架构升级》

news 来源：原创 2025/6/15 13:05:58

1. 问题爆发：单体架构的极限

原来的订单系统长这样：

技术栈：SpringBoot + MyBatis + MySQL（主从）
部署：单机跑所有模块（订单、支付、库存）
痛点：
- 接口响应慢：高峰期下单接口从200ms飙升到5s+
- 数据库扛不住：订单表超过500万行，order by create_time 直接OOM
- 耦合严重：改库存逻辑居然要重启订单服务

结论：单体架构在业务早期确实快，但流量上来后就是灾难。

2. 技术选型：微服务还是垂直拆分？

面对性能瓶颈，考虑过两种方案：

方案	优点	缺点
垂直拆分	改造成本低，风险小	治标不治本，扩展性差
微服务化	彻底解耦，独立伸缩	技术复杂度高，运维成本爆炸

最终选择 SpringCloud Alibaba，因为：

业务未来需要快速迭代（比如独立升级支付模块）
团队已有K8s集群，能解决微服务部署问题

3. 实战：订单系统的微服务改造

(1) 服务拆分

订单服务：核心下单逻辑，MySQL分库分表
支付服务：对接支付宝/微信，独立降级
库存服务：Redis缓存+异步扣减

(2) 引入关键组件

# Nacos 服务注册与配置中心
spring:
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848

# Sentinel 流控熔断
feign:
  sentinel:
    enabled: true

(3) 分布式事务方案

放弃强一致，改用最终一致性：

下单流程：
- 订单服务生成预订单（状态=待支付）
- 发MQ消息触发支付和库存预占
- 支付成功后更新订单状态
补偿机制：
- 定时任务扫描"待支付超时"订单
- 调用库存服务释放预占库存

// 伪代码：下单入口
@Transactional
public void createOrder(OrderDTO orderDTO) {
    // 1. 本地事务保存订单
    orderMapper.insert(order); 
    // 2. 发MQ消息（保证本地事务成功后发送）
    rocketMQTemplate.send("order-create-topic", order);
}