从“能用”到“优雅”：一次支付系统重构中的架构熵减实战
在多数技术团队中，“能跑就行”往往成为系统腐化的第一块多米诺骨牌。我曾参与一个运行五年的支付核心系统，单体应用、存储过程混用、状态机散落在各处——业务每新增一个渠道，就要复制粘贴上百行代码。表面上看功能都在，但每一次发布都像在雷区跳舞。这次重构并不是推倒重来，而是采用“熵减”策略，像做手术一样逐步切除坏死组织，最终让系统重新变得可解释、可扩展、可测试。
技术债不是无缘无故产生的，而是来自“局部最优”的长期叠加。 刚开始团队为了快速上线，把订单状态判断写进SQL，把支付回调逻辑塞进同一个Controller；后来为了兼容某个特殊商户，又添加了无数个if分支。每个改动在当时都是“合理”的，但累积起来就成了“蝴蝶效应”的温床。我们统计过，核心支付链路中超过60%的代码从未被单元测试覆盖，而故障率最高的模块恰恰是那些“最灵活”的地方——所谓灵活，其实是没有任何约束的混沌。
在这次重构中，我们确立了一个核心观点：架构的优雅不在于用了多少高级技术，而在于把复杂逻辑约束在清晰的边界内。 我们引入了领域驱动设计（DDD）的思想，但没有机械地照搬战术模式，而是先把支付行为抽象成“指令-确认-补偿”三个领域事件。原本散落在存储过程中的状态流转，全部上移到应用层，由显式的状态机管理。数据库表仍然存在，但不再承担业务判断——它回归了“持久化容器”的本分。仅仅这一步，就让线上紧急故障的数量下降了约40%。
更关键的实战技巧是“渐变式重写”。我们没有单独搞一个“重构分支”去憋大招，而是采用绞杀者模式：在旧系统旁边构建新模块，通过路由层将新流量逐步切到新代码上。每当一个接口迁移完成，旧代码就立即删除，而不是继续保留“双写开关”。删除是熵减最有力的手段——每一个不再需要的分支、每一段注释掉的代码、每一个多余的抽象，都是架构质量的负资产。重构期间，我们每周进行一次代码评审，重点不是检查功能，而是检查是否有新引入的重复和隐式依赖。
另一个被严重低估的是“可观测性”对重构的护航价值。以前我们只有日志，没有链路追踪，出了问题只能凭猜。这次我们首先完善了traceId贯穿全链路，并画出核心链路的时序图。然后我们基于这个时序图去拆分模块，而不是靠想象。事实证明，很多所谓的“核心依赖关系”其实是历史包袱，真正的依赖比我们想象的要简单得多。当我们把无用的耦合剥掉后，新架构的复杂度甚至比老架构还要低——重构的目标从来不是增加代码，而是减少真正需要维护的认知负荷。
最后想说的是，重构最难的其实不是技术，而是团队对“干净代码”的一致追求。 如果没有统一的定义，代码风格很快会倒退到混乱。我们为此制定了一份只有三页的“架构规范手册”，明确什么可以做什么不可以做，比如禁止在Controller写业务逻辑、禁止跨服务直接访问对方数据库表、禁止用异常控制正常流程。这些规则本身并不新颖，但一旦被严格执行，系统就能保持在一个低熵状态。这次项目实战给我的最大启示是：技术债务永远无法一次还清，但我们可以建立一个持续“还债”的机制，让系统每天比昨天更优雅一点。