Docker stop仅发送SIGTERM信号触发进程级优雅关闭，不负责流量切除或预热；优雅流量切除依赖注册中心注销与就绪探针协同，预热则需启动/就绪探针组合、服务网格或应用自身支持。
“docker stop”本身不直接支持流量切除或预热——它只是向容器内主进程发送 sigterm 信号，触发进程级优雅关闭。真正实现微服务架构中的优雅流量切除和服务预热，依赖的是上层编排系统（如 kubernetes 或 docker swarm）与应用自身配合的完整机制，而非单条 stop 命令。
优雅流量切除的关键不在 stop，而在前置解注册与就绪探针协同
在滚动更新或缩容场景中，“切除流量”必须发生在容器停止之前，否则请求仍会被负载均衡器转发到即将退出的实例：
- 应用需监听 SIGTERM 并在收到后主动向注册中心（如 Nacos、Consul、Eureka）注销自身服务实例，通常耗时 1–5 秒
- 同时，就绪探针（readiness probe）必须配置为失败即下线：一旦应用开始注销，就绪检查立即返回失败，K8s 或 Swarm 会立刻将其从 Service 的 Endpoint 列表中剔除，后续新请求不再路由过去
- Docker Compose 中虽无原生 Endpoint 管理，但搭配反向代理（如 Traefik、Nginx）并启用健康检查时，也能实现类似效果：代理自动将不健康的容器从上游池中摘除
预热不是靠 stop 实现，而是靠启动阶段的渐进式流量接入
预热本质是让新实例在完全承接全量流量前，先用少量请求完成初始化（如 JVM JIT、连接池填充、缓存加载）。这与 stop 无关，而取决于：
- 启动探针（startup probe）+ 就绪探针组合：K8s 中 startup probe 确保应用真正“启动完成”，之后 readiness probe 才开始工作；只有 readiness 变为 true，实例才被加入流量池
- 服务网格或插件级预热控制：例如华为云 ServiceStage 的 Sermant Agent，可在实例刚上线时动态限制其接收流量比例（如首 30 秒仅 10%，随后按指数曲线升至 100%）
- 应用自身支持预热接口（如
/warmup），CI/CD 流水线在容器就绪后、正式切流前主动调用一次，触发内部初始化逻辑
stop 命令在该流程中只承担收尾角色
当流量已完全切除、所有外部连接已释放、应用确认可安全退出时，stop 才执行最终终止：
- 建议在 Dockerfile 中设置
STOPSIGNAL SIGTERM，确保 stop 发送正确信号 - 应用需捕获 SIGTERM，在超时时间内（如 30 秒）完成资源清理、等待活跃请求结束、关闭连接池等，再退出进程
- 避免使用
docker kill强制终止——它跳过优雅关闭流程，可能导致连接中断、事务丢失或数据不一致
不复杂但容易忽略：stop 是终点，不是起点；真正的平滑切换，藏在注册、探针、代理、应用四者对齐的细节里。
