就绪探针要不要囊括下游依赖看是否真阻塞

判断某个外部依赖该不该算进就绪探针，标准不是”这个依赖重不重要”，而是”这个依赖不可用时，应用还能不能继续提供部分能力”。目录服务对下单服务来说是外部依赖，但下单服务已经给这条调用配好了熔断器和降级逻辑，目录服务挂了下单服务依然能以降级形式继续工作，所以不该把目录服务的健康状况接进下单服务的就绪探针——接进去的话，目录服务一抖动会连累下单服务被判定为”没准备好”，直接被摘掉流量，明明还能用的能力也被一并关掉了。反过来边缘服务离不开 Redis 存会话数据，Redis 不可用时边缘服务压根处理不了新请求，这种”没有它就彻底干不了活”的依赖才应该被纳入就绪探针一起判断。发散：这条判断标准和[[优雅关闭的信号竞态与延迟]]系列卡片是同一种审慎——不是所有”用到的外部系统”都该被无脑塞进健康检查，塞多了反而会把局部的抖动放大成整个服务被摘流量的连锁反应，判断的关键始终是”这个依赖不可用时，我还能不能提供哪怕降级的服务”。