non-stop，这词听着挺唬人，感觉就是不能停，一直干呗？我刚开始接触这个概念的时候，也是这么想的，觉得这事儿跟上了发条的机器似的，嘎嘎转，永不停歇。可真要自己实践起来，才发现，这玩意儿，比我想象的要复杂得多。
项目重启
我记得那是三年前，我们有个核心系统老跑在几台老旧的物理机上，那时候还没有搞什么虚拟化和容器。老板拍着桌子说，要搞“不间断服务”，那会儿刚接触到这个概念，大家一听，都激动了，觉得技术部门要搞个大新闻。
我们第一步就是想办法把服务拆开。我带着两个小兄弟，熬了好几个通宵，对着那堆紧耦合的代码下手。那代码写得，跟意大利面条似的，一根线牵着好几条业务逻辑。我们拿着 Visio，画了又擦，擦了又画，硬着头皮先把用户登录、请求校验这块剥离出来，弄了个小的 API 网关服务。这第一步，光是把依赖关系捋清楚，就折腾了一个星期。
数据迁移的坑
接着就是最头疼的数据库。咱们这套系统，数据量还真不小，关键是实时性要求高，不能说停就停。我们研究了半天，决定搞个双写策略，先在新的架构里把数据写进去，然后对比老库，确保一致性。
我记得有一次半夜，我们启动了首次全量同步。我盯着那台老服务器的 CPU 跑了全程监控，生怕一个操作不对就让业务崩了。同步过程中，发现有个定时任务卡住了，导致部分数据没拉过去。我赶紧远程连上老服务器，手动清理了那个任务的锁，重新触发同步。等数据对齐，我看了眼时间，凌晨四点半，那一刻感觉自己像个值夜班的灯塔看守员，生怕自己一瞌睡，整个海面都陷入黑暗。
切换的瞬间
等新服务在新硬件上跑了两周，性能测试、压力测试都通过了，老板拍板，要切到新服务上。
我们选了个周日的凌晨两点，这会儿业务量最低。我提前半小时就坐在机房了，戴着耳机，手里拿着操作手册，像个外科医生准备开颅一样紧张。第一步，修改 DNS 解析，将流量导向新集群。我敲下命令，按下回车，然后就死死盯着监控面板。流量开始跳变，从老机器到新机器，曲线一点点爬升。
一开始挺顺利，流量上去了，CPU 负载也稳定。我心里稍微松了口气，准备着手关闭老服务器的业务端口。就在我准备执行第二步指令的时候，监控上突然冒出一个红色警告，一个关键的缓存服务响应变慢了！
我立马一个急刹车，想都没想，直接在操作手册上写下“回滚”两个字。我迅速把 DNS 解析切回老机器，整个过程不到三分钟。等流量全部回过去，老系统的指标恢复正常。我擦了擦额头的汗，心想，差点就栽在这里。
真正的 Non-Stop
那天我们没敢再尝试切换，第二天接着修补缓存问题。后来我们发现，不是新代码写的有问题，而是新环境的防火墙策略把某个 UDP 端口给限制了，导致缓存自动发现机制出错了。
等到我们彻底把防火墙策略搞定，再次切换的时候，感觉就轻松多了。流量平稳过渡，老服务彻底下线。那一刻我才明白，non-stop 不是说你一次操作就一劳永逸了，它是一个过程，是你有能力在出现问题时，能迅速、无感知地把服务导向备用路径，并且能让你在短时间内恢复正常的能力。它是“失败可控”的艺术，而不是“从不失败”的空谈。整个过程中，我发现我自己在想的不是怎么保证不犯错，而是，万一犯错了，我怎么能在别人还没察觉的时候，就把坑填平了，然后继续往前跑。这才是真正的 non-stop。
