优雅下线怎么做
下线后端时直接停进程会打断正在处理的请求，用户侧看到的就是零散的连接错误。规范做法是分三步：先把权重调 0 或把成员从服务器组摘除，让负载均衡停止向它分配新连接；再观察该后端的活跃连接数降到接近零；最后才执行进程停止或发布操作。这个流程的核心是让「不再收新流量」与「服务停止」之间有一段等待窗口，而不是同时发生。
下线流程
- 将成员权重调 0 或从服务器组摘除，停止接收新连接
- 观察该后端的活跃连接数与请求速率降到接近 0
- 执行进程停止或发布操作
- 验证完成后按需重新加回，并逐步恢复权重
基本信息
| 核心动作 | 先停新流量，再等存量结束，最后停服务 |
|---|---|
| 观察指标 | 该成员的活跃连接数与请求速率 |
| 长连接场景 | 需提前通知对端重连，或接受连接自然到期 |
| 回滚 | 重新加回成员并逐步恢复权重 |
观察存量连接下降过程
观察存量连接下降过程
ss -tan | grep ':8080' | wc -l
# 与负载均衡监控中该成员的活跃连接曲线相互印证
# 降到接近 0 再做下一步，避免过早停进程常见后端类型的等待策略
| 后端类型 | 下线策略 |
|---|---|
| 无状态 Web 服务 | 摘除后等待秒级即可 |
| 长连接网关 | 通知客户端重连或等待自然到期 |
| 数据库与消息队列 | 先切主或迁移客户端，再停服务 |
| 批处理任务 | 确认当前批次结束后再停止 |
数据库、消息队列这类长连接后端，下线前通知对端主动重连，比单纯等待连接释放更可靠。
把它变成可重复的流程
发布与缩容的稳定性，取决于这套流程是否被写进脚本与检查清单，而不是依赖执行人的经验。建议把「摘除、等待、停止、加回」做成一键脚本，并在每一步加入校验：摘除后确认该成员健康状态已转为不接收流量；等待阶段打印剩余连接数；停止前若连接数仍高于阈值就中止并告警。这样一来，即使换人操作或夜里执行，也不会因为赶时间而跳过等待窗口。