Was ist eine Service-Registry?

Eine Service-Registry ist eine Datenbank für die Speicherung von Datenstrukturen für die Kommunikation auf Anwendungsebene. Sie fungiert als zentraler Ort, bei dem Anwendungsentwickler sich registrieren und die Schemata finden können, die für bestimmte Anwendungen verwendet werden.

Modernes Softwaredesign wird auf verteilten und lose gekoppelten Microservices ausgeführt, die Daten über APIs (Application Programming Interfaces) austauschen.

In einem großen Unternehmen und darüber hinaus ist dieser Datenaustausch zwischen Anwendungen geschäftskritisch. All Ihre Anwendungen senden in jeder Sekunde Daten hin und her, um Ihr Unternehmen am Laufen zu halten. Deshalb ist es unglaublich wichtig, die Integrität dieser Daten sicherzustellen. Und wie können Sie sicherstellen, dass all diese unterschiedlichen Anwendungen darauf ausgelegt sind, diese wichtigen Daten zu nutzen? Eine der wichtigsten Lösungen ist eine Service-Registry.

Ein Messaging-System, das Daten transportiert (z. B. Apache Kafka) kann von sich aus keine Daten verifizieren. Was passiert, wenn ein Daten-Producer Daten sendet, die nicht verarbeitet werden können? Was, wenn der Producer beispielsweise ein Feld hinzufügt oder entfernt oder das Datenformat verändert? Wenn der Consumer der Daten über diese Veränderung nicht benachrichtigt wird, kann er die Daten nicht korrekt verarbeiten. Im schlimmsten Fall bricht das gesamte System zusammen.

Bevor ein Datenaustausch stattfindet, muss der Daten-Consumer die vom Producer verwendete Struktur der Daten, das sogenannte „Schema", kennen. Der Consumer muss außerdem informiert werden, wenn Änderungen an diesem Schema durchgeführt wurden. Die Daten müssen sich entwickeln lassen, ohne dass dadurch eine Unterbrechung des Messaging-Systems verursacht wird.

Ein Producer kann den Consumern das Schema manuell zukommen lassen, indem er es zum Beispiel als E-Mail-Anhang verschickt. Wie bei vielen manuellen Prozessen kann dies jedoch kompliziert, fehleranfällig und schwer zu überprüfen sein. Eine Folge davon ist, dass Services nicht mehr funktionieren und dass es keine einfache Möglichkeit gibt, den Grund für diesen Ausfall festzustellen.

Eine Service-Registry hingegen kann diese Information auf einer problemlos zugänglichen Plattform zur Verfügung stellen. Sie fungiert als zentraler Ort, bei dem die Entwickler von Producer-Anwendungen die Schemata registrieren können, die sie für bestimmte Anwendungen verwenden. Entwickler der Consumer-Anwendungen wiederum verwenden die Service-Registry, um dieses Schema zu finden. Mithilfe des Schemas ermöglichen Sie es der Anwendung, Daten von diesem Producer zu nutzen. Schemata, die in einer Service-Registry gespeichert werden können, sind unter anderem Apache Avro, JSON Schema und Google Protocol Buffer.

Zusätzlich zu den Schemata kann Ihre Service-Registry auch andere Assets speichern, die auch als „Artefakte" bezeichnet werden. API-Spezifikationen für die synchrone Kommunikation auf Anwendungsebene können zum Beispiel ebenfalls in der Service-Registry gespeichert werden. Je zahlreicher und komplexer Ihre Services werden, desto nützlicher wird Ihre Service-Registry.

Das Konzept einer Service-Registry gibt es schon seit vielen Jahren. In letzter Zeit ist es aber wieder in den Fokus gerückt, da es für diesen notwendigen Zweck in der Welt der Microservices bestens geeignet ist. Die Service-Registry fungiert als „Single Source of Truth" für die Datenstrukturen einer bestimmten Anwendung, auf die sich Entwickler der Producer- und Consumer-Anwendungen geeinigt haben. Sie unterstützt einen „Contract-First"-Ansatz. Anstatt zuerst die Anwendung zu programmieren und nachträglich einen Vertrag anzubieten, damit andere Anwendungen oder Organisationen mit Ihrer Anwendung kommunizieren können, spezifiziert die Service-Registry den Vertrag im Vorfeld – einschließlich Eingaben, Ausgaben, Payload-Spezifikationen und möglicherweise sogar Validierungsregeln. Alles ist eindeutig festgehalten, damit keine Missverständnisse darüber entstehen, wie Interaktionen zu funktionieren haben.

