Spring Cloud 服务注册与发现深度原理——Eureka、Nacos 注册机制内部实现

老张2026/4/30大约 8 分钟

Spring Cloud 服务注册与发现深度原理——Eureka、Nacos 注册机制内部实现

适读人群：Spring Cloud 中级开发者、想搞懂注册中心底层的后端工程师 | 阅读时长：约16分钟 | 核心价值：彻底吃透注册中心的内部实现，不再只会 YAML 配置

一次"灵魂拷问"

大约两年前，我在帮一家物流公司做架构评审，他们的 Spring Cloud 系统已经运行了一年多，Eureka 做注册中心，一切看起来都还好。直到那天下午，架构师小王问了我一个问题：

"老张，你说我们这套 Eureka，如果注册中心挂了，已经注册的服务还能正常调用吗？"

我回答："能，Eureka 有客户端缓存。"

"那如果客户端也重启了呢？"

"……"

这个追问让我意识到，我们对注册中心的理解往往停留在"用它"的层面，而不是"懂它"的层面。Eureka 的客户端缓存机制、Nacos 的 AP/CP 切换、心跳与健康检查的差异——这些才是决定系统稳定性的关键，而不是那几行配置。

今天，我们把 Eureka 和 Nacos 的注册机制从头剖开，不留死角。

一、Eureka：CAP 取舍下的 AP 设计

1.1 Eureka Server 的核心数据结构

Eureka Server 的服务注册表在内存中的核心结构是一个双层 ConcurrentHashMap：

registry: ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>
          ↑ serviceName          ↑ instanceId    ↑ 租约对象

Lease<InstanceInfo> 对象包含实例信息（IP、端口、元数据等）以及租约的时间戳（最后心跳时间、注册时间、过期时间）。

这个结构决定了 Eureka 的查询效率极高——根据服务名查所有实例，时间复杂度 O(1)。

1.2 三级缓存机制

Eureka Server 维护三级缓存，这是很多人不知道的：

Registry（注册表）：源数据，写操作（注册、注销、心跳）直接作用于此
ReadWriteCacheMap：可读写缓存，默认 180 秒过期，从 Registry 读取并序列化为 JSON/XML 格式
ReadOnlyCacheMap：只读缓存，默认每 30 秒从 ReadWriteCacheMap 同步一次

Eureka Client 获取服务列表时，读的是 ReadOnlyCacheMap。这意味着，即使一个服务刚刚注销，最长可能需要 30 秒 + 30 秒（Client 刷新间隔）= 60 秒 后，其他服务才能感知到这个变化。

这就是为什么 Eureka 在服务下线后，还有一段时间会出现调用失败的根本原因。

// 模拟 Eureka Client 的服务发现过程（简化版）
@Component
public class ServiceDiscoveryDemo {
    
    @Autowired
    private DiscoveryClient discoveryClient;
    
    /**
     * Eureka Client 在本地维护一份服务列表缓存
     * 默认每 30 秒从 Server 拉取增量更新（Delta）
     * 第一次启动拉取全量（Full），之后拉取增量
     */
    public List<ServiceInstance> getInstances(String serviceName) {
        // 这里实际上读的是本地缓存，不是每次都请求 Server
        List<ServiceInstance> instances = discoveryClient.getInstances(serviceName);
        
        if (instances.isEmpty()) {
            // 缓存里没有，说明可能服务刚注册还没同步，或者服务真的不存在
            log.warn("No instances found for service: {}", serviceName);
        }
        
        return instances;
    }
}

1.3 自我保护模式——被误解最深的机制

Eureka Server 的自我保护模式（Self-Preservation Mode）是很多团队的噩梦来源。

原理：Eureka Server 期望每分钟收到的心跳总数 = 实例数 × 每分钟心跳数 × 0.85。如果实际收到的心跳数低于这个阈值，Eureka Server 就不再剔除任何实例，认为"可能是网络问题，而不是服务真的挂了"。

踩坑一：开发/测试环境自我保护模式导致的"幽灵实例"

现象：测试环境频繁重启服务，Eureka 里一直存在大量已经不存在的实例，负载均衡器偶尔把请求打到这些幽灵实例上，返回连接超时。

原因：测试环境实例数少，心跳数本来就低，触发了自我保护模式。

解法：测试环境直接关闭自我保护：

eureka:
  server:
    enable-self-preservation: false   # 测试环境关闭自我保护
    eviction-interval-timer-in-ms: 5000  # 缩短剔除间隔到 5 秒（默认 60 秒）
  instance:
    lease-renewal-interval-in-seconds: 5    # 心跳间隔 5 秒（默认 30 秒）
    lease-expiration-duration-in-seconds: 15 # 过期时间 15 秒（默认 90 秒）

生产环境保持自我保护开启，但要合理设置告警：当 Eureka 进入自我保护模式时，立刻触发告警，排查是网络抖动还是大量服务宕机。

二、Nacos：注册中心的"进化版"

2.1 AP 与 CP 的切换

Nacos 支持两种模式：AP（基于 Distro 协议） 和 CP（基于 Raft 协议）。

默认临时实例走 AP 模式，持久化实例走 CP 模式。

AP 模式：每个 Nacos Server 节点都接受注册请求，节点间异步同步数据，最终一致性。适合服务注册发现这种高可用优先的场景。
CP 模式：写操作必须经过 Raft 选举出的 Leader 节点，强一致性。适合配置中心这种数据准确性优先的场景。

