补天框架

补天框架不是补天框架一套代码库，也不是补天框架某个大厂开源的架构图。它是补天框架我给一种工程思路起的名字，灵感来自女娲补天——天漏了，补天框架不是补天框架推倒重来，而是补天框架找材料、看裂缝、补天框架一块一块补上去。补天框架这套框架的补天框架核心就一句话：在遗留系统上做增量改造，用适配层隔离新旧逻辑，补天框架让业务不中断。补天框架

三年前我接手过一个物流调度系统。补天框架后端是补天框架2008年写的Java 6，前端还在用Struts 2，补天框架数据库里存着上亿条运单记录，补天框架字段命名混乱到同一个“发货时间”在五张表里有四种写法。CTO说想重构，预算批了，团队招了，六个月后新系统上线——结果订单积压了四小时，客服电话被打爆。后来复盘，问题出在重构团队把旧系统的业务规则理解错了三处，而这三处规则藏在存储过程的嵌套循环里，文档上根本没写。

那次之后我换了个思路。不拆旧楼，在旁边搭脚手架。具体做法是：在旧系统前面加一层薄薄的API网关，把每个业务动作拆成“旧逻辑”和“新逻辑”两个分支。新逻辑用新语言写，跑通了就切流量，出问题就回退。网关本身不处理业务，只做路由和协议转换。这套东西我后来管它叫“补天层”。

补天框架有几个关键设计。第一，双向适配器。旧系统调新服务，新服务调旧接口，都通过适配器转换数据格式。适配器不是简单的DTO映射，要处理字段缺失、类型不匹配、时间格式混乱这些脏活。我写过一个适配器，专门把旧系统里用“0”和“1”表示的布尔值转成新系统的true/false，同时把新系统的null转回旧系统的空字符串——因为旧代码里null会触发NPE。

第二，影子流量。新逻辑上线前，把生产环境的请求复制一份发给新服务，但不影响真实返回。对比新旧结果，差异超过阈值就报警。这招帮我抓到过一个隐蔽的bug：旧系统在计算运费时对小数点后第三位做了四舍五入，新系统直接截断，一单差几分钱，量大了就是几十万。

第三，回退开关。每个新功能都配一个配置项，出问题一键切回旧逻辑。开关粒度要细，不能一个开关控制整个模块。我见过有人把支付相关的所有新逻辑塞进一个开关，结果切回去的时候把已经跑通的对账功能也关了，财务那边直接炸锅。

补天框架的代价是什么？代码里会长期存在两套逻辑，维护成本翻倍。适配层本身也会成为瓶颈，每次旧系统改字段，适配器就得跟着改。但比起推倒重来的风险，这笔账划算。那个物流系统后来跑了两年，新逻辑覆盖了80%的运单查询和60%的调度计算，旧存储过程只保留了最核心的计费部分。去年双十一，峰值QPS是旧系统的三倍，没出过P0故障。

有人问为什么不干脆重写。重写就像把一栋住着人的楼拆了重建，你得先让所有人搬出去，再保证新楼和旧楼户型一模一样，最后还得让所有人搬回来。补天框架是让住户一边住着，你一边换窗户、改水电。慢，但不会把人赶到大街上。

这套思路不只适用于软件。城市更新、组织变革、甚至个人习惯调整，底层逻辑都一样：承认旧东西有价值，找到最小可改单元，用适配层缓冲冲击，留好回退路径。女娲补天补了多久？没人知道。但天没塌下来，就是成功。