Begriff

Dapr (Distributed Application Runtime)

Microservices Architecture S3

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Microservices haben immer die gleichen Probleme: "Wie rede ich mit Service B?" "Wie speichere ich Zustand?" "Wie verschlüssele ich Secrets?" Jeder Entwickler erfindet das Rad neu (in Java, in Go, in Python...). Dapr ist ein Werkzeugkoffer ("Sidecar"), der das für dich macht. Du rufst Dapr an: "Hey, speichere 'Hund' in der Datenbank!" Dapr speichert es. Egal ob Redis, CosmosDB oder SQL dahinter steckt. Du änderst nur eine Config-Datei, nicht deinen Code. Dapr macht deine App unabhängig von der Infrastruktur.

Merksatz: Eine portable, ereignisgesteuerte Laufzeitumgebung, die Entwicklern hilft, widerstandsfähige, zustandslose und zustandsbehaftete Microservices zu erstellen.

Das Sidecar-Pattern. Deine App läuft auf Port 3000. Dapr läuft auf Port 3500. Um Service B aufzurufen, machst du einen POST an loalhost:3500/v1.0/invoke/service-b/method/hello. Dapr kümmert sich um:

Service Discovery (Wo ist B?).
mTLS (Verschlüsselung).
Retries (Wenn B kurz weg ist).
Tracing (Für Jaeger).

1. Das Actor Model und Concurrency Control

Eines der stärksten Module in Dapr ist das integrierte Actor Model (inspiriert von Orleans / Akka). Ein Actor ist eine isolierte Code-Instanz (z. B. ein IoT-Device oder ein Warenkorb) kombiniert mit exklusivem State. Der Dapr-Sidecar garantiert, dass zu einem Zeitpunkt immer nur ein einziger Thread auf diesen Actor zugreift (Turn-based Concurrency). Skaliert man die Architektur in Kubernetes auf 50 Pods hoch, regelt der Dapr-Placement-Service, auf welchem Pod der "Kunde_123"-Actor gerade liegt. Will Pod A und Pod B gleichzeitig auf Kunde 123 zugreifen, schleust Dapr alle TCP-Requests durch eine Queue direkt zum exklusiven Actor-Host. Race-Conditions auf Datenbank-Ebene (Lost Updates) sind dadurch konzeptionell brutal unterbunden.

2. Pluggable Component Architecture und gRPC

Während der Entwickler primitive REST-Calls (POST /v1.0/state/statestore) an seinen Lokalen Sidecar funkt, passiert im Hintergrund hochperformantes Engineering. Die Kommunikation zwischen den Dapr-Sidecars quer über das Cluster verläuft obligatorisch per gRPC (HTTP/2 mit Protobuf-Streaming). Die Komponenten (z. B. der Binding-Adapter zu Kafka oder Azure Service Bus) sind in Go kompiliert und greifen per Interface an. Ein Umzug von AWS SQS zu GCP PubSub erfordert exakt Null Code-Änderungen in der Python-Businesslogik. Lediglich das YAML-Manifest der Komponente wird angepasst. Dapr abstrahiert die Retry-Loops, Circuit-Breaker und At-Least-Once-Delivery Semantiken des Brokers komplett ins Control-Plane.

3. Resiliency Policies als Coderettung

Seit Dapr v1.7 nutzt man Resiliency Policies, die tief in die Runtime eingreifen. Ein traditioneller HTTP-Call in Java crasht bei einem Timeout. In Dapr konfiguriert man eine Policy: maxRetries: 5, timeout: 5s, circuitBreaker: maxRequests 10. Wenn der Zielservice (Dapr to Dapr) oder die Datenbank stottert, fängt das Sidecar den Fehler, rechnet einen Exponential Backoff aus, und versucht es transparent erneut. Der anrufende Java-Code blockt in dieser Zeit einfach. Das entlastet die Sprache enorm von Bibliotheken wie Resilience4j.

Quick-Check

Von wem?
Microsoft. Aber Open Source (CNCF).
Performance-Killer?
Kaum. Dapr ist in Go geschrieben und extrem schnell. Der Overhead ist minimal (< 1ms).
Brauche ich Kubernetes?
Nein! Dapr läuft überall. Auch auf deinem Laptop oder einer VM. Aber in K8s fühlt es sich am wohlsten.