在生成/消费者消息时，添加Schema Registry的附加层（即故障点）是否有任何好处？如果服务不断下降，则消息不会被消费或生成。使用Kafka的系统不会因为不使用Schema Registry而更容易出错，这样可以减少故障点吗？
答案 0 :(得分：5)
在架构中使用架构注册表的一个关键点是确保您的数据管道端到端工作即使在正常运行期间也是如此......
即使所有系统都启动并运行（＆＃34;全绿色，100％正常运行时间！＆＃34;），例如，由团队A管理的生产者应用程序可能会更新现在开始生成不兼容的数据，这些数据会对由{1}}和B团队管理的下游消费者造成附带损害，而这些消费者并不期待这种变化。
因此，当您决定是否使用架构注册表时，您不仅应该问自己关于场景的问题，以及当事情失败时＃34; （这很可能会在某些时候发生，这就是为什么例如Confluent Schema Registry支持高可用性设置等功能），还有关于数据管道所需的保证。
如果服务中断，则不会消费或生成消息。
总的来说，是的。在实践中，诸如模式注册表服务的高可用性模式，模式的客户端缓存等功能都有助于最小化任何此类损坏。
使用Kafka的系统不会因为不使用Schema Registry而更容易出错，这样可以减少故障点吗？
你是对的，一般来说，你想避免引入一个可能是链中另一个失败点的组件。
也就是说，如果您正在生产中运行数据管道 - 特别是在较大的组织中 - 架构注册表也有助于消除＆＃34;故障点＆＃34;通过确保始终可以读取写入的数据。有人可能会争辩说，由数据引起的失败会导致数据发生变化。至少与一个或多个系统不可用触发的故障一样普遍。
答案 1 :(得分：3)
架构注册表可以配置为highly available，因此它不是单点故障。
也就是说，如果您想要架构注册表附带的便利和架构兼容性规则，那么您想要使用它。并非所有连接到Kafka群集的客户端都需要使用它，因此您可以在不影响同一群集上的其他客户端的情况下进行尝试。
使用架构注册表获取avro消息的主要替代方法是将架构添加到消息本身。一些用户可以使用更大的消息大小而不是系统地发展模式。模式注册表适用于那些与此类事情有关的人。