Microservices-Architektur: Design, Kommunikation und Bereitstellung

Was sind Microservices?

Microservices ist ein architektonischer Ansatz, der eine einzelne große Anwendung (Monolith) in kleine, unabhängige, deploybare Services aufteilt.

Jeder Service implementiert eine spezifische Geschäftslogik (Business Capability). User Service, Order Service, Payment Service usw.

Unabhängiges Deploy: Jeder Service kann unabhängig deployt werden. Änderungen in einem Service beeinflussen andere Services nicht.

Technologievielfalt: Jeder Service kann unterschiedlichen Technologie-Stack verwenden. Node.js, Python, Go, Java können im selben System zusammenarbeiten.

Inter-Service-Kommunikation

Synchron: Direkte Kommunikation via REST API oder gRPC. Einfach, aber erzeugt Kopplung (Abhängigkeit).

Asynchron: Event-getriebene Kommunikation via Message Queue (RabbitMQ, Kafka, SQS). Bietet lose Kopplung.

API Gateway: Einziger Einstiegspunkt für alle Services. Führt Routing, Authentication, Rate Limiting, Load Balancing durch.

Service Mesh: Infrastrukturschicht zur Verwaltung der Inter-Service-Kommunikation. Tools wie Istio, Linkerd bieten Traffic Management, Observability, Security.

Circuit Breaker: Verhindert Cascade Failure bei Service-Ausfällen. Implementiert mit Hystrix oder resilience4j.

Datenverwaltung

Database per Service: Jeder Service hat seine eigene Datenbank. Dies bewahrt die Service-Unabhängigkeit.

Event Sourcing: Zustandsänderungen als Events speichern. Zustand kann aus Event Store rekonstruiert werden.

CQRS (Command Query Responsibility Segregation): Lese- und Schreiboperationen trennen. Unterschiedliche Datenmodelle und Optimierungen verwenden.

Saga Pattern: Verteilte Transaktionen verwalten. Via Choreography (event-basiert) oder Orchestration (zentraler Koordinator).

Datenkonsistenz: Eventual Consistency akzeptieren. Eventual Consistency ist in Microservices praktischer als Strong Consistency.

Bereitstellung und Skalierung

Containerization: Jeden Service als Docker-Container verpacken. Mit Kubernetes orchestrieren.

Auto-Scaling: Automatische Skalierung basierend auf Service-Last. Kubernetes HPA (Horizontal Pod Autoscaler) verwenden.

Service Discovery: Services finden sich dynamisch. Consul, Eureka oder Kubernetes DNS verwenden.

Load Balancing: Last zwischen Service-Instances verteilen. Round-robin, Least Connections oder Consistent Hashing Algorithmen.

Blue-Green Deployment: Zero-Downtime Deploy. Neue Version in paralleler Umgebung ausführen, Traffic umleiten.

Überwachung und Observability

Distributed Tracing: Anfragen über Services hinweg verfolgen. Jaeger, Zipkin oder OpenTelemetry verwenden.

Centralized Logging: Alle Service-Logs an zentralem Ort (ELK Stack, Loki) sammeln. Anfragen mit Correlation ID verfolgen.

Metrics: Service-Metriken sammeln (Prometheus) und visualisieren (Grafana). Latency, Error Rate, Throughput überwachen.

Health Checks: Jeder Service sollte Health Endpoint (/health) bereitstellen. Mit Kubernetes Liveness und Readiness Probes integrieren.

Alerting: Alert-Regeln für kritische Metriken definieren. On-Call-Management mit PagerDuty oder Opsgenie.

Microservices Anti-Patterns

Distributed Monolith: Services sind eng gekoppelt (tight coupling). Änderungen sind schwierig. Unabhängiges Deploy unmöglich.

Shared Database: Alle Services nutzen dieselbe Datenbank. Dies eliminiert Service-Unabhängigkeit.

Chatty Services: Zu viele Netzwerkaufrufe zwischen Services. Latenz steigt, Leistung sinkt.

Nano-Services: Services zu klein. Overhead (Netzwerk, Serialisierung) übersteigt Nutzen.

Premature Optimization: Zu Microservices wechseln, ohne mit Monolith zu beginnen. Zuerst mit Monolith beginnen, bei Bedarf aufteilen.