健康检查
Health Check
中级通用健康检查（Health Check）是服务提供的一个简短检查，用来回答“它现在能否继续运行或接收请求”。它让部署系统和负载均衡器及时发现不可用的实例，例如新版本虽已启动，却还没准备好处理用户请求。
你可能会说：「我想让系统知道服务什么时候真的能接请求，没准备好时先别把用户流量发过去。」
动手看看下单服务何时接收请求
1
部署系统刚拉起新的下单实例。它已经在运行，但还在连接数据库；负载均衡器先发起健康检查，不急着转发订单。
要点健康检查到底在检查什么？
- 1
先分清活着和准备好了
进程还在运行，不代表用户请求能成功。我们可以分别检查“服务是否还活着”和“是否准备好接收流量”：前者帮助发现卡死的实例，后者让刚启动、尚未完成初始化的实例暂时不接请求。
- 2
检查结果要能指导动作
假设你的网站有多个服务实例，负载均衡器定期请求每个实例的检查端点。某个实例报告未准备好时，它就可以先不接新流量；恢复后再加入。检查有价值，是因为结果会被拿来做决定。
- 3
只检查影响当前判断的事
健康检查通常要快，检查项也要和用途对应。如果只是判断实例是否卡死，每次都请求外部支付服务就不合适：支付服务一抖动，所有实例可能一起被判为不健康。确实依赖某项资源才能接请求时，再考虑把它纳入就绪检查。
容易混淆的地方
健康检查回答的是“此刻这个实例能否运行或接流量”，监控则持续记录错误率、延迟等变化，帮你发现和分析问题；健康检查正常，也不代表用户体验一定正常。冒烟测试通常在部署后走一遍关键功能，验证新版本是否可用，比健康检查覆盖得更广，但不适合高频执行。
什么时候用
适合用
- 你部署了多个后端实例，想让负载均衡器避开尚未完成启动或暂时无法接请求的实例。
- 你的 AI 工具启动时要加载模型配置，想等初始化完成后再让新实例接收对话请求。
- 你在排查服务反复重启，想区分进程卡死和依赖暂时不可用，以便决定该重启还是先停止分流。
不适合用
- 你只是想确认一次新版网站的登录和下单流程能否走通，用部署后的冒烟测试更合适。
- 你想了解过去一周接口为何变慢、错误何时开始增加，用监控指标和服务端日志来分析。
- 你做的是托管平台上的纯静态页面，没有自己的运行中服务实例；想知道页面能否访问，可用外部可用性监测。
练一练选一个答案，看看解释
你把聊天服务扩成多个实例。新实例启动后还要加载配置，期间无法处理请求。怎样让用户尽量不遇到启动中的实例？
让 AI 帮你做复制给 AI Agent 直接用
请为这个聊天后端设计健康检查：区分进程存活和实例就绪；配置加载完成前不要接收用户流量。先说明各检查项、失败时返回什么结果，以及部署系统如何使用结果，再实现并补充测试。不要把无关外部服务的短暂故障当作实例卡死。