很多人一听到“系统重构”就紧张，觉得肯定要停机维护，网站得挂个“正在维护”的页面，用户进不来，老板急得跳脚。其实，重构不一定非得停机。
什么时候可以不停机？
如果你的系统设计得够灵活，比如用了微服务架构，各个模块拆得清楚，那完全可以一部分一部分地换。就像装修房子，不用整栋拆了重建，可以先改厨房，再翻卫生间，边住边改。数据库加个新字段、接口做一层兼容，老系统照常跑，新功能悄悄上线，用户根本感觉不到。
举个例子，你原来有个订单查询接口返回的是 XML，现在想改成 JSON。可以在一段时间里两个都支持，等所有调用方都切过去，再把旧的删掉。这种渐进式重构，压根不需要停机。
什么时候必须停机？
但有些情况躲不过。比如你要把整个数据库从 MySQL 换成 PostgreSQL，表结构大变，字段类型不兼容，迁移数据还得保证一致性。这时候就得停服，不然一边写一边迁，数据乱了谁也兜不住。再比如单体应用直接重写，旧代码全删，新系统没跑稳之前不敢切流量，那就只能挑个半夜，用户最少的时候停机上线。
还有种常见情况：依赖第三方的老系统，人家只认特定格式，你没法搞双写兼容。这时候重构就像换心脏，必须断电几分钟。
怎么减少停机时间？
就算非停不可，也能压缩时间。提前做好迁移脚本，测试环境跑熟了，正式切的时候一键执行。比如数据库迁移，可以用工具先同步大部分历史数据，上线时只差最后几分钟的增量，这样停机可能就两三分钟。
pg_dump -h old_db > backup.sql
psql -h new_db < backup.sql
# 增量同步脚本启动
python sync_delta.py --since=last_timestamp另外，灰度发布也是好办法。先让10%的用户走新系统，没问题再慢慢放大。哪怕出问题，影响也小，回滚快。
所以别一听重构就慌。关键看你怎么设计、怎么拆步骤。能不停机当然最好，真要停，也得让它短到用户 barely notice。