1. 关系概述

Dubbo 是一个高性能 RPC 框架，而 ZooKeeper 是 Dubbo 推荐的默认注册中心。

  • Dubbo 负责微服务的远程调用和治理。
  • ZooKeeper 负责服务的注册、发现和配置管理。

两者结合构成了经典的分布式服务架构。

2. 为什么选择 ZooKeeper？（优点）

  1. 成熟稳定：在 Dubbo 早期，ZK 是当时最成熟的开源分布式协调方案。
  2. 树形结构契合：ZK 的树形节点结构（/dubbo/service/providers）非常适合存储服务的层级元数据。
  3. Watch 机制：Dubbo 利用 ZK 的 Watch 机制实现了服务动态发现。当服务提供者宕机（临时节点消失），消费者能立刻收到通知并更新本地缓存，无需轮询。
  4. 自动容错：临时节点的特性使得服务节点下线后能自动摘除，无需人工干预。

3. 潜在问题（缺点/争议）

随着微服务规模的扩大，ZooKeeper 作为注册中心也暴露了一些问题（这也是 Eureka/Nacos 崛起的原因）：

  1. CP 设计牺牲可用性：
    • ZK 保证 CP（一致性+分区容错）。当 Leader 选举时，集群会短暂不可用（无法注册新服务）。
    • 对于服务发现场景，AP（高可用） 往往比 CP 更重要。我们宁愿读到旧的服务列表，也不愿服务发现完全瘫痪。
  2. 写性能瓶颈：
    • ZK 的所有写请求都由 Leader 处理，无法水平扩展写性能。当服务实例达到万级规模，频繁的上下线（写操作）会压垮 ZK。
  3. 网络风暴：
    • 当大量服务同时上下线，会触发海量的 Watch 通知，瞬间打满网卡带宽。

4. 总结

面试官：Dubbo 与 ZooKeeper 有什么关系？为什么选择 ZooKeeper 作为注册中心？

候选人： ZooKeeper 是 Dubbo 最经典的注册中心实现。

选择它的原因主要有三点：

  1. 数据模型契合：树形结构很适合组织服务-提供者列表。
  2. 动态感知：利用 Watch 机制，消费者能实时感知服务提供者的上下线。
  3. 自动容错：利用临时节点特性，服务宕机自动剔除。

但在超大规模微服务场景下，ZK 也有局限性。因为它遵循 CP 原则，在选举期间服务注册不可用；且写性能无法扩展，容易成为瓶颈。所以现在很多新项目也会选择 Nacos（支持 AP 模式）作为替代。