Versionierung von Nachrichten und Events

Vor der Umsetzung ist jede Änderung als kompatibel oder inkompatibel einzustufen. Eine Änderung gilt für bestehende Kanäle (d.h. Queues und Topics) nur dann als kompatibel, wenn sie vollständig kompatibel ist, also Abwärts- und Aufwärtskompatibilität gegeben sind oder die betroffenen Producer und Consumer kontrolliert in einer abgestimmten Reihenfolge migriert werden.

Die folgende Tabelle beschreibt die Muster knapp und verweist auf die entsprechenden Abschnitte, in denen die Muster ausführlich beschrieben werden.

Vollständig kompatible Änderungen können auf demselben Topic, derselben Queue oder demselben Nachrichten- oder Event-Typ umgesetzt werden. Hierfür empfiehlt sich die Verwendung von Schema Evolution. Fehlerhafte Schema Evolution kann zu Fehlern bei der Deserialisierung, blockierten Kanälen, fehlerhaften Replays oder stillen fachlichen Fehlinterpretationen führen. Das relevanteste Risiko ist nicht ein offensichtliches Systemversagen, sondern "stille semantische Fehler". Der Consumer verarbeitet eine formal gültige Nachricht, interpretiert sie aber fachlich falsch. Die fachliche Kompatibilität ist daher zusätzlich zur technischen Schema-Kompatibilität zu prüfen.

Inkompatible Änderungen, also Breaking Changes, dürfen nicht durch eine Änderung des bestehenden Nachrichtenformats auf demselben Kanal eingeführt werden. Die folgenden Änderungen sind typische Breaking Changes:

Standardmäßig ist hierfür ein neuer Event-Typ, ein neuer Routing-Key oder ein neuer Kanal vorzusehen. Es liegt ein Schemabruch vor. Inkompatible Änderungen sollten durch ein Schema Management kontrolliert vorgenommen werden. Im Fall von Events sind deren Besonderheiten zu beachten. Wird ein neuer Kanal eingeführt, so sollte ein Vorgehen für die Migration festgelegt werden.

Schemata ändern sich fortlaufend mit neuen Anforderungen. Um Wildwuchs von Versionen zu vermeiden, müssen sie an einer zentralen Stelle verwaltet werden. Dies kann mithilfe eines Wikis oder Git-Repositories geschehen. In der Praxis hat sich jedoch der Einsatz einer Schema Registry bewährt.

Der große Vorteil einer Schema Registry ist die Erkennung von Schemabrüchen während der Schema-Validierung. Damit sind Breaking Changes durch Anpassungen am Schema praktisch ausgeschlossen, weil nur kompatible Änderungen zugelassen werden. Eine Schema Registry ist vor allem dann sinnvoll, sobald eine verteilte Entwicklung stattfindet oder mehr als ein Consumer an der Kommunikation beteiligt ist.

Die Vorteile von Schema Registries erkauft man sich u.a. durch die gestiegene Komplexität und Aufwände für den Betrieb eines zusätzlichen Systems in der Anwendungslandschaft.

Die Versionierung von Events unterliegt besonderen Anforderungen. Die Grundlagen von Event Streaming sind im entsprechenden Kommunikationsmuster umrissen.

Events werden genutzt, um über geschäftsrelevante Ereignisse innerhalb der Anwendungslandschaft zu informieren. Aus der Sicht der konsumierenden IT-Systeme sind Events wichtige historische Ereignisse (Fakten), die für die Weiterverarbeitung benötigten Daten enthalten.

IT-Systeme tauschen Events in einem wohldefinierten Format untereinander aus. Wie die Struktur einer Nachricht konkret aufgebaut ist (Syntax), wird in einem Schema festgehalten. Das vereinbarte Schema wird von Producern verwendet, um vor dem Versenden die Nachricht zu validieren. Der Consumer verwendet es für die Validierung der empfangenen Nachricht (Design by Contract).

Die Verwendung von Schemata stellt die korrekte Kommunikation zwischen den Teilnehmern und damit die Funktion insbesondere von Consumern sicher.

Bei inkompatiblen Änderungen an der Struktur von Nachrichten können bestehende oder neue Consumer alte Nachrichten nicht mehr korrekt verarbeiten. Um Stabilität und Datenkonsistenz zu gewährleisten, wird ein neues Topic für inkompatible Schemaänderungen erstellt. Im nächsten Schritt können Producer und Consumer auf das neue Topic migriert werden.