Nacos服务注册为何默认临时实例？10个关键原因解析

在K8s环境中使用Nacos，建议大家保持默认配置就好，尤其不要手动去开启持久化模式。不然你的控制台里很可能留下一堆清理不掉的无用数据。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

做过Spring Cloud开发的同学，对Nacos肯定不陌生。

大家平时写代码，配置文件里只要配好Nacos地址，程序一启动，服务就自动注册上去了。

但不知道大家有没有留意过一个细节：

当你把服务停掉，或者直接Kill进程，Nacos控制台上的那个服务实例，很快就消失了。它不是变成了红色的不健康状态，而是直接从列表里被删除了。

这在以前用Zookeeper或者早期Dubbo的时候，其实是不太一样的。那时候服务挂了，通常只是显示不健康，节点信息还会保留在那儿。

为什么Nacos要默认把它直接删掉呢？

临时 vs 持久

其实在Nacos的设计里，实例是分两种的：临时实例（Ephemeral）和持久实例（Persistent）。

Spring Cloud Alibaba默认给我们的配置，就是临时实例。

这二者最大的区别，在于谁来维持心跳，以及挂了之后怎么处理。

临时实例（默认）

客户端（你的微服务）主动给Nacos发心跳，默认5秒一次。

如果Nacos一段时间（比如30秒）没收到心跳，它就默认你已经下线了，直接把你从服务列表里剔除。

持久实例

客户端注册一次就不管了。Nacos服务端会主动去探测这个IP通不通。我就在这儿，你不注销我，我就一直在。

如果探测不通，Nacos只会把你标记为不健康，但不会删除你。这条记录会一直留在列表里。

为什么要默认选临时？

很多从传统架构转过来的同学可能会觉得：保留历史记录不好吗？持久化下来，方便我排查问题啊。

在物理机时代，这确实没问题。因为那时候IP是固定的，机器挂了，修好重启，IP还是那个IP。

但现在Docker和K8s的普及，环境变了。

想象一下，你的服务部署在K8s里：

每次发布更新，旧的Pod被销毁，新的Pod被创建。关键点是：新Pod的IP地址通常是变的。

如果你用的是持久实例：

每次重启，Nacos里就会多出几个不健康的旧IP。发布几次之后，你的服务列表里就会堆积成百上千个无效的IP地址。

这不仅浪费存储，还会导致客户端拉取服务列表时，还得花精力去过滤那些已经不存在的节点。

所以Nacos默认选择临时实例，因为在云原生环境下，IP地址是随时可能回收的资源。

服务挂了就是挂了，直接清理掉，给新IP腾位置，保持服务列表的干净。

深层原因：CAP的取舍

除了IP变动，还有一个更核心的原因，涉及分布式系统的CAP理论。

持久实例（CP模式）

因为它要求数据可靠，Nacos内部通常走Raft协议。

Raft是强一致性的，这意味着如果Nacos集群里的Leader挂了，需要重新选举。在选举期间，整个注册中心是不可写的。

对于高频上下线的微服务来说，因为网络抖动就导致服务注册不上，这是很难接受的。

临时实例（AP模式）

它走的是Nacos自研的Distro协议，它的逻辑是：高可用大于强一致。

即使集群之间数据还没完全同步，只要能服务注册上来，能让别人发现你，不报错，比什么都强。

什么时候该用持久实例？

持久实例它主要适用的场景，是那些IP不怎么变、且极其重要的基础设施，比如数据库MySQL、Redis。

有时候我们希望把MySQL也注册到Nacos里，让微服务去发现数据库的地址。

因为数据库通常是固定的，即使它暂时挂了，我们也不希望它从列表里消失。我们希望它只是显示异常，等修好了，IP还是那个IP，业务能自动恢复。

说在最后

回到最初的问题：为什么默认是临时实例？

因为在现在的微服务架构里，活着比记住更重要。

微服务应用：是流动的资源，用临时实例（AP模式）。挂了就清理，保持服务列表的有效性，别让客户端调用到死节点。

数据库/重资产：是固定的资源，用持久实例（CP模式）。挂了保留记录，方便运维排查。

大家在K8s环境下用Nacos，建议就保持默认配置，不要手动去开持久化模式，否则你的控制台里可能会留下一堆清理不掉的无用数据。