订单系统的架构演进——从单体订单到事件驱动的 CQRS 架构重构一、单体订单的困境不是扛不住量而是改不动逻辑很多团队对订单系统的第一反应是性能不够需要拆分。但实际排查后我们发现早期单体的真正瓶颈不是 QPS而是代码的耦合度。一个OrderService里有下单、支付回调、退款、状态机、库存扣减、积分发放、对账逻辑改一个字段需要理解几千行代码。业务方提出新需求——比如增加拼团配置、预售逻辑、拆单规则——每加一个特性都需要在同一个 Service 里塞更多分支。一次支付模块升级因为改动了订单状态流转逻辑导致退款模块的一个边缘场景出现数据不一致。排查了六个小时原因是订单表上同时有下单写入、支付更新、退款更新和对账读取读写路径缠绕在一起。从这个事故开始团队决定把订单系统拆分为命令端和查询端走 CQRS 路线。二、重构路线从单体分拆到事件驱动不是一蹴而就CQRS 的核心是把修改和查询的模型分开。命令端持有订单的写模型包含全量状态和业务规则负责处理下单、支付、取消、退款等操作。操作完成后发布领域事件到消息队列下游的查询服务、库存服务、积分服务、风控服务各自消费事件更新各自的读模型。迁移策略选了分阶段进行。第一阶段把查询接口分离订单列表、详情、导出和统计的读接口都切到OrderQueryService底层走 ES 索引和缓存命令端不再直接提供查询。第二阶段在命令端内部引入领域事件先用 Spring 事件机制在进程内发布验证事件模型设计合理后再切到消息队列。第三阶段才把下游消费者从命令端剥离改为独立服务消费事件。每一步都有回退路径不是大爆炸式重构。三、命令端示例聚合根 事件溯源的设计思路命令端的订单聚合根只关注状态管理的正确性。下面是一个简化的下单处理示例。public OrderAggregate createOrder(CreateOrderCommand command) { // 构建订单聚合根 OrderAggregate order OrderAggregate.create( OrderId.next(), command.buyerId(), command.items(), command.address()); // 校验业务规则 ValidationResult result order.validate(); if (!result.isValid()) { throw new OrderValidationException(订单校验失败 result.errors()); } // 触发领域事件 ListDomainEvent events List.of( new OrderCreatedEvent(order.getOrderId(), order.getItems(), order.getAmount()), new InventoryReservedEvent(order.getOrderId(), order.getSkuQuantities())); // 持久化聚合 事件同一事务 orderRepository.save(order, events); // 事务提交后由事件发布器异步发送到消息队列 return order; }事件溯源做不做要看业务场景。订单系统对历史状态追溯有强需求——退款时要看当时下单的金额、支付方式的快照、使用的优惠券。我们采用的是部分事件溯源订单金额、状态、支付方式等核心字段通过事件驱动更新但像备注、收货地址等纯信息字段直接更新不做事件消费。这样避免了全量事件溯源带来的存储膨胀和重放复杂度。查询端的读模型设计也有讲究。订单查询服务不是简单把写模型的数据同步到 ES而是按查询场景定制索引结构。用户端订单列表需要按买家 ID、状态、时间范围查询商家端需要按商品 ID、店铺 ID、物流状态查询。两种查询的字段不同排序方式不同索引策略也不同。我们在查询端维护了两套读模型由不同的事件处理器各自更新。四、生产关注点最终一致性和事件可靠性CQRS 引入的最大挑战是最终一致性。命令端写成功并发布事件后查询端的读模型可能存在短暂的延迟。这个问题不能回避需要从两个层面处理。技术层面事件消费需保证 at-least-once 投递、消费端幂等处理、死信队列兜底。产品层面对用户明确提示状态同步延迟例如支付成功后列表页刷新间隔设为 2 秒。幂等性是事件消费的第一要务。我们采用订单 ID 加事件类型加事件时间戳的唯一键做幂等消费端在处理前先查幂等表。对于事件乱序问题——例如先收到退款事件再收到支付事件——在消费端做状态机校验只允许合法的状态转移。事件失败的处理也不能一概而论。库存扣减失败需要回滚订单状态并通知用户积分发放失败只需要重试和告警不影响订单主流程对账消费失败只需记录并延迟重试不阻塞其他消费者。我们定义了三级事件重要性核心事件影响业务闭环、次要事件影响辅助功能、审计事件只影响数据记录分别配置不同的重试策略和告警级别。五、总结订单系统从单体到 CQRS 的重构重点是把改和读的模型分离开让命令端专注业务规则查询端按场景定制。事件驱动的异步解耦带来了最终一致性的复杂度但只要幂等、降级、监控做到位这些复杂度是可控的。分阶段迁移比大爆炸更安全每一步保留回退路径才能让业务在架构演进中持续保持可用。
