老系统要改，用户不能停
公司里的订单系统跑了快八年，代码像老房子，墙皮掉了不敢敲太狠。这次要重构数据库结构，接口也得跟着变，可线上每分钟都有几千单进来，直接上线？谁也不敢拍这个板。
我们决定用灰度发布配合重构，一边改底层，一边让用户无感过渡。
先搭新架子，不拆旧路
第一步不是动老代码，而是把新服务跑起来。新版本用了更清晰的模块划分，数据库字段也做了归一化处理。两个版本共存，老系统继续接流量，新系统先挂上，但不对外暴露。
通过内部网关配置，我们把一小部分请求（比如 1%）导到新服务。这部分用户的行为不会影响主流程，但能真实跑通链路。
<!-- 网关路由规则示例 -->
<route name="order-service"
from="order-api"
to="order-service-v1" weight="99" />
<route name="order-service"
from="order-api"
to="order-service-v2" weight="1" />数据双写 + 对比校验
关键点在数据层。重构后表结构变了，但我们没停写老库。新服务在处理完请求时，同时往新老两个库写数据。
另外起一个对账脚本，定时比对两边的数据差异。比如同一笔订单，金额、状态、时间是否一致。发现不匹配就告警，回滚也不迟。
这就像装修房子时先铺好临时电线，等确认新线路没问题，再切断旧线。
逐步放量，问题早露早修
从 1% 放到 5%，再到 20%、50%，每次放大都观察半小时。监控面板盯着错误率、响应时间和日志异常。
还真发现问题：某个字段在老系统是字符串，新系统转成枚举后，第三方对接方传了空值，导致解析失败。要是全量上线，就得炸。现在只影响 5% 的请求，修复后重新部署，继续放量。
切换完成，老服务下线
当新服务稳定承载 100% 流量三天后，我们把老服务的入口彻底关掉，数据库停止双写，清理冗余字段。最后删掉老代码分支，整个重构闭环。
整个过程用户毫无感知，客服组甚至没收到一条投诉。技术团队也没熬大夜救火，这才是理想的重构。
灰度发布不是保险绳，而是手术刀。配合重构，能让“动心脏”变成“常规体检”。