添加额外的Schema Registry注册表权重？

Question

在生成/消费者消息时添加Schema Registry的附加层（又称失败点）是否有任何好处？如果服务发生故障，则不会消耗或生成消息。使用卡夫卡的系统不会因为不使用架构注册表而导致错误少一点，从而不易发生错误？

Answer 1

在您的体系结构中拥有模式注册表的一个关键点是确保您的数据管道即使在正常操作期间也是端到端工作的“。也就是说，即使所有系统启动并运行（“全部绿色，100％正常运行！”），由团队A管理的生产者应用程序可能会得到更新，并且现在开始生成不兼容的数据，这些数据导致对下游消费者造成的附带损害，这​​些下游消费者由团队B和C管理，他们并不期待这种变化。

因此，当您决定是否使用模式注册表时，您不仅应该问自己“何时失败”的情况（这很可能会在某个时候发生，这就是为什么例如Confluent模式注册表支持诸如高可用性设置之类的功能），但是关于数据管道所需的一般保证。

如果服务发生故障，则不会消耗或生成消息。

一般来说，是的。实际上，架构注册表服务的高可用性模式，模式的客户端缓存等功能都有助于最大限度地减少任何此类损害。

使用卡夫卡的系统不会因为不使用架构注册表而导致错误少一点，从而不会出现错误？

你是对的，一般来说，你想避免引入一个组件，这将是链中的另一个失败点。也就是说，如果您正在生产中运行数据管道 - 特别是在一个更大的组织中 - 模式注册中心还有助于通过确保写入的数据始终可以读取来消除“故障点”。有人可能会争辩说，由“数据变化”引发的故障至少可以和由于一个或多个系统不可用而引发的故障一样常见。

Answer 2

模式注册表可以配置为highly available，因此它不是单点故障。

也就是说，如果您需要模式注册表附带的便利性和模式兼容性规则，那么您希望使用它。并非所有连接到Kafka集群的客户端都需要使用它，因此您可以尝试它，而不会影响同一集群上的其他客户端。

对于avro消息使用模式注册表的主要替代方法是将模式添加到消息本身。一些用户对于较大的消息大小并没有系统地演进架构是可以的。模式注册表适用于那些关心这些事情的人。