Was ist Microservice-Reporting?

Beim Microservice-Reporting werden Berichte auf der Basis einer Microservices-Architektur erstellt. Die Microservices-Architektur bietet Unternehmen zwar viele Vorteile, stellt aber aufgrund ihres fragmentierten Charakters Herausforderungen für das Reporting dar.

Was ist ein Microservice-Modell?

Um Microservice-Reporting zu verstehen, muss man ein gutes Verständnis der Architektur dahinter haben. Eine Microservice-Architektur ist ein Cloud-basiertes System, bei dem das Software-System eines Unternehmens aus einer Reihe kleinerer Komponenten besteht. Diese Services oder Komponenten sind unabhängig voneinander einsetzbar, aber lose miteinander verknüpft, in der Regel über Schnittstellen zur Anwendungsprogrammierung (APIs). Ähnlich einem Gehirn sind die Services wie Gehirnzellen, die durch Synapsen (APIs) miteinander verbunden sind, die die Übertragung von Informationen von einer Zelle zur anderen ermöglichen. Jeder dieser Microservices übernimmt eine bestimmte Aktion oder Anforderung und wird bei Bedarf automatisch bereitgestellt.

Diese Services haben all ihre eigenen Datenbanken und teilen keine Informationen aus einer zentralen Datenbank, wie es andere Systeme tun. Das wird als „begrenzt“ bezeichnet, da alles, was für den Betrieb dieses Services benötigt wird, in der App gebündelt ist.

Diese Begrenzung ist wichtig, um sicherzustellen, dass es nicht zu einer unbeabsichtigten Kopplung von Services kommt. Wenn Datenschemas von allen Services gemeinsam genutzt werden, muss eine Änderung in einem Schema auf alle zugrundeliegenden Datenschemas repliziert werden. Wenn alles getrennt bleibt, bedeutet das begrenzte Änderungen, die vollständige Autonomie der Services und die Architektur bewahrt ihre volle Agilität.

Unternehmen entscheiden sich aus einer Vielzahl von Gründen für den Einsatz von Microservices. Die unabhängigen Apps können einfach aktualisiert und geändert werden, neue Funktionen können schnell hinzugefügt werden. Verschiedene Teams können verschiedene Stacks von Apps oder Programmen unter einem Dach betreiben, was dem Geschäftsmodell eine enorme Agilität verleiht.

Das kann auch eine sehr kostengünstige Architektur sein. APIs sind kostenlos oder kostengünstig; einzelne Programme können als Software-as-a-Service (SaaS) eingekauft und vom Nutzer bezahlt werden. Das ist vollständig skalierbar und es gibt keine großen Infrastrukturanforderungen.

Zu den Unternehmen, die Microservices-Architektur verwenden, gehören Amazon, Netflix, Uber und SoundCloud. Es ist wirklich eine Softwarestruktur, die enorme Flexibilität und Skalierbarkeit in einem Geschäftsmodell ermöglicht.

Die Nachteile von Microservices sind jedoch, dass die APIs ein höheres Risiko für Cyberangriffe darstellen und die Vielfalt der Programmiersprachen und der Kommunikation zwischen den Apps fehlerhaft sein kann. Aber das größte Problem entsteht beim Reporting. Jede App oder jedes Programm hat eine eigene Datenbank. Wie ruft ein Nutzer alle Daten für seine Berichte aus den Datenbanken ab? Bei diesem Konzept, bei dem Daten aus jeder Anwendung abgerufen werden, bleibt der Kernwert des begrenzten Kontexts nicht erhalten.

Microservice-Reporting

Wenn ein Unternehmen eine Microservice-Architektur betreibt, könnte ein einfaches Modell davon ausgehen, dass es verschiedene Programme für Folgendes hat:

• Finanzen und Abrechnung
• Workflow-Tool
• Verkaufsprogramm
• Gehaltsabrechnungssystem

Jeder dieser Microservices hat seine eigene Datenbank. APIs verbinden diese Programme miteinander, sodass sie unter einer Oberfläche betrieben werden können. Die Probleme beginnen jedoch, wenn Berichte erforderlich sind, die Daten aus mehreren Datenbanken abrufen.

