负载均衡健康检查怎么设计？存活、就绪与故障摘除
健康检查首先是一条流量决策
负载均衡根据健康状态决定是否把新请求交给节点，因此检查目标应是“这台节点现在能否接收这类业务”。只检查端口能连接，可能把已经失去数据库连接的应用继续当成健康；检查得过重，又可能在高峰时给系统增加负担。
存活检查通常用于判断进程是否需要被恢复或重启，就绪检查用于判断是否可以接收流量，启动检查则给初始化阶段单独的判定方式。Kubernetes对这几类探针的区分有明确说明，即使不使用容器编排，也可以借用这个设计思路。官方探针说明
检查路径要足够真实，也要足够轻
准备专用健康接口，返回稳定且容易识别的状态。它应验证必要的本地初始化状态，并根据服务职责考虑关键依赖，但不宜每次执行昂贵查询或写入正式业务数据。对外返回的信息尽量简洁，详细诊断留在受权限控制的监控中。
假设一个节点提供商品查询，只有数据库连接可用时才能正常服务，可以把必要依赖状态纳入就绪判断。但若整个数据库集群短时不可用，让所有应用节点因存活检查失败而同时重启，通常无法修复数据库，反而延长恢复。应分清“暂不接流量”和“必须重启”的后果。
对于可以降级的功能，判断还应更细。例如推荐模块失败但核心页面仍可用，不一定要摘除整台节点。检查结果需要符合业务降级设计，而不是把所有依赖一律串成单点否决。
阈值控制敏感度与恢复速度
需要核对检查间隔、单次超时、连续失败次数、连续成功次数和成功状态码范围。阈值过敏感容易把短暂抖动变成反复摘除，过迟钝则让真实故障持续接收请求。产品的具体判定方式并不完全一致，必须阅读实际负载均衡说明。AWS ALB健康检查文档
例如假设每十秒检查一次、连续三次失败才摘除，发现故障的时间还取决于故障发生相位和单次超时，不能简单承诺“三十秒一定完成切换”。重新加入也应验证节点已完成预热，并有足够连续成功结果，避免刚恢复就再次被流量压倒。
成功码范围应符合健康接口约定。把所有重定向和客户端错误都算健康，可能掩盖访问了错误路径、默认站点或认证页面的问题。检查使用的Host和协议也要与目标配置相符。
了解全部节点异常时的产品行为
不同负载均衡对“没有健康节点”的处理可能不同。有的平台返回错误，有的平台在特定状态下继续向目标转发。AWS ALB文档描述了其所有目标不健康时的相关行为，因此不能把某个平台的经验当作通用规则。
应在隔离测试环境验证单节点失败、全部节点失败和节点恢复三种情况，观察实际响应与告警。健康检查自身被防火墙拦截也会误判，应确认来源与路径配置符合平台要求。
摘除节点后，已有连接如何处理也要核实。新请求不再进入，不代表长连接或正在执行的任务立即结束；发布维护时应结合连接排空和应用优雅退出。
把验收写成实际动作
一次有效演练可以包括：让测试节点停止接收业务、观察健康状态变化、确认新请求转移、恢复节点并确认重新加入。记录期间的错误率和响应时间，而不是只保存控制台颜色变化。
演练结束后保存健康接口约定与阈值选择原因。应用依赖、启动时长或部署方式改变时复查这些条件，让健康检查持续代表当前业务能力，而不是成为多年未调整的一条固定URL。