改了 Nacos 一行配置，搞崩线上支付系统！

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

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

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

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

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

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

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

注册中心：默认临时实例

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

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

临时实例

临时实例是 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中添加一行配置，就能切换实例类型，就是这行配置，被新人改错导致了故障：

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）用持久化实例；

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

读到这就等于学会！