Ereignisbasierte Architekturen entwickeln sich von einem begrenzten Modell zwischen wenigen Diensten zu einem weitläufigen Netzwerk aus Produzenten, Konsumenten und Nachrichtenkanälen. An diesem Punkt besteht das grundlegende Problem nicht mehr darin, die Nachricht zu senden, sondern darin zu wissen, was gesendet wird, wem es gehört, wer davon abhängig ist und wie sich sein Schema ändern oder seine Infrastruktur neu erstellen lässt, ohne Produktionsausfälle zu verursachen. Darum geht es in der Sitzung von Ian Cooper über die Verwaltung asynchroner Programmierschnittstellen im großen Maßstab, die auf realen Engineering-Praktiken bei Just Eat Takeaway basiert.
Warum wird es mit zunehmender Größe komplizierter?
In kleinen Organisationen kennen die Teammitglieder möglicherweise die Dienste, die Ereignisse veröffentlichen und konsumieren. Themen oder Kanäle können außerdem über das Messaging-Framework oder durch eine direkte Anfrage an das Plattformteam erstellt werden. Mit zunehmender Zahl von Teams und Diensten verliert dieser Ansatz jedoch seine Wirksamkeit. Es ist möglicherweise unklar, wem ein bestimmter Endpunkt gehört, welcher Vertrag die Nachricht beschreibt oder ob unbekannte Konsumenten in Daten- und Analyseteams existieren.
Das Risiko zeigt sich, wenn ein Team das Schema einer Nachricht nach der Abstimmung nur mit bekannten Konsumenten ändert, während andere Teams von der Nachricht abhängen, ohne in den Kommunikationskreis einbezogen zu sein. Das Löschen eines Themas, von dem man annimmt, dass es nicht verwendet wird, kann zum Verlust eines kritischen Pfads führen, insbesondere wenn es keine verlässliche Möglichkeit gibt, seinen Besitzer zu ermitteln oder die erforderliche Infrastruktur erneut bereitzustellen, außer indem große Teile des Systems erneut ausgerollt werden.
Drei Bereiche der Verwaltung von Ereignisschnittstellen
Cooper unterteilt das Problem in Erkennung, Governance und Bereitstellung. Dies beginnt mit dem Verständnis dessen, was an einem Endpunkt beschrieben werden muss, anhand dessen, was er die „ABCs“ nennt: Adresse, Bindung und Vertrag. Die Adresse legt fest, wohin der Nachrichtenstrom fließt, die Bindung beschreibt Protokoll, Transport und Kodierung, während der Vertrag die Header und Daten festlegt, die die Nachricht enthält.
In diesem Zusammenhang bietet AsyncAPI ein Gegenstück zu Mechanismen für die Dokumentation von HTTP-Schnittstellen wie OpenAPI, einschließlich der Modellierung von Servern, Kanälen, Nachrichten, Operationen und protokollspezifischen Bindungen. Die Beschreibung von Nachrichten mit JSON Schema, Avro und Protobuf wird unterstützt; außerdem können Definitionen wiederverwendet werden, anstatt sie in mehreren Dateien zu wiederholen. Cooper betont jedoch, dass die Ablage Hunderter AsyncAPI-Dateien in einem einzigen Repository die Erkennung allein nicht löst; die Textsuche bleibt begrenzt, wenn das Ereignisinventar wächst.
Organisationen benötigen daher möglicherweise Katalogwerkzeuge wie EventCatalog oder Marmot oder ein offenes Register wie xRegistry, um Nachrichtenströme und ihre Beziehungen darzustellen und Schemata mit Produzenten und Konsumenten zu verknüpfen. Diese Werkzeuge unterscheiden sich hinsichtlich des Visualisierungsgrads und der verfügbaren Benutzeroberflächen, doch ihre gemeinsame Funktion besteht darin, die Erkennung von einer Frage in Slack oder einer Suche in verstreuten Repositories zu einem abfragbaren Dienst zu machen.
Die Rolle von CloudEvents bei der Vereinheitlichung von Metadaten
CloudEvents übernimmt einen anderen Teil des Problems, indem es einen einheitlichen Satz von Metadaten wie ID, Quelle, Version und Typ bereitstellt, ergänzt um optionale Felder für den Datentyp des Inhalts, das Thema, die Zeit und einen Schema-Link. Der Ereignistyp kann verwendet werden, um die Nachricht weiterzuleiten oder eine Deserialisierungsmethode auszuwählen, wenn sich mehrere Typen einen Kanal teilen.
In der Sitzung wird erklärt, dass die Modi „binary“ und „structured“ in CloudEvents mit der Fähigkeit des Transportprotokolls zusammenhängen, Header zu übertragen, und nicht damit, ob die Nachricht im gewöhnlichen Sinn „binär“ oder „strukturiert“ ist. Die Bedeutung dieses Details zeigt sich in Systemen wie SNS, bei denen eine begrenzte Anzahl von Nachrichtenattributen schnell konsumiert werden kann, wenn alle CloudEvents-Daten in den Headern platziert werden. Dadurch wird das Verpacken dieser Daten im Body in bestimmten Szenarien zu einer praktischen Option.
Governance beschränkt sich nicht auf Dokumentation
Die Dokumentation des Vertrags informiert Konsumenten darüber, wie die Nachricht aussieht, verhindert jedoch nicht, dass der Produzent eine Änderung veröffentlicht, die ihre Abhängigkeiten beeinträchtigt. Der vorgestellte Ansatz empfiehlt daher die Verwendung eines Schema-Registers, das bei der Aktualisierung von Verträgen Kompatibilitätsregeln anwendet und Nachrichten oder Änderungen ablehnt, die den genehmigten Regeln nicht entsprechen.
Zu den sicheren Praktiken gehören in der Regel das Hinzufügen von Feldern als optionale Felder, das Verschieben der Löschung von Feldern, bis alle Konsumenten ihre Verwendung eingestellt haben, sowie die Behandlung einer Umbenennung als Änderung, die aus einer Löschung und einer Hinzufügung besteht. Die Änderung des Feldtyps gilt meist als nicht abwärtskompatible Änderung und kann durch das Hinzufügen eines neuen Feldes mit dem gewünschten Typ umgesetzt werden. Anschließend werden die Konsumenten auf dieses Feld umgestellt, bevor das alte Feld entfernt wird.
Was ändert sich in der Praxis?
Die zentrale Botschaft für technische Leser lautet, dass die Verwaltung von Ereignissen im großen Maßstab eine zusammenhängende Kette und kein einzelnes Werkzeug erfordert: AsyncAPI zur Beschreibung der Schnittstellen, CloudEvents zur Vereinheitlichung der Metadaten, einen Katalog oder ein Register zur Erleichterung der Erkennung, ein Schema-Register zur Durchsetzung der Kompatibilität sowie Automatisierung zur Bereitstellung der Infrastruktur und zur Überwachung ihrer Abweichungen. Ohne diese Schichten kann sich eine ereignisbasierte Architektur in ein Netzwerk unsichtbarer Abhängigkeiten verwandeln.
Praktische Einschränkungen bleiben bestehen: Standards allein liefern kein vollständiges Wissen über die Konsumenten, und die Werkzeuge unterscheiden sich bei der Unterstützung von Schnittstellen, Visualisierung und Integration mit Brokern. Die Umsetzung dieses Ansatzes erfordert daher eine klare Festlegung der Zuständigkeit für Verträge und Kanäle, die Verknüpfung von Änderungen mit CI/CD-Prozessen sowie die Aufbewahrung eines Wiederherstellungspfads, der Ressourcen neu erstellen kann, anstatt sich auf Einzelwissen oder veraltete Dokumentation zu verlassen.