Ein Beispiel dafür sind auf abgeschlossenen und abgerechneten Jobs basierende Vergütungen. Das Finanztool muss auf das Workflow-Tool zugreifen können, und nur dann verfügt das Gehaltsabrechnungstool über genaue Informationen, um die Mitarbeiter zu bezahlen. Wenn ein Unternehmen einen Bericht erstellen möchte, in dem laufende Arbeitsaufträge mit abgeschlossenen Verkäufen für den Monat verglichen werden, muss es auf drei verschiedene Programme zugreifen.

Es wird noch komplexer, wenn eine Vielzahl Microservices eingesetzt wird. Netflix hat zum Beispiel mehr als zwei Milliarden API-Edge-Anfragen pro Tag, die auf über 700 Microservices verteilt sind. Uber nutzt über 1300 Microservices. Bei einer Vielzahl Services wird die Reporting immer komplexer.

Herausforderungen bei Microservice-Reporting

Es gibt drei große Herausforderungen beim Microservice-Reporting.

Leistungsprobleme

Wenn ein Unternehmen zwei Milliarden API-Anfragen pro Tag für Geschäftsfunktionen hat, kann man sich vorstellen, wie sehr die Berichterstattung die Belastung erhöht. Wenn ein Reporting-Tool Daten aus mehreren Quellen abruft, oft mehrere hundert Mal am Tag, wie wird sich das auf das System auswirken? Das wird die Prozesse erheblich verlangsamen oder möglicherweise dazu führen, dass Prozesse zeitverzögert ablaufen.

Anti-Pattern

Die eigentliche Idee der Microservice-Architektur ist, dass jeder Service begrenzt ist. Das heißt, jede Anwendung ist ein Miniprogramm an sich. Die Architektur enthält alles, was benötigt wird und funktioniert innerhalb ihrer eigenen Grenzen. Sie benötigt keinen Zugriff auf etwas anderes zur Erfüllung ihrer Funktionen.

Wenn das Reporting erfordert, dass Services ihre Datenbanken gemeinsam nutzen, entsteht ein Anti-Pattern.

Verschiedene Datenmodelle und -typen

Wenn jeder Service in einer anderen Programmiersprache geschrieben ist, muss eine zusätzliche Kommunikationsebene zwischen den Services eingefügt werden, um das Verständnis zu ermöglichen. Wenn die Daten in einer anderen Form vorliegen, müssen sie automatisch bearbeitet werden, damit sie vom Reporting-Tool verarbeitet und genutzt werden können.

Widersprüchliche Daten

Weil jeder Service seine eigene Datenbank hat, kann es zu Datenredundanz, Duplizierung oder Konflikten kommen. Wenn zum Beispiel ein Lieferant auch Kunde ist und er dieselbe Adresse hat, aber eine im System falsch ist, könnte das zu Problemen bei der Datenkompilierung führen.

Was Reporting für Microservices erfordert

Gutes Reporting ist für die Gesundheit und das Wachstum eines Unternehmens unerlässlich. Ein gutes Reporting-System muss die folgenden Elemente enthalten:

Benutzerfreundlich

Berichte müssen einfach zu erstellen sein. Über ein zentrales Dashboard sollte es einfach sein, Parameter auszuwählen und die relevanten Daten zu übernehmen. Da Microservices alle unter das Dach eines Dashboards fallen, ist das leicht zu bewerkstelligen.

Single Source of Truth

Damit die Berichte korrekt sind, müssen die Daten korrekt sein. Die Daten sollten aus einer einzigen Informationsquelle (Single Source of Truth) stammen, keine Duplizierungen, veraltete oder falsche Informationen enthalten, und alles, was für den Bericht benötigt wird, sollte vorhanden sein. Das ist die größte Herausforderung für Microservices, da die Anwendungen getrennt und lose miteinander verknüpft sind.

Zeitnah verfügbar

In einer Welt, in der alles sofort verfügbar ist, muss das Reporting auf dem neuesten Stand sein. Wenn es Weihnachtsverkäufe, eine Änderung der Arbeitsumgebung gibt oder sich das Kundenverhalten ändert, müssen diese Änderungen zur Kenntnis genommen und so schnell wie möglich angegangen werden. Das stellt auch Herausforderungen für das Microservices-Modell dar, je nachdem, wie auf Daten zugegriffen wird.

Fast

