System Design

In herkömmlichen monolithischen Anwendungen ist die Aufrechterhaltung der Datenkonsistenz über mehrere Einheiten hinweg unkompliziert. Relationale Datenbank-Engines bieten ACID-Garantien (Atomizität, Konsistenz, Isolation, Haltbarkeit), die in lokale SQL-Transaktionen eingebettet sind. Wenn eine Auftragserteilung, ein Zahlungsabzug oder eine Lagerbestandsreserve auf halbem Weg fehlschlägt, wird durch den Aufruf von ROLLBACK jede Datenbankänderung sofort rückgängig gemacht. Bei der Migration auf eine moderne Microservices-Architektur verändert sich das Datenmanagement jedoch grundlegend. Um Domänenautonomie und unabhängige Skalierbarkeit sicherzustellen, besitzt jeder Microservice seine private Datenbank. Ein einzelner Geschäftsvorgang – wie die Verarbeitung einer E-Commerce-Kaufabwicklung – erstreckt sich jetzt über mehrere Servicegrenzen und Datenbank-Engines (z. B. PostgreSQL für Bestellungen, DynamoDB für Zahlungen, Redis für Inventar).

In modernen verteilten Softwaresystemen ist die Event-Driven Architecture (EDA) der Grundpfeiler für skalierbare Microservices. Services senden regelmäßig Ereignisse wie OrderCreated oder PaymentProcessed, um Zustandsänderungen sicher zu kommunizieren. Die Herausforderung: Wie stellt man sicher, dass ein Datenbank-Update und das Veröffentlichen des zugehörigen Events entweder beide erfolgreich sind oder beide fehlschlagen? Wenn ein Microservice seine lokale Datenbank aktualisiert und anschließend versucht, ein Event über das Netzwerk an einen Message Broker (wie Apache Kafka oder RabbitMQ) zu senden, können Netzwerkausfälle oder Timeouts zu Dateninkonsistenzen führen.

In einer Microservices-Architektur bilden Dienste ein Netz verteilter Netzwerkaufrufe. Dadurch können Teams zwar unabhängig voneinander Dienste aufbauen und skalieren, es bedeutet aber auch, dass die Gesamtzuverlässigkeit Ihres Systems nur so stark ist wie sein schwächstes Glied. Wenn ein kritischer Dienst ausfällt oder nicht mehr reagiert, kann dies einen kaskadierenden Fehler auslösen, der die gesamte Anwendung unterbricht.

In einer Microservices-Architektur kommunizieren Dienste über ein Netzwerk und nicht über In-Memory-Aufrufe. Während diese Entkopplung eine massive horizontale Skalierung und unabhängige Bereitstellungen ermöglicht, bringt sie auch eine große Schwachstelle mit sich: Das Netzwerk ist unzuverlässig. Bei einem Downstream-Dienst kann es jederzeit zu einem kurzen Netzwerkfehler, einem vorübergehenden CPU-Spitzenwert, einem schnellen Datenbanksperrenkonflikt oder einem rollierenden Update-Neustart kommen. Diese vorübergehenden Ausfälle werden als vorübergehende Fehler bezeichnet.

In einer Microservices-Architektur ist eine einzelne Anwendung in Dutzende oder Hunderte unabhängiger, zusammenarbeitender Dienste unterteilt. Während dieses Design die Modularität und Skalierbarkeit verbessert, birgt es auch ein großes Risiko: Ein Ausfall in einem Dienst kann zu einer Kaskade führen und das gesamte System zum Absturz bringen. Wenn ein Downstream-Dienst träge wird oder nicht mehr reagiert, häufen sich die eingehenden Anfragen an Ihre Upstream-Dienste. Wenn alle den gleichen Speicher, die gleiche CPU oder den gleichen Thread-Pool nutzen, kann eine langsame Abhängigkeit schnell alle verfügbaren Ressourcen erschöpfen und zum Absturz Ihrer gesamten Anwendung führen.

In modernen Cloud-nativen Systemen wird von Microservices viel mehr erwartet, als nur Geschäftslogik auszuführen. Sie müssen sich um die Protokollierung kümmern, SSL/TLS-Zertifikate verwalten, Metriken sammeln, Wiederholungsmechanismen implementieren und sichere Kommunikation mit anderen Diensten koordinieren. Wenn wir all diese übergreifenden Funktionen direkt in die Codebasis jeder Anwendung einbetten, kommt es zu Code-Aufblähung, enger Kopplung und Sprachbindung.

In der modernen Softwareentwicklung sind veraltete monolithische Anwendungen eine häufige Herausforderung. Mit der Zeit wird eine erfolgreiche Codebasis so groß und vernetzt, dass einfache Änderungen riskant werden, Bereitstellungen Stunden dauern und die Skalierung einzelner Funktionen praktisch unmöglich ist. Wenn Teams beschließen, ihre Systeme durch die Migration auf Microservices zu modernisieren, stehen sie vor einer wichtigen Frage: Wie schreiben wir das System neu, ohne unser aktuelles Geschäft zu zerstören?

In einer Microservices-Architektur sind unsere Systeme in Dutzende kleiner, fokussierter Services unterteilt – wie einen Benutzerservice, einen Bestellservice und einen Produktservice. Wenn es jedoch darum geht, Ihren Benutzern diese Informationen anzuzeigen, haben verschiedene Geräte sehr unterschiedliche Anforderungen. Ein Webbrowser auf einem Hochgeschwindigkeits-Desktop-Computer benötigt ein umfangreiches Dashboard voller Tabellen, Seitenleisten und Grafiken. Eine mobile App in einem langsamen Mobilfunknetz benötigt ein einfaches, schlankes Layout, um Bandbreite und Akku zu sparen. Eine Smartwatch-App benötigt möglicherweise nur eine einzige Textzeile.

Der Übergang von einer einzelnen, monolithischen Anwendung zu einer Microservices-Architektur löst viele Probleme. Es ermöglicht Teams, unabhängig zu arbeiten, Dienste separat bereitzustellen und Teile des Systems nach Bedarf zu skalieren. Es bringt jedoch auch eine neue Herausforderung mit sich: Wie interagieren Kunden mit all diesen unabhängigen Diensten? Wenn Sie zehn, fünfzig oder Hunderte winziger Microservices haben, sollte eine mobile App oder Webseite eine direkte Verbindung zu jedem einzelnen von ihnen herstellen?

Wenn Unternehmen von einer monolithischen Architektur zu Microservices wechseln, stehen sie vor einer kritischen, hochriskanten Frage: Wie ziehen wir die Grenzen unserer Services? Theoretisch sollten Microservices lose, entkoppelte Einheiten sein, die unabhängig voneinander entwickelt, bereitgestellt und skaliert werden können. In der Praxis bauen viele Teams jedoch letztendlich einen verteilten Monolithen auf – ein System, in dem Dienste so eng miteinander verbunden sind, dass eine einzelne Geschäftsänderung die gleichzeitige Änderung und Bereitstellung mehrerer Dienste erfordert, was zu Netzwerklatenz und Bereitstellungsblockaden führt.