我们那个老平台，跑了快十年了，代码堆得跟喜马拉雅山一样高。每次想加点新功能，都得像考古学家一样，一层一层往里挖。所有人都知道，这系统迟早要崩，这就是我说的“宿命论”——早晚得重写，只是时间问题。
下定决心：启动“绅士游戏”
我接手这个烂摊子的时候，团队已经习惯了“打补丁”式的维护。内存泄漏跟家常便饭一样，每隔两个月就得半夜起来重启服务，搞得大家怨声载道。老板一直催着要提速降本，但不动手术，光吃药是没用的。我拍板了：必须彻底重写，但不能影响用户，更不能引发内部恐慌。这就是我们的“绅士游戏”规则：表面上要云淡风轻，背地里要干得滴水不漏。
我没有直接动现有的业务逻辑，那风险太大了。我们得从最核心、最不容易出错的地方开始下手——数据。
- 我们花了整整一个月时间，把数据库的读写权限彻底隔离了出来。
- 然后，我们把所有对旧系统的查询请求，全部通过一个定制的中间件，先做一层拦截。
这么干的目的，就是为了让新老系统在数据层面上，可以平行运行，互相不影响。
暗中操作：影子服务的部署
我们选择用Go来写这个新的核心服务，为因为它启动快，性能最重要的是，资源占用小，我们能用最少的钱跑出最好的效果。但是，新系统一上来就接流量，谁敢保证不炸？
我的方法是部署“影子服务”。
新系统上线后，它的主要工作不是服务用户，而是当个“小偷”。它会偷偷接收所有发给老系统的请求，然后进行双重处理：老系统继续返回结果给用户，新系统也处理一遍，但只把结果丢进一个临时的对比队列里。
那段时间，我们每天的工作就是盯着这个对比队列。我们写了一个自动化的脚本，专门做数据对比，看老系统吐出来的数据，和新系统吐出来的数据，是不是完全一样。但凡有一个字节不一样，立刻报警。
遭遇挑战与最终收网
你猜怎么着？刚开始那一个星期，报警声就没停过。不是新系统逻辑写错了，而是老系统里藏着太多我们自己都不知道的“土办法”。
比如有一个关于积分计算的接口，在老系统里，因为它太慢，程序员自己写了个定时脚本，每小时跑一次，所以接口返回的数字不是实时的，而是缓存的。新系统傻乎乎地实时计算，数据当然对不上。遇到这种“历史遗留问题”，我们只能一个个地去问当年的老员工，去填这些坑。
等到连续两周，对比系统的误差率稳定在万分之一以下的时候，我知道时机成熟了。我们开始逐步切流量：
- 第一步：先切内部员工的测试账号，让他们先体验。
- 第二步：切1%的边缘用户，观察他们的反馈和系统的负载。
- 第三步：在一个周末的凌晨，我们一咬牙，把剩下99%的流量全部指向了新系统。
那天晚上，我们所有人都守在监控屏幕前，大气都不敢出。当看到新系统的CPU负载只有老系统的五分之一，响应时间快了三倍的时候，大家悬着的心才放下来。
老系统终于可以体面地退役了。回头看，从我们发现老系统已经无法承载未来业务那天起，这回重写就是注定的结局。我们只是用一种体面、谨慎的“绅士”方式，完成了这场“宿命论”下的技术交接。干完这事，感觉像是还清了前几年欠下的技术债，舒服！