Wenn die Bearbeitung eines Berichts Stunden in Anspruch nimmt und Ressourcen belastet, stellt das ein erhebliches Hindernis für erfolgreiche Reporting-Systeme dar. Der Betrieb Tausender APIs für den gleichzeitigen Zugriff auf Daten stellt ein erhebliches Hindernis für eine gute Berichterstattung in der Microservices-Architektur dar.

Automatisierung

Das System, mit dem die Daten abgerufen, extrahiert, verarbeitet und die Berichte erstellt werden, sollte hoch automatisiert sein. Nutzer sollten nicht auf das Backend zugreifen, manuelle Betriebsabläufe ausführen oder Daten manuell bearbeiten müssen.

Leicht verständlich

Berichte in Zeilen mit detaillierten Daten werden nicht immer benötigt, zudem sind sie nicht immer leicht verständlich. Berichte sollten stattdessen Graphen, Tabellen und Grafiken enthalten, die schnell Trends, Muster und Zahlen aufzeigen, damit sie von möglichst vielen Nutzern leicht verstanden werden.

Die Möglichkeit, Drilldowns durchzuführen

Wenn ein Nutzer oder Moderator ein einfaches Diagramm hat, aber verstehen muss, wie und warum etwas passiert ist, müssen Funktionen bereitstehen, über die er die detaillierten Daten einsehen kann. Unternehmen müssen in der Lage sein, Informationen einfach aufzugliedern, um Probleme, Stärken und Anomalien zu identifizieren.

Funktionen der künstlichen Intelligenz (KI)

Es macht keinen Sinn, über Daten zu verfügen, wenn ein Unternehmen nicht in der Lage ist, diese Daten für umsetzbare Verbesserungen zu nutzen. KI-Funktionen können diese Daten in Erkenntnissen und Prognosen umwandeln. Nach der Datenerhebung ist das Hinzufügen von KI-Funktionen aufgrund der Segmentierung der Microservices sehr einfach.

Mögliche Lösungen für Microservice-Reporting

Es gibt eine Reihe Optionen, um Reporting in einer Microservices-Architektur zu ermöglichen. Die richtige Lösung für ein Unternehmen hängt von vielen verschiedenen Faktoren ab, und es gibt keine pauschale Antwort.

Der erste Schritt besteht darin, die richtigen Services zu finden. Das Microservices-Modell bedeutet, dass für jede Aufgabe eine andere App oder ein anderes Programm erforderlich ist. Diese Microservices werden neben allen anderen Apps und Programmen installiert. Es ist wahrscheinlich, dass ein Unternehmen einen Service, der Daten abruft oder empfängt, einen weiteren mit Berichtsfunktionen und dann noch einen mit KI-Funktionen, benötigt.

Nach der Installation der Services müssen die Daten von den anderen Microservices abgerufen und die erforderlichen Berichte erstellt werden.

Direkte Datenbankverbindungen

Der Reporting-Service stellt eine direkte Verbindung zu den anderen Microservices her, ruft die relevanten Informationen aus deren Datenbanken ab und leitet sie an ein Data Warehouse weiter. Das ist einfach, bedeutet aber, dass jede Änderung eines Datenbankschemas auch eine Änderung im Reporting-Service erfordert. Außerdem wird der begrenzte Kontext, der in der Microservices-Architektur so wichtig ist, durchbrochen.

Aggregationsservice HTTP-Pull-Modell

Dieser Service verwendet APIs für die Verbindung mit den relevanten Microservices. Der Service ruft die erforderlichen Informationen auf und leitet sie über das Data Warehouse und das Reporting-Tool weiter. Diese Methode ist jedoch anfällig für Zeitverzögerungen und 504-Timeout-Fehler. Jeder zusätzliche Service, mit dem er kommunizieren muss, belastet das System zusätzlich und aggregiert mehrere Datenquellen, was zu massiven Leistungsproblemen führt.

Dieses Pull-Modell verstößt ebenfalls gegen den begrenzten Kontext.

Batch-Pull und dedizierte Datenbank

Bei dieser Strategie wird ein Befehl nach einem Zeitplan ausgeführt und Informationen werden in Batches aus allen relevanten Microservice-Datenbanken abgerufen. Diese Daten werden dann massenweise in der Reporting-Datenbank aktualisiert. Wie bei der direkten Datenbankverbindung könnte jedoch jede Änderung des Schemas den gesamten Batch-Job zum Scheitern bringen. Jedes Mal, wenn sich das Schema ändert, müssen auch die Batch-Funktionen aktualisiert werden.