理解这个区别非常重要。Nacos 默认配置中心和注册中心共享同一个集群，但在底层，它们使用的一致性协议是不同的。

2.2 Nacos 服务注册的完整流程

Client 启动
    ↓
调用 NacosServiceRegistry.register()
    ↓
构建 Instance 对象（包含 IP、Port、权重、元数据）
    ↓
发送 HTTP POST /nacos/v1/ns/instance 到 Server
    ↓
Server 接收注册请求
    ↓
判断临时/持久化实例
    ↓ (临时实例)              ↓ (持久化实例)
写入内存注册表              写入磁盘 + 内存
    ↓                          ↓
Distro 协议同步              Raft 协议同步
    ↓                          ↓
其他节点更新               其他节点更新
    ↓
Client 开启心跳任务（每 5 秒一次）

踩坑二：多网卡环境下注册到错误的 IP

现象：服务注册到 Nacos 后，消费方调用时连接到了一个内网隔离的 IP，导致请求超时。

原因：服务器有多个网卡（比如 Docker 环境、VPN 环境），Nacos Client 自动选择了错误的网卡 IP。

解法：

spring:
  cloud:
    nacos:
      discovery:
        ip: 10.0.1.100   # 显式指定注册 IP
        # 或者指定网卡名
        network-interface: eth0

如果是容器环境，建议通过环境变量注入：

spring:
  cloud:
    nacos:
      discovery:
        ip: ${POD_IP:}   # Kubernetes 通过 downward API 注入 Pod IP

2.3 服务发现的订阅机制

Nacos 的服务发现不是纯粹的拉模型，而是拉 + 推的混合模型：

客户端启动时，拉取服务列表，并发送订阅请求
服务端有变化（实例上下线）时，主动推送给订阅了该服务的客户端（UDP 推送）
客户端同时维护一个定时任务，每 10 秒做一次兜底轮询

这比 Eureka 纯拉模型的感知延迟低得多。Eureka 感知服务变化最长需要 60 秒，而 Nacos 在网络正常的情况下，服务变化推送延迟通常在 1 秒以内。

// Nacos 服务订阅示例（直接使用 NamingService，绕过 Spring Cloud 抽象层）
@Component
public class NacosServiceSubscriber implements ApplicationRunner {
    
    @Autowired
    private NamingService namingService;
    
    @Override
    public void run(ApplicationArguments args) throws Exception {
        // 订阅服务变化，实时感知实例列表变化
        namingService.subscribe("inventory-service", "DEFAULT_GROUP",
            event -> {
                if (event instanceof NamingEvent) {
                    NamingEvent namingEvent = (NamingEvent) event;
                    List<Instance> instances = namingEvent.getInstances();
                    log.info("服务实例变化: service={}, instances={}", 
                        namingEvent.getServiceName(), 
                        instances.stream()
                            .map(i -> i.getIp() + ":" + i.getPort() + 
                                     "[healthy=" + i.isHealthy() + "]")
                            .collect(Collectors.joining(", ")));
                    // 可以在这里更新本地路由表或连接池
                }
            });
    }
}

三、深度对比：该选 Eureka 还是 Nacos？

我经历过从 Eureka 迁移到 Nacos 的项目，也见过从 Nacos 退回 Eureka 的（虽然很少）。核心对比如下：

感知延迟：Nacos 的拉推结合模型，服务变化感知通常在 1 秒以内；Eureka 纯拉模型，最长 60 秒。这对需要快速故障转移的系统来说差异巨大。

功能：Nacos 同时支持注册中心和配置中心，减少了中间件数量。Eureka 只做注册中心，配置中心需要额外的 Spring Cloud Config。

维护状态：Eureka 2.0 官方已停止开发，现在社区版本也处于维护状态，不再有新特性。Nacos 仍在活跃开发中。

踩坑三：从 Eureka 迁移到 Nacos 时的双注册陷阱

现象：迁移过程中，部分服务注册到了 Nacos，部分还在 Eureka，服务间调用失败。

原因：迁移没有规划好顺序，消费方已经切到 Nacos 发现，但提供方还在 Eureka 注册。

解法：迁移必须先让提供方双注册（同时注册到 Eureka 和 Nacos），再切换消费方，最后再摘掉提供方的 Eureka 注册。

// 双注册实现思路：实现自定义的 ServiceRegistry 包装器
@Configuration
public class DualRegistryConfig {
    
    @Bean
    @Primary
    public ServiceRegistry dualServiceRegistry(
            EurekaServiceRegistry eurekaRegistry,
            NacosServiceRegistry nacosRegistry) {
        return new DualServiceRegistry(eurekaRegistry, nacosRegistry);
    }
}

四、总结：注册中心选型的决策框架

从原理层面看，选择注册中心有几个核心维度：

一致性需求：如果你的系统对服务发现的实时性要求极高（金融交易、实时竞价），选 Nacos；如果可以接受 30-60 秒的感知延迟，Eureka 也没问题
运维复杂度：Nacos 需要维护数据库，Eureka 是纯内存的，相对简单
技术栈统一性：如果已经在用 Spring Cloud Alibaba 全套，Nacos 是自然选择；如果只是用了 Spring Cloud Netflix，切换成本要评估

无论选哪个，一定要做客户端侧的容错：超时重试、熔断降级、本地缓存兜底。注册中心只是服务发现的辅助工具，真正保证系统稳定的，是客户端的容错逻辑。