前上线出问题，线上灰度发布后部分用户反馈付款后订单状态不更新，支付服务的失败率飙升。一顿排查后发现致命配置错误。小可爱上线时，将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）用持久化实例；
