EF Core Db Migrations结合滚动/金丝雀部署实现零停机方案咨询

1 禁用应用启动自动执行迁移 #

移除应用启动流程中所有调用context.Database.Migrate()的逻辑，迁移操作统一通过dotnet ef命令行工具或者独立的迁移执行任务触发，彻底杜绝应用实例启动时自动修改数据库结构的风险。
可以为应用运行时使用的数据库账号配置仅业务读写权限，移除数据库结构修改、__EFMigrationsHistory表写入权限，从权限层面兜底避免应用误执行迁移。

2 采用向后兼容的分阶段迁移策略 #

这是实现零停机部署的核心，要求每次数据库变更同时兼容当前线上旧版本和待发布新版本的应用：

• 所有结构调整优先做兼容改造：新增字段必须设置默认值或允许为空，禁止直接删除旧版本依赖的字段、表、约束，禁止直接修改旧字段的类型、非空等约束；字段重命名场景要先新增新字段，应用侧做新旧字段双写同步，全量升级完成后再删除旧字段
• 拆分迁移为两个独立阶段：
  • 预迁移阶段：仅新增结构、补充兼容逻辑，不删除任何旧版本依赖的数据库对象，执行完成后旧版本应用可完全正常运行，新版本应用也可正常运行
  • 清理迁移阶段：待所有应用实例全量升级到新版本、稳定运行且确认无回滚需求后，再单独执行，仅用于删除废弃的字段、表、约束等冗余结构

3 调整部署流程适配迁移逻辑 #

• 滚动部署/金丝雀发布开始前，先单独执行预迁移，校验数据库兼容新旧版本后再启动应用实例的升级流程
• 金丝雀发布阶段可先将小比例流量切给新版本实例，验证业务无异常后再逐步扩大升级范围
• 升级过程中如果出现问题，直接将全量流量切回旧版本应用即可，无需回滚数据库，预迁移的兼容设计可保障旧版本完全正常运行

4 异常回滚预案 #

• 全量升级完成前的回滚：直接切回旧版本应用即可，无需操作数据库
• 已执行清理迁移后的回滚：需先执行对应版本的回滚迁移恢复被清理的数据库结构，再回滚应用版本，因此清理迁移必须在确认无回滚需求后再执行

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