播面

在 Nacos 中，服务实例被分为两类：临时实例（Ephemeral Instance） 和 持久化实例（Persistent Instance）。

这两者的核心区别在于生命周期管理、健康检查机制以及数据一致性协议（CAP模型）。

以下是详细的对比和解析：

1. 核心区别总结

2. 详细原理解析

A. 临时实例 (Ephemeral)

这是云原生架构中最常见的模式。

• 工作机制：
  1. 注册：服务启动时向 Nacos 注册。
  2. 心跳（Keep Alive）：客户端（服务实例）维护一个定时任务，定期向 Nacos 服务端发送心跳包（Nacos 2.x 使用 gRPC 长连接，连接断开即视为心跳丢失）。
  3. 剔除：如果 Nacos 在一定时间内（默认 15秒）没收到心跳，会将实例标记为不健康；如果更长时间（默认 30秒）没收到，Nacos 会直接将该实例从服务列表中删除。
• 数据存储：
  • 数据只保存在 Nacos 节点的内存中。
  • 如果 Nacos 重启，数据会丢失，但因为客户端会不断重试注册和发送心跳，数据很快会恢复。
• CAP 选择：AP（可用性）。
  • 使用 Distro 协议。数据同步是 Peer-to-Peer 的，不依赖 Leader，写入性能高，适合高并发的服务注册。

B. 持久化实例 (Persistent)

这是为了兼容传统架构或核心基础组件设计的。

• 工作机制：
  1. 注册：服务向 Nacos 注册，Nacos 将其写入磁盘。
  2. 主动探测：Nacos 服务端会主动检测客户端的健康状态（通常是 TCP 或 HTTP 探测）。
  3. 保留：即使探测失败，Nacos 也只会将该实例标记为 Unhealthy（不健康），而永远不会自动删除该实例信息，除非运维人员手动调用 API 删除。
• 数据存储：
  • 数据会持久化到 Nacos 服务器的磁盘上。
  • Nacos 重启后，会从磁盘加载这些实例信息。
• CAP 选择：CP（一致性）。
  • 使用 Raft 协议。集群中必须选出 Leader 才能写入，保证所有节点数据强一致。

3. 适用场景

• 临时实例（推荐用于微服务）：

  • Kubernetes (K8s) 环境：Pod 的 IP 是动态变化的，Pod 重启后 IP 会变，旧的 IP 应该立即失效并被删除。
  • 弹性伸缩：业务高峰期自动增加实例，低峰期销毁实例。
  • Spring Cloud / Dubbo 业务服务：无状态的服务。

• 持久化实例（推荐用于基础设施）：

  • 数据库 (MySQL, Oracle)：IP 通常是固定的。
  • 缓存 (Redis)、消息队列 (RocketMQ)。
  • 传统部署的单体应用：IP 固定，不希望因为网络抖动导致服务信息丢失。

4. 如何配置

在 Spring Cloud Alibaba Nacos Discovery 中，可以通过配置文件进行切换。

设置为临时实例（默认，通常不需要配置）：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: true # 默认为 true

设置为持久化实例：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为 false 即为持久化实例

5. 为什么 Nacos 要同时支持这两种？

这是 Nacos 相比于 Eureka（只支持 AP/临时）和 Zookeeper（只支持 CP/持久）的一大优势。

• Eureka 认为服务发现场景下，可用性比一致性重要（AP），所以它适合微服务，但不适合做强一致性的元数据管理。
• Zookeeper 追求强一致性（CP），网络抖动可能导致服务不可用（Leader 选举期间），且写入性能受限。

Nacos 的设计哲学是：

• 对于服务注册发现（Service Discovery），绝大多数场景是临时的，需要高性能和高可用，所以默认走 AP 模式（临时实例）。
• 对于配置管理（Config）或核心组件管理，需要强一致性，所以走 CP 模式（持久化实例）。

通过一个开关 ephemeral，Nacos 能够同时满足云原生微服务和传统架构的需求。