Microservices-Architektur — viele kleine Services, ein System

Microservices-Architektur — viele kleine Services, ein System

Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.

So lesen Sie diese Darstellung

• Lesen Sie zuerst die linke Spalte von oben nach unten: Clients zum Gateway zu den Services — das ist der Weg der Anfrage.
• Folgen Sie den Pfeilen aus jedem Service heraus: zum Message Bus, zur eigenen Datenbank und zur Observability.
• Die rechten Bahnen sind die gemeinsame Infrastruktur des Systems — Messaging, Daten und Observability —, und deshalb zeigt jeder Service in sie hinein.

Der Weg der Anfrage

„Web- und Mobile-Clients“ starten den Ablauf, und „API-Gateway leitet weiter und aggregiert“ ist der einzige Eingang — es leitet jede Anfrage an den richtigen Service weiter, übernimmt die Authentifizierung und setzt oft Antworten mehrerer Services zusammen. Das Gateway ist die eine Komponente, die jeder Client sieht, und steht deshalb zwischen der Client-Schicht und den Services.

Die Services

„Bestell-Service“, „Nutzer-Service“ und „Zahlungs-Service“ sind die unabhängig ausgerollten Einheiten. Jeder gehört einem eigenen Team und wird in eigenem Takt ausgeliefert. Die Darstellung verbindet jeden Service mit dem Message Bus — Services kommunizieren über Events statt über direkte Aufrufe — und mit seiner eigenen Datenbank, denn erst die Hoheit über die eigenen Daten macht einen Service unabhängig ausrollbar.

Die gemeinsame Infrastruktur

„Message Bus entkoppelt die Services“ erlaubt es einem Service, ein Event zu veröffentlichen, ohne zu wissen, wer es konsumiert. „Jeder Service hat seine eigene Datenbank“ ist die Regel, die eine Kopplung über gemeinsamen Zustand verhindert. „Metriken, Logs und Traces in einer Ansicht“ ist die Observability, die ein System aus vielen Services im Betrieb beherrschbar macht — ohne sie ist eine Störung über die Grenzen hinweg unsichtbar. Diese drei Bahnen sind der Preis und der Gewinn dieser Architektur.

Wichtige Zusammenhänge und Erkenntnisse

• Jeder Service ist unabhängig ausrollbar — die Eigenschaft, die alles andere in dieser Architektur schützen soll.
• Services kommunizieren über den Message Bus und halten ihre eigenen Datenbanken; gemeinsamer Zustand ist das Anti-Pattern.
• Das API-Gateway ist die einzige Eingangstür des Systems; Clients sprechen nie direkt mit den Services.
• Unabhängigkeit muss mit Observability bezahlt werden — viele Services sind nur beherrschbar, wenn eine Ansicht sie alle abdeckt.
• Microservices orchestrieren die Container, die Docker verpackt — die beiden Darstellungen hängen zusammen.

Wann Sie diese Darstellung nutzen

• Einem Team erklären, warum es Microservices gibt und worin die Abwägungen tatsächlich bestehen, bevor es sie einführt.
• Die Service-Grenzen, Message-Topics und Datenhoheit eines bestehenden Systems für die Einarbeitung dokumentieren.
• Auf die Anti-Pattern prüfen: eine gemeinsame Datenbank oder ein Service, der einen anderen direkt aufruft, ist ein Leck in der Grenze.

So funktioniert es

1. Benennen Sie die Services auf Ihr System um

   Ersetzen Sie Bestell-, Nutzer- und Zahlungs-Service durch Ihre tatsächlichen Services und ergänzen Sie die, die diese generischen drei auslassen — jeden als eigenen Kasten in der Bahn „Services“.

2. Benennen Sie Ihre Message-Topics

   Vermerken Sie am Message Bus die echten Events, die Ihre Services veröffentlichen und abonnieren, damit die Entkopplung konkret wird und nicht nur behauptet ist.

3. Halten Sie die Datenhoheit fest

   Notieren Sie an der Kante jedes Service zu seiner Datenbank den tatsächlichen Speicher (PostgreSQL, einen Cache, einen Suchindex) und was er hält, um zu prüfen, ob die Regel einer Datenbank pro Service trägt.

4. Ergänzen Sie die Fehler- und Skalierungszweige

   Fügen Sie die echten Pfade ein — den Retry und den Circuit Breaker eines Service am Bus, ein hochskaliertes Replikat eines stark belasteten Service —, jeweils mit einem ausdrücklichen Endzustand.

Häufig gestellte Fragen

Was ist eine Microservices-Architektur?

Es ist ein Architekturstil, bei dem eine Anwendung aus vielen kleinen Services besteht, von denen jeder für eine fachliche Fähigkeit zuständig ist, unabhängig ausgerollt wird und seine eigenen Daten hält. Die Services kommunizieren über das Netzwerk — typischerweise über HTTP und einen Message Bus — statt über gemeinsamen Speicher oder eine gemeinsame Datenbank. Der Gewinn sind unabhängige Auslieferbarkeit und Autonomie der Teams; die Kosten sind die Komplexität des Netzwerks und der Bedarf an Observability.

Warum hat jeder Microservice seine eigene Datenbank?

Weil gemeinsame Daten genau die Kopplung sind, die unabhängiges Ausrollen unmöglich macht. Lesen und schreiben zwei Services dieselbe Tabelle, können sie ihr Schema nicht ändern, nicht skalieren und nicht ausrollen, ohne sich abzustimmen. Erst die Hoheit über den eigenen Datenspeicher lässt einen Service in eigenem Takt wachsen und skalieren — die Regel, die die Bahn „Jeder Service hat seine eigene Datenbank“ in der Darstellung durchsetzt.

Welche Rolle spielt das API-Gateway bei Microservices?

Das Gateway ist der einzige Eingang des Systems. Es leitet Anfragen an den richtigen Service weiter, übernimmt übergreifende Aufgaben wie Authentifizierung und Rate Limiting und kann Antworten mehrerer Services zu einer zusammenfassen. Clients sprechen mit dem Gateway, nie direkt mit einzelnen Services — so bleibt die Topologie der Services dahinter frei veränderbar.

Wann sollten Sie Microservices NICHT einsetzen?

Wenn das System klein ist oder das Team klein ist. Microservices tauschen architektonische Komplexität — Netzwerkfehler, verteilte Transaktionen, Observability — gegen unabhängige Auslieferbarkeit, und dieser Tausch lohnt sich erst, wenn ein Team groß genug ist, dass die unabhängige Auslieferbarkeit die eigentliche Engstelle ist. Viele Teams lösen ihre Probleme mit einem gut modularisierten Monolithen, um den es in der Darstellung zur monolithischen Architektur geht.

Diese Darstellung in QueryChart (FlowJam) bearbeiten

Öffnen Sie genau diese Microservices-Zeichenfläche als eigenes Diagramm, benennen Sie die Services auf Ihr System um und zeichnen Sie Ihre echten Grenzen ein.

Diese Darstellung in QueryChart (FlowJam) bearbeiten