健康检查是零宕机发布的关键支撑，通过自定义探测确认业务真正就绪、联动编排工具控制滚动更新节奏、驱动负载均衡动态剔除异常节点，并为发布完成提供可验证信号。
健康检查是零宕机发布能落地的关键支撑，不是锦上添花，而是决定新旧实例能否安全切换的“守门人”。它让系统真正知道：一个容器进程在运行，不等于它能处理请求。
精准识别“就绪”而非“启动完成”
应用启动后常需加载配置、连数据库、预热缓存——这些耗时操作期间，端口可能已监听，但服务实际无法响应。健康检查通过自定义探测（如访问/health接口），确认业务逻辑真正可用，才允许流量进入。没有这一步，滚动更新中可能出现大量502或超时请求。
- 用start_period参数为冷启动留出缓冲时间，避免过早失败
- HTTP探针建议返回轻量JSON并校验状态字段，不只是看200
- 避免在健康端点中做重查询或写操作，防止干扰主业务
驱动滚动更新的安全节奏
在Docker Compose或Swarm中，order: start-first配合健康检查，实现“先启新、等健康、再停旧”。编排工具会持续轮询新容器的healthy状态，只有确认达标后，才触发旧实例下线。
- 若新容器卡在starting或反复变unhealthy，更新自动暂停，人工介入前服务不受影响
- retries和timeout需匹配应用真实初始化时长，太激进易误判，太宽松则拖慢发布
联动负载均衡动态剔除异常节点
Kubernetes的Readiness探针或Swarm的服务发现机制，都依赖健康检查结果更新后端节点列表。一旦某实例连续失败，它会立刻从Service或Ingress的转发池中移除，后续请求不再打过去。
- 这不仅用于发布阶段，日常也能隔离因内存泄漏、连接池耗尽导致的“假活”实例
- 建议将Readiness与Liveness分离：前者管流量接入，后者管是否重启，避免误杀
提供可验证的发布完成信号
运维或CI/CD流水线可通过docker inspect --format='{{.State.Health.Status}}'实时获取每个容器状态。当所有新副本稳定处于healthy，即可认为本次发布成功，触发后续通知或监控告警收敛。
- 比单纯看容器Running状态更可靠，杜绝“看着在跑，其实挂了”的盲区
- 结合Prometheus+Grafana，还能绘制健康率趋势图，长期评估服务稳定性
