交换部署槽前将100%流量路由至staging槽是否可行？

可行性结论 #

这个方案完全可行，是解决App Service槽交换强制用户下线问题的成熟思路，尤其适配老旧架构无法做无缝升级的场景。

核心逻辑验证 #

• 流量路由切换：将staging槽流量占比设为100%后，所有新请求会直接路由到staging的新版本，production槽不再接收新连接，不会干扰正在使用的用户。
• 现有连接保留：production槽上已建立的用户连接（包括长连接）会维持到自然结束（用户主动关闭、会话超时等），不会被强制中断。
• 槽交换无影响：当production槽无活跃连接时执行交换，操作仅切换两个槽的配置与路由规则，已路由到staging的现有连接不会受到任何影响——因为交换不会重启或替换staging的实例，只是将其角色切换为production槽，已建立的连接会持续保留在原实例上。

是否值得投入时间研究 #

绝对值得，理由如下：

• 零额外成本：无需修改老旧架构代码，仅通过调整App Service的流量分配规则和等待逻辑即可解决问题。
• 可自动化落地：可以将整个流程脚本化：
  • 自动将staging槽流量设为100%
  • 定期查询production槽的活跃连接指标
  • 连接数清零时自动触发槽交换
  • 交换完成后按需调整流量分配
• 彻底解决用户体验问题：完全避免了槽交换时的强制下线，大幅提升用户体验，同时保留了槽交换带来的发布优势。

注意事项 #

• 确保应用会话状态使用分布式存储（如Redis）而非实例本地内存，避免流量切换后新用户无法访问旧会话（若架构已有此问题，槽交换本身也会触发同样问题，本方案不会新增风险）。
• 提前测试长连接场景（如WebSocket、Server-Sent Events），确认production槽的长连接会自然终止，staging槽的长连接不受交换操作影响。

内容的提问来源于stack exchange，提问作者Jan van Veldhuizen