两个问题，不是一个问题
就绪探针问：这个实例此刻能否提供服务？存活探针问：这个进程是否已经陷入不重启就无法恢复的状态？数据库迁移、缓存冷启动或队列积压会让实例暂时不就绪，但它完全活着。此时重启只会抹掉预热进度，从头再来。
失败后应触发什么
就绪失败会把端点从负载均衡中摘除，进程继续运行、继续重试，恢复后重新加入。存活失败会杀掉并重启容器。这是很粗暴的手段，只应对死锁、线程耗尽或不可恢复状态使用。
例如，服务失去数据库连接时应该让就绪失败，而不是让存活失败。如果两者同时失败，所有副本会一起重启，数据库迎来连接风暴，恢复时间比原始故障还长。
启动阶段
慢启动应用需要第三个信号。启动探针在应用初始化完成前暂停存活判定，避免长时间预热期间反复重启。没有它，团队只能把初始延迟调得很长，结果在稳定运行时存活检查形同虚设。
与单一健康端点的对比
单一端点运维更简单，对没有依赖的小服务足够用。代价出现在部分故障时：要么重启健康但未就绪的实例，要么把流量硬塞过去。拆分信号只多了一点配置，却换来精确且可回退的处置手段。
阈值怎么调
就绪检查应快，并能容忍下游的瞬时错误；存活检查应慢，并且只关注本地健康。发布时要同时验证两者：就绪应在数秒内拦住流量，而存活在正常滚动发布中绝不应触发。