改了 Nacos 一行配置,搞崩线上支付系统!

节前上线出问题,线上灰度发布后部分用户反馈付款后订单状态不更新,支付服务的失败率飙升。一顿排查后发现致命配置错误。小可爱上线时,将payment-service服务的 Nacos 注册类型改成了ephemeral=false(持久化实例)。

当时其中一台服务节点因内存泄漏频繁 GC,心跳线程被阻塞超过 30 秒,但是由于持久化实例没被 Nacos 剔除,导致调用方持续往这台异常节点发请求,最终拖垮整个支付链路。

这个面试场景题总问,不过很多同学对 Nacos 临时、持久实例的认知,只停留在服务会不会消失的表面,什么时候该用临时,什么时候该用持久,适用场景是什么,没太明白。

注册中心和配置中心本质区别

我们用 Nacos 主要使用到它的服务注册中心和配置中心,它们的设计初衷不同,服务注册中心要求符合 CAP 中的高可用(AP)服务发现不能中断,允许短暂数据不一致;注册中心要求是一致性(CP),配置不能错、不能丢,更新需同步到所有节点。

简单说,注册中心的实例是活的服务节点,配置中心的实例是死的配置文件

它们之间的实例的概念也不太一样:

对比维度 服务注册中心的实例 配置中心的实例
本质 运行中的服务节点(如user-service的某台服务器) 静态配置数据单元(如redis-dev.yml配置文件)
核心作用 提供服务发现,让调用方找到可用节点 集中管理配置,支持动态更新
创建方式 客户端自动注册(如 Spring Cloud 服务启动时) 手动创建(控制台 / API)或代码推送
生命周期依赖 依赖服务节点的运行状态(节点宕机则实例失效) 依赖手动维护(不删就一直存在)

注册中心:默认临时实例

要知道服务注册中心的核心需求是实时感知服务可用性

它设计了临时实例持久化实例两种模式,分别对应动态服务和静态服务场景。

临时实例

临时实例是 Nacos 服务注册的默认模式

Spring Cloud、Dubbo 等业务服务启动时,若不额外配置,都会以临时实例注册。核心逻辑是心跳保活,来检测服务的可用性。

  • 心跳机制:客户端每 5 秒向 Nacos 服务端发送一次心跳;服务端 15 秒没收到心跳,就把实例标记为不健康;30 秒没收到,直接从注册表中剔除实例;

  • 存储方式:实例信息只存在服务端内存中,不写磁盘。Nacos 重启后,所有临时实例都会消失,需客户端重新注册;

  • 故障表现:服务节点宕机、网络中断,或像我们支付服务那样因 GC 阻塞心跳,实例会被自动摘除,调用方不会再路由到无效节点。

持久化实例

持久化实例则完全相反,它针对长期稳定运行、很少变化的基础服务(如 MySQL、Redis、Elasticsearch)设计,核心逻辑是服务端主动探活 + 数据持久化,不适合支付、订单这类动态业务服务。

  • 保活机制:不需要客户端发心跳,而是 Nacos 服务端主动探活。支持 TCP 端口探测(如 MySQL 的 3306 端口)、HTTP 接口探测(如 Redis 的 /health 接口)、自定义协议探测;

  • 存储方式:实例信息会持久化到 Nacos 的数据库(默认 Derby,生产用 MySQL),即使 Nacos 重启,实例信息也不会丢失;

  • 故障表现:实例宕机后,Nacos 只会把它标记为不健康,不会删除。运维能在控制台实时看到故障节点,方便排查,恢复后实例自动变回健康。

在 SpringCloud 项目中,只需在application.yml中添加一行配置,就能切换实例类型,就是这行配置,被新人改错导致了故障:

yaml 复制代码
spring:
   cloud:
     nacos:
       discovery:
          server-addr: 192.168.1.100:8848
          ephemeral: false # 新人误改为此值,正确应为true(默认)
          service: payment-service # 注册的服务名

配置中心:默认持久化

Nacos 配置中心的所有配置实例(即配置文件)默认都是持久化的,根本不存在临时配置的概念,所谓的动态更新也和临时无关。

Nacos 配置中心的设计初衷是集中管理配置,避免配置丢失,因此所有配置都满足以下特性:

  • 存储层面:无论在控制台创建、还是用 API 推送的配置,都会持久化到数据库(如 MySQL),即使 Nacos 服务端重启、甚至服务器宕机,配置也不会丢失;

  • 生命周期:配置只会被手动删除或覆盖更新,不会因为客户端断开连接、或服务重启而自动消失;

  • 动态更新:客户端通过长轮询机制监听配置变化(默认每 30 秒轮询一次,可调整),配置更新后 1 秒内推送到客户端。但动态更新是 内容实时变化,不是配置临时存在。

写在最后

说了一大堆其实总结起来就两句话:

  • 服务注册中心:动态业务服务(支付、订单)用临时实例(默认),静态基础组件(MySQL、Redis)用持久化实例;

  • 配置中心:没有临时配置,所有配置默认持久化,动态更新 ≠ 临时存在。

读到这就等于学会!

相关推荐
寻星探路3 小时前
【深度长文】万字攻克网络原理:从 HTTP 报文解构到 HTTPS 终极加密逻辑
java·开发语言·网络·python·http·ai·https
想用offer打牌4 小时前
MCP (Model Context Protocol) 技术理解 - 第二篇
后端·aigc·mcp
曹牧5 小时前
Spring Boot:如何测试Java Controller中的POST请求?
java·开发语言
KYGALYX5 小时前
服务异步通信
开发语言·后端·微服务·ruby
掘了6 小时前
「2025 年终总结」在所有失去的人中,我最怀念我自己
前端·后端·年终总结
爬山算法6 小时前
Hibernate(90)如何在故障注入测试中使用Hibernate?
java·后端·hibernate
kfyty7256 小时前
集成 spring-ai 2.x 实践中遇到的一些问题及解决方案
java·人工智能·spring-ai
猫头虎6 小时前
如何排查并解决项目启动时报错Error encountered while processing: java.io.IOException: closed 的问题
java·开发语言·jvm·spring boot·python·开源·maven
李少兄6 小时前
在 IntelliJ IDEA 中修改 Git 远程仓库地址
java·git·intellij-idea