Azure App Service交换部署槽位是否会影响运行中的长耗时作业？

核心结论 #

默认配置下，执行生产/暂存槽交换时，你正在跑的1-3分钟长耗时请求一定会被中断，根本跑不完。

底层逻辑说明 #

• 槽交换不是大家想象的「原子化切流量路由」，交换执行过程中Azure平台会先对两个槽位的实例做配置对齐、工作进程回收：原本承接生产流量的生产槽实例，会先触发托管进程（对应.NET Core应用就是承载Kestrel的w3wp/dotnet工作进程）的优雅关闭流程，等超时窗口到了就强制杀进程。
• Azure App Service默认给工作进程留的优雅关闭等待窗口只有30秒，也就是说进程收到关闭信号后，最多等30秒给正在处理的请求收尾，超过时间没跑完的请求会被直接断开连接、强制终止，你的1-3分钟的任务远长于这个默认窗口，必然会被打断。

别信网上说的「交换时旧实例会等所有请求跑完再下线」的错误说法——交换过程的进程回收动作是在流量完全切走之前就触发的，根本不会给长请求留足够的等待时间。

规避方案 #

如果要避免长请求被交换操作打断，可以按实际场景选下面的方案：

• 调整进程关闭超时配置：你可以通过修改托管配置把shutdownTimeLimit参数调大，Azure环境下这个参数最大支持设为10分钟，足够覆盖你1-3分钟的请求耗时。注意这个配置必须同时部署到生产、暂存两个槽位，不然任意一侧槽位在交换时触发回收都可能打断请求。
• 从架构层面解耦长任务：这是最稳妥的根治方案，Web请求线程本来就不适合跑超过几十秒的任务，你可以把1-3分钟的耗时逻辑丢到后台消息队列，由独立的后台工作者处理，完全不和前端Web实例的生命周期绑定——不光槽交换不会影响，平台升级、实例扩容、故障重启都不会打断这类任务。
• 人工引流后再交换：如果是手动触发交换的场景，可以先在生产槽实例上配置停止接收新请求，等监控看到所有在途请求都处理完成后再点交换，不过这个方案没法适配自动交换的CI/CD流程。

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