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

最新推荐文章于 2025-11-12 22:07:21 发布

转载最新推荐文章于 2025-11-12 22:07:21 发布 · 28 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://www.cnblogs.com/chengxy-nds/p/19134558

文章标签：

#it

节前上线出问题，线上灰度发布后部分用户反馈付款后订单状态不更新，支付服务的失败率飙升。一顿排查后发现致命配置错误。小可爱上线时，将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中添加一行配置，就能切换实例类型，就是这行配置，被新人改错导致了故障：

/* by yours.tools - online tools website : yours.tools/zh/ */
spring:
   cloud:
     nacos:
       discovery:
          server-addr: 192.168.1.100:8848
          ephemeral: false # 新人误改为此值，正确应为true（默认）
          service: payment-service # 注册的服务名