Am Beispiel von Apache Kafka schauen wir uns an, wie eine Service-Registry funktioniert. In diesem bestimmten Use Case ist eine Service-Registry ideal, da Kafka Consumern die Datenstruktur nicht automatisch bereitstellt und auch keine Datenverifizierung anbietet. Weil Kafka Ihre Daten weder analysiert noch liest, verwendet es keine wichtigen Ressourcen und ist dadurch in der Lage, Daten sehr schnell direkt an die Consumer zu verteilen. Wenn Kafka die Daten vorher verifizieren würde, wäre die Performance um einiges schlechter. Die fehlende Daten-Governance ist bei Kafka also kein Problem. Sie ermöglicht im Gegenteil sogar einen der größten Vorteile des Programms: hohe Performance.

Allerdings müssen Sie zusätzlich eine Governance mit der Datenstruktur implementieren, um sicherzustellen, dass die Consumer-Anwendungen die Daten korrekt nutzen können. Die Lösung ist eine Service-Registry, die Regeln nicht nur bereitstellt, sondern auch durchsetzt.

Consumer und Producer tauschen Daten über Kafka aus. Durch die Verwendung einer Service-Registry können Producer und Consumer die Metadaten, die den Datenverkehr definieren, von Anfang an dokumentieren, teilen und festlegen. Dadurch werden zukünftige datenbezogene Fehler vermieden. Diese Metadaten werden in Form von Schemata in der Service-Registry gespeichert.

Der Entwickler der Producer-Anwendung registriert das Schema in der Service-Registry, die dann sicherstellt, dass der Producer sich an die Spezifikationen seines eigenen Schemas hält. Die Service-Registry kann sogar ungültige Daten ablehnen, die nicht dem registrierten Schema entsprechen.

Schemata können, wie im obigen Beispiel, vom Entwickler einer bestimmten Producer-Anwendung registriert werden. Sie können aber auch von einer Organisation für die generelle Verwendung innerhalb des Entwicklungsteams registriert werden. In diesem zweiten Fall fungiert die Service-Registry als eine Library für die Entwickler von Producer- und Consumer-Anwendungen.

Zusätzlich nutzen die Entwickler von Consumer-Anwendungen die Service-Registry ebenfalls als Library und greifen auf Schemata zu, mit denen sie Anwendungen entwickeln können, die Daten aus Producer-Anwendungen nutzen können. Wenn Änderungen am Schema vorgenommen werden, stellt die Service-Registry den Consumern die neueste Version des Schemas zur Verfügung.

Eine Service-Registry bietet folgende Vorteile für das Entwicklungsteam und das Unternehmen:

Entkopplung der Datenstruktur von Anwendungen

Sie können eine Service-Registry verwenden, um die Struktur Ihrer Daten von Ihren Anwendungen zu entkoppeln und Ihre Datenstrukturen und API-Beschreibungen zur Laufzeit mithilfe einer REST-Schnittstelle zu teilen und zu managen.

Hervorragende Datenqualität

Eine Service-Registry validiert das Schema und erkennt Fehler in den Daten, um die Datenintegrität sicherzustellen. Die Service-Registry kann Regeln beinhalten, um sicherzustellen, dass hochgeladene Inhalte syntaktisch und semantisch gültig sowie mit anderen Versionen rückwärts- und vorwärtskompatibel sind. Außerdem verhindert die Service-Registry, dass ein Producer ungültige Daten sendet, die nicht dem Schema entsprechen.

Dokumentierte Single Source of Truth

Die Service-Registry bietet eine „Single Source of Truth", auf die sich alle Beteiligten geeinigt haben und die von ihnen validiert wurde.

Gesteigerte Entwicklerproduktivität

Die Service-Registry ermöglicht eine konsistente Wiederverwendung von Schemata und API-Designs. Dadurch sparen Entwickler Zeit bei der Erstellung von Producer- und Consumer-Anwendungen.

Kosteneinsparungen

Datenbezogene Fehler werden bereits früh im Entwicklungs-Lifecycle erkannt und nicht erst zur Laufzeit. Dadurch werden die Kosten für eine längere Entwicklungszeit eingespart, die sonst für die spätere Fehlerbehebung aufgebracht werden müsste.