核心内容摘要
张婉莹的暑假作业：当创意遇上“内卷”，一场奇幻漂流的诞生
代码重构如何与原有代码兼容企业落地版目标在不影响线上稳定性的前提下让新旧实现可共存、可灰度、可回滚并逐步把流量/调用迁移到新代码上。
先把“兼容”说清楚你要兼容什么重构时的“兼容”通常包含 5 类API 兼容请求/响应字段、语义、错误码、幂等等不变行为兼容边界条件、默认值、排序规则、精度/舍入、超时重试等不变数据兼容数据库结构、历史数据、索引、唯一约束、数据校验规则不破坏依赖兼容对外部系统MQ/缓存/第三方的交互协议、topic/key、数据格式不变运维兼容监控指标、日志结构、告警规则、SLA 口径尽量不变否则排障会很痛一句话别人怎么调用你、怎么查你、怎么排障你都不要被重构吓到。
最核心的落地策略让“新旧实现共存”
1 外观层/门面Facade——保持入口不变保留原有的 Controller / Service 接口把内部实现替换为可切换的“门面”。
优点调用方 0 改动缺点门面层要做好路由、监控、兜底示例SpringpublicinterfaceOrderQueryService{OrderDTOquery(LongorderId);}ServicepublicclassOrderQueryFacadeimplementsOrderQueryService{privatefinalOldOrderQueryServiceoldImpl;privatefinalNewOrderQueryServicenewImpl;privatefinalFeatureSwitchfeatureSwitch;OverridepublicOrderDTOquery(LongorderId){if(featureSwitch.isNewQueryEnabled(orderId)){returnnewImpl.query(orderId);}returnoldImpl.query(orderId);}}关键点入口不动只换内部实现切换策略建议“按用户/店铺/订单号取模”实现稳定灰度
2 适配器Adapter——新实现适配旧接口/旧数据当新代码模型更合理但旧接口/旧库结构短期改不了用适配器做“翻译”。
publicclassNewToOldOrderAdapter{publicOldOrderDTOadapt(NewOrdernewOrder){OldOrderDTOdtonewOldOrderDTO();dto.setId(newOrder.getOrderId());dto.setAmount(newOrder.getPayAmount().toPlainString());// ...returndto;}}适配器的价值把“脏兼容逻辑”集中隔离避免污染核心域模型。
3 绞杀者模式Strangler Fig——按能力/场景逐步替换不要“一次性重写”。
按“最容易切、收益最大、风险最小”的路径拆先把纯查询迁到新实现无副作用最安全再迁弱一致写可补偿最后迁强一致核心写路径下单、扣减、支付迁移顺序常用优先级只读接口异步链路低频写接口核心写接口最后
API 兼容接口别随便动真要动也要“可并存”
1 兼容性改动 vs 破坏性改动兼容性改动新增字段响应新增字段一般 OK新增枚举值注意客户端是否做了严格校验扩展错误码不改变老错误码语义破坏性改动删除/改名字段改变字段类型string→number改变默认值/排序/分页语义改动幂等语义
2 版本化推荐对外 API 必做URL 版本/api/v1/orders、/api/v2/ordersHeader 版本Accept: application/vnd.xxx.v2json落地建议新旧版本并存一段时间明确下线窗口配合监控“谁还在用 v1”
数据兼容数据库怎么改才不会炸
1 最稳的三步先加、再写、最后删绝对不要先删字段/改类型。
Step 1扩展不影响老代码新增列允许 NULL / 给默认值新增索引注意加索引锁表风险线上要用在线 DDL新增表旁路表Step 2双写/回填写入时新旧字段都写dual write异步回填历史数据job 校验Step 3切读 清理流量切到新字段/新表读观察稳定后再删旧字段/旧表一定要留足回滚窗口
2 双写的坑以及怎么补双写最常见的问题新旧写成功/失败不一致部分失败时序问题导致读到“半迁移态”回滚时数据不完整实战建议双写时以旧为主新为影子先保证旧链路稳定新写失败打点告警补偿队列别在主链路硬失败用 MQ/CDC 做异步同步会更稳尤其跨服务
行为兼容最容易被忽略但最容易出事故
1 建“行为合同”Contract写清楚旧实现的行为空值/缺失字段怎么处理金额精度/舍入方式排序规则分页page 从 0 还是 1size 最大多少错误码哪些场景返回哪个 code幂等重复请求返回什么然后对新实现做契约测试Contract Test用同一套输入跑新旧实现对比输出差异允许白名单差异把对比报告做成 CI gate不通过不准合并
2 “影子流量 / 回放”是神器线上主请求走旧实现同步/异步把同请求喂给新实现不影响用户对比响应差异积累差异样本注意脱敏/合规别把用户隐私乱写日志新实现要做限流避免被影子流量拖死
发布与切流让风险变成“可控的小步”
1 开关Feature Flag是重构的安全带常用开关粒度全局开关一键全开/全关按用户/店铺/订单取模灰度按接口/能力点开关最推荐开关必须满足实时可切配置中心可回滚秒级切回旧实现有审计谁什么时候切的
2 灰度策略建议从保守到激进白名单内部账号1% / 5% / 10% 按哈希灰度分城市/分机房全量每一步至少观察P99 延迟错误率5xx/业务失败核心业务指标下单成功率、支付成功率
回滚策略别把自己逼进死角
1 回滚必须“预设计”能回滚的前提是旧实现没删数据仍能被旧实现读取/解释新字段写失败不会让旧实现崩
2 常见回滚套路开关回滚最优秒级版本回滚次优分钟级依赖发布系统数据回滚最差成本高、风险大所以别让“数据结构大改”成为唯一方案。
常见场景的“兼容打法”
1 重构 Service 层但 Controller 不动Controller 调用 FacadeFacade 内路由新旧 Service输出 DTO 保持旧结构内部用适配器
2 拆微服务单体 → 服务化先抽出“查询”服务最简单对外仍由原服务提供 API内部转 RPCBFF/Facade逐步把写链路迁走期间用 MQ 保持数据同步
3 引入新缓存/新索引先“写入新缓存但不读”shadow write后“读新缓存失败再回源旧逻辑”read fallback命中率稳定后再切主读
最小可行的兼容落地清单拿去当检查表
1 设计阶段兼容范围定义清楚API/行为/数据/依赖/运维新旧共存方案Facade/Adapter/Strangler灰度策略 开关设计回滚路径明确至少开关回滚
2 开发阶段旧行为合同文档默认值、错误码、排序、幂等契约测试新旧对比影子流量/回放对比如适用日志/指标埋点一致或做映射
3 上线阶段白名单灰度 → 小流量 → 全量观测看板P99/错误率/核心业务指标告警联动新实现失败率阈值触发自动回滚可选回滚演练至少预发演练一次
一个“很现实”的经验别追求 100% 行为一致有些差异是合理的比如更严格的参数校验更标准的错误码性能优化导致的超时口径变化做法对差异建立白名单并在契约测试里显式声明让差异“可见、可解释、可追踪”不要偷偷改
结尾你真正要追求的是“可控变化”重构不是把代码写得更优雅而是把系统从“改一点就炸”变成“小步迭代、随时回滚、指标可见”。
只要你做到新旧共存 可灰度 可回滚 有契约测试大部分重构都能稳着落地。