Consul 健康检查

健康检查是 Consul 把"注册了"变成"可用了"的关键：agent 按配置定时探测实例，状态变 critical 的服务会从查询结果中消失，调用方不会把请求发给故障机器。

检查类型对比

五种检查类型分 agent 主动探测与业务心跳上报两类：

类型	原理	适用
script	定时执行脚本，退出码 0 判通过	自定义探活逻辑
http	定时 GET 指定 URL，2xx 判通过	Web/HTTP 服务
tcp	定时尝试建立 TCP 连接	任意有端口的服务
ttl	业务主动上报心跳，超时判失败	无法被动探测的任务类业务
grpc	定时调用 gRPC 健康检查接口	gRPC 服务

script/http/tcp 属主动探测，需配 interval 轮询间隔；ttl 只声明过期时长。

HTTP 与 TCP 检查完整示例

一个服务同时挂 HTTP 探活与 TCP 端口检查，放进配置目录：

{
  "service": {
    "name": "web",
    "port": 80,
    "checks": [
      { "http": "http://127.0.0.1:80/health", "interval": "10s" },
      { "tcp": "127.0.0.1:80", "interval": "5s" }
    ]
  }
}

consul reload
# 故意停掉 web 进程后查询检查状态：
curl http://127.0.0.1:8500/v1/health/checks/web
# 输出里该检查的 Status 从 passing 变 critical，Output 字段带失败原因

HTTP 检查约定：2xx 通过、429 判 warning、其他状态判 critical。

TTL 检查与外部心跳程序

TTL 把判活权交给业务自身，注册只声明过期时间，由外部心跳程序或业务线程定时上报：

{ "service": { "name": "worker", "check": { "ttl": "30s" } } }

# 心跳程序每 15 秒执行一次（30 秒收不到即判 critical）：
curl -X PUT http://127.0.0.1:8500/v1/agent/check/pass/service:worker
# 业务自知要下线时主动上报 fail：
curl -X PUT http://127.0.0.1:8500/v1/agent/check/fail/service:worker

检查状态与反熵同步

状态共三种：passing（正常）、warning（告警但可用）、critical（故障）。agent 与 server 之间靠反熵（antientropy）机制周期性对账，把本地最新检查结果同步到 server 目录，agent 重启后状态也会被纠正，不会永远卡在旧值上。

服务自动注销

critical 服务默认只从查询结果摘除、定义仍在；进程恢复注册后自动复活。想彻底清理故障残留，可设置自动注销时长：

{
  "service": {
    "name": "worker",
    "deregister_critical_service_after": "90s"
  }
}

小结

选型口诀：有 HTTP 接口用 http，只有端口用 tcp，无法探测就 ttl 心跳。检查状态决定服务在目录里的去留，配合 deregister_critical_service_after 自动清理，故障实例才能无人值守地被摘除。