阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处程序员小富「xiaofu」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

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

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）用持久化实例；
配置中心：没有临时配置，所有配置默认持久化，动态更新 ≠ 临时存在。

读到这就等于学会！

芋道源码 —— 纯源码解析博客

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