Das andere Problem ist, dass es als Pull-Modell dem begrenzten Kontext widerspricht und möglicherweise nicht zu einem zeitnahen Reporting führt. Wenn der Pull-Request an die Zeit gebunden ist, an der die Last am geringsten ist, also um 2:00 Uhr, bedeutet das nur ein Update pro Tag.

Dedizierte Datenbank mit asynchronem Event-Pushing

Das ist komplizierter, aber es führt zu besseren Ergebnissen und verstößt nicht gegen das begrenzte Modell. Ein Event-Processor-Microservice erhält Updates, wenn etwas in einem anderen Services aktualisiert oder geändert wird. Anstatt Informationen aus der App abzurufen, sendet er Ereignisbenachrichtigungen. Das bedeutet, dass ein Datenerfassungsservice über alle relevanten Updates informiert und die Datenbank aktualisiert wird. Von dort aus kann ein Berichtsservice Berichte nach Bedarf erstellen.

Zu den Vorteilen dieser Reporting-Methode gehören:

• Beibehaltung der Prinzipien einer auf Microservices beschränkten Architektur. Der Berichtsservice reagiert nicht auf die Apps oder ruft keine Informationen ab.
• Sicherstellung, dass die resultierenden Berichte aktuell sind, weil der Berichtsservice über Ereignisse oder Informationsaktualisierungen informiert wird.
• Ausfiltern von Informationen, die während des gesamten Datenerfassungsservices nicht erforderlich sind.
• Daten in einer Form zusammenfassen, die der Reporting-Service über den Datenerfassungsservice nutzen kann.
• Bereitstellung von asynchronem Reporting, um hohe Verarbeitungslasten, Zeitüberschreitungen oder zeitliche Kopplung zu vermeiden.

Lösung widersprüchlicher Daten

Weil es buchstäblich Tausende Datenbanken geben könnte, ist es fast sicher, dass Daten doppelt oder falsch oder fehlerhaft erfasst wurden. Die Lösung dieses Problems ist wichtig, um genaue Berichte zu erstellen. Es gibt mehrere Lösungen für diese Herausforderung.

Ein Service zur Aktualisierung von Datenbanken

Wenn es einen Vermittlungsservice gibt, der erkennt, wenn eine Information aktualisiert wird, kann er diese Aktualisierung an die anderen Services weitergeben. Wenn zum Beispiel die Adresse eines Kunden aktualisiert wurde, werden diese Informationen an alle Instanzen der Kundeninformationen weitergegeben. Das kann unglaublich komplex sein und mehr Bandbreite im System erfordern, zudem ist es ein Anti-Pattern.

Wählen Sie für jeden Datentyp eine einzige Informationsquelle

Weil jeder Service in dieser Architektur eine einzelne Aufgabe erfüllt, muss die Datenbank dafür nicht umfassend sein. Die Rechnungsabteilung muss die Anschrift kennen, während die Vertriebsabteilung die Adresse benötigt, um das Produkt zu versenden. Benennen Sie einen Service als zentrale Informationsquelle für diese Daten.

Microservice-Reporting erfordert Planung

Es gibt eine Reihe von Herausforderungen für Microservice-Reporting, und es ist nicht die einfachste Architektur für das Reporting. Selbst die Aufrechterhaltung konsistenter Daten erfordert mehr Planung und Überlegung als andere traditionelle Architekturen. Es ist jedoch möglich, Berichte zu erstellen und gleichzeitig die Prinzipien begrenzter Services aufrechtzuerhalten.

Wenn ein Unternehmen ein Microservice-Framework einführen möchte, muss das IT-Team viel Planung und Grundlagenarbeit leisten, um sicherzustellen, dass Datenkonsistenz und Genauigkeit an erster Stelle stehen, gefolgt von einem Schwerpunkt auf der Weiterleitung von Daten von Quelldiensten zu anderen Services, die Data Lakes als Datenquelle erstellen, und diese Daten dann zu den erforderlichen Berichten verarbeiten.

In Anbetracht der enormen Vorteile, die das Microservice-Modell eines Unternehmens liefern kann, ist es die zusätzliche Komplexität des Reportings wert. Alle Herausforderungen können mit Überlegungen und Planung bewältigt werden.

Ähnliche Resourcen