凌晨两点，群里又弹出一条告警。核心订单库连接数满了。值班的人一边骂，一边去翻十年前的存储过程。那东西没注释，作者早离职了。遗留系统改造，往往就是从这种时刻被提上日程。可一旦立项，很多人第一反应是——推倒重来。
我见过一个团队，花半年重写商品中心，上线前才发现促销规则里藏着一堆人工审批例外。老系统丑，但它把坑都踩过。新系统漂亮，踩坑从零开始。说实话，这不是技术选型问题，是风险问题。
重写像搬家 但老房子还住着人
遗留系统改造最怕的不是代码老，是业务规则没有唯一真相。它们散在存储过程、定时任务、手工表、离职员工的脑子里。你问业务方，业务方说系统就是这么跑的。你问运维，运维说别动，动就挂。
所以更稳的路径是绞杀者模式。在旧系统前面挡一层路由，新功能走新服务，旧功能慢慢搬。像给老楼加电梯，不能把住户赶出去。麻烦在于路由。同一个用户，一会儿走新，一会儿走旧。会话、权限、事务边界，全要理。说白了，这就是个取舍。切得猛，故障面大；切得慢，双跑成本高。
我比较认同一句话：先让新系统在边缘活下来，再往核心走。别一上来就碰下单和支付。先剥报表、通知、导出。这些模块读多写少，坏了还能人工补。
数据是硬骨头 表结构会撒谎
文档写字段必填，实际一堆空值。状态码有七种，代码只认五种。外键？不存在的。孤儿数据靠人肉清理。迁移前先做数据画像：空值率、枚举分布、重复主键、时间戳异常。别信文档，信查询结果。
先把只读流量切走，再动写路径。写路径是心脏，碰之前准备好回滚。双写是常见选择。新库写一份，旧库写一份。代价是写放大、延迟、失败补偿。对账跑不平，半夜爬起来查。这事没那么玄，就是脏活。谁做谁知道。
对账不是迁完跑一次，是持续跑。差异表要留，回滚脚本要测。灰度要能按用户、按地区、按业务类型切。别嫌麻烦。真出问题的时候，能回滚就是救命。
组织问题比技术问题更早爆发
老系统维护者往往是最忙的人。新项目要人，只能抽他。抽走一半，旧系统着火没人救。业务方不关心架构，只问什么时候加功能。于是改造变成地下工作。白天做需求，晚上写新服务。
怎么破？把改造目标翻译成业务收益：发布频率、故障恢复时间、报表时效。别只说技术债。留出救火预算。代码所有权要清晰。接口契约先定，哪怕先用文件传输顶着。
没有业务方买单的改造，最后都会变成技术团队的自我感动。这话难听，但现场经常这样。你拆得再漂亮，业务只感知到一次停机，信任就没了。
拆到哪一步算够
微服务不是终点。有的模块拆完，调用链长了三倍，排查故障要开五个窗口。模块化单体也能救急。先定边界，不急着拆进程。等团队、监控、发布流程跟上了，再拆不迟。
观察指标别只看CPU。成功率、延迟、队列积压、对账差异、回滚次数，这些更诚实。改造不是一次大扫除，更像长期透析。慢慢过滤，维持生命，等新器官长好。
有人问，到底值不值。我的答案：看你能不能接受继续为不可知买单。改造有代价，不改也有代价。只是后者通常来得更晚，账单更吓人。先切一个只读接口，先跑通对账，先让旧系统少一个定时任务。每剥掉一层，就多一点呼吸空间。
别等完美方案。完美方案通常不会来。