在容器化环境中，“进程仍在运行”并不等于“服务可以正常工作”。应用可能出现线程阻塞、接口持续报错或依赖连接失效，但容器状态依旧显示为运行中。要提升服务可用性，需要把健康检查、重启策略、依赖管理和监控告警组合起来，而不是简单地配置一个自动重启参数。本文将从实际部署角度介绍一套可直接落地的实践方法。🛠️
一、理解健康状态与运行状态
Docker 的 HEALTHCHECK 指令用于检测容器内的应用是否能够正常提供服务。配置健康检查后，容器会经历 starting、healthy、unhealthy 三种健康状态。需要注意的是，健康状态独立于容器是否正在运行，即使容器被标记为 unhealthy，其主进程仍可能继续运行。具体语法和参数可参考 Dockerfile 官方文档。
一个有效的检查应尽量贴近真实业务，但又不能过于复杂。例如，Web 服务可以访问本机健康接口，数据库可以执行轻量级连通性命令，消息消费者可以检查内部工作线程状态。只判断进程是否存在通常意义不大，因为 Docker 本身已经能够识别主进程退出。
常用参数说明
- interval：两次检查之间的时间间隔。
- timeout：单次检查允许执行的最长时间。
- retries：连续失败多少次后标记为 unhealthy。
- start-period：应用启动预热期，适合初始化较慢的服务。
- start-interval：启动阶段的检查间隔，应结合当前 Docker 版本确认支持情况。
下面是一个 Web 应用的示意配置。由于不同镜像未必自带 curl，构建镜像时应确认检查工具确实存在，或者直接使用应用自身提供的轻量命令。
HEALTHCHECK --interval=30s --timeout=5s --start-period=20s --retries=3 \
CMD curl --fail --silent 来源链接 || exit 1
二、设计可靠的健康检查接口
健康检查接口应快速、稳定且无副作用。建议返回明确的成功或失败状态，不要在检查过程中执行写数据库、创建文件、发送消息等操作。探测逻辑过重会增加资源消耗，严重时甚至可能让检查本身成为故障来源。🔍
检查范围需要根据用途划分。基础存活检查主要判断应用是否卡死，服务就绪检查则判断应用当前能否接收流量。如果把所有外部依赖都纳入同一个检查，一旦共享数据库短暂抖动，可能导致大量容器同时被判定异常，形成级联重启。
- 为健康接口设置较短的内部超时，避免探测命令长期挂起。
- 在启动较慢的服务中合理配置 start-period，减少初始化阶段的误判。
- 避免检查公网地址或不受本服务控制的第三方接口。
- 确保健康接口不输出密码、令牌、连接字符串等敏感信息。
- 根据实际启动时间和故障恢复目标设置参数，不机械照搬示例值。
三、正确选择自动重启策略
Docker 的重启策略处理的是容器主进程退出，而不是健康检查失败。换句话说，容器变成 unhealthy 后，普通 Docker Engine 不会仅凭该状态自动触发 restart policy。因此，健康检查负责发现问题，重启策略负责处理退出事件，两者不能混为一谈。
使用 docker run 时可以通过 --restart 设置策略；使用 Compose 时可在服务中配置 restart。Docker 提供的主要策略及其行为可查看 自动启动容器官方说明。
- no：默认值，容器退出后不自动重启，适合一次性任务或调试环境。
- on-failure：仅当进程以非零退出码结束时重启，可设置最大重试次数，适合批处理和后台任务。
- always：容器停止后持续尝试恢复，Docker 守护进程重新启动时也会处理该容器。
- unless-stopped：行为接近 always，但人工停止后不会因为 Docker 守护进程重启而再次自动启动，适合多数长期运行服务。
docker run -d --name api --restart unless-stopped my-api:latest
对于已经创建的容器，可以使用 docker update 修改策略，而不必重新构建镜像：
docker update --restart unless-stopped api
四、让 unhealthy 容器获得恢复能力
由于健康检查失败不会直接触发 Docker 重启，生产环境需要额外设计恢复路径。最稳妥的方式是让应用在确认自身不可恢复时主动退出，并返回非零退出码，再由 on-failure 或 unless-stopped 策略接管。应用退出前应尽量完成日志刷新、连接关闭和必要的状态保存。
另一种方式是通过外部监控系统订阅 Docker 事件或定期读取健康状态，在满足持续失败、冷却时间和重试上限后执行重启。不过，这类组件如果挂载 Docker Socket，通常拥有较高的宿主机控制权限，需要限制访问范围、固定可信镜像版本并保留完整审计记录。⚠️
无论采用哪种方式，都应防止无限重启掩盖真实问题。建议设置告警阈值和冷却机制，并同步关注退出码、重启次数、OOMKilled 状态、应用日志、CPU 和内存使用情况。资源不足、配置错误或依赖不可用不会因为反复重启而自动消失。
五、在 Docker Compose 中协同配置
Compose 可以同时声明 healthcheck、restart 和服务依赖。普通 depends_on 主要控制启动顺序，并不代表依赖服务已经准备好。使用 condition: service_healthy 后，Compose 会等待依赖通过健康检查，再启动对应服务，相关行为可参考 Compose 启停顺序官方指南。
services:
api:
image: my-api:latest
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "curl --fail 来源链接 || exit 1"]
interval: 30s
timeout: 5s
retries: 3
start_period: 20s
depends_on:
db:
condition: service_healthy
这类配置可以降低启动竞争问题，但应用仍应具备依赖重连和超时处理能力。数据库在运行期间可能重启，仅依靠首次启动顺序无法保证后续连接始终有效。
六、上线前的检查清单 ✅
- 在容器内部手动执行探测命令，确认工具、端口和路径正确。
- 模拟接口超时、进程退出、依赖断开和内存不足等场景。
- 通过 docker inspect 查看健康检查输出、连续失败次数和退出信息。
- 验证人工停止容器后，所选重启策略的行为是否符合运维预期。
- 为频繁重启、长期 unhealthy 和 OOMKilled 分别设置告警。
- 保留应用日志与 Docker 事件，确保故障发生后能够定位根因。
总结
Docker 容器的稳定运行，需要明确区分“进程退出”和“服务异常”。健康检查负责提供可靠的状态信号，重启策略负责恢复已经退出的容器，Compose 依赖条件用于改善启动顺序，监控系统则负责发现持续故障和阻止重启风暴。🚀 实践中应优先采用轻量、无副作用的检查方式，并通过主动退出或受控的外部恢复机制处理 unhealthy 状态。只有把检测、恢复、告警和根因分析连接起来，自动重启才会成为真正的可靠性能力，而不是隐藏故障的开关。
