健康检查接口核心是暴露轻量、稳定、业务无关的http端点（如/health），要求响应≤200ms、返回200及{"status": "up"}，不查db、不调远程、无副作用，并由外部组件按5–10秒间隔、1–2秒超时、连续3次失败才判不可用。
应用层通过健康检查接口实现存活探测，核心是让服务主动暴露一个轻量、稳定、业务无关的 HTTP 端点（如 /health 或 /actuator/health），由外部组件（如注册中心、网关、负载均衡器或独立巡检服务）定期调用并依据响应结果判断服务状态。
健康端点设计要点
端点必须满足三个基本要求：快、稳、纯。
- 响应极快：只做最小必要检查，不查数据库、不调远程依赖、不触发复杂计算；理想响应时间 ≤200ms
- 稳定性高：即使业务线程阻塞或部分功能异常，只要进程存活、HTTP 服务器能响应，就应返回 200
-
语义清晰：返回标准 JSON，包含明确的
"status": "UP"字段；避免返回 5xx 或空响应
调用方探测策略
探测行为需兼顾及时性与抗抖动能力，不能因单次网络波动误判：
- 间隔设为 5–10 秒，超时严格控制在 1–2 秒内（避免堆积连接）
- 连续失败 ≥3 次才标记为“不可用”，避免网络瞬断导致误摘除
- 首次探测前加随机抖动（如 0–1000ms），防止多节点同时请求造成后端压力尖峰
- 禁用
Connection: keep-alive，用短连接降低服务端连接管理负担
与注册中心协同工作
若使用 Nacos、Eureka 或 Consul，优先复用其内置健康检查能力：
- Nacos 临时实例默认走客户端心跳，但可配置
metadata.healthy-check-type=http切换为主动探测 - Eureka 支持
health-check-url配置，将其指向你的/health接口，由 Eureka Server 定期轮询 - Consul 的
http类型 check 会自动 GET 该路径，并校验状态码和可选响应体内容
避免常见陷阱
很多故障源于端点逻辑与真实健康脱节：
- 不要在
/health中检查 MySQL 连接——这属于“依赖健康”，不是“本机存活” - 不要返回完整指标（如内存、线程数），除非下游明确需要；二值判断（UP/DOWN）才是心跳本质
- 确保日志框架未因错误配置导致
/health响应卡死（例如 Logback 异步队列满） - Kubernetes 中，
readinessProbe可复用同一端点，但需注意：它影响流量接入，而心跳影响服务发现，二者目的不同，配置可分离
