Begriff
Circuit Breaker
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.
Wie die Sicherung in deinem Stromkasten. Wenn der Toaster kurzschließt und zu viel Strom zieht, brennt nicht das Haus ab. Die Sicherung "fliegt raus" (Stromkreis unterbrochen). In Software: Service A ruft Service B. Service B ist langsam oder tot. Service A wartet und wartet... und stürzt selbst ab (weil alle Threads warten). Ein Circuit Breaker überwacht die Fehler. "Oha, 5 Fehler in Folge bei Service B!" Er öffnet den Stromkreis. Ab jetzt werden alle Anfragen an B sofort abgelehnt ("Service B ist down"), ohne zu warten. A überlebt. Nach einer Weile prüft er vorsichtig ("Half-Open"), ob B wieder lebt.
Merksatz: Ein Stabilitäts-Muster, das verhindert, dass ein System wiederholt versucht, einen ausgefallenen Dienst aufzurufen, um Kaskadeneffekte zu vermeiden.
Bibliotheken wie Resilience4j (Java) oder Polly (.NET). Istio hat es eingebaut (Mesh-Level). Wichtig: Fallback. Wenn die Sicherung raus ist (Service B "Empfehlungen" weg), zeige dem User nicht "Fehler 500". Zeige stattdessen eine leere Liste oder Standard-Empfehlungen ("Bestseller"). Das nennt man Graceful Degradation.
1. Zustände
- Closed: Alles ok. Strom fließt.
- Open: Fehler-Limit erreicht. Anfragen werden sofort geblockt (Fail Fast).
- Half-Open: Timeout vorbei. Der Breaker lässt eine Test-Anfrage durch.
- Erfolg -> Reset auf Closed.
- Fehler -> Zurück auf Open (Timer neu starten).
2. Bulkhead Pattern
Verwandt. Wie Schotten in einem Schiff. Wenn eine Kammer volläuft (Service B langsam), darf das Schiff nicht sinken. Man begrenzt die Ressourcen pro Service ("Maximal 10 Threads für Service B"). Circuit Breaker und Bulkheads nutzt man oft zusammen.
1. Sliding Window Metrics & State Machines
Um das Brechen einer Sicherung stochastisch zuverlässig zu triggern, betreiben Profi-Libs (wie Resilience4j) keinen simplen integer Counter. Sie nutzen Ring-Buffer oder Sliding Time Windows.
Der Breaker füllt ein Zeitfenster (z.B. die letzten 100 Call-Ergebnisse). Fällt in der Metrik die failureRateThreshold auf über 50% und mind. 20 Anrufe wurden registriert (minimumNumberOfCalls), kickt die State Machine sofort in Open. Um transiente Netzwerk-"Glitches" auszublenden, tolerieren Breaker als Failure oft nur gnadenlose "Timeouts" oder HTTP 500. HTTP 404 Not Found ist beispielsweise ein deterministischer Business-Error; der Circuit bleibt hier richtigerweise stumm und misst diesen Request als Erfolg (Success).
2. Service Mesh Integration und Outlier Detection
Das Coden von @CircuitBreaker Annotations in jede Java-Microservice Methode bindet Logik hart an die Softwarearchitektur.
Moderne Infrastrukturen verlagern Pattern ins Control Plane eines Service Mesh (Istio / Linkerd / Consul). Envoy-Proxies sitzen als Sidecar direkt am Pod. Bevor der ausgehende Paket-Request das Netzwerk berührt, interceptiert der Sidecar. Sinkt der Health-Status des Zielpunkts im Mesh, öffnet Istio die Sicherung mittels Outlier Detection (Traffic wird auf Netzwerkebene schlicht mit HTTP 503 beantwortet). Die Applikation meint, einen Call zu machen, dieser verlässt aber physisch niemals den eigenen Knoten – CPU-Zyklen sind massiv gerettet.
3. Das Thundering Herd Problem (Half-Open Cautiousness)
Der gefährlichste Moment des Circuit Breaker Paradigmas ist das Zurücksetzten.
Ist die Sicherung zu (Open) und der Sleep-Window Timer (z.B. 30 Sekunden) abgelaufen, geht der Breaker in Half-Open.
Wenn Tausende paralleler Threads exakt jetzt erwachen, rollen sie wie eine Stampede (Thundering Herd) über den noch fragilen Ziel-Service hinweg und töten ihn im Bruchteil einer Sekunde wieder ab. In der Implementierung darf der Breaker strikt nur permittedNumberOfCallsInHalfOpenState = 3 Threads durch die Lücke schleichen lassen. Sind diese Tester "grün", klickt der Mechanismus in Closed zurück und erst dann öffnet er das Tor für die restliche Masse.
Quick-Check
Warum nicht einfach Retries?
Retries ("Versuch's nochmal") machen das Problem schlimmer. Wenn Service B überlastet ist, und 1000 Clients machen Retries, trittst du ihn tot ("Retry Storm"). Circuit Breaker gibt ihm eine Pause zum Erholen.Ist das Client-Side oder Server-Side?
Meistens Client-Side (der Aufrufer schützt sich selbst). Aber mit Service Mesh (Sidecar) passiert es in der Infrastruktur dazwischen.Wer setzt ihn zurück?
Er macht das automatisch nach einer Zeit (Reset Timeout). Kein Mensch muss zum Sicherungskasten laufen.