我之前在维护Azure上的Windows应用集群时，遇到过几乎一模一样的问题——LB的哈希路由导致已转发的流量还会持续打到要下线的节点，加上健康探测的延迟，很容易出现请求超时。结合Azure LB的特性和Windows应用的部署经验，给你几个可行的解决方案：

1. 启用Azure LB的**连接耗尽（Connection Drain）**功能 #

这是解决已有流量持续问题的核心。默认情况下Azure LB不会等待已有连接处理完成就把节点从池中移除，开启连接耗尽后，LB会：

• 停止向该节点发送新的请求
• 等待设置的超时时间，让已有连接的请求自然完成
• 超时后再彻底标记节点不可用

操作步骤（Azure门户）：

• 找到你的负载均衡器，进入后端池
• 选择目标后端池，点击配置
• 找到连接耗尽，设置为启用，并根据你的应用请求处理时间设置合适的超时（比如30-60秒，确保大部分请求能处理完）

配合你之前用防火墙阻断健康探测端口的操作：当你需要下线节点时，先阻断健康探测端口，LB很快会将节点标记为不可用，同时连接耗尽会让已有请求完成后再切断，不会出现超时。

2. 优化健康探测参数，缩短节点下线触发时间 #

你当前的健康探测是5秒间隔、2次失败判定，确实会有10秒的窗口让新流量进来。可以调整参数来缩小这个窗口：

• 把探测间隔改成2秒，失败阈值改成1次
• 这样只要健康探测失败1次（2秒内），LB就会停止向该节点发新流量
• 注意：探测间隔不要太小（比如1秒），避免给服务器带来额外压力，2秒是比较均衡的选择

调整后，结合连接耗尽，新流量的窗口从10秒降到2秒，大大减少超时请求的数量。

3. 在Windows应用层实现优雅关闭逻辑 #

光靠LB的设置还不够，应用本身也要配合处理关闭流程，比如：

针对IIS应用： #

• 设置应用池的关闭超时：用命令行 appcmd set config /section:applicationPools /[name='YourAppPoolName'].shutdownTimeLimit:60（60秒是示例，根据你的应用调整），这样IIS在收到停止信号时，会等待60秒让已有请求处理完，再关闭应用池
• 还可以在应用中监听Application_End事件，拒绝新请求但完成已有请求的处理

针对自定义Windows服务应用： #

• 在服务的停止事件中，添加逻辑：停止接收新请求，等待所有正在处理的请求完成后再退出服务

4. 可选：临时调整会话亲和性（如果业务允许） #

因为你已经用了集中式会话数据库，会话数据不依赖单个节点，所以在更新服务器时，可以临时关闭LB的会话亲和性（如果之前开启了的话）。这样LB会把新请求均匀分配到正常节点，而不会因为哈希路由持续把同一用户的请求打到要下线的节点。更新完成后再重新开启会话亲和性即可。

总结流程 #

建议你按照这个流程来操作服务器下线/更新：

1. 启用LB的连接耗尽并设置合理超时
2. 调整健康探测参数为2秒间隔、1次失败阈值
3. 在应用层配置优雅关闭逻辑
4. 当需要下线节点时，先通过Windows防火墙阻断健康探测端口
5. 等待LB标记节点为不可用（约2秒），同时连接耗尽让已有请求处理完成
6. 此时再重启/更新服务器，就不会出现请求超时或丢失的情况

内容的提问来源于stack exchange，提问作者Joel'-'