Go 优雅停机：让正在处理的请求有机会收尾

服务不是只在运行时需要并发治理，停机时同样需要。没有优雅停机，正在处理的请求会被直接断开，后台任务可能写一半，连接池也没有机会释放。

先停止接收新请求

收到 SIGTERM 后，服务应该从负载均衡摘除或停止监听，再给已有请求一个有限时间完成。

Shutdown 不是永久等待

Shutdown 要传入带 timeout 的 context。超过时间仍未完成的请求需要被强制结束，否则发布会卡住。

后台任务也要退出

HTTP server 之外的 worker、消费者和定时任务都应该监听同一个根 context，收到停止信号后不再接收新任务。

生产场景

适用于容器发布、滚动重启、扩缩容和配置变更。没有优雅停机时，并发请求和后台任务会在发布瞬间变成不确定状态。

关键指标

• SIGTERM 到进程退出耗时
• Shutdown 期间仍在处理的请求数
• 后台 worker 排水完成率和超时取消数量

常见误区

• 只关闭 HTTP server，忘记消息消费者和定时任务
• Shutdown 没有 timeout 导致发布卡住
• Kubernetes terminationGracePeriodSeconds 小于应用排水时间

落地建议

建议把停机流程纳入发布演练：先摘流量，再停止接收新任务，最后等待已有请求和 worker 在预算内收尾。停机日志要能说明每个组件是否正常退出。

代码示例

srv := &http.Server{Addr: ":8080", Handler: mux}
ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM, syscall.SIGINT)
defer stop()

go srv.ListenAndServe()

上线检查

• 容器停止时间大于 Shutdown timeout。
• 停止后不再接收新任务。
• 后台 worker 有退出日志。