无损发布需应用、容器、负载均衡协同：应用响应SIGTERM并降级就绪状态，容器配置确保信号直达且设合理宽限期，LB短周期健康检查并及时摘流。
要实现生产环境应用无损发布，docker stop 本身不是终点，而是协同链中的一环。真正“无损”的核心在于：在容器停止前，让流量彻底不再进入，同时给应用留足时间处理完存量请求并完成清理。这需要应用、容器配置、负载均衡三者对齐信号与状态。
应用层必须响应 SIGTERM 并主动降级就绪状态
收到 SIGTERM 后，应用不能只关服务，还要快速通知上游“我不再可用了”：
- 立即关闭监听端口（如 HTTP server.close()），拒绝新连接
- 设置 /readyz 或 /healthz 接口返回 503（而非 200），触发 LB 快速摘流
- 等待活跃请求自然结束，超时建议设为 20–45 秒（如 Go 的 srv.Shutdown(ctx)、Spring Boot 的 spring.lifecycle.timeout-per-shutdown-phase）
- 执行数据库连接释放、缓存刷新、临时文件清理等收尾逻辑
容器运行时需确保信号直达且不被拦截
如果 PID 1 是 shell，SIGTERM 就会卡住——应用根本收不到：
- Dockerfile 中必须用 exec 格式启动：CMD ["java", "-jar", "app.jar"]，而非 CMD java -jar app.jar
- 若需 shell 环境（如环境变量预处理），应在 ENTRYPOINT 前引入 tini：ENTRYPOINT ["/sbin/tini", "--"]
- 启动容器时显式延长宽限期：docker run --stop-timeout=45 ... 或 Compose 中写 stop_grace_period: 45s
- Kubernetes 场景下，terminationGracePeriodSeconds 应 ≥ stop-timeout，并配 readinessProbe 失败后立即生效
负载均衡必须短周期感知并剔除节点
LB 不知道容器要停，就不会自动切走流量——这是无损最关键的外部依赖：
- 健康检查间隔 ≤ 3 秒，失败阈值设为 1～2 次（避免延迟摘流）
- Nginx 可配 max_fails=1 fail_timeout=3s + 自定义 health_check 指向 /readyz
- 若使用注册中心（如 Nacos），应用收到 SIGTERM 后应主动注销实例
- 滚动更新时，严格按“先调 LB 下线 → 等 1～2 次健康检查确认无流量 → 再 docker stop”顺序执行
验证是否真正无损的关键指标
别只看容器退出码，要从全链路观察：
- 容器日志末尾出现 received SIGTERM、shutting down、all requests completed 等字样
- 退出码为 0（非 137，137 表示被 SIGKILL 强杀）
- LB 访问日志中，在容器停止前 3 秒内已无新请求打到该实例
- 监控系统显示该实例的 active request 数在收到信号后平滑归零，无突降或报错激增
