融合模式如何帮助确保读取(投影)Avro模式进化？

Question

SchemaRegistry 有助于与需要写入架构来解码接收到的消息的使用者共享用于对消息进行编码的写入 Avro 架构。另一个重要功能是协助架构演变。

假设生产者P定义了存储在逻辑模式S下的写Avro模式v1，消费者C1定义了读(投影)模式v1，另一个消费者C2定义了它自己的读(投影)模式。读取模式不共享，因为Avro在本地使用它们将消息从编写器模式转换到读取器模式。

想象一下没有任何突破性变化的模式演变:

• 使用者 C1 通过添加到其架构中的新可选字段来请求新属性。这是向后兼容的更改。没有此字段编码的消息仍将转换为读取架构。现在，我们已获得 C1 的读取架构的 v2。
• 生产者 P 通过添加到其架构中的新字段来满足使用者 C1 的需求。该字段不必是必需的，因为这是向前兼容的更改。使用者 C1 将访问在新添加的字段中编码的数据。消费者C2将简单地忽略它，因为它是一个宽容的阅读器。现在我们有了 P 的写入架构的 v2。使用者需要知道写入消息的确切架构，因此新版本存储在逻辑架构 S 下。

现在想象一些模式突破性的变化:

< li >生产者P决定删除一个非可选字段。其中一个消费者可能会使用这个字段。这不是向前兼容的更改。假设主题S配置了FORWARD_TRANSITIVE兼容类型，存储新写模式的尝试将失败。我们安全了。 < li >使用者C2通过添加到其架构中的新字段请求新属性。因为它不是由生产者编写的，所以这不是向后兼容的改变。

问题是，SchemaRegistry如何才能派上用场，防止消费者方面的任何破坏性更改？请注意，必须对所有版本的写模式进行读模式的兼容性检查。

有一个endpoint允许检查主题中版本的兼容性。问题是它使用在主题上设置的兼容性类型。不能使用包含写入模式版本的主题，因为它配置了FORWARD_TRANSITIVE兼容性类型，但读取模式必须向下兼容。

创建另一个具有兼容性类型BACKWARD_TRANSITIVE主题将不起作用，因为具有向前兼容更改（例如，添加非可选字段）的写入架构的新版本将无法存储在此主题中。

想到的一个选项是使用CompatibilityChecker编写一些单元测试。这是一个丑陋的解决方案，因为每个消费者必须在本地持有所有版本的写模式。当生产者的模式发生变化时，同步所有消费者将是一件痛苦的事情。

Answer 1

Schema Registry允许我们跟踪生产者和消费者当前使用的模式。

创建另一个具有兼容性类型BACKWARD_TRANSITIVE主题将不起作用，因为具有向前兼容更改（例如，添加非可选字段）的写入架构的新版本将无法存储在此主题中。

你非常接近。实际上，向写模式添加非可选字段是向前兼容的，但不是向后兼容的，因为您可能已经生成了没有该字段值的数据。但我们并没有对写模式和读模式应用相同的更改。这仅在更改同时向前和向后兼容（也称为完全兼容）时有效，例如添加/删除可选字段。在本例中，我们必须将新字段作为可选字段添加到读取模式。

最初可以将写模式推送到这个新主题，但从那时起，它是一个独立的读模式，必须与写模式分开发展。

您可以应用当前用于检查写入模式更改的任何方法。例如，在允许使用之前，让每个使用者将它将要使用的模式推送到具有BACKWARD_TRANSITIVE兼容性类型的主题。

还有一个用于CI/CD环境的Schema Registry Maven插件。

另一种选择是使用具有完全传递兼容性的单个主语。