系统如何探活并保障高可用？

核心回答

探活负责发现服务是否存活、是否适合接流量；高可用还需要冗余部署、流量切换、容量余量、依赖隔离和故障恢复。一个健康检查接口返回 200，不等于真实业务链路一定可用。

应先定义关键业务的可用性目标，再根据故障类型决定摘流量、重启、降级还是切换，避免所有异常都用重启解决。

三类检查怎样分工

以 Kubernetes 为例，startup probe 保护慢启动应用，在初始化完成前不运行其他两类探针；readiness probe 判断实例是否能接收新流量，失败后使其不再成为就绪服务端点；liveness probe 判断容器是否陷入需要重启才能恢复的状态，持续失败后由 kubelet 按规则重启容器。

存活检查宜聚焦实例自身，例如主循环是否可响应；就绪检查可以考虑必要资源是否准备好，但不要让一次共享数据库波动就触发所有实例反复重启。探针本身应轻量、有超时和合理的连续失败阈值，避免高频深检查成为额外负载。

还需要外部合成检查或真实请求指标验证完整业务路径，例如登录、关键查询或任务提交能否完成；内部探针和端到端监控解决的问题不同。

如何把故障检测转成高可用

无状态服务多副本部署到独立故障域，负载均衡只给就绪实例分配新请求；发布和退出时先停止接新流量，再处理在途请求并优雅终止。剩余实例要有接管余量，否则摘掉一个实例可能把其余实例一起压垮。

数据库、缓存、消息队列等依赖也要有相应冗余和恢复方案。调用方设置超时、有限重试、熔断和隔离，防止故障沿调用链传播；重要任务持久化状态、幂等处理并支持恢复。

如何证明有效

同时观察业务成功率、延迟、错误类型、实例就绪状态、切换耗时和恢复后数据一致性。演练进程崩溃、慢启动、依赖超时、网络隔离及发布中断，检查是否误摘全部实例、是否出现重启风暴，以及丢失和重复请求如何处理。

常见追问

为什么健康检查会让故障更严重？ 如果所有副本都依赖同一坏掉的下游，过深检查可能把整组实例判为失败；大量重启又触发冷启动、重连和缓存重建。应区分局部故障与共同依赖故障，并限制自动动作的影响范围。

参考资料