无损切流需健康检查暴露业务就绪信号并由负载均衡器实时响应：Web服务用含依赖检查的/health接口，数据库执行SELECT 1；Docker Swarm自动过滤不健康容器，Kubernetes依赖Readiness Probe注入Endpoint。
健康检查与负载均衡配合实现无损切流，关键在于让负载均衡器只把流量分发给真正可用的容器——不是“进程在跑”，而是“服务能响应”。这需要健康状态实时同步、策略精准协同、切换过程平滑。
健康检查必须暴露明确的业务就绪信号
负载均衡器依赖健康状态做路由决策，所以健康检查不能只验证进程存活，而要反映真实服务能力。
- Web 服务用 HTTP GET /health，接口需返回 200 且包含关键依赖检查（如数据库连通性、缓存可用性）
- 数据库容器建议执行轻量 SQL 查询（如 SELECT 1），而非仅检测端口是否开放
- 避免使用
curl -f http://localhost这类不带路径或无业务逻辑的检查，容易误判“假死”
负载均衡器必须监听并响应 Docker 健康状态变化
Docker Swarm 和 Kubernetes 原生支持将容器健康状态映射为后端节点可用性。普通反向代理（如 Nginx）需额外集成。
- Docker Swarm 的 ingress 网络自动过滤 unhealthy 容器，请求永不路由过去
- Kubernetes 中 Readiness Probe 成功后才将 Pod 加入 Endpoint 列表，是实现无损切流的前提
- docker ps --filter "health=healthy" -q 动态更新 upstream，或对接 Consul 等服务发现组件
启动宽限期与恢复机制要留足余量
新容器刚启动时，应用常需加载配置、建立连接、预热缓存——此时若立即接入流量，会导致 5xx 或超时，破坏“无损”。
- 在
HEALTHCHECK中设置 start-period（如 40s），让健康检查在启动后延迟开始 - 在 docker-compose.yml 中配
start_period: 40s，配合condition: service_healthy控制依赖服务启动顺序 - Swarm/K8s 中设置 initialDelaySeconds 和 failureThreshold，避免冷启动阶段被误摘除
滚动更新时依赖健康状态驱动流量切换
无损切流不仅发生在故障时，更体现在发布过程中——新实例健康了，旧实例才下线。
- Docker Swarm 的滚动更新默认等待新任务进入 running + healthy 状态后，才停止旧任务
- Kubernetes 的 RollingUpdate 策略中，maxSurge 和 maxUnavailable 需与 readiness probe 配合，确保始终有健康实例在线
- 在 CI/CD 流水线中，可加入
docker inspect --format='{{.State.Health.Status}}' $CONTAINER校验，健康才继续下一步
