Entwurfsmuster für Microservices dienen als Strategien für die Entwicklung von Software mithilfe der Microservices-Architektur, einem Ansatz, der einzelne Anwendungen in kleinere Komponenten oder Dienste zerlegt.
Diese Architekturmuster bieten standardisierte Lösungen für die täglichen Herausforderungen, mit denen Entwicklungsteams bei der Implementierung verteilter Computersysteme konfrontiert sind, einschließlich Servicekommunikation, Datenkonsistenz, Fehlertoleranz und Skalierbarkeit.
Viele der heutigen Digital Experience, auf die sich die Welt verlässt, werden durch Microservice-Designmuster ermöglicht und sind in vielen realen Anwendungsfallen zu finden. Wenn Sie beispielsweise eine Sendung auf Netflix streamen, arbeiten Hunderte von separaten Diensten zusammen, um Inhalte bereitzustellen, Benutzerprofile zu verwalten und vorzuschlagen, was Sie als Nächstes sehen möchten.
In ähnlicher Weise koordiniert Amazon Bestand, Zahlungen und Versand über verschiedene Services. In der Finanzbranche verlassen sich Banken und andere Institutionen auch auf Microservice-Entwurfsmuster, um Risikomanagement und Kundenservice zu trennen, das Geld sicher und zugänglich zu halten.
Laut der IBM-Umfrage Microservices in der Enterprise, 2021, geben 88 % der Unternehmen an, dass Microservices den Entwicklungsteams viele Nutzen bieten. Zu diesen Vorteilen gehören eine Steigerung der Entwicklerproduktivität um 20–50 % aufgrund einer besseren Codeorganisation, einfacherer Wartung und schnellerer Bereitstellungszyklen.
Bleiben Sie mit dem Think-Newsletter über die wichtigsten – und faszinierendsten – Branchentrends in den Bereichen KI, Automatisierung, Daten und mehr auf dem Laufenden. Weitere Informationen finden Sie in der IBM Datenschutzerklärung.
Die Microservices-Architektur ist eine cloudnative Methode, die Anwendungen in lose gekoppelte, unabhängige in Containern bereitgestellte Dienste aufteilt, die von Orchestrierungsplattformen wie Kubernetes verwaltet werden.
Jeder Service arbeitet unabhängig mit seinem eigenen Technologie-Stack, einschließlich dedizierter Datenbanken und Datenverwaltungsmodelle. Die Kommunikation zwischen Services erfolgt über REST-APIs, Event-Streaming-Plattformen wie Apache Kafka und Message Broker, während Teams Services rund um Geschäftsfunktionen mit klaren Grenzen, sogenannten begrenzten Kontexten, entwickeln.
Dieser moderne Ansatz für die Softwareentwicklung unterstützt die operative Flexibilität, die für moderne Initiativen zur digitalen Transformation erforderlich ist, wie z. B.DevOps -Automatisierung und CI/CD-Pipelines, Cloud-Migration, Anwendungsmodernisierung und Integration künstlicher Intelligenz (KI).
Obwohl Microservices erhebliche Vorteile für moderne Anwendungen bieten, ist ein Vergleich mit traditionellen monolithischen Ansätzen erforderlich, um zu verstehen, wann diese Architektur gewählt werden sollte.
Die monolithische Architektur erstellt eine Anwendung als eine einzige bereitstellbare Einheit, in der alle Geschäftsfunktionen integriert sind und dieselbe Codebasis, Datenbank und Laufzeitumgebung teilen. Die Microservices-Architektur gliedert eine Anwendung in kleinere, unabhängige Dienste auf, die über genau definierte Programmierschnittstellen (APIs) kommunizieren, wobei jeder Dienst eine eigene Datenbank und einen eigenen Bereitstellungszyklus haben kann.
Der Hauptunterschied zwischen diesen Entwurfsmethoden ist die Kopplung – wie eng die verschiedenen Teile des Systems miteinander verbunden sind. Monolithe haben eine hohe interne Kopplung, aber eine einfache Bereitstellung, während Microservices lose zwischen Diensten gekoppelt sind, aber komplexere IT-Infrastrukturanforderungen haben.
Softwareentwickler entscheiden sich häufig für eine monolithische Architektur für kleinere, einfachere Anwendungen, z. B. für kleine Unternehmen oder Start-ups, die Kosten kontrollieren und die Entwicklung beschleunigen möchten. In komplexen Szenarien, die eine hohe Skalierbarkeit, Belastbarkeit und Flexibilität erfordern (z. B. Social-Media-Plattformen, Bankanwendungen), sind Microservices die bessere Wahl.
Bei der Entscheidung für einen Ansatz sollten Unternehmen jeden einzelnen Ansatz anhand seiner spezifischen Anforderungen bewerten, einschließlich Teamgröße, Komplexität der Anwendungen, Skalierbarkeitsanforderungen und DevOps-Reifegrad.
Mehr erfahren über monolithische Architektur im Vergleich zu Microservices.
Die Entwurfsmuster für Microservices erstrecken sich auf fünf Schlüsselbereiche, die getestete Lösungen bieten, die Teams bei der Lösung von Herausforderungen der verteilten Architektur unterstützen:
Muster für die Dienstregistrierung
Das Service-Registrierungsmuster erstellt ein zentrales Verzeichnis, in dem Dienste ihre Endgeräte und ihren Zustand registrieren, sodass keine festen Adressen erforderlich sind. Wenn Services kommunizieren müssen, fragen sie die Registrierung ab, um verfügbare Serverinstanzen zu finden. Wenn ein Zahlungsdienst beispielsweise Kontakt zu einem Bestandsservice aufnehmen muss, überprüft er die Registrierung, um einwandfreie Bestandsinstanzen zu finden.
API Gateway-Muster
Ein API-Gateway-Muster erstellt einen einzelnen Einstiegspunkt zwischen Clients und mehreren Back-End-Microservices. Anstatt dass Clients separate Aufrufe an verschiedene Services senden, empfängt das API-Gateway eine Anfrage, leitet sie an die entsprechenden Microservices weiter und kombiniert die Antworten zu einem einzigen Ergebnis.
Beim Laden einer Produktseite kann das Gateway beispielsweise gleichzeitig Produktdetails, Preisgestaltung, Bestand und Prüfungen von verschiedenen Diensten abrufen. Anschließend werden all diese Informationen in einer einzigen, konsolidierten Antwort an den Client zurückgegeben.
Muster der Service-Erkennung
Ein Service Discovery Pattern löst die Herausforderung, dass Services sich gegenseitig in dynamischen Umgebungen lokalisieren. Wenn Microservices skaliert werden oder auf eine neue Version aktualisiert werden, ändern sich ihre Netzwerkstandorte ständig. Serviceerkennungsmuster bieten automatisierte Mechanismen für Dienste, um sich selbst zu registrieren und andere Dienste zu finden, mit denen sie kommunizieren müssen, sodass keine hartkodierten Adressen erforderlich sind.
Datenbank pro Servicemuster
Das Muster „Datenbank pro Service“ stellt sicher, dass jeder Microservice seine eigene Datenbank besitzt und verwaltet, wodurch gemeinsame Datenabhängigkeiten zwischen den Services vermieden werden. Dieser Ansatz verhindert den direkten Datenzugriff zwischen Services und reduziert die Kopplung, obwohl Services über APIs kommunizieren müssen, wenn sie Informationen aus anderen Informationsquellen benötigen. In einem ERP-System (Enterprise Resource Planning) verwaltet der Buchhaltungsservice beispielsweise Finanzdaten unabhängig von der Mitarbeiterdatenbank des Personaldienstes.
Saga-Muster
Ein Saga-Muster verwaltet Transaktionen, die sich über mehrere Microservices erstrecken, indem sie in koordinierte Schritte aufgeteilt werden. Jeder Service schließt seine lokale Transaktion ab und löst so die nächsten Schritte in der Kette aus. Wenn ein Schritt fehlschlägt, führt das Muster automatisch Aktionen aus, um vorherige Schritte rückgängig zu machen. Wenn beispielsweise bei der Bearbeitung einer Online-Bestellung die Zahlung nach der Reservierung des Bestands fehlschlägt, gibt Saga die reservierten Artikel automatisch frei.
CQRS (Command Query Responsibility Segmentation Pattern)
Das CQRS-Muster trennt Datenänderung (Befehle) von Datenabruf (Abfragen), indem es jeweils dedizierte Modelle verwendet. Durch diese Aufteilung kann das System jeden Pfad unabhängig optimieren. Dadurch werden Schreibkonflikte auf der Befehlsseite minimiert und die Abfragelatenz auf der Leseseite verringert. In einem E-Commerce-System wird beim Aufgeben einer Bestellung das schreiboptimierte Befehlsmodell verwendet, während beim Erstellen eines Verkaufsberichts das leseoptimierte Abfragemodell genutzt wird.
Muster des Leistungsschalters
Das Trennschaltermuster verhindert, dass sich Ausfälle eines Dienstes auf das gesamte System ausbreiten, indem es Aufrufe an nachgelagerte Dienste überwacht und Anfragen stoppt, wenn Ausfälle erkannt werden. Wenn ein Dienst nicht mehr reagiert, „löst“ der Trennschalter aus und blockiert weitere Aufrufe, wodurch Systemressourcen geschützt und Kettenausfälle verhindert werden.
Wenn beispielsweise ein Bestandservice ausfällt, verhindert der Trennschalter, dass der Bestellservice wiederholt fehlgeschlagene Anfragen stellt. So kann der Rest des Systems weiter fortfahren, während den Kunden Ausweichantworten bereitgestellt werden.
Schutzwandmuster
Das Bulkhead-Muster isoliert Systemressourcen, um zu verhindern, dass Ausfälle in einem Bereich das gesamte System beeinträchtigen. Wie Fächer im Schiffsrumpf trennen Schotte verschiedene Funktionen, sodass bei Ausfall des einen die anderen funktionsfähig bleiben. Das Muster begrenzt die Anzahl gleichzeitiger Anforderungen oder Ressourcen, die bestimmten Services zugewiesen sind.
Backend for Frontend (BFF)-Muster
Ein Backend-for-Frontend (BFF) erstellt einen dedizierten Backend-Service, der auf jede spezifische Front-End-Schnittstelle zugeschnitten ist. Da mobile Apps andere Anforderungen haben als Anwendungen (z. B. kleinere Bildschirme, begrenzte Bandbreite, unterschiedliche Funktionen), ermöglicht das BFF-Muster den Entwicklern, jedes Backend für sein jeweiliges Frontend zu optimieren.
Entitäts- und Aggregatmuster
Ein Entitäts- und Aggregatmuster organisiert verwandte Daten in logischen Einheiten, die auf DDD-Konzepten (Domain-Driven Design) basieren. Eine Entität stellt ein eigenständiges Objekt mit einer eindeutigen Identität dar, wie ein Kundenkonto, das durch eine E-Mail-Adresse identifiziert wird. Ein Aggregat kombiniert verknüpfte Entitäten, die zusammen als eine Einheit aktualisiert werden müssen.
In einem E-Commerce-System würde eine Bestellaggregation beispielsweise die Bestelldetails, die Positionen und die Versandinformationen enthalten, die bei Änderungen alle synchronisiert bleiben müssen.
Strangler-Muster
Ein Würgermuster hilft bei der Verwaltung des Refactorings einer monolithischen Anwendung in eine verwaltbare Microservices-Architektur. Neue Microservices werden nach und nach neben dem bestehenden Monolithen erstellt und übernehmen langsam die Funktionalität, bis das alte System vollständig ersetzt ist. Der Name leitet sich von der Metapher ab, wie ein Weinstock (Microservice) allmählich um einen Baum (die Anwendung) wächst und ihn schließlich erdrosselt (engl. to strangle).
Ereignisgesteuertes Muster
Ein ereignisgesteuertes Muster ermöglicht Microservices eine asynchrone Kommunikation durch die Veröffentlichung und Nutzung von Ereignissen, anstatt direkte Serviceaufrufe zu tätigen. Wenn ein Dienst eine Aktion abschließt, sendet er ein Ereignis, das andere interessierte Dienste anhören und entsprechend reagieren können. Dieser Ansatz sorgt für eine lose Kopplung zwischen den Diensten, sodass sie unabhängig voneinander arbeiten und gleichzeitig ihre Aktivitäten über ein gemeinsames Ereignissystem koordinieren können.
Sidecar-Muster
Ein Sidecar-Muster bezieht sich auf das Bereitstellen eines sekundären Containers (der „Sidecar“) neben einer primären Anwendung oder einem primären Dienst innerhalb derselben Ausführungsumgebung. Das Sidecar bearbeitet bereichsübergreifenden Belange (zum Beispiel Logging, Überwachung, Sicherheit, Observability) und erweitert die Funktionalität der Hauptanwendung, ohne deren Codebasis zu ändern.
Adapter-Microservices-Muster
Ein Adapter-Microservice-Muster ermöglicht die Kommunikation zwischen inkompatiblen Systemen oder Schnittstellen. Genauso wie man sein Gerät mit einem Reiseadapter an ausländische Steckdosen anschließen kann, wandeln Adaptermuster verschiedene Datenformate, Protokolle oder APIs um. Dieses Muster ist von Vorteil bei der Integration mit Altlasten oder Services von Drittanbietern, die unterschiedliche Kommunikationsstandards verwenden.
Die Entwurfsmuster von Microservices sind besonders in Branchen praktisch, die eine hohe Skalierbarkeit, komplexe Geschäftslogik und zuverlässige Leistung erfordern. Zu den wichtigsten Anwendungsfällen gehören:
Die Entwurfsmuster von Microservices bieten Best Practices für die Verwaltung der komplexen verteilten Systeme von heute und bieten diese weitreichenden Vorteile:
Die Auswahl geeigneter Muster hängt von den spezifischen Anforderungen und organisatorischen Funktionen Ihres Systems ab. Ein systematischer Ansatz kann bei diesen wichtigen Entscheidungen helfen.
Beginnen Sie mit API Gateway und Serviceerkennung, bevor Sie komplexe Muster wie Event Sourcing oder CQRS implementieren. Diese Kernmuster bilden die Kommunikationsinfrastruktur, die für anspruchsvollere Implementierungen benötigt wird.
Berücksichtigen Sie Ihre Erfahrungen mit verteilten Systemen, betrieblicher Kompetenz und DevOps-Praktiken. Teams, für die Microservices noch Neuland sind, haben zunächst einen Nutzen von einfacheren Mustern, während erfahrene Teams fortgeschrittenere Koordinationsmuster in Angriff nehmen können, die tiefere operative Kenntnisse erfordern.
Jedes Muster bringt Komplexität mit sich, die Ihr Team auf lange Sicht bewältigen muss. Datenbanken pro Service erfordern Strategien zur Datensynchronisation. Ereignisgesteuerte Muster erfordern eine Message-Broker-Infrastruktur. Stellen Sie sicher, dass Sie über die nötige Kapazität verfügen, um die von Ihnen ausgewählten Muster zu unterstützen.
Beginnen Sie mit einigen wenigen Services und verwenden Sie grundlegende Muster, sammeln Sie Erfahrungen und erweitern Sie diese dann, wenn Sie sich mehr Fachwissen aneignen. Dieser inkrementelle Ansatz verhindert Overengineering und ermöglicht es, aus frühen Implementierungen zu lernen.
Nutzen Sie die Leistungsfähigkeit von KI und Automatisierung, um Probleme im gesamten Anwendungs-Stack proaktiv zu lösen.
Verwenden Sie DevOps-Software und -Tools, um cloudnative Anwendungen für mehrere Geräte und Umgebungen zu erstellen, bereitzustellen und zu verwalten.
Geschäftsagilität und -wachstum beschleunigen: Modernisieren Sie Ihre Anwendungen mit unseren Cloud-Consulting-Services durchgehend auf jeder Plattform.