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.