Docker HEALTHCHECK 实现业务级探针需用 shell 脚本封装多步验证（如HTTP端点、DB查询、Redis PING），任一失败即 exit 1；关键参数设为 --interval=20s、--timeout=5s、--start-period=60s，并通过 docker inspect 查看详细日志定位故障根因。
直接在 Docker 中用 HEALTHCHECK 实现业务级探针，关键不是“复杂”，而是让检查命令真正反映业务可用性——比如数据库连得上、缓存能写入、下游依赖响应正常。单纯检测端口或进程存活远远不够，容易出现“容器活着，服务已死”的假健康状态。
设计业务级健康检查命令
健康检查的核心是 CMD 后面那条命令，它必须能执行多步验证并统一返回退出码。推荐用 shell 脚本封装逻辑，避免单条 curl 或 telnet 的片面性。
- 把检查逻辑写进 ./health.sh 并 COPY 到镜像中，例如：
- 检查 HTTP 健康端点是否返回 200；
- 用 mysql -h db -u user -ppass -e "SELECT 1" 验证数据库可查询；
- 用 redis-cli -h redis PING 确认缓存服务响应；
- 任意一步失败就 exit 1，全部通过才 exit 0。
然后在 Dockerfile 中引用：
HEALTHCHECK --interval=20s --timeout=5s --start-period=60s --retries=3 \CMD ["./health.sh"]
合理设置 start-period 和 timeout
业务服务启动慢很常见：Spring Boot 应用可能要 40 秒才完成初始化，依赖的 Redis 或 MySQL 也可能延迟就绪。如果没设好 --start-period，健康检查会在应用还没准备好时就开始失败，直接导致容器被反复标记为 unhealthy。
- --start-period=60s：给足 1 分钟宽限期，期间所有失败不计数；
- --timeout=5s：单次检查不能拖太久，否则会阻塞下一轮探测；
- --interval=20s：比默认 30s 更频繁一点，加快故障发现速度，但别低于 10s，避免压垮服务。
与编排系统联动剔除故障
Docker 自身只管标记 unhealthy，真正实现“自动剔除”要靠上层调度器：
- 在 docker-compose.yml 中，配合 depends_on.condition: service_healthy，确保上游服务等下游健康后再启动；
- 在 Kubernetes 中，把 Docker 的 HEALTHCHECK 映射为 readinessProbe，让 Service 自动从 endpoints 中移除 unhealthy 实例；
- Swarm 模式下，任务状态变为 unhealthy 会触发自动重启或重新调度到其他节点。
查看和调试真实健康状态
别只看 docker ps 里模糊的 “Unhealthy”，要用 inspect 深挖细节：
- docker inspect --format='{{.State.Health.Status}}' myapp —— 查当前状态
- docker inspect --format='{{json .State.Health.Log}}' myapp | jq —— 查最近几次检查的命令输出、退出码、时间戳，精准定位哪一步失败
- 如果日志里显示 exit code 1 且输出含 "redis timeout"，说明是缓存问题，不是应用本身崩溃。
