Africa Studio - stock.adobe.com
Eine ereignisgesteuerte Microservices-Architektur verwenden
Ereignisgesteuerte Microservices sind flexibler und pflegeleichter als Legacy-Anwendungen mit einer monolithischen Architektur. Entwickler müssen diese aber managen können.
Um die Geschäftsanforderungen zu erfüllen, müssen Anwendungen heute ein Maximum an Skalierbarkeit und Ausfallsicherheit bieten und rund um die Uhr verfügbar sein. Da bestehende Architekturen solche Anforderungen nicht erfüllen konnten, sind Technologien wie Event Hubs, Cloud Computing und Microservices entstanden.
Ereignisgesteuerte Microservices ersetzen Anwendungen mit einer monolithischen Architektur und schaffen Systeme, die flexibler, skalierbarer und pflegeleichter sind. Im Vergleich zu Legacy-Systemen bietet die ereignisgesteuerte Architektur in Microservices verschiedene Vorteile.
Softwaredesigner und -entwickler müssen allerdings lernen, wie sie die Kommunikation, Wartung und Skalierbarkeit von Microservices innerhalb dieser ereignisgesteuerten Methoden angehen. Darüber hinaus sollte sich ein Entwicklungsteam für ein Architekturmuster entscheiden, das am besten zu den Aufgaben der Anwendung passt: Event Sourcing, Polyglotte Persistenz (Polyglot Persistence) oder Command Query Responsibility Segregation (CQRS).
Vorteile der ereignisgesteuerten Architektur
In einer ereignisgesteuerten Architektur stehen Domain Events an erster Stelle. Domain Events sind die Ereignisse, die in einer bestimmten Domäne passieren und die den Fachexperten wichtig sind. Solche Ereignisse sind unabhängig von den Technologien. Domain Events im E-Commerce-Umfeld sind zum Beispiel: Ein Besucher hat sich registriert; eine Bestellung ist eingegangen; die Zahlungsfrist ist abgelaufen.
Ereignisgesteuerte Architekturen – häufig in Microservices und serverbasierten Projekten zu finden – unterstützen Systeme, die zuverlässig, lose gekoppelt, skalierbar und hochverfügbar sind. Moderne Microservices-Architekturen sind grundsätzlich ereignisgesteuert und reaktiv. Wenn eine Komponente in einer ereignisgesteuerten Architektur ausfällt, arbeiten die anderen Komponenten weiterhin wie gewohnt. In einer typischen monolithischen Anwendung kann hingegen der Ausfall einer Komponente auch die anderen Komponenten mit sich reißen.
Unternehmen wie LinkedIn und Netflix verwenden eine ereignisgesteuerte, asynchrone Messaging-Architektur.
Datenmanagement für Microservices
Wenn Unternehmen ereignisgesteuerte Microservices einsetzen möchten, müssen sie im Vergleich zum Design von Legacy-Anwendungen mit vielen Änderungen rechnen. Dies betrifft insbesondere die Daten.
Eine monolithische Anwendungsarchitektur enthält typischerweise eine einzige Datenbank beziehungsweise Datenbasis. Im Gegensatz dazu ist der Datenzugriff in einer Microservices-Architektur komplexer. Jeder Microservice hat typischerweise seine spezifischen Daten, was bedeutet, dass die Daten für diesen Microservice reserviert sind.
Wenn ein Dienst auf Daten zugreifen möchte, die einem anderen Dienst gehören, muss er über die API dieses Dienstes einen Zugriff anfragen. Darüber hinaus erleichtert die Art und Weise, wie eine API Daten kapselt, Entwicklern den Aufbau lose gekoppelter Microservices sowie deren unabhängige Verwaltung, Pflege und Änderung.
Wenn mehrere Dienste auf ein und dieselben Daten zugreifen, wird die Sache kompliziert. Um es noch schwieriger zu machen: möglicherweise verfügt man über Microservices, die verschiedene Arten von Datenbanken verwenden. Ein Beispiel hierfür sind Microservices mit einer Mischung aus SQL- und NoSQL-Datenbanken, was als Polyglott Persistent (Polyglot Persistence) bezeichnet wird.
Polyglotte Persistenz hat zweifellos eine Fülle von Vorteilen – wie lose gekoppelte Dienste und bessere Leistung und Skalierbarkeit. Sie stellt allerdings auch große Herausforderungen an das verteilte Datenmanagement.
Wie beispielsweise sollen Business-Transaktionen über mehrere Services hinweg durchgeführt und die Datenkonsistenz sichergestellt werden? Eine typische monolithische Anwendung kann die Vorteile von Atomarität, Konsistenz, Isolation und Dauerhaftigkeit – bekannt unter dem Akronym ACID - nutzen, um die Konsistenz zu erhalten. Diese Art von Transaktionen passt jedoch nicht zu Microservices-Anwendungen.
Kommunikation zwischen ereignisgesteuerten Microservices
In einer typischen ereignisgesteuerten Architektur müssen mehrere Microservices asynchron miteinander kommunizieren. Diese Dienste sollten skalierbar, voneinander entkoppelt und individuell gepflegt werden. Darüber hinaus sollten die Microservices Ereignisse erzeugen, die andere Dienste verwenden können.
In einer ereignisgesteuerten Microservice-Architektur veröffentlicht ein Microservice ein Ereignis, wenn eine bestimmte Aktivität eintritt – zum Beispiel die Statusaktualisierung eines Auftrags. Sobald ein Dienst ein Ereignis erhält, aktualisiert er seine Daten. Dann abonnieren die anderen Microservices diese Ereignisse. Dieses Design kann bei der Implementierung von Geschäftstransaktionen helfen, die mehrere Dienste umfassen.
Betrachten wir als Beispiel zwei Dienstleistungen – den Bestellservice und den Kundenservice. Beide müssen zur Bearbeitung von Bestellungen kommunizieren. Dem Bestellservice gehört die Auftragstabelle und dem Kundendienst die Kundentabelle. Wenn der Bestellservice eine Bestellung mit dem Status Neu erstellt und das Ereignis Bestellung erstellt veröffentlicht, nimmt der Kundenservice dieses Ereignis entgegen, reserviert Guthaben hierfür und veröffentlicht dann ein Ereignis Guthaben reserviert. Anschließend nimmt der Bestellservice dieses Ereignis entgegen und setzt den Bestellstatus auf Offen.
Ereignisgesteuerte Microservices helfen Entwicklern auch bei der Generierung reaktionsschneller Anwendungen. Betrachten wir einen Service mit dem Namen Bestätigung, der die Benutzer benachrichtigt, sobald ihre Bestellung eingegangen und in die Warteschlange platziert wurde.
Da mehrere Benutzer gleichzeitig auf die Anwendung zur Auftragsbearbeitung zugreifen, müssen alle Benachrichtigungen in die Warteschlange gestellt werden, bevor sie an die jeweiligen Benutzer gesendet werden. In diesem Fall muss ein Benutzer nicht warten, während die Bestellung ausgeführt wird. Diese Architektur erzeugt eine reaktionsfähige, lose gekoppelte Anwendung.
Ereignisgesteuerte Microservices-Architekturmuster
Muster für den Aufbau von ereignisgesteuerten Microservices sind Event Sourcing, Polyglotte Persistenz und Command Query Responsibility Segregation (CQRS).
Event Sourcing ist ein häufig verwendetes Architekturmuster für die Migration von einem Monolithen zu Microservices. Beim Event-Sourcing-Muster bestimmt eine Abfolge von Ereignissen den Zustand der Anwendung. Dieses Muster verwendet einen reinen Ereignisstrom wie dies zum Beispiel bei Apache Kafka oder RabbitMQ der Fall ist. Ereignisse werden in der gleichen Reihenfolge bearbeitet, in der sie empfangen werden – wie in einer Warteschlange.
Bei polyglotten Persistenz-Mustern werden die Datenspeicher in Abhängigkeit von den Eigenschaften der Datentypen ausgewählt. Microservices-Architekturen können Daten als separaten Dienst und in mehreren Formaten speichern. Zum Beispiel benötigt eine E-Commerce-Anwendung eine Volltextsuchfunktion. Die von dieser Suchmaschine verwendete Datenbank ist eine Dokumentendatenbank – zum Beispiel MongoDB - da sie eine schnelle Suche ermöglicht. Doch die E-Commerce-Anwendung verwendet eine relationale Datenbank, um Transaktionen zu verfolgen. Daher sollten die Suchmaschine und ihre Datenbank neben der anderen relationalen Datenbank oder den Datenbanken, die die E-Commerce-Anwendung verwendet, koexistieren. So ermöglicht man polyglotte Persistenz.
CQRS isoliert das Lese- vom Schreibmodell. Dieses Architekturmuster arbeitet mit verschiedenen Modellen zum Lesen und Aktualisieren von Domänendaten. Im CQRS-Muster gibt es typischerweise für die Einfüge- oder Aktualisierungsoperationen sowie für die Datenabfrage einen separaten Dienst, ein eigenes Modell und eine eigene Datenbank.
