【Spring】 Spring Cloud 服务注册与发现深度解析：Eureka/Nacos/Consul 源码、AP vs CP 与自我保护机制

Spring Cloud 服务注册与发现深度解析：Eureka/Nacos/Consul 源码、AP vs CP 与自我保护机制

服务注册与发现是微服务架构的基石，Spring Cloud 通过抽象接口统一了多种实现。本文深入剖析 Eureka、Nacos、Consul 三大注册中心的源码实现，揭示其背后的 CAP 权衡与自我保护机制。

---

一、Spring Cloud Commons 统一抽象

Spring Cloud 定义了统一接口，解耦具体实现：

// 服务注册接口
public interface ServiceRegistry<R extends Registration> {
    void register(R registration);    // 注册
    void deregister(R registration);  // 注销
    void close();                     // 关闭
    void setStatus(R registration, String status);  // 设置状态
}

// 服务发现接口
public interface DiscoveryClient {
    String description();  // 描述
    List<String> getServices();  // 获取所有服务名
    List<ServiceInstance> getInstances(String serviceId);  // 获取服务实例
}

核心实现类：

• Eureka ：EurekaServiceRegistry, EurekaDiscoveryClient
• Nacos ：NacosServiceRegistry, NacosDiscoveryClient
• Consul ：ConsulServiceRegistry, ConsulDiscoveryClient

---

二、Nacos 源码深度剖析

2.1 客户端自动注册机制

入口 ：spring-cloud-starter-alibaba-nacos-discovery 的 spring.factories

// NacosServiceRegistryAutoConfiguration 创建三个核心 Bean
@Configuration
public class NacosServiceRegistryAutoConfiguration {
    
    @Bean
    public NacosServiceRegistry nacosServiceRegistry(
            NacosDiscoveryProperties nacosDiscoveryProperties) {
        return new NacosServiceRegistry(nacosDiscoveryProperties);
    }
    
    @Bean
    public NacosRegistration nacosRegistration(
            NacosDiscoveryProperties nacosDiscoveryProperties,
            ApplicationContext context) {
        return new NacosRegistration(nacosDiscoveryProperties, context);
    }
    
    @Bean
    @ConditionalOnBean(AutoServiceRegistrationProperties.class)
    public NacosAutoServiceRegistration nacosAutoServiceRegistration(
            NacosServiceRegistry registry,
            NacosRegistration registration) {
        return new NacosAutoServiceRegistration(registry, registration);
    }
}

自动触发 ：NacosAutoServiceRegistration 监听 WebServerInitializedEvent 事件

// AbstractAutoServiceRegistration 模板方法
public void onApplicationEvent(WebServerInitializedEvent event) {
    bind(event);  // 触发注册
}

public void bind(WebServerInitializedEvent event) {
    // 获取应用端口
    int port = event.getWebServer().getPort();
    this.registration.setPort(port);
    
    // 调用服务注册
    start();
}

public void start() {
    if (!this.running.get()) {
        this.serviceRegistry.register(this.registration);  // 核心注册逻辑
        this.running.set(true);
    }
}

2.2 客户端服务注册与心跳

服务注册 ：NacosServiceRegistry.register()

public void register(Registration registration) {
    Instance instance = new Instance();
    instance.setIp(registration.getHost());
    instance.setPort(registration.getPort());
    instance.setServiceName(registration.getServiceId());
    instance.setMetadata(registration.getMetadata());
    
    // 调用 Nacos Client SDK
    namingService.registerInstance(
        registration.getServiceId(),
        getGroup(),
        instance
    );
}

// NacosNamingService.registerInstance()
public void registerInstance(String serviceName, String groupName, Instance instance) throws NacosException {
    String groupedServiceName = NamingUtils.getGroupedName(serviceName, groupName);
    // 1. 本地缓存注册信息
    BeatInfo beatInfo = beatReactor.buildBeatInfo(groupedServiceName, instance);
    // 2. 添加心跳任务（每 5 秒一次）
    beatReactor.addBeatInfo(groupedServiceName, beatInfo);
    // 3. 发送 HTTP 注册请求
    serverProxy.registerService(groupedServiceName, groupName, instance);
}

心跳机制 ：BeatReactor 定时任务

public void addBeatInfo(String serviceName, BeatInfo beatInfo) {
    String key = buildKey(serviceName, beatInfo.getIp(), beatInfo.getPort());
    BeatInfo oldBeat = beatMap.put(key, beatInfo);
    // 立即发送一次心跳
    executorService.submit(new BeatTask(beatInfo));
    
    // 定时调度（默认 5 秒间隔）
    ScheduledFuture<?> future = GlobalExecutor.scheduleBeat(new BeatTask(beatInfo), 
                                                              0, 
                                                              beatInfo.getPeriod(), 
                                                              TimeUnit.MILLISECONDS);
}

