Microservices-Architektur für Webanwendungen

Microservices-Architektur: Muster und Best Practices

Die Microservices-Architektur besteht darin, Anwendungen als eine Sammlung kleiner, unabhängiger Dienste zu erstellen. Jeder Dienst konzentriert sich auf eine bestimmte Geschäftsfähigkeit, hat seine eigene Datenbank und kann unabhängig bereitgestellt werden. Dieser Ansatz bietet Flexibilität und Skalierbarkeit, bringt aber auch Komplexität mit sich, die sorgfältig gemanagt werden muss.

Servicegrenzen: Die richtige Aufteilung finden

Die wichtigste Entscheidung in einer Microservices-Architektur ist, wo die Grenzen zwischen den Diensten gezogen werden. Der beste Ansatz ist, die Dienste an den Geschäftsfähigkeiten auszurichten. Ein Benutzerdienst verwaltet Benutzerkonten und -profile. Ein Bestelldienst verwaltet Bestellungen. Ein Zahlungsdienst verwaltet Zahlungen. Jeder Dienst besitzt eine vollständige Geschäftsdomäne, einschließlich seiner Daten und Logik.

Eine nützliche Technik ist es, mit einem gut strukturierten Monolithen zu beginnen und die Grenzen nach und nach zu identifizieren. Die Muster, die sich beim Trennen von Belangen in einem Monolithen auf natürliche Weise ergeben, sind oft die richtigen Grenzen für Microservices. Ein vorzeitiges Aufteilen in Dienste, bevor man die Domäne versteht, führt zu einem verteilten Monolithen – dem Schlimmsten aus beiden Welten.

Kommunikation zwischen Diensten

Dienste müssen miteinander kommunizieren. Die beiden Hauptansätze sind synchrone Kommunikation (HTTP- oder gRPC-Anfragen) und asynchrone Kommunikation (Nachrichten über eine Warteschlange oder einen Ereignisbus). Synchron ist einfacher, erzeugt aber Kopplung – wenn der Bestelldienst den Zahlungsdienst aufruft und der Zahlungsdienst langsam ist, ist der Bestelldienst auch langsam.

Asynchrone Kommunikation entkoppelt Dienste. Der Bestelldienst gibt ein Ereignis aus, wenn eine Bestellung erstellt wird. Der Zahlungsdienst hört auf dieses Ereignis und verarbeitet die Zahlung. Wenn der Zahlungsdienst ausfällt, bleibt das Ereignis in der Warteschlange und wird verarbeitet, wenn er zurückkommt. Dies ist widerstandsfähiger, aber schwieriger zu durchschauen.

Datenverwaltung

Jeder Dienst sollte seine eigenen Daten besitzen. Der Bestelldienst hat seine eigene Datenbank, der Benutzerdienst hat seine eigene, und sie teilen sich keine Datenbanken direkt. Diese Unabhängigkeit macht Dienste skalierbar und unabhängig bereitstellbar. Aber es bedeutet auch, dass Operationen, die mehrere Dienste umfassen – wie das Anzeigen aller Bestellungen eines Benutzers – eine Koordination zwischen den Diensten erfordern.

Das Saga-Muster ist eine gängige Methode zur Verwaltung von Transaktionen, die mehrere Dienste umfassen. Anstelle einer einzelnen Datenbanktransaktion wird die Operation in eine Reihe lokaler Transaktionen aufgeteilt, jede mit einer kompensierenden Aktion, die sie rückgängig macht, wenn etwas schiefgeht.

Operative Komplexität

Microservices erfordern einen erheblichen operativen Aufwand. Sie benötigen Service Discovery, damit Dienste einander finden können. Sie benötigen ein API-Gateway, um einen einzigen Einstiegspunkt für Clients bereitzustellen. Sie benötigen verteiltes Tracing, um Anfragen zu debuggen, die mehrere Dienste umfassen. Sie benötigen zentralisierte Protokollierung und Überwachung. Sie benötigen automatisierte Bereitstellungspipelines für jeden Dienst.

Diese operative Komplexität ist der Hauptgrund, warum Microservices nicht für jedes Projekt geeignet sind. Für ein kleines Team überwiegt der Aufwand für die Verwaltung mehrerer Dienste die Vorteile. Für eine große Organisation sind die Unabhängigkeit und Skalierbarkeit die Investition wert.