Zookeeper服务发现方案：微服务架构中的可靠选择

ref="/tag/414/" style="color:#EB6E00;font-weight:bold;">服务发现为什么需要Zookeeper？

在微服务架构越来越普及的今天，服务之间的调用变得频繁而复杂。想象一下，你公司有几十个服务分布在不同的服务器上，订单服务要找库存服务，用户服务又要调用优惠券服务——如果靠手动配置IP和端口，一旦某个服务重启或迁移，整个链条就可能断裂。

这时候就需要一个“通讯录”，让每个服务启动后自动登记，其他服务需要时能快速查到。Zookeeper正是这样一个可靠的分布式协调工具，被广泛用于服务注册与发现场景。

Zookeeper如何实现服务发现

Zookeeper本质上是一个分布式的、层次化的文件系统，数据存储在类似目录树的znode中。服务启动时，在指定路径下创建一个临时节点（Ephemeral Node），比如 /services/order-service/192.168.1.10:8080。只要服务在线，这个节点就存在；一旦宕机或断开连接，Zookeeper会自动删除该节点。

其他服务通过监听（Watch）机制，可以实时感知节点的变化。例如，订单服务列表一旦有增减，购物车服务马上就能收到通知，更新本地缓存，避免调用失效地址。

一个简单的代码示例

使用Curator（Zookeeper的Java客户端封装）注册服务：

CuratorFramework client = CuratorFrameworkFactory.newClient("192.168.1.100:2181", new ExponentialBackoffRetry(1000, 3));
client.start();

ServiceInstance<String> instance = ServiceInstance.builder()
    .name("user-service")
    .address("192.168.1.20")
    .port(8080)
    .build();

ServiceDiscovery<String> discovery = ServiceDiscoveryBuilder.builder(String.class)
    .client(client)
    .basePath("/services")
    .build();
discovery.registerService(instance);

消费方可以通过discovery.queryForInstances("user-service")获取当前所有可用实例。

实际应用中的注意事项

虽然Zookeeper稳定可靠，但也不是万能钥匙。它依赖强一致性，写操作性能受限于集群多数派确认，适合读多写少的场景。如果你的服务频繁上下线，可能要考虑连接风暴和Watcher过多带来的压力。

另外，Zookeeper本身也需要高可用部署，通常以三或五节点集群运行。别忘了设置合理的Session超时时间，太短会导致误删，太长又无法及时感知故障。

不少互联网公司早期都采用Zookeeper做服务发现，比如当当网的Dubbo框架默认集成的就是Zookeeper。虽然后来也有Consul、Nacos等新选择，但在稳定性要求高的场景，Zookeeper仍是许多团队的首选。