这绝对是多租户SaaS部署里最头疼的问题之一——稍有不慎就会出现应用和数据库版本不兼容，导致部分甚至全部租户服务异常。我在做SaaS架构咨询的时候，帮不少团队落地过可行的方案，这里分享几个经过生产环境验证的思路：

1. 先兼容、再清理的双版本过渡策略（最常用） #

这是应对这类问题的黄金准则，核心是让应用先具备兼容新旧数据库状态的能力，再逐步完成数据库和应用的最终更新：

• 第一步：发布兼容型应用版本
  先上线一个同时支持旧schema和新schema的应用版本。比如你要给表加新列notification_settings，那要满足两个条件：
  • 数据库新列设为可空，或者配置合理的默认值；
  • 应用逻辑里：读取数据时如果没有这个列，就用预设的默认值（比如{"email": true, "sms": false}）；写入数据时，旧数据库环境下跳过该列的写入，新环境下正常写入。
    这个版本上线后，不管数据库是旧版还是新版，应用都能正常运行。
• 第二步：批量更新所有租户数据库
  这时候你可以放心地逐个（或批量）更新租户的数据库schema了——因为应用已经兼容两种状态，单个租户数据库更新期间，对应的应用服务不会出现版本不匹配的问题。如果是共享schema的多租户模式（所有租户用同一套表结构），那一次schema变更就能覆盖所有租户，这个步骤会更简单。
• 第三步：发布最终应用版本
  等所有租户的数据库都完成更新后，再上线移除了兼容逻辑的最终版本，彻底切换到新的业务逻辑上。

2. 蓝绿/金丝雀发布结合滚动租户迁移（云原生场景） #

如果你的架构是云原生的，能方便地做流量切换，那可以结合部署策略来降低风险：

• 蓝绿部署：先部署一套新版本的应用（绿环境），然后分批次将租户的流量从旧应用（蓝环境）切到绿环境，同时给对应的租户更新数据库schema。等所有租户都完成切换和数据库更新后，再下线蓝环境的旧应用。
• 金丝雀发布：先让小比例的租户（比如5%）使用新版本应用，同时给这部分租户更新数据库schema。验证没有问题后，逐步扩大比例，直到覆盖所有租户。这种方式能把风险控制在小范围内，适合对稳定性要求极高的场景。

3. 数据库schema的无中断迁移技巧 #

不管用哪种策略，数据库变更本身的无中断性也很重要：

• 避免破坏性变更：不要直接删除列、修改列类型这类会导致旧应用崩溃的操作。如果要替换旧列，先添加新列，逐步把数据迁移过去，等所有应用都兼容新列后，再废弃旧列。
• 使用在线schema迁移工具：比如PostgreSQL的pg_repack、MySQL的pt-online-schema-change，这些工具能在不锁表、不中断业务的情况下完成schema变更，尤其适合大表的更新。
• 事务化变更：如果是支持事务的数据库，把schema变更放在事务里执行，一旦失败能立即回滚，避免留下半更新的状态。

关键注意事项 #

• 一定要做灰度验证：先在测试租户或小比例租户上验证整个流程，没问题再推广到所有租户。
• 保留回滚路径：如果某个租户的数据库更新失败，要能快速把该租户切回旧版本应用，同时回滚数据库变更。
• 监控到位：更新期间要实时监控应用的错误率、数据库的性能指标，一旦出现异常立即暂停更新。

内容的提问来源于stack exchange，提问作者Timsen