// BeatTask.run()
public void run() {
    long result = serverProxy.sendBeat(beatInfo, beatInfo.isLightBeatEnabled());
    // 处理心跳响应
    if (result > 0) {
        // 服务端返回下次心跳间隔
        beatInfo.setPeriod(result);
    }
}

2.3 服务端处理流程

入口 ：InstanceController

@RestController
@RequestMapping(UtilsAndCommons.NACOS_NAMING_CONTEXT + "/instance")
public class InstanceController {
    
    @PostMapping
    public String register(HttpServletRequest request) throws Exception {
        final String namespaceId = WebUtils.optional(request, CommonParams.NAMESPACE_ID, 
                                                      Constants.DEFAULT_NAMESPACE_ID);
        final String serviceName = WebUtils.required(request, CommonParams.SERVICE_NAME);
        final Instance instance = parseInstance(request);
        
        // 核心：调用 ServiceManager 注册
        serviceManager.registerInstance(namespaceId, serviceName, instance);
        return "ok";
    }
}

ServiceManager.registerInstance()

public void registerInstance(String namespaceId, String serviceName, Instance instance) throws NacosException {
    // 1. 创建空服务（如果不存在）
    createEmptyService(namespaceId, serviceName, instance.isEphemeral());
    
    // 2. 获取服务
    Service service = getService(namespaceId, serviceName);
    if (service == null) {
        throw new NacosException(...);
    }
    
    // 3. 添加实例
    addInstance(namespaceId, serviceName, instance.isEphemeral(), instance);
}

addInstance()：高并发写入优化

public void addInstance(String namespaceId, String serviceName, 
                        boolean ephemeral, Instance... ips) throws NacosException {
    // 构造唯一 Key
    String key = KeyBuilder.buildInstanceListKey(namespaceId, serviceName, ephemeral);
    
    // 获取服务
    Service service = getService(namespaceId, serviceName);
    
    // 加锁（细粒度，按服务级别）
    synchronized (service) {
        // 获取当前实例列表
        List<Instance> instanceList = addIpAddresses(service, ephemeral, ips);
        
        // 一致性服务（AP 模式用 Distro，CP 模式用 Raft）
        consistencyService.put(key, new Instances(instanceList));
    }
}

一致性服务切换：Nacos 同时支持 AP 和 CP

@Component("consistencyDelegate")
public class ConsistencyServiceDelegateImpl implements ConsistencyService {
    
    @Autowired
    private PersistentConsistencyService persistentConsistencyService; // CP 模式（Raft）
    
    @Autowired
    private EphemeralConsistencyService ephemeralConsistencyService; // AP 模式（Distro）
    
    @Override
    public void put(String key, Record value) throws NacosException {
        // 根据 ephemeral 标记选择协议
        if (KeyBuilder.matchEphemeralKey(key)) {
            ephemeralConsistencyService.put(key, value);  // AP 模式
        } else {
            persistentConsistencyService.put(key, value); // CP 模式
        }
    }
}

---

三、Eureka 源码与自我保护机制

3.1 Eureka 架构

核心组件：

• Eureka Server：注册中心服务端
• Eureka Client：服务提供者/消费者
• Region/Zone：多区域容灾

3.2 服务注册流程

客户端 ：DiscoveryClient

@Singleton
public class DiscoveryClient implements EurekaClient {
    
    private final ScheduledExecutorService scheduler;
    
    @Inject
    DiscoveryClient(ApplicationInfoManager applicationInfoManager, 
                    EurekaClientConfig config,
                    AbstractDiscoveryClientOptionalArgs args) {
        // 1. 初始化任务调度器
        scheduler = Executors.newScheduledThreadPool(3);
        
        // 2. 注册服务
        if (clientConfig.shouldRegisterWithEureka()) {
            register();
        }
        
        // 3. 启动心跳定时器（默认 30 秒）
        initScheduledTasks();
    }
    
    boolean register() throws Throwable {
        EurekaHttpResponse<Void> httpResponse = eurekaTransport.registrationClient.register(instanceInfo);
        return httpResponse.getStatusCode() == 204;
    }
    
    private void initScheduledTasks() {
        // 心跳任务
        scheduler.schedule(
            new HeartbeatThread(),
            clientConfig.getInstanceInfoReplicationIntervalSeconds(), 
            TimeUnit.SECONDS
        );
        
        // 缓存刷新任务（拉取注册表）
        scheduler.schedule(
            new CacheRefreshThread(),
            clientConfig.getRegistryFetchIntervalSeconds(),
            TimeUnit.SECONDS
        );
    }
}

服务端 ：InstanceResource

@Produces({"application/xml", "application/json"})
public class InstanceResource {
    
    @POST
    public Response addInstance(InstanceInfo info) {
        registry.register(info, "true".equals(isReplication));
        return Response.status(204).build();
    }
}

3.3 自我保护机制（AP 核心）

触发条件：当心跳失败比例超过阈值（默认 85%），进入自我保护模式。

public abstract class AbstractInstanceRegistry implements InstanceRegistry {
    
    private volatile long expectedNumberOfClientsSendingHeartbeats = 0;
    
    protected volatile int numberOfRenewsPerMinThreshold;
    
    public void evict(long additionalLeaseMs) {
        // 检查是否启用自我保护
        if (!isLeaseExpirationEnabled()) {
            return;  // 直接返回，不剔除失效实例
        }
        
        // 正常剔除逻辑...
    }
    
    public boolean isLeaseExpirationEnabled() {
        // 计算续约阈值
        int registrySize = (int) getLocalRegistrySize();
        int numOfRenewsInLastMin = getNumOfRenewsInLastMin();
        
        return numOfRenewsInLastMin > numberOfRenewsPerMinThreshold * 0.85;
    }
}

源码逻辑：

// PeerAwareInstanceRegistryImpl
public void openForTraffic(ApplicationInfoManager applicationInfoManager, int count) {
    // 计算预期每分钟心跳数
    this.expectedNumberOfClientsSendingHeartbeats = count;
    updateRenewsPerMinThreshold();  // 更新阈值
}

public void updateRenewsPerMinThreshold() {
    // 预期心跳数 = 实例数 * 2（默认 30 秒一次）
    this.numberOfRenewsPerMinThreshold = 
        (int) (this.expectedNumberOfClients SendingHeartbeats * 2 * 0.85);
}

自我保护优势：

• 网络分区容错 ：当网络抖动导致大面积心跳失败，不剔除实例，避免雪崩
• CAP 权衡：牺牲一致性（可能包含已下线的实例），保证可用性（服务仍能发现）

劣势：

• 脏数据 ：已下线实例可能被调用，需客户端 Ribbon 重试 兜底
• 恢复延迟：网络恢复后，需等待 15 分钟才退出保护模式

---

四、Consul 源码与 CP 实现

4.1 Consul 架构

核心组件：

• Consul Agent：每个节点运行，负责健康检查、注册
• Consul Server：3-5 个节点组成 Raft 集群
• Raft 协议：强一致性，Leader 处理写请求

4.2 注册流程

客户端 ：ConsulServiceRegistry

public class ConsulServiceRegistry implements ServiceRegistry<ConsulRegistration> {
    
    private final ConsulClient client;
    
    @Override
    public void register(ConsulRegistration registration) {
        // 1. 创建服务实例
        NewService service = new NewService();
        service.setId(registration.getInstanceId());
        service.setName(registration.getServiceId());
        service.setAddress(registration.getHost());
        service.setPort(registration.getPort());
        service.setCheck(createCheck(registration));  // 健康检查
        
        // 2. HTTP 注册到 Consul Agent
        client.agentServiceRegister(service);
        
        // 3. Agent 转发到 Server（Raft 写入）
    }
}

// 健康检查配置
private NewService.Check createCheck(ConsulRegistration registration) {
    NewService.Check check = new NewService.Check();
    check.setHttp("http://" + registration.getHost() + ":" + registration.getPort() + "/health");
    check.setInterval("10s");  // 每 10 秒检查
    check.setDeregisterCriticalServiceAfter("30s");  // 30 秒后剔除
    return check;
}

服务端：Raft 写入流程

// Consul Server 处理
public class RPCService {
    
    public Response<Void> registerService(NewService service) {
        // 1. 构造 Raft 日志
        Command cmd = new RegisterCommand(service);
        
        // 2. 提交到 Raft Leader
        raftServer.apply(cmd);
        
        // 3. 等待多数节点确认（约 10-50ms）
        return Response.success();
    }
}

// Raft 核心：apply 日志
public class RaftServer {
    
    public void apply(Command cmd) {
        // Leader：写入本地日志
        log.append(cmd);
        
        // 广播到 Follower
        for (Follower follower : followers) {
            sendAppendEntries(follower, cmd);
        }
        
        // 等待多数派响应
        waitForMajority();
        
        // 提交日志（状态机应用）
        stateMachine.apply(cmd);
    }
}

4.3 CP 特性与劣势

强一致性优势：

• 无脏数据：服务下线立即剔除，调用方不会路由到失效节点
• Leader 选举：故障自动切换，RTO < 5 秒

劣势（CP 的代价）：

• 写延迟高 ：需等待多数节点确认，约 10-50ms
• 网络分区不可用 ：当 Leader 所在分区失联，整个集群拒绝写请求，新服务无法注册
• 脑裂风险：分区恢复后需日志回放，可能丢失未提交数据

---

五、AP vs CP 全面对比与选型

5.1 理论对比

维度	AP（Eureka/Nacos-AP）	CP（Consul/Nacos-CP）
一致性	最终一致（短暂不一致可容忍）	强一致（所有节点实时同步）
可用性	高（无单点，快速响应）	可能牺牲（分区时拒绝写）
分区容错	✅ 优先保证	✅ 优先保证
写延迟	< 1ms（本地更新）	10-50ms（Raft 多数派）
脏数据风险	有（可能读到已下线实例）	无（实时剔除）
客户端容错	需重试、熔断	无需额外容错
适用场景	非关键服务（推荐、头像）	关键服务（库存、支付）

CAP 不可兼得：分布式系统必须在 C 和 A 之间选择，P 是必选项。

5.2 自我保护 vs 强一致

Eureka 自我保护：

// 网络分区场景
Partition 1: 15 个实例（与 Partition 2 失联）
Partition 2: 5 个实例

// Partition 1 的 Eureka Server 发现 5 个实例心跳失败
// 失败比例 = 5/20 = 25% < 85%，正常剔除
// Partition 2 的 Eureka Server 发现 15 个实例心跳失败
// 失败比例 = 15/20 = 75% > 85%，**触发自我保护，不剔除**

Consul Raft：

// 网络分区场景
Partition 1: 3 个 Server（Leader + 2 Follower）
Partition 2: 2 个 Server（Follower）

// Partition 2 的写请求因无法达到多数派（3/5）而被 **拒绝**
// 新的服务实例无法在 Partition 2 注册
// 业务影响：分区期间，Partition 2 的服务扩容失败

5.3 选型决策树

服务关键性？
├─ 关键（库存、支付）→ CP（Consul/Nacos-CP）
│                     └─ 容忍短暂不可用
│               
├─ 非关键（推荐、日志）→ AP（Eureka/Nacos-AP）
│                     └─ 优先保证可用性
│               
└─ 混合场景 → Nacos（动态切换）⭐
              ├─ 默认 AP（高可用）
              └─ 关键服务用 CP（强一致）

---

六、生产实践建议

6.1 Eureka 优化

关闭自我保护（生产谨慎）：

eureka:
  server:
    enable-self-preservation: false  # 关闭后，网络分区时严格剔除
    renewal-percent-threshold: 0.49   # 降低阈值，更敏感

客户端重试：

@Bean
public Retryer retryer() {
    return new Retryer.Default(100, 1000, 3);  // 最多重试 3 次
}

6.2 Nacos 最佳实践

动态切换模式：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: true  # true = AP 模式，false = CP 模式
        # 关键服务设为 false（CP）

集群部署：

# 3 节点混合部署（2 个 AP + 1 个 CP）
nacos:
  mode: mixed  # 混合模式

6.3 Consul 高可用

Raft 集群配置：

# 5 节点部署（容忍 2 节点故障）
consul:
  server: true
  bootstrap_expect: 5  # 期望节点数

健康检查优化：

// 避免频繁检查导致 CPU 飙升
@Bean
public TTLConsulHeartbeatProperties heartbeatProperties() {
    TTLConsulHeartbeatProperties props = new TTLConsulHeartbeatProperties();
    props.setTtl(30);  // TTL 30 秒
    props.setHeartbeatIntervalRatio(2.0 / 3.0);  // 20 秒检查一次
    return props;
}

---

七、总结

注册中心	AP/CP	自我保护	协议	适用规模	维护成本
Eureka	AP	✅ 内置	HTTP	< 5000 实例	低（已停止更新）
Nacos	AP/CP 切换	✅ AP 模式有	Distro/Raft	< 100000 实例	中
Consul	CP	❌	Raft	< 50000 实例	高（需运维 Raft）

一句话总结 ：云原生时代，Nacos 凭借 AP/CP 灵活切换成为首选；Eureka 适合存量系统；Consul 适合对一致性有极致要求的金融场景。选型核心是理解业务对可用性 和一致性的真实需求。