如何为含Azure SQL数据库的.NET应用实现带架构更新的零停机部署？

一、App Service Slots搭配数据库架构更新的核心流程 #

要实现零停机，核心是保证应用版本与数据库架构的双向兼容性，再结合Slots的流量切换能力，流程如下：

• 部署更新后的.NET应用到staging槽：新版本代码必须兼容当前生产库的旧架构，同时也要兼容即将更新的新架构（比如新增字段设为可空、新表不被旧代码调用）。
• 在staging槽验证数据库变更：先对Azure SQL执行兼容式的DDL操作（例如ALTER TABLE Orders ADD COLUMN TrackingNumber VARCHAR(100) NULL），然后测试staging槽的应用，确认新版本与更新后的数据库正常协作。
• 验证旧版本兼容性：确认生产槽的旧应用在数据库架构更新后仍能正常运行——这是零停机的关键，因为流量切换过程中旧版本还在处理请求，不能因为数据库变更挂掉。
• 执行槽交换：使用App Service的交换功能，流量会平滑切换到新版本，旧版本被移到staging槽。如果出现异常，立即回滚交换即可恢复到之前的状态。
• 清理冗余数据库对象：等新版本稳定运行一段时间后，再删除旧版本不再依赖的数据库对象（比如废弃的字段、过时的存储过程），这一步必须在流量完全切换后执行。

二、Azure SQL的"类Slots"隔离验证方案 #

Azure SQL没有直接对应App Service Slots的槽功能，但可以通过以下方式实现类似的隔离测试效果：

• 数据库副本/快照：创建生产数据库的只读副本或快照，在副本上执行架构变更，搭配staging槽的应用完成测试，确认没问题后再将变更同步到生产库。
• 事务性DDL操作：大部分常见的DDL操作（如新增字段、创建表）可以包裹在事务中执行（Azure SQL支持这类事务），如果变更失败可以快速回滚。注意：删除表、修改主键等操作无法通过事务回滚，需谨慎处理。
• 弹性池中的测试数据库：如果使用Azure SQL弹性池，可以在池中创建一个与生产库结构一致的测试库，先在测试库验证所有变更，再应用到生产环境。

三、关键最佳实践 #

• 强制双向兼容：任何代码或数据库变更都必须满足：新版本能跑在旧数据库上，旧版本能跑在新数据库上。比如新增字段不要加非空约束，修改业务逻辑时兼容旧数据格式。
• 拆分大变更为小步骤：不要一次性执行大量架构调整，拆分成多个小的、兼容的变更，每一步都验证后再推进。
• 使用自动化迁移工具：用Entity Framework Core迁移（dotnet ef migrations）、Flyway或Liquibase等工具管理数据库变更，确保变更可追溯、可重复执行，避免手动操作出错。
• 监控+快速回滚机制：槽交换后实时监控应用请求成功率、数据库连接数、错误日志等指标，一旦出现异常立即回滚槽交换；数据库变更如果出现问题，利用Azure SQL的自动备份恢复到之前的状态。
• 避开业务峰值：尽量在低流量时段执行部署和数据库变更，即使是零停机，也能减少潜在的并发问题影响范围。

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