优雅注销需服务主动完成通知注册中心→停收新请求→处理存量→确认注销闭环，关键在pid 1可收sigterm、pre_stop钩子摘除、缓存刷新对齐及闭环验证。
要通过 Docker Compose 的进程拓扑管理实现分布式微服务优雅注销，关键在于让每个服务实例在终止前主动完成“通知注册中心→停止接收新请求→处理完存量请求→确认注销”这一闭环，而非依赖容器强制销毁。这需要从进程模型、信号传递、依赖时序和外部协调四个层面协同设计。
确保 PID 1 进程可接收并转发 SIGTERM
Compose 默认将启动命令作为容器内 PID 1 进程。若该进程是 shell（如 /bin/sh -c "java -jar app.jar"），它会忽略 SIGTERM，导致 Java 应用收不到退出信号。必须使用 exec 替换 shell 层：
- ✅ 正确写法：
command: ["sh", "-c", "exec java -jar /app.jar"]或直接command: ["java", "-jar", "/app.jar"] - ❌ 错误写法：
command: sh -c "java -jar /app.jar"（shell 拦截 SIGTERM，子进程无法感知） - 验证方式：进入容器执行
ps -eo pid,ppid,comm | grep -E '^(PID| 1)'，确认 Java 进程 PID 为 1
利用 pre_stop 钩子触发前置下线动作
Docker Compose v2.23+ 支持 pre_stop 钩子，在容器收到 SIGTERM 前自动执行命令，适合做负载均衡摘除、锁释放、状态上报等非应用内逻辑：
- 向 Consul/Nacos 主动注销（绕过应用自身延迟）：
curl -X PUT "http://consul:8500/v1/agent/service/deregister/app-${HOSTNAME}" - 通知 API 网关下线节点：
curl -X POST http://gateway/admin/remove?instance=app-${HOSTNAME} - 释放分布式锁（如 Redis）：
redis-cli DEL lock:service:app:${HOSTNAME} - 注意：
pre_stop执行超时默认为 10s，复杂操作需配合stop_grace_period调整
对齐注册中心与客户端缓存刷新节奏
即使服务已注销，其他微服务仍可能因本地缓存继续发请求——这是分布式系统“最后一公里”问题。需从两端收敛延迟：
- 服务端：将注册中心心跳间隔（
health-check-interval）设为 5–10s，TTL 设为 2–3 倍心跳（如 30s），确保注销后快速清理 - 客户端：Spring Cloud 默认使用 Ribbon 缓存 30s，应启用
spring.cloud.loadbalancer.cache.enabled=false或改用 Spring Cloud LoadBalancer + 缓存刷新策略 - 补充手段：在
pre_stop中调用网关的主动剔除接口，比依赖注册中心传播更快
构建可验证的注销闭环流程
优雅注销不能只靠“写了逻辑”，必须可观测、可验证：
- 应用内记录注销日志，含时间戳、注销结果（HTTP 状态码）、注册中心响应体
- 在
docker compose down后，立即检查注册中心 UI/API，确认对应实例已消失（如curl http://nacos:8848/nacos/v1/ns/instance/list?serviceName=app） - 监控指标联动：当服务实例数下降时，观察其最后一条访问日志的时间是否晚于注销开始时间，确认无请求被丢弃
- 压测验证：在持续请求中执行
docker compose restart app，检查错误率是否为 0，TP99 是否无尖刺
