这次的背景是生产环境 Nacos 集群 3 个节点，其中一个节点因底层硬件问题需要重启。按理说，集群架构天然支持节点故障转移，但重启后大量服务开始报不健康告警，最终引发连锁反应——大面积服务重启。 科技新闻。
节点地址不可用，连接直接中断。
关闭后： Nacos 抖动也不影响服务存活
线上背景与起因
spring.cloud.discovery.client.health-indicator.enabled 是 Spring Cloud 框架的通用配置，Nacos 作为 Discovery Client 的实现，天然遵循这套规范。
思路很直接：既然健康检查会因为 Nacos 抖动误判，那就关掉它对 Nacos 状态的依赖。
把 nacos-config 和 nacos-discovery 的健康检查都关掉。
线上事件经过
Spring Cloud 提供了一个通用参数 spring.cloud.discovery.client.health-indicator.enabled，设为 false 后，健康检查不再去查 Nacos 的服务发现状态。
我们的 Nacos 集群版本是 1.4.2，配合 Spring Cloud Alibaba 使用。排查发现，Spring Cloud 会定期调用 /actuator/health 端点检查服务健康状态，而这个健康检查默认会去探测 Nacos 的发现服务状态。当 Nacos 节点重启期间短暂不可达时，健康检查判定服务 DOWN，触发了大规模重启。
关闭前： Nacos 一抖，整体状态 DOWN
线上各方回应
问题的本质是：Nacos 服务端的一次短暂抖动，怎么就传导成了客户端的雪崩？
健康检查默认开启（enabled: true），不加配置就是全开状态
关键就是最后两行——把 nacos-config 和 nacos-discovery 的健康检查都关掉。/actuator/health 不检查 Nacos和Config 连接状态 ，不可用不应阻断服务。
线上影响分析
针对这次的nacos问题而产生的议题就是如何避免因nacos的抖动而降低对客户端的影响降到最小。
加配置后：
这个参数需要 Spring Cloud Alibaba 2.1.0 或更高版本，老版本可能不支持
nacosConfig、nacosDiscovery 都是 DOWN，直接拖垮整体状态。
加配置前：
服务明细列表干净了，只剩 nacosConfig 和 nacosDiscovery 两个状态指标。
看下当时的客户端日志：
加了这个配置后，/actuator/health 的返回内容会发生变化。
只剩 diskSpace、refreshScope、hystrix 这些本地指标，Nacos 状态完全不参与判定，服务稳了。
nacosDiscovery 和 nacosConfig 都在健康检查列表里，且包含所有服务列表，Nacos 抖动直接判定整体 DOWN。
光关掉 discovery 的还不够，其他组件也可能在 Nacos 抖动时误判。进一步精细化配置：
关闭后，服务实例不再因为 Nacos 服务短暂不可达就被判定为不健康，客户端进程不会被误杀重启
关闭 Nacos 健康检查不等于放弃监控——Prometheus + Grafana 该配还得配，只是别让 Actuator 健康端点来背这个锅，引发了热烈讨论。
