线上惊魂:Nacos 抖动导致大面积服务掉线,我们是怎么兜底的

事故现场

这次的背景是生产环境 Nacos 集群 3 个节点,其中一个节点因底层硬件问题需要重启。按理说,集群架构天然支持节点故障转移,但重启后大量服务开始报不健康告警,最终引发连锁反应------大面积服务重启。

问题的本质是:Nacos 服务端的一次短暂抖动,怎么就传导成了客户端的雪崩?

针对这次的nacos问题而产生的议题就是如何避免因nacos的抖动而减少对客户端的影响降到最小。

根因定位

我们的 Nacos 集群版本是 1.4.2,配合 Spring Cloud Alibaba 使用。排查发现,Spring Cloud 会定期调用 /actuator/health 端点检查服务健康状态,而这个健康检查默认会去探测 Nacos 的发现服务状态。当 Nacos 节点重启期间短暂不可达时,健康检查判定服务 DOWN,触发了大规模重启。

看下当时的客户端日志:

节点地址不可用,连接直接中断。

解决方案

思路很直接:既然健康检查会因为 Nacos 抖动误判,那就关掉它对 Nacos 状态的依赖。

Spring Cloud 提供了一个通用参数 spring.cloud.discovery.client.health-indicator.enabled,设为 false 后,健康检查不再去查 Nacos 的服务发现状态。

第一步:禁用 Discovery 健康指标

YAML 复制代码
spring:
  profiles: prd
  cloud:
    discovery:
      client:
        health-indicator:
          enabled: false

加了这个配置后,/actuator/health 的返回内容会发生变化。

加配置前:

nacosDiscovery 和 nacosConfig 都在健康检查列表里,且包含所有服务列表,Nacos 抖动直接判定整体 DOWN。

加配置后:

服务明细列表干净了,只剩 nacosConfig 和 nacosDiscovery 两个状态指标。

第二步:精细控制各组件健康检查

光关掉 discovery 的还不够,其他组件也可能在 Nacos 抖动时误判。进一步精细化配置:

YAML 复制代码
management:
  endpoints:
    web:
      exposure:
        include: '*'
  endpoint:
    health:
      show-details: ALWAYS
    metrics:
      enabled: true
    prometheus:
      enabled: true
  metrics:
    export:
      prometheus:
        enabled: true
    tags:
      application: ${spring.application.name}
  health:
    redis:
      enabled: false
    rabbit:
      enabled: false
    db:
      enabled: false
    nacos-config:
      enabled: false
    nacos-discovery:
      enabled: false

关键就是最后两行------把 nacos-config 和 nacos-discovery 的健康检查都关掉。/actuator/health 不检查 Nacos和Config 连接状态 ,不可用不应阻断服务。

效果验证

关闭前: Nacos 一抖,整体状态 DOWN

nacosConfig、nacosDiscovery 都是 DOWN,直接拖垮整体状态。

关闭后: Nacos 抖动也不影响服务存活

只剩 diskSpace、refreshScope、hystrix 这些本地指标,Nacos 状态完全不参与判定,服务稳了。

为什么这个参数有效

  1. spring.cloud.discovery.client.health-indicator.enabled 是 Spring Cloud 框架的通用配置,Nacos 作为 Discovery Client 的实现,天然遵循这套规范。

  2. 把 nacos-config 和 nacos-discovery 的健康检查都关掉。

  3. 关闭后,服务实例不再因为 Nacos 服务短暂不可达就被判定为不健康,客户端进程不会被误杀重启

踩坑提醒

  • 这个参数需要 Spring Cloud Alibaba 2.1.0 或更高版本,老版本可能不支持

  • 健康检查默认开启(enabled: true),不加配置就是全开状态

  • 关闭 Nacos 健康检查不等于放弃监控------Prometheus + Grafana 该配还得配,只是别让 Actuator 健康端点来背这个锅

相关推荐
2501_933923257 天前
SpringCloud组件:Nacos服务注册快速入门
后端·spring·spring cloud·nacos
jonyleek7 天前
JVS数字底座私有化部署实践:Spring Cloud + K8S 实现文档平台开箱即用
elasticsearch·kubernetes·私有化部署·springcloud·minio·jvs企业文档·文档治理
wangjialelele9 天前
一文梳理 Spring Cloud 核心组件:Eureka、Nacos、OpenFeign、LoadBalancer 与 Gateway
java·spring boot·spring·spring cloud·微服务·nacos
LQQrk智能排产物联网规则引擎14 天前
规则上线从3天到3分钟:JVS-Rules热更新实践——基于Spring Cloud的无重启规则发布方案
springcloud·微服务架构·热更新·规则引擎·灰度发布·jvs-rules·规则测试
Java成神之路-15 天前
深入理解 Spring Cloud Gateway、Nacos 与 OpenFeign:核心原理与协作流程全解析
springcloud
wewowilling15 天前
认识微服务
java·运维·微服务·springcloud
流烟默17 天前
网关 Sentinel 限流实战:API 分组、规则加载与全量匹配踩坑记
nacos·gateway·sentinel·流控规则
spencer_tseng17 天前
nacos CVE‑2021‑29441
nacos·alibaba
Joy T18 天前
Spring AI 项目中的 pom.xml、application.yml 与 Nacos:从依赖管理到运行配置
spring·nacos·pom.xml·profile·参数配置·application.yml
LoneEon19 天前
CentOS7 部署 Nacos3.x 集群实战:从注册中心到 AI 管理中心
linux·人工智能·nacos