注册中心选型：ZooKeeper vs Nacos vs Eureka#

面试官问候选人小李："你们团队在做技术选型时，为什么选了 Nacos 而不是 ZooKeeper？"

小李说："因为 Nacos 是阿里开源的，文档多..."面试官追问："那 ZooKeeper 的问题是什么？Nacos 比 ZooKeeper 好在哪？"

小李答不上来。

【面试官心理】 这道题我用来考察候选人的技术选型能力。能从 CAP 理论、一致性模型、运维复杂度、生态集成等多个维度分析选型的候选人，说明他有架构视野。这种候选人在我这里是 P7 的潜力股。

#一、三种注册中心定位 🔴

#1.1 概览对比

#1.2 一致性光谱

graph LR
    A[强一致] --> B[ZooKeeper<br/>ZAB 协议]
    B --> C[Nacos CP<br/>Raft 协议]
    C --> D[Nacos AP<br/>Distro 协议]
    D --> E[Eureka<br/>最终一致]
    E --> F[可用性]

    style A fill:#ffcccc
    style B fill:#ffcccc
    style F fill:#ccffcc
    style E fill:#ccffcc

#二、ZooKeeper：CP 的分布式协调器 🟡

#2.1 核心优势

#2.2 核心劣势

#2.3 适用场景

• 分布式锁：需要强一致锁的场景
• 配置管理：需要配合 Apollo 等配置中心
• Master 选举：需要强一致选主的场景
• Hadoop 生态：Hadoop、Kafka、Storm 等组件原生支持

#三、Nacos：AP + CP 双模式的注册中心 🟡

#3.1 核心优势

#3.2 核心劣势

#3.3 Nacos vs ZooKeeper

#3.4 Nacos 2.0 的性能优势

graph TD
    subgraph Nacos 1.0["Nacos 1.0 HTTP 长轮询"]
        A[Consumer] --> B[HTTP 请求]
        B --> C[Nacos Server<br/>等待 30 秒]
        C --> D[返回响应]
    end

    subgraph Nacos 2.0["Nacos 2.0 gRPC 长连接"]
        E[Consumer] --> F[gRPC 连接]
        F --> G[Nacos Server<br/>变更时立即推送]
        G --> H[响应延迟 < 1s]
    end

    style A fill:#ffcccc
    style E fill:#ccffcc

#四、Eureka：AP 的自我保护注册中心 🟡

#4.1 核心优势

#4.2 核心劣势

#4.3 自我保护机制

Eureka 的自我保护机制防止网络分区时误删健康实例：

// Eureka Server 每 15 分钟统计
// 如果健康实例占比 < 85%，进入自我保护
// 自我保护期间，不删除任何实例

// 自我保护触发条件
// expectedRenewsPerMin > 0.85 * renenwsPerMinThreshold
// expectedRenewsPerMin: 期望的心跳数
// renenwsPerMinThreshold: 实际收到的心跳数

自我保护的问题：

graph TD
    A[网络分区] --> B[部分 Eureka<br/>节点不可达]
    B --> C[进入自我保护<br/>不删除实例]
    C --> D[Consumer 调用<br/>已下线实例]
    D --> E[调用失败<br/>重试其他节点]
    E --> F[延迟增加]

#五、综合对比表 🔴

#5.1 核心维度对比

#5.2 生产环境对比

#六、选型决策树 🟡

#6.1 决策流程

graph TD
    A[注册中心选型] --> B{需要配置中心？}
    B -->|是| C[Nacos ✅]
    B -->|否| D{Nacos 生态？}
    D -->|是| C
    D -->|否| E{需要强一致？}
    E -->|是| F{ZooKeeper<br/>运维能力足够？}
    F -->|是| G[ZooKeeper ✅]
    F -->|否| H[Nacos CP ✅]
    E -->|否| I{Eureka 维护状态？}
    I -->|已停止维护| C
    I -->|维护中| J[Eureka ✅]

#6.2 按场景选型

#6.3 按团队能力选型

#七、生产避坑 🟡

#7.1 ZooKeeper 的坑

1. 单机部署的隐患：单机 ZooKeeper 无法容忍任何故障
2. 写入压力过大：高并发写入场景下 Leader 成为瓶颈
3. Session 超时配置：心跳间隔和超时时间要配合好
4. 数据量限制：不适合存储大量数据（最大 1MB/节点）

#7.2 Nacos 的坑

1. gRPC 端口未开放：Nacos 2.0 需要开放 9848 端口
2. Distro 数据不一致：AP 模式下可能读到过期数据
3. 命名空间隔离：不同环境要用不同命名空间
4. 数据量过大：单节点超过 100 万实例后性能下降

#7.3 Eureka 的坑

1. 已停止维护：继续使用有安全风险
2. 自我保护误判：网络抖动时可能保护已下线实例
3. 无配置中心：需要配合 Spring Cloud Config
4. 客户端缓存：可能读到 30 秒前的数据

#八、迁移方案 🟢

#8.1 ZooKeeper 到 Nacos

# 之前：ZooKeeper
dubbo:
  registry:
    address: zookeeper://127.0.0.1:2181

# 之后：Nacos
dubbo:
  registry:
    address: nacos://127.0.0.1:8848
    group: DEFAULT_GROUP
    namespace: dev

#8.2 Eureka 到 Nacos

# 之前：Eureka
spring:
  application:
    name: order-service
  eureka:
    client:
      service-url:
        defaultZone: http://127.0.0.1:8761/eureka/

# 之后：Nacos
spring:
  application:
    name: order-service
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
        namespace: dev

【面试官心理】 注册中心选型是考察架构能力的关键问题。能从 CAP 理论、一致性模型、运维复杂度、生态集成等多个维度分析选型的候选人，说明他有架构视野。这种候选人在我这里是 P7 的潜力股。