22、实战案例一：电商订单系统重构（下）- 逐步实施重构与验证
上一章我们拆解了订单系统的“病灶”，画好了重构的蓝图。这一章，咱们要动真格的了。
说实话，很多团队的重构死在“想一口吃成胖子”。我见过最典型的场景：架构师画了张完美的目标架构图，然后让团队一个月内全部改完。结果呢？线上事故不断，回滚都来不及。嗯，重构最忌讳的就是“大跃进”。
我个人习惯的做法是：小步快跑，每步验证。把一个大重构拆成若干个可独立上线的小步骤，每一步都能单独验证、单独回滚。这样风险可控，团队心里也有底。
第一步：剥离“订单查询”到只读库
为什么先动查询？因为查询是只读操作，不涉及数据写入。即使出问题，也不会产生脏数据。风险最低，适合练手。
具体怎么做？我建议分三步走：
- 搭建只读库：从主库同步一份数据到只读库。可以用 MySQL 的主从复制，也可以用 Canal 监听 binlog 同步到 TiDB 或 Elasticsearch。
- 改造查询接口：把订单查询的 DAO 层数据源切换到只读库。注意，这里要做一个开关（Feature Flag），方便随时切回主库。
- 灰度验证：先让 1% 的流量走新查询路径，观察响应时间和错误率。没问题再逐步放量到 10%、50%、100%。
核心原则：每一步都要有“回退按钮”。如果新查询路径有问题，一键切回老路径，用户无感知。
我在项目中遇到过一个问题：只读库的数据延迟导致用户查不到刚下的订单。解决方案是：对于“我的订单”这类实时性要求高的查询，强制走主库；对于历史订单查询，走只读库。这叫“读写分离的精细化策略”。
第二步：拆分“订单创建”到独立服务
查询搞定了，接下来动核心流程——订单创建。这一步风险高，必须慎之又慎。
我的策略是：先拆逻辑，再拆服务。也就是说，先在代码层面把订单创建的逻辑从单体应用中抽出来，变成一个独立的模块，但部署上仍然在同一个进程里。等逻辑稳定了，再把它拆成独立的微服务。
具体步骤：
- 抽取订单创建模块：在原有项目中新建一个 Maven Module，把订单创建相关的 Service、DAO、Model 全部移过去。确保编译通过，单元测试通过。
- 引入防腐层：订单创建模块不能直接调用用户模块、商品模块的 DAO，而是通过接口调用。这样未来拆成微服务时，只需要把接口实现从 RPC 换成 HTTP 或 gRPC。
- 独立部署：把订单创建模块打包成一个独立的服务，部署到新的服务器集群。老服务通过 RPC 调用新服务。
注意：拆分过程中，事务一致性是最大的坑。原来在单体应用里，订单创建、扣库存、加积分是在一个数据库事务里的。拆成微服务后，就需要引入分布式事务。我个人建议先用“本地消息表 + 定时任务”这种柔性事务方案，等业务量大了再考虑 Seata 或 Saga。
我曾经踩过一个坑：拆分后，订单创建成功了，但扣库存失败了，导致超卖。后来加了个“库存预扣”的补偿机制：创建订单时先预扣库存，如果订单最终未支付，定时任务释放预扣的库存。嗯，虽然不完美，但至少不会超卖了。
第三步：引入消息队列解耦“订单履约”
订单创建成功后，后续的履约流程（发货、物流、评价提醒）其实不需要同步完成。引入消息队列，把这些异步化，能大幅提升系统的吞吐量。
我推荐用 RocketMQ 或 Kafka。RocketMQ 的事务消息可以保证“订单创建成功”和“消息发送成功”的一致性，非常适合这个场景。
改造后的流程：
- 订单创建成功后，发送一条“订单已创建”的消息到 MQ。
- 履约服务消费这条消息，执行发货、物流等操作。
- 如果履约失败，消息进入死信队列，人工介入处理。
小技巧：消息体里不要只放订单 ID，最好把关键字段（用户 ID、商品 ID、金额）也带上。这样消费方不需要再查一次数据库，能减少一次 RPC 调用。这在双十一这种大流量场景下，效果很明显。
验证策略：每一层都要有“安全网”
重构不是写完代码就完事了。验证环节必须跟上。我一般会做三层验证：
| 验证层级 | 验证手段 | 验证目标 |
|---|---|---|
| 单元测试 | JUnit + Mockito | 每个方法的逻辑正确性 |
| 集成测试 | Testcontainers + 真实数据库 | 模块间的交互正确性 |
| 灰度验证 | 流量染色 + 监控大盘 | 线上真实流量的正确性 |
灰度验证这块，我习惯用“流量染色”的方式。给每个请求打一个标签（比如 header 里加一个 x-canary=true），新服务只处理带标签的请求。这样新老服务同时运行，对比结果。如果发现不一致，立刻排查。
我记得有一次灰度验证时发现，新服务的订单金额比老服务多了 1 分钱。查了半天，原来是浮点数精度问题。老服务用 double，新服务用 BigDecimal，四舍五入的规则不一样。嗯，这种细节，不灰度验证根本发现不了。
SVG：重构实施路线图
下面这张图，是我做重构时必画的路线图。它清晰地展示了每一步的输入、输出和验证点。团队照着这张图执行，不会跑偏。
避坑指南：我踩过的三个大坑
重构过程中，有些坑是共性的。我分享三个我亲身经历过的：
- 坑一：数据迁移丢数据。有一次从 MySQL 迁移到 TiDB，因为 binlog 解析程序有个 bug，导致部分历史订单没同步过去。后来我加了个“全量对账”的定时任务，每天凌晨比对源库和目标库的数据量，发现不一致就报警。从此再没丢过数据。
- 坑二：灰度流量没切干净。灰度验证时，新服务的一个 bug 导致所有流量都打到了新服务上，因为配置中心的开关没生效。嗯，从那以后，我要求所有灰度开关必须支持“本地配置文件 + 配置中心”双重保障，本地配置优先级最高。
- 坑三：依赖服务超时导致雪崩。订单创建服务依赖用户服务和商品服务。拆分后，用户服务的一次慢查询导致订单创建服务的线程池被打满，进而影响了其他接口。后来加了线程池隔离和熔断降级，才解决了这个问题。
总结一下：重构就像做手术，不能一刀切下去不管了。每一步都要有预案，每一步都要能回退。灰度验证不是可选项，而是必选项。记住：重构成功的标准不是“代码改完了”，而是“线上稳定运行了一周”。
好了，这一章的内容就到这里。下一章我们会进入另一个实战案例，看看支付系统的重构有哪些不一样的套路。