十万个why：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，建议就保持默认配置，不要手动去开持久化模式，否则你的控制台里可能会留下一堆清理不掉的无效数据。
看完等于学会，点个赞吧！！！