Windows
macOS
Android
iOS
节点故障自动切换的目标，是在业务节点确实无法稳定提供服务时，把新请求转移到可用节点。但如果判断条件设计不当，短暂的网络抖动、进程重启或后端依赖变慢，也可能被当成节点故障，造成不必要的流量迁移。
更麻烦的是，误切换往往会放大原有问题：一台节点被移出后，剩余节点承受更高负载；如果多个节点使用同一数据库、缓存或出口网络，切换并不能消除根因，反而可能让更多实例同时报警。
先区分“节点坏了”和“业务暂时失败”
配置节点故障自动切换前，必须先明确故障范围。机器宕机、网卡失联与单个接口响应变慢，不应使用完全相同的判定方式。
- 基础连通性问题：节点无法建立 TCP 连接、端口不再监听，通常更接近节点级故障。
- 进程状态问题：进程仍在运行，但线程池耗尽、文件描述符不足或持续拒绝新连接，属于服务不可用。
- 依赖异常问题：订单服务访问数据库或缓存超时，可能是共享依赖故障，并不代表所有业务节点都需要切换。
- 局部功能问题：图片处理、报表导出等非核心功能失败，不宜直接触发整个节点摘除。
因此，健康探针至少应分成存活检查和就绪检查。存活检查回答“进程是否还活着”，就绪检查回答“节点现在是否适合接收流量”。后者应覆盖必要的初始化状态、连接池可用性和关键配置加载结果，但不要把所有低频依赖都塞进一次探测。
最容易误触发的五类配置
1. 单次失败立即切换
一次超时可能由链路拥塞、垃圾回收、容器重启或瞬时丢包造成。更稳妥的做法是连续失败计数与时间窗口结合，例如在约 10 至 30 秒窗口内连续失败若干次再摘除。具体次数要结合请求时延、节点数量和业务容错能力调整；低延迟交易接口与普通内容页面不能套用同一阈值。
2. 探针超时短于正常响应时间
如果业务在高峰期通常需要数百毫秒完成，而探针只等待几十毫秒，系统会把正常波动识别为故障。探针超时应明显高于稳定状态下的常见响应时间，同时设置独立的失败次数，避免单纯拉长超时后又长期占用连接。
3. 把共享依赖写进每一次切换条件
多个节点同时访问同一消息系统或数据库时，共享依赖中断会让所有探针一起失败。此时逐个切换节点没有意义。应分别观察节点本地状态、依赖错误比例和入口流量结果，必要时使用熔断机制保护后端，而不是让节点故障自动切换反复迁移流量。
4. 忽略维护和发布窗口
滚动发布、证书替换、容器镜像更新期间，节点可能短暂失去就绪状态。若调度器没有维护标记，系统会把计划操作记录成故障。发布前应先停止接收新流量，确认连接排空，再执行变更；恢复后让节点经过预热，再逐步加入。
5. 只设置摘除规则，没有恢复规则
节点恢复后立即承接全部流量，容易出现冷缓存、连接池未建立或启动任务未完成的问题。恢复阶段应采用冷却时间、连续成功次数和逐步放量组合。比如先观察约 30 秒至数分钟，再从小比例流量开始，时间范围需根据应用启动速度和流量规模确定。
一套更稳妥的配置步骤
- 列出节点必须满足的条件：端口可连接、进程已启动、关键配置已加载，以及核心请求能够完成。
- 为存活检查和就绪检查分别设置路径、超时和失败计数，不要用一个“返回 200”覆盖全部判断。
- 将连续失败、失败持续时间和最小摘除比例同时纳入规则，避免网络抖动造成集群同时减容。
- 为发布、扩容、缩容和人工维护提供明确的排空入口，避免运维动作与故障判断相互竞争。
- 恢复时先验证日志、错误率和资源使用，再进行小流量试接；确认稳定后才完全放量。
- 记录每次切换的触发原因、探针结果、节点负载和入口分布，方便判断是真故障还是误判。
不同业务的取舍
| 场景 | 更适合的判定方式 | 主要风险 |
|---|---|---|
| 无状态网页服务 | 就绪探针加连续失败计数 | 阈值过低会造成频繁摘除 |
| 长连接服务 | 区分新连接接入与既有连接排空 | 切换过快可能中断会话 |
| 依赖较多的业务 | 节点状态与依赖错误分开判断 | 共享依赖异常引发集体误切换 |
| 有本地缓存的服务 | 预热后逐步恢复流量 | 立即满载可能再次超时 |
对于依赖会话状态的系统，还要检查会话一致性。单纯把请求转移到另一台节点，并不能自动复制本地会话、未提交任务或临时文件。此类业务应采用共享会话存储、可重试的请求设计，或明确哪些请求不能自动重放。
发现误切换后的排查顺序
先看切换时间点是否与发布、网络变更或流量突增重合；再比较探针失败与真实用户错误是否同步；随后检查节点自身资源，以及数据库、缓存、消息系统等共享依赖。若只有探针失败而用户请求正常，优先修改探针路径和超时；若探针与用户错误同时上升，则应保留切换动作，继续定位服务根因。
还应检查是否存在“切走后又立刻切回”的循环。循环通常说明恢复门槛过低、冷却时间不足，或备用节点没有完成预热。调整时不要只提高失败阈值，也要补充恢复成功次数、最短稳定时间和流量渐增规则。
常见问题
健康探针越复杂越可靠吗？
不是。探针应覆盖接收请求所必需的条件；加入过多非核心依赖，反而会把局部故障扩大成节点故障。
应该优先调大超时时间，还是增加失败次数？
两者解决的问题不同。响应偶尔变慢时可适当增加超时；网络短暂抖动时，增加连续失败次数通常更有效，应结合业务时延观察。
备用节点越多，自动切换越安全吗？
不一定。备用节点还要有足够容量、相同配置和可用依赖，否则切换只是转移压力。
多久做一次故障演练合适？
没有适用于所有系统的固定周期。重大架构、发布流程或依赖变更后应重新演练，平时也应定期验证摘除、恢复和告警链路。
归根结底，节点故障自动切换依赖的是准确判断，而不是更激进的切换速度。把探针、阈值、维护流程、容量和恢复规则分开设计，才能减少误触发，并让真正的故障得到及时隔离。