Schema-Registrys für Event-Streams: Subjects, Schema-IDs im Payload und Prüfungen bei der Registrierung

Worum es geht

Serialisierte Events brauchen zum Lesen ein Schema. Das Schema mit jeder Nachricht mitzuschicken ist verschwenderisch, und sich auf eine gemeinsam genutzte Bibliotheksversion zu verlassen ist fragil, weshalb eine Registry die Schemas hält und Kennungen ausgibt. Die Confluent-Dokumentation (zitiert) beschreibt das von ihren Serializern verwendete Wire-Layout: ein Versions-Byte (0), eine von der Registry zurückgegebene 4-Byte-Schema-ID, bei Protobuf ein Nachrichtenindex, dann die serialisierten Daten. Ein Konsument liest die ID, ruft das Schema ab, cacht es und dekodiert. Schemas werden unter Subjects registriert, und die Subject-Namensstrategie legt fest, wie Subjects mit Topics zusammenhängen: TopicNameStrategy (die Standardeinstellung) leitet das Subject vom Topic-Namen ab und verlangt deshalb, dass alle Nachrichten eines Topics einem einzigen Schema entsprechen; RecordNameStrategy gruppiert nach Record-Namen, sodass sich verschiedene Ereignistypen ein Topic teilen können; TopicRecordNameStrategy kombiniert beides.

Warum es wichtig ist

Kompatibilität wird bei der Registrierung einer Schemaversion durchgesetzt, bevor irgendein Produzent sie verwenden kann. Die Dokumentation besagt, dass der Standardmodus BACKWARD ist (Konsumenten mit dem neuen Schema können mit dem vorherigen geschriebene Daten lesen), was für Kafka bevorzugt wird, damit sich Konsumenten an den Anfang eines Topics zurücksetzen lassen; BACKWARD vergleicht nur mit der letzten Version, während BACKWARD_TRANSITIVE mit allen früheren vergleicht. Der verwandte Artikel zu Avro und Parquet erklärt, was jeder Modus erlaubt.

So wird es angewendet

• Den Modus nach der Deployment-Reihenfolge wählen (zuerst Konsumenten: backward; zuerst Produzenten: forward; unbekannt: full) und eine transitive Variante verwenden, wenn Konsumenten Historie erneut abspielen.
• Die Subject-Strategie vor der ersten Nachricht festlegen: eine spätere Änderung benennt Subjects um und ändert, was mit was verglichen wird.
• Schemas aus der CI mit einer Kompatibilitätsprüfung gegen die Registry registrieren, statt Produktions-Produzenten automatisch registrieren zu lassen, womit auch immer sie gebaut wurden.
• Die Registry als Teil des Datenpfads behandeln: Sie braucht Backups, Zugriffskontrolle und Monitoring, denn ein Konsument, der kein Schema abrufen kann, kann nichts lesen.
• Die Schema-ID zusammen mit archivierten Nachrichten aufbewahren; ohne die Registry-Version, auf die diese ID zeigt, sind alte Daten nur Bytes.

Stolpersteine

Eine Registry macht eine inkompatible Änderung nicht sicher; sie weigert sich nur, sie zu registrieren, und die Arbeit landet dann bei der Person, die die Änderung braucht. Das Löschen einer Schemaversion, auf die innerhalb der Aufbewahrungsfrist noch Nachrichten verweisen, macht diese unlesbar. Registrys verschiedener Anbieter verwenden unterschiedliche Wire-Layouts und Kennungssemantiken, weshalb sich Produzenten und Konsumenten auf eine einigen müssen. Eine Registry-Prüfung deckt das Serialisierungsschema ab, nicht die Bedeutung eines Felds; amount von Cent auf Franken umzubenennen besteht jede Prüfung.