Microservices
Microservices ist eine Architektur wo du deine Software in viele kleine, unabhängige Services aufteilst - jeder macht eine spezifische Aufgabe.
Statt einer großen monolithischen Anwendung hast du viele kleine Programme die zusammenarbeiten.
Grundprinzip
Ein Microservice ist ein kleiner, autonomer Service der eine spezifische Business-Funktion erfüllt und unabhängig deployed werden kann.
Eigenschaften:
- Klein und fokussiert - Jeder Service macht genau eine Sache
- Unabhängig deploybar - Services können einzeln aktualisiert werden
- Eigene Datenbank - Jeder Service hat seine eigenen Daten
- Technologie-Unabhängigkeit - Verschiedene Services können verschiedene Technologien nutzen
- Kommunikation über APIs - Services sprechen über REST API oder Message Queues
Vergleich zu Monolithen
| Aspekt | Monolith | Microservices |
|---|---|---|
| Größe | Eine große Anwendung | Viele kleine Services |
| Deployment | Alles zusammen | Einzeln pro Service |
| Skalierung | Gesamte App | Nur benötigte Services |
| Technologie | Eine für alles | Verschiedene möglich |
| Komplexität | Einfach zu starten | Komplex zu orchestrieren |
Architektur-Beispiel
Statt einer App hast du:
- User-Service - Verwaltung von Nutzerdaten
- Product-Service - Produktkatalog
- Order-Service - Bestellungen
- Payment-Service - Zahlungsabwicklung
- Shipping-Service - Versand
Jeder kann unabhängig entwickelt, getestet und deployed werden.
Vorteile
- Skalierbarkeit - Nur stark genutzte Services skalieren
- Unabhängige Entwicklung - Teams arbeiten parallel
- Technologie-Freiheit - Bestes Tool für jeden Service
- Fehler-Isolierung - Ein Service-Ausfall stoppt nicht alles
- Schnellere Releases - Services können einzeln aktualisiert werden
Beispiel Skalierung:
Wenn zu Weihnachten viele bestellen, skalierst du nur Order-Service und Payment-Service - nicht das komplette System!
Nachteile
- Komplexe Kommunikation - Services müssen miteinander sprechen
- Verteiltes System - Schwerer zu debuggen
- Mehr Infrastruktur - Braucht Docker, Kubernetes, etc.
- Datenkonsistenz - Schwieriger wenn jeder Service eigene Datenbank hat
- Mehr Deployment-Aufwand - Viele Services = viel zu deployen
Service-Kommunikation
Synchrone Kommunikation
Service ruft anderen Service direkt auf - wartet auf Antwort.
User-Service → GET /products → Product-Service
Product-Service → Response mit Produkten → User-Service
Vorteile:
- Einfach zu verstehen
- Sofortiges Feedback
Nachteile:
- Services müssen verfügbar sein
- Kann langsam werden bei vielen Aufrufen
Asynchrone Kommunikation
Service sendet Nachricht - wartet nicht auf Antwort.
Message Queue (z.B. RabbitMQ, Kafka):
Order-Service → "Bestellung erstellt" → Message Queue
Payment-Service liest Nachricht → Verarbeitet Zahlung
Shipping-Service liest Nachricht → Bereitet Versand vor
Vorteile:
- Services müssen nicht gleichzeitig laufen
- Entkopplung
- Besser skalierbar
Nachteile:
- Komplexer zu entwickeln
- Eventual Consistency (Daten sind nicht sofort überall aktuell)
Service Discovery
Wie finden Services einander in einem dynamischen System?
Problem:
Services starten/stoppen dynamisch - IP-Adressen ändern sich.
Lösung:
- Service Registry - Zentrale Liste aller Services (z.B. Consul, Eureka)
- Services registrieren sich beim Start
- Services fragen Registry nach anderen Services
API Gateway
Einstiegspunkt für alle Client-Anfragen - verteilt Requests an richtige Services.
Funktionen:
- Routing - Leitet Anfragen an richtigen Service
- Authentifizierung - Prüft Zugriffsrechte zentral
- Rate Limiting - Schützt vor Überlastung
- Logging - Zentrale Protokollierung
Client → API Gateway → User-Service
→ Product-Service
→ Order-Service
Deployment
Container-Technologie
Microservices laufen meist in Docker-Containern, orchestriert durch Kubernetes.
- Jeder Service in eigenem Container
- Isoliert und portabel
- Einfaches Deployment
- Automatisches Deployment und Skalierung
- Self-Healing (startet abgestürzte Services neu)
- Load Balancing
Datenverwaltung
Database per Service Pattern
Jeder Microservice hat seine eigene Datenbank - kein Service greift direkt auf Daten anderer Services zu.
Vorteile:
- Services sind wirklich unabhängig
- Verschiedene Datenbank-Typen pro Service möglich
- Keine Kopplungen
Herausforderungen:
- Datenbank-übergreifende Transaktionen schwierig
- Daten-Duplikation manchmal nötig
- Eventual Consistency statt sofortiger Konsistenz
Testen von Microservices
Test-Pyramide für Microservices:
- Unit Tests - Teste einzelne Funktionen
- Integrationstests - Teste Service mit seiner Datenbank
- Contract Tests - Teste API-Verträge zwischen Services
- End-to-End Tests - Teste gesamten Workflow
End-to-End-Tests sind aufwändig wenn alle Services laufen müssen - nutze Service Mocks wo möglich!
Monitoring und Observability
Bei verteilten Systemen ist Monitoring kritisch!
Was monitoren:
- Service Health - Läuft der Service?
- Response Times - Wie schnell antwortet er?
- Error Rates - Wie viele Fehler?
- Dependencies - Welche Services sind betroffen wenn einer ausfällt?
Tools:
- Prometheus - Metriken sammeln
- Grafana - Visualisierung
- Jaeger/Zipkin - Distributed Tracing (verfolge Request durch alle Services)
- ELK Stack - Log-Aggregation
Wann Microservices nutzen?
- Große, komplexe Anwendungen
- Viele Teams arbeiten parallel
- Verschiedene Skalierungsanforderungen
- Langfristige Projekte
- Wenn schnelle Releases wichtig sind
- Kleine Projekte mit 1-2 Entwicklern
- Projekte wo einfache Architektur ausreicht
- Wenn du keine Container/Orchestrierung-Expertise hast
- Startup-MVPs (Minimum Viable Products)
Prüfungsrelevanz AP2
- Vorteile/Nachteile kennen
- Unterschied zu Monolith erklären können
- Kommunikationsmuster (synchron/asynchron)
- Wann einsetzen, wann nicht
- Service Discovery und API Gateway Konzepte
Verwandte Konzepte
- MVC - Architektur-Pattern
- REST API - Kommunikation zwischen Services
- Docker - Container-Technologie
- Kubernetes - Orchestrierung
- API Gateway - Einstiegspunkt
- Load Balancing - Lastverteilung
- Cloud - Microservices laufen oft in Cloud
Zusammenfassung
Microservices teilen große Anwendungen in viele kleine, unabhängige Services auf - jeder Service macht eine spezifische Aufgabe und kann unabhängig entwickelt, deployed und skaliert werden.
Trade-off:
Mehr Flexibilität und Skalierbarkeit, aber auch mehr Komplexität in Kommunikation und Deployment.