Verteilte Architektur

Was sind Microservices?

Microservice-Architektur

Microservices sind ein Architekturstil, bei dem eine Anwendung in fachlich eigenständige Dienste zerlegt wird, die jeweils eigene Daten halten, über das Netz miteinander sprechen und sich unabhängig voneinander ausliefern lassen.

Wenn jede kleine Änderung ein Release der gesamten Anwendung erzwingt und drei Teams dabei aufeinander warten, kommt der Schnitt in eigenständige Dienste auf den Tisch.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Schnitt entlang: Fachlichen Grenzen, nicht technischen Schichten
Je Dienst: Eigene Daten und eigene Auslieferung
Preis: Netzwerk, Betrieb und verteilte Fehlersuche
Verwechselt mit: Modulith mit sauberen Modulgrenzen

Der Schnitt entscheidet alles

Die schwierige Arbeit ist nicht die Technik, sondern die Grenze. Ein Dienst sollte einen fachlichen Bereich vollständig besitzen, etwa die Auftragsannahme oder die Rechnungsstellung, und nicht eine technische Schicht, in der zum Beispiel sämtliche Datenbankzugriffe liegen. Schneidest du technisch, muss für jede fachliche Änderung trotzdem jeder Dienst angefasst werden, und du hast dir die Nachteile ohne den Nutzen eingehandelt.

Ein brauchbarer Test ist die Frage, wie viele Dienste ein typisches Ticket berührt. Sind es regelmäßig drei oder vier, liegt die Grenze falsch.

Eigene Daten, verteilte Wahrheit

Zur Selbstständigkeit gehört, dass kein Dienst in die Tabellen eines anderen schaut. Was er von dort braucht, holt er über eine Schnittstelle oder bekommt es als Ereignis zugeschickt. Der Preis dafür ist, dass es keine Transaktion mehr über alles gibt: Eine Buchung, die Lager und Zahlung betrifft, wird zu einer Abfolge von Schritten mit Ausgleichsbuchungen, falls ein Schritt scheitert.

Damit einher geht Eventual Consistency. Der Lagerbestand in der Suchansicht kann für einige Sekunden veraltet sein. Das ist kein Fehler, sondern eine Entscheidung, und sie muss mit der Fachseite abgesprochen sein, bevor sie im Betrieb auffällt.

Was der Betrieb dazubekommt

Aus einem Deployment werden viele. Das funktioniert nur mit automatisierten Pipelines, Containern und einer Plattform, die Ausfälle wegsteckt. Dazu kommt Beobachtbarkeit: Ohne verteiltes Tracing, in dem eine Anfrage über alle beteiligten Dienste hinweg dieselbe Kennung trägt, findet niemand mehr heraus, wo die Latenz herkommt.

Netzaufrufe scheitern zudem anders als Methodenaufrufe. Zeitlimits, Wiederholungen mit wachsendem Abstand und ein Circuit Breaker, der einen kranken Dienst kurzzeitig abklemmt, gehören deshalb zum Standardgepäck. Spring Boot und Quarkus bringen das über Bibliotheken mit.

Wann sich der Aufwand nicht lohnt

Bei einer kleinen Anwendung und einem einzigen Team zahlst du den vollen Preis und bekommst wenig zurück. Der Nutzen entsteht dort, wo mehrere Teams unabhängig voneinander ausliefern wollen, wo Teile der Anwendung sehr unterschiedlich skalieren oder wo ein Bereich technologisch aus der Reihe tanzen muss.

Ein gangbarer Weg ist der modulare Monolith: klare Modulgrenzen im selben Deployment. Sind die Grenzen erst sauber, lässt sich ein Modul später herauslösen. Umgekehrt ist es deutlich schwerer.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Microservices und was oft damit gleichgesetzt wird

Microservices gegen Monolith

Ein Monolith wird als eine Einheit gebaut und ausgeliefert. Das ist kein Schimpfwort: Solange ein Team daran arbeitet, ist er schneller zu entwickeln, zu testen und zu betreiben.

Microservices gegen Serviceorientierte Architektur

Die ältere SOA arbeitete häufig mit einem zentralen Enterprise Service Bus, in dem Routing und Umsetzung lagen. Microservices halten die Verbindungsschicht bewusst dünn und die Logik in den Diensten.

Microservices gegen Modulith

Der modulare Monolith trennt fachlich wie Microservices, verzichtet aber auf die Verteilung. Du bekommst die Grenzen ohne den Netzwerk- und Betriebsaufwand.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Ein schlechter Schnitt macht aus Methodenaufrufen Netzwerkfehler

Zerlegst du entlang technischer Schichten, entsteht ein verteilter Monolith. Jeder Anwendungsfall braucht dann drei Dienste, die synchron aufeinander warten, und ein Ausfall reicht, damit nichts mehr geht. Der Schnitt muss so liegen, dass ein Dienst eine fachliche Aufgabe allein zu Ende bringt.

Über Dienstgrenzen hinweg gibt es keine gemeinsame Transaktion. Eine Bestellung, die im einen Dienst angelegt und im anderen bezahlt wird, lässt sich nicht in einem Rutsch zurückrollen, sondern braucht einen ausdrücklich beschriebenen Ausgleichsschritt. Diese Fälle vorher durchzuspielen ist der eigentliche Entwurfsaufwand.

Dazu kommt, was vorher niemand gebraucht hat. Ohne eine Kennung, die jeden Aufruf durch alle Dienste begleitet, findest du eine fehlgeschlagene Bestellung nicht mehr, weil ihre Spur über vier Protokolldateien verteilt liegt. Wer damit anfängt, sollte diese Grundausstattung stehen haben, bevor der zweite Dienst dazukommt.

Microservices lernen

Wie ein Dienst mit Zeitlimits, Circuit Breaker und Tracing produktionsreif wird, zeigen die Kurse zu Spring Boot und Quarkus am laufenden Beispiel.

Die Entwurfsfragen dahinter, also Grenzen, Kopplung und Schnittstellen, gehören in die allgemeinen Programmier- und Architekturkurse .

Kurse, die Microservices behandeln

Häufige Fragen

Wie groß darf ein Microservice sein?

Die Zeilenzahl ist das falsche Maß. Brauchbarer ist: Ein Team muss den Dienst allein verstehen, ändern und ausliefern können, und eine fachliche Änderung darf ihn nicht regelmäßig zusammen mit anderen betreffen.

Müssen alle Dienste dieselbe Sprache verwenden?

Technisch nein, das ist einer der beworbenen Vorteile. In der Praxis begrenzen die meisten Organisationen die Auswahl trotzdem, weil jede zusätzliche Laufzeit eigene Bibliotheken, Sicherheitsupdates und Bereitschaftsdienste nach sich zieht.

Wie sprechen die Dienste miteinander?

Synchron über HTTP oder gRPC, wenn eine Antwort sofort gebraucht wird, und asynchron über einen Nachrichtenbroker wie Kafka oder RabbitMQ, wenn ein Ereignis nur weitergereicht werden muss. Je mehr asynchron läuft, desto weniger reißt der Ausfall eines Dienstes mit.

Persönlich für dich da