服务发现与健康检查的日常场景
在公司刚上线的新项目里，后端拆成了七八个微服务，前端请求一个页面，背后要调用用户、订单、库存好几个接口。某天早上，订单服务突然卡住不动了，但进程还在，接口一直超时。用户投诉电话直接打到了运维组。这时候，服务发现系统如果没做健康检查，注册中心还会把流量继续往这个“半死不活”的实例上转，问题只会越来越糟。
这就是为什么服务发现必须搭配健康检查——它像是个自动巡检员，定时敲一敲每个服务的门，看它能不能正常应答。
健康检查的核心作用
服务发现负责告诉调用方“哪个IP和端口能提供某个服务”，但没法保证这个地址现在还能用。健康检查补上了这一环：通过定期探测，标记出失联或异常的服务实例，并从可用列表中临时剔除，等恢复后再重新加入。
比如用 Consul 做服务注册，每个服务启动时会向 Consul 注册自己，同时附带一个健康检查配置。Consul 每隔几秒就会按配置去访问这个服务的 /health 接口，如果连续三次返回 500 或超时，就把它标为“不健康”，其他服务再查这个服务的实例列表时，就不会拿到这台机器的地址。
常见的健康检查方式
最简单的就是 HTTP 检查。给服务加个 /health 路由，返回 JSON 格式的 {"status": "ok"} 就行。复杂点的可以在这个接口里连一下数据库、缓存，确认依赖都通着。
{\n "service": {\n "name": "user-service",\n "port": 8080,\n "check": {\n "http": "http://localhost:8080/health",\n "interval": "10s"\n }\n }\n}另一种是 TCP 检查，适合那些不走 HTTP 的服务，比如 Redis 或自定义协议的内部服务。只要端口能连上就算健康，简单粗暴但有效。
还有脚本检查，写个 shell 脚本跑点逻辑，比如检查磁盘使用率、内存占用，甚至 curl 外部接口验证网络连通性。适合对运行环境有特殊要求的场景。
踩过的坑：过于敏感的检查频率
之前有个同事把健康检查设成每 2 秒一次，看着挺稳妥。结果某次发布新版本，服务启动稍慢了一点，还没完全初始化好就被 Consul 标成不健康，反复重启，形成雪崩。后来改成 5 秒一次，超时时间设到 3 秒，留足缓冲，问题才解决。
另外，别忘了设置首次检查延迟（initial_status 或 interval 的 offset）。新服务启动时，先给它 10 秒热身时间，别一上来就猛查。
服务自身也要主动配合
有些服务在收到关闭信号时，会先从注册中心注销自己，再停止监听端口。这种“优雅下线”机制能减少请求被打断的概率。Kubernetes 里的 PreStop 钩子就是干这个的。
比如在 Pod 关闭前执行一段命令：
lifecycle:\n preStop:\n exec:\n command: [\"sh\", \"-c\", \"curl -X PUT http://consul:8500/v1/agent/service/deregister/user-service-1\"]\n这样在真正停服前，注册中心已经把它摘掉了，正在处理的请求还能继续完成，新请求不会再进来。
服务发现不是一劳永逸的事儿，健康检查更是需要根据实际运行情况不断调整的细节。一个配置得当的健康检查，能让整个系统更稳，半夜报警少一半。
","seo_title":"服务发现健康检查机制详解 - 知用网","seo_description":"了解服务发现中健康检查的工作原理、常见实现方式及实际运维中的注意事项，提升系统稳定性。","keywords":"服务发现,健康检查,微服务,Consul,网络运维,服务注册,健康探测"}