Microservices-Architektur · Mindmaps

Microservices-Architektur · Mindmaps

Die interaktive MindMap-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 Mindmap

• Beginnen Sie beim Thema in der Mitte und folgen Sie einem farbigen Zweig zu den zugehörigen Ideen.
• Geschwungene Linien zeigen Beziehungen; Pfeile stehen nur dort, wo die Richtung wichtig ist.

Clients & gateway

Dieser Zweig verbindet “Web and mobile clients”, “The gateway is the single entry point: it routes each request to the right service, handles authentication and often aggregates responses from several services.”.

Independent services

Dieser Zweig verbindet “Orders service”, “Payments service”, “Teams deploy and scale services independently”, “Users service”.

Messaging

Dieser Zweig verbindet “Services communicate by publishing events rather than calling each other directly — so one service's change or outage never blocks another.”.

Owned data

Dieser Zweig verbindet “The defining rule of microservices: no shared schema. Each service's data is private to it, which is what allows teams to deploy independently.”.

Observability

Dieser Zweig verbindet “Metrics, logs and traces feed one view”.

Verbindungen zwischen den Zweigen

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.

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. Mittleres Thema anpassen

   Benennen Sie das Thema für Ihr Projekt oder Ihren Unterricht um.

2. Zweige ausbauen

   Bearbeiten Sie Ideen und ergänzen Sie Beispiele oder Notizen.

3. Ideen verbinden

   Zeichnen Sie Verbindungen zwischen Zweigen; Pfeile zeigen eine wichtige Richtung an.

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 Mindmap in QueryChart bearbeiten

Öffnen Sie die Mindmap auf einer bearbeitbaren Leinwand. Verschieben Sie Ideen und ergänzen Sie Zweige und Verbindungen.

Diese Mindmap in QueryChart bearbeiten