在生成/消费者消息时，添加Schema Registry的额外层(也就是故障点)有什么好处吗?如果服务出现故障，则不会使用或生成消息。使用Kafka的系统不会因为不使用模式注册表而减少一个故障点而更容易出错吗?
在您的体系结构中使用模式注册表的一个关键点是确保您的数据管道"即使在正常操作期间"也是端到端的工作。
也就是说，即使所有系统都启动并运行("全部绿色，100%正常运行时间!")，例如，由团队A管理的生产者应用程序可能会被更新，现在开始生成不兼容的数据，从而导致由团队B和C管理的下游消费者没有预料到这种变化的附带损害。
因此，当您决定是否使用模式注册表时，您不仅应该问自己"当事情失败时"的场景(这很可能会在某些时候发生，这就是为什么Confluent模式注册表支持高可用性设置等特性)，还应该问自己需要保证数据管道正常工作。
如果服务发生故障，那么消息将不会被使用或生成。
一般来说，是的。在实践中，模式注册服务的高可用性模式、模式的客户端缓存等特性都有助于将此类损害降至最低。
使用Kafka的系统不会因为不使用Schema Registry而减少一个故障点而更容易出错吗?
您是对的，一般来说，您希望避免引入可能成为链中另一个故障点的组件。
也就是说，如果您在生产环境中运行数据管道——特别是在一个较大的组织中——模式注册表还可以通过确保写入的数据也总是可以读取来帮助消除"故障点"。有人可能会争辩说，由"数据更改"触发的故障至少可以与由一个或多个系统不可用触发的故障一样常见。
模式注册表可以配置为高可用性，因此它不是单点故障。
也就是说，如果您想要模式注册表带来的便利性和模式兼容性规则，那么您希望使用它。并不是所有连接到Kafka集群的客户端都需要使用它，所以你可以在不影响同一集群上的其他客户端的情况下尝试它。
为每个消息使用模式注册表的主要替代方法是将模式添加到消息本身。有些用户可以接受更大的消息大小和不系统地发展模式。模式注册表是为那些关心这些事情的人准备的。