ZooKeeper + Curator 服务注册与发现实践

项目背景

ZooKeeper 是 Apache 基金会旗下的分布式协调服务，在分布式系统中有广泛的应用场景：服务注册与发现、配置管理、分布式锁、集群选举等。这个项目通过 ZooKeeper 构建了一个完整的服务注册与发现机制，并对比了使用原生 ZooKeeper API 和使用 Curator 框架两种方式的优劣。 在学习 ZooKeeper 之前，需要先理解分布式系统面临的核心挑战：在多个节点组成的集群中，如何统一管理配置？如何让服务发现彼此？如何协调并发操作？ZooKeeper 通过一个类文件系统的树形命名空间和 Watcher 机制解决了这些问题。

ZooKeeper 核心概念

ZooKeeper 的数据模型是一个层次化的命名空间，类似于标准文件系统。根节点是 /，其下可以创建子节点，每个节点称为 ZNode。每个 ZNode 可以存储数据（最大 1MB），并且可以有子节点。操作方式也与文件系统类似——create、delete、exists、getData、setData、getChildren。 ZNode 有三种类型，各自适用于不同的场景。持久节点（Persistent）创建后一直存在，直到显式删除，适合存储配置信息。临时节点（Ephemeral）与创建者的会话绑定，会话断开后自动删除，非常适合做服务注册（服务下线时自动清理注册信息）。顺序节点（Sequential）会在节点名后自动追加递增序号，适合做分布式锁的排队机制。 Watcher 机制是 ZooKeeper 的核心特性。客户端可以在节点上设置 Watcher，当节点数据发生变化或子节点列表变化时，ZooKeeper 会主动通知客户端。这种"推送"机制避免了客户端频繁轮询，是实现服务发现的基础。

服务注册与发现实现

服务注册的实现非常简洁。服务提供者启动时，在 ZooKeeper 的指定路径（如 /services/user-service）下创建一个临时顺序节点，节点的数据内容存储服务的 IP 地址和端口号。临时节点的特性确保了服务异常下线后，ZooKeeper 会自动清理注册信息，不需要额外的健康检查机制。 服务发现的过程同样优雅。服务消费者启动时，通过 getChildren 方法获取 /services 路径下的所有子节点列表，这就是当前可用的服务实例列表。同时，消费者在 /services 路径上设置 Watcher。当有新的服务注册或现有服务下线时，ZooKeeper 主动推送通知，消费者收到通知后更新本地缓存的服务列表。 消费者获取到服务列表后，使用随机选择或轮询策略选择一个服务实例进行调用。这种客户端侧的负载均衡策略不需要引入独立的负载均衡器（如 Nginx），架构更简单。如果需要更复杂的路由策略（如权重、最小连接数），可以在 Curator 框架中配置。

Curator 框架的优势

原生 ZooKeeper API 存在一些明显的不足之处。连接管理需要手动创建和重连，Watcher 注册是一次性的（每次通知后需要重新注册），递归操作需要手动遍历子节点。这些细节在大型项目中会导致大量重复代码和边缘情况 bug。 Curator 框架优雅地解决了这些问题。ConnectionStateListener 自动处理连接的创建和重连，开发者只需要关注业务逻辑。TreeCache 可以自动监听整个子树的变化，不需要为每个子节点单独注册 Watcher。InterProcessMutex 一行代码即可实现分布式锁，避免了手动实现锁的繁琐和易错。

踩坑与解决方案

第一个问题是会话超时配置。ZooKeeper 的默认会话超时时间较短（通常为几秒到十几秒），在网络不稳定的环境中会导致服务频繁上下线。需要根据实际网络情况调整 tickTime 和 sessionTimeout 参数，通常设置在 10-30 秒之间。 第二个问题是临时节点清理延迟。如果客户端进程异常退出（如被 kill -9），会话不会立即结束，而是在 sessionTimeout 之后才会超时。在这段时间内，消费端拿到的服务列表中还包含已经宕机的服务实例，导致调用失败。通过设置合理的 sessionTimeout 和客户端的心跳检测可以缓解。 第三个问题是"羊群效应"。当大量客户端同时监听同一个父节点的子节点变化时，一个节点的变动会导致所有客户端同时收到通知并触发回调，造成瞬间的负载飙升。Curator 的 TreeCache 通过批量通知机制缓解了这个问题。在极端场景下，可以使用 Curator 的 Leader Latch 让其中一个客户端作为代表接收通知。

总结

ZooKeeper 作为分布式协调服务，虽然功能强大，但实际项目中很少直接操作 ZooKeeper API。Curator 封装了大部分复杂逻辑，是生产环境的首选。这个项目让我理解了服务发现的核心本质：服务启动时注册 -> 客户端监听变化 -> 节点变化时通知 -> 客户端更新本地缓存。这个模式不仅适用于 ZooKeeper，也适用于 Nacos、Consul、Eureka 等其他注册中心。