Confluent Schema Registry 的 ZooKeeper 依赖解析

背景介绍

Confluent Schema Registry 是一个流行的模式管理服务，用于在 Kafka 生态系统中集中管理 Avro、JSON Schema 和 Protobuf 等数据格式的模式。许多开发者在部署 Schema Registry 时，对其依赖关系特别是与 ZooKeeper 的关系存在疑问。

ZooKeeper 依赖的演变

早期版本的 Schema Registry 确实依赖 ZooKeeper 进行主节点选举和元数据存储。这种设计源于 Schema Registry 最初与 Kafka 紧密集成的历史背景，而 Kafka 本身在早期版本中也重度依赖 ZooKeeper。

但随着技术演进，Schema Registry 已经逐步减少了对 ZooKeeper 的依赖：

1. 主节点选举机制：从 ZooKeeper 转向了基于 Kafka 的选举机制
2. 元数据存储：不再需要 ZooKeeper 存储这些信息

当前架构说明

在现代部署中，Schema Registry 可以完全独立于 ZooKeeper 运行，特别是在以下场景：

• 使用云托管 Kafka 服务（如 AWS MSK、Confluent Cloud）
• 采用 Kafka 2.8+ 版本（已内置 KRaft 模式，无需 ZooKeeper）
• 独立部署 Schema Registry 集群

Schema Registry 的节点标识现在仅由主机名和端口组成，不再需要 ZooKeeper 存储这些信息。这一变化简化了部署架构，减少了运维复杂度。

部署建议

对于新部署的用户，建议：

1. 优先选择基于 Kafka 的主节点选举机制
2. 在云环境中可以完全省略 ZooKeeper 组件
3. 确保 Schema Registry 配置中正确设置了监听地址

对于从旧版本升级的用户，需要注意配置迁移，确保主节点选举机制已更新为 Kafka 模式。

总结

Confluent Schema Registry 的发展体现了技术栈的持续优化。从最初依赖 ZooKeeper 到现在的轻量化架构，这一演进使得 Schema Registry 更加适合现代云原生环境，降低了部署和运维的复杂度。用户现在可以更加灵活地选择部署方案，无需担心 ZooKeeper 带来的额外负担。