Nacos 一行配置搞崩支付系统！(转)

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

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

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

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

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

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

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

对比维度	服务注册中心的实例	配置中心的实例
本质	运行中的服务节点（如user-service的某台服务器）	静态配置数据单元（如redis-dev.yml配置文件）
核心作用	提供服务发现，让调用方找到可用节点	集中管理配置，支持动态更新
创建方式	客户端自动注册（如 Spring Cloud 服务启动时