Microservices Architektur
Dieser Beitrag ist eine Begriffserklärung zu Microservices – inklusive Prüfungsfragen und Tags.
In a Nutshell
Microservices sind kleine, eigenständig deploybare Dienste mit klar abgegrenzter Fachverantwortung. Jeder Dienst kapselt seine Daten und kommuniziert über wohldefinierte Schnittstellen.
Kompakte Fachbeschreibung
In der Microservices Architektur wird ein System in fachlich geschnittene Dienste aufgeteilt, oft entlang eines Bounded Context aus DDD. Jeder Dienst besitzt sein eigenes Datenmodell und seinen eigenen Persistenzspeicher. Kommunikation erfolgt bevorzugt asynchron über Events, für synchronen Bedarf über schlanke APIs wie REST oder gRPC. Deployments sind unabhängig, Continuous Delivery ermöglicht schnelle Inkremente. Konsistenz ist meist eventual, über Sagas werden verteilte Transaktionen koordiniert. Beobachtbarkeit ist Pflicht: strukturierte Logs, Metriken, Traces und Korrelations-IDs sind nötig, um verteilte Aufrufe zu verfolgen.
Prüfungsrelevante Stichpunkte
- Schnitt entlang Fachdomäne, pro Dienst ein Bounded Context, Daten pro Service, kein Shared Schema
- Kommunikationsstile: asynchrones Messaging für Entkopplung, synchron sparsam einsetzen
- Datenkonsistenz: Sagas, Outbox, Inbox, idempotente Verarbeitung, genau einmal Semantik
- Qualitätsziele benennen: Änderbarkeit, Verfügbarkeit, Sicherheit, Nachvollziehbarkeit (SLOs)
- Unabhängige Repos, Build, Test, Deploy pro Service, Consumer Driven Contract Tests
- Sicherheitsaspekt: mTLS, OAuth 2/OIDC, Secrets Management, Policy Enforcement, Rate Limiting
- Wirtschaftlichkeit: Team Autonomie, parallele Entwicklung, Skalierung pro Hotspot, höherer Betriebsaufwand
- Dokumentationspflicht: C4 Modell Level 1-3, Schnittstellenverträge, ADRs, Betriebsführung, Notfallkonzept
Kernkomponenten
- Fachlicher Schnitt, Bounded Context je Service
- API Design: Ressourcen oder RPC, Versionierung, Abwärtskompatibilität
- Daten pro Service: eigenständige Persistenz, Migrationsstrategie
- Kommunikationsschicht: Message Broker, Queue, Stream, Request-Response
- Service Discovery und Routing: API Gateway, Ingress
- Resilienz: Circuit Breaker, Timeouts, Retries mit Backoff, Bulkheads
- Observability: Logs, Metriken, Tracing, Korrelations-ID
- Deployment und Infrastruktur: Container, Orchestrierung, IaC, CI/CD
- Sicherheit: mTLS, AuthN/AuthZ, Secrets Management, Audit Logging
- Testverfahren: Unit, Integration, Contract Tests, Chaos Engineering, Lasttests
Praxisbeispiel
// Saga, Orchestriert: Bestellprozess mit Order Service, Payment Service, Inventory Service
POST order/create { customerId: 42, items: [{ sku: "A1", qty: 2 }] }
Order Service speichert Order status: pending, erzeugt Event: order.created (outbox)
Orchestrator empfängt order.created, ruft Payment Service:
POST payments mit Idempotency Key: ord-42
Payment Service autorisiert Betrag, publiziert Event: payment.authorized
Orchestrator ruft Inventory Service:
POST reservations { orderId: 42, items: ... }
Inventory reserviert Artikel, publiziert Event: inventory.reserved
Orchestrator setzt Order auf status: confirmed, publiziert order.confirmed
Kompensation bei inventory.reservation.failed:
- Ruft Payment Service: POST payments/refund
- Setzt Order auf cancelled
Vorteile und Nachteile
Vorteile
- Unabhängige Deployments, schnellere Änderungen
- Gezielte Skalierung, bessere Fehlereingrenzung
- Technologievielfalt pro Service, klare Verantwortlichkeiten
- Team-Autonomie, parallele Entwicklung
Nachteile
- Höhere Komplexität im Betrieb
- Verteilte Fehlersuche, Netzwerkfehler und Latenzen
- Datenkonsistenz muss explizit modelliert werden
- Anspruchsvolle Observability und Security
- Risiko eines Verteilten Monolithen
Typische Prüfungsfragen (mit Kurzantwort)
- Fachlicher Schnitt für Microservices? Entlang eines Bounded Context mit klarer Ubiquitous Language, minimale Kopplung, maximale Kohäsion.
- Verteilte Transaktionen ohne Two Phase Commit? Über Saga mit Orchestrierung/Choreografie, idempotente Kompensationsschritte, Outbox-Pattern.
- Problem synchrone Kettenaufrufe? Verstärken Latenzen/Ausfälle, Kaskadeneffekte, verringern Autonomie. Gegenmittel: asynchrone Events, Circuit Breaker.
- Daten pro Service in der Praxis? Jeder Service besitzt eigenes Persistenzschema, versteckt es hinter API, Integrationen über Events/APIs.
- Rolle API Gateway? Zentraler Eintrittspunkt: Routing, Authentisierung, Rate Limits, Observability, Protokollübersetzung.
- Nachvollziehbarkeit über Service Grenzen? Korrelations-IDs, verteiltes Tracing, strukturierte Logs, konsistente Propagation über alle Aufrufe.
- Wann wirtschaftlich sinnvoll? Bei größeren Teams und komplexen Domänen, wenn unabhängige Deployments den Betriebsaufwand rechtfertigen.
- Konsistenz vs. Verfügbarkeit bei CAP? meist höhere Verfügbarkeit mit eventual consistency, lokale Invarianten strikt, globale über Sagas.