使用 confluent cp-schema-registry，它是否必须与您用于生产者/消费者的同一个 Kafka 通信？

Question

我们已经在生产环境中运行了 Kafka。不幸的是，它是一个旧版本，0.10.2。我想从 Confluent Platform 的社区版开始使用 cp-schema-registry。这意味着安装旧的 3.2.2 模式注册表映像以与我们的旧 kafka 兼容。

从我在文档中阅读的内容来看，Confluent Schema Registry 似乎使用 Kafka 作为其存储状态的后端。但是，生成/读取 Kafka 主题的客户端独立于 Kafka 与 Schema Registry 进行通信。

所以我想知道在一个容器中运行 Schema Registry/Kafka/Zookeeper 是否更容易在生产中管理，独立于我们的主 Kafka 集群。然后我可以使用最新版本的一切。另一个好处是，让这个新的服务组件站起来不会对现有的 Kafka 集群造成任何意想不到的负面影响。

我发现文档并没有很好地解释每种部署策略的优缺点。有人可以就他们如何在现有 Kafka 的环境中部署模式注册表提供指导吗？将模式注册表连接到主 Kafka 集群的主要优势是什么？

Answer 1

较新的 Kafka 客户端向后兼容 Kafka 0.10，因此您没有理由不能使用比 3.2 更新的 Schema Registry

在文档中

Confluent Platform 3.2 及更高版本中包含的架构注册表与 Confluent Platform 3.0 及更高版本中包含的任何 Kafka 代理兼容

---

---

我当然会避免将所有东西都放在一个容器中......这不是它们的用途，也没有理由需要另一个 Zookeeper 服务器

当您可以在现有集群上存储相同的信息时，似乎没有必要使用仅保存一个主题模式的辅助 Kafka 集群

生成/读取 Kafka 主题的客户端独立于 Kafka 与 Schema Registry 交谈

客户与两者交谈。在您的常规客户端代码到达主题之前，仅通过 HTTP 发送 Avro 模式。不，模式和客户端数据不必属于同一个 Kafka 集群

任何人部署 Schema Registry 时，都会将其添加到“现有的 Kafka”中，不同之处在于您的 Kafka 中可能包含更多数据