Circuit Breaker und Retrays

Circuit Breaker und Retrays

1) Warum es notwendig ist

Netzwerke sind unzuverlässig: Latenz pulsiert, Knoten fallen, Grenzen werden erreicht. Retrays retten vor kurzfristigen Ausfällen und Circuit Breaker schützt das System vor kaskadierenden Ausfällen und „Selbst-DDoS“. Die Kombination mit den richtigen Timeouts und Limits spart SLO, stabilisiert Schwanzverzögerungen und den Preis der Neunen.

2) Grundprinzipien

Erst Timeouts, dann Retrays, dann Circuit Breaker.
Retraim nur idempotente Operationen (GET, sichere POST/PUT mit einem idempotenten Schlüssel).
Weisen Sie ein Retraybudget zu: ≤ 10-15% des ursprünglichen RPS pro Route.
Lokalisiere den Fehler: bulkhead (getrennte Pools/Kontingente) + rate-limit.
Bei Degradation - schneller Ausfall (fail-fast), graceful-degradation/stub.

3) Die Semantik der Retrays

Wann retratieren

Transiente Fehler: Timeouts, 5xx, Netzwerk nicht verfügbar, 429 (nach 'Retry-After').
Sie können nicht zurücktreten: offensichtliche Geschäftsfehler (4xx ≠ 429), Seiteneffekte ohne Idempotenz (Zahlung ohne Schlüssel).

Strategien

Exponentieller Backoff + Jitter (vollständig oder gleichmäßig): Glättet die Rückzugsräume.
Max attempts: 1-2 (selten 3) - mehr ist in der Regel schädlich.
Budget: Globaler Retrace/sec-Zähler pro Dienst und per-request „retry tokens“.
Hedging (selten): Paralleles Abfragen-Double nach t-Quantil (p95) - nur für streng idempotente Lesungen.

python base = 100 # ms for attempt in range(1, max_attempts+1):
try:
return call()
except Transient as e:
if attempt == max_attempts: raise sleep_ms = min(cap_ms, base 2(attempt-1))
sleep(random(0, sleep_ms)) # full jitter

4) Zeiträume und „schnelle Ablehnung“

Client-Timeout <Upstream-Timeout: um keine „Zombie“ -Anfragen zu horten.
Делите: connect timeout, read timeout, overall deadline.
Tail-aware Timeouts: Ziel in p95/p99 + kleiner Vorrat.
Verwenden Sie ein gemeinsames Terminfeld (z.B. gRPC 'deadline') und streichen Sie es die Kette hinunter.

5) Circuit Breaker: Wie es funktioniert

• Geschlossen: überspringt den Verkehr, zählt Fehler/Latenz.
• Öffnen: Gibt sofort eine schnelle Ablehnung (oder eine Ersatzantwort) ab.
• Half-Open: Prüfanforderungen; Bei Erfolg schließt er.

• Die Fehler/Timeouts überschreiten den Anteil von X% pro Fenster N Anfragen/Sekunden oder p99 über dem Schwellenwert.
• Rollierende Statistiken und Mindestvolumen (z. B. ≥ 50 Anfragen) sind relevant.

6) Bulkhead, Quoten und „teile und herrsche“

Getrennte Pools von Per-Upstream- und Per-Fich-Verbindungen.
Quoten für In-Flight-Anfragen; überflüssig - schnelle Ablehnung.
Bei Mangel - Degradation von Fich mit niedriger Priorität (Feature Flags).

7) Integration mit Perimeter (Envoy/Istio/Nginx)

yaml routes:
- match: { prefix: "/api" }
route:
cluster: upstream_api timeout: 2s retry_policy:
retry_on: "connect-failure,reset,retriable-4xx,5xx"
num_retries: 2 per_try_timeout: 600ms retry_back_off: { base_interval: 100ms, max_interval: 800ms }
hedge_policy:
hedge_on_per_try_timeout: true initial_requests: 1 additional_request_chance: { numerator: 5, denominator: HUNDRED } # 5%
clusters:
- name: upstream_api circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 500 max_requests: 1000 max_retries: 200 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService spec:
hosts: ["payments"]
http:
- route: [{ destination: { host: payments } }]
timeout: 2s retries:
attempts: 2 perTryTimeout: 600ms retryOn: "5xx,connect-failure,refused-stream,reset"

yaml nginx. ingress. kubernetes. io/proxy-connect-timeout: "2"
nginx. ingress. kubernetes. io/proxy-read-timeout: "2"
nginx. ingress. kubernetes. io/proxy-next-upstream: "error timeout http_502 http_503 http_504"
nginx. ingress. kubernetes. io/proxy-next-upstream-tries: "2"

8) Bibliotheken und Code (Stapel-Snippets)

java var cb = CircuitBreaker. ofDefaults("psp");
var retry = Retry. of("psp-retry",
RetryConfig. custom()
.maxAttempts(2)
.waitDuration(Duration. ofMillis(200))
.intervalFunction(IntervalFunction. ofExponentialRandomBackoff(100, 2. 0, 0. 5) )//jitter
.retryExceptions(SocketTimeoutException. class, IOException. class)
.build());

Supplier<Response> decorated =
CircuitBreaker. decorateSupplier(cb,
Retry. decorateSupplier(retry, () -> client. call()));

return Try. ofSupplier(decorated)
.recover(BusinessException. class, fallback())
.get();

go ctx, cancel:= context. WithTimeout(context. Background(), 2time. Second)
defer cancel()
var lastErr error for i:= 0; i < 2; i++ {
reqCtx, stop:= context. WithTimeout(ctx, 600time. Millisecond)
lastErr = call(reqCtx)
stop()
if lastErr == nil { break }
sleep:= time. Duration(rand. Intn(1<<uint(7+i))) time. Millisecond // full jitter time. Sleep(min(sleep, 800time. Millisecond))
}
if lastErr!= nil { return fastFail() }

js import pRetry from 'p-retry';
await pRetry(() => got(url, { timeout: { connect: 500, request: 2000 } }), {
retries: 2,
factor: 2,
randomize: true,
minTimeout: 100,
maxTimeout: 800,
onFailedAttempt: e => { if (isBusiness(e)) throw e; }
});

9) Retray- und SLO-Budget

Retry-Token eingeben: Jedes Retray gibt ein Token aus; Pool ist begrenzt.
Verknüpfung mit Fehlerbudget: bei Burn-Rate über Schwelle - Retrays ausschalten, CB öfter öffnen, Degradation einschalten.
Kanarienreleases: Auf Kanaren Versuche und Token reduzieren.

10) Hedging (Vorsicht)

Führen Sie eine zusätzliche Abfrage nach p95-Deadline durch, indem Sie den Verlierer stornieren.
Nur für Lesungen und „sichere“ idempotente Operationen; Begrenzen Sie den Anteil (≤ 1-5%).
Beobachten Sie die steigende Upstream-Belastung.

11) Beobachtbarkeit

RED-Metriken für Routen: Rate, Fehler, Dauer (p50/p95/p99).
CB-Metriken: Status (open/half-open), Öffnungshäufigkeit, fehlende/verweigerte Anfragen.
Retrays: attempts/request, retry-rate, verbrannte Token.
Perimeter: outlier-ejection, ejection-rate.
Traces: Beschriften Sie' retry _ attempt', 'cb _ state', 'hedged = true', streichen Sie' trace _ id'.

12) Integration mit der Architektur

Bulkhead + CB für jeden kritischen Upstream.
Warteschlangen/Asynchron: für lange Operationen statt verrückter Timeouts.
Cache/Stubs: für nicht-kritische Fich bei Fail-Open.
Auto-Scale: kompensiert keine schlechten Retrays - stoppen Sie zuerst den „Sturm“.

13) Anti-Muster

Retrays ohne Timeouts → „schwebende“ Verbindungen und Erschöpfung von Pools.
Wiederholung nicht-idempotenter Transaktionen (doppelte Abschreibungen).
Endloses exponentielles Wachstum ohne Cap und Jitter.
Eine einzige CB für alle Upstreams → Drag-and-Drop-Fehler für das gesamte Produkt.
429/' Retry-After 'ignoriert.
Der Timeout des Kunden ist länger als der des Upstreams (oder gar nicht).
„Behandeln“ Sie Geschäftsfehler mit Retrays.

14) Implementierung Checkliste (0-30 Tage)

0-7 Tage

Identifizieren Sie Routen und deren Idempotenz.
Stellen Sie die Timeouts (connect/read/overall) ein, aktivieren Sie die minimalen Retrays (× 1) und die Standard-CB.
Teilen Sie Pools/Kontingente (Bulkhead) für die wichtigsten Upstreams.

8-20 Tage

Aktivieren Sie Jitter und das globale Budget von Retrays, Alerts von Retry-Rate.
Konfigurieren Sie die Outlier-Ejection am Perimeter, eine schnelle Ablehnung für Low-Prio-Fit.
RED + CB/Retry Dashboards, Trails mit Tags.

21-30 Tage

Kanarische Profile von Retrays (weniger Versuche), Game-Day „Upstream Slow/Flaps“.
Dokumentieren Sie die Politik: wer/was retrait, Grenzen, Ausnahmen.
Überprüfen Sie p95/p99 und Timeouts nach Daten, nicht nach Auge.

15) Reifegradkennzahlen

100% der Routen haben Timeouts und eine dokumentierte Rückzugs-/SV-Politik.
Retry-Rate passt in das Budget (≤ 10-15%), es gibt keine Spitzen bei Vorfällen.
CBs werden ausgelöst, bevor der gesamte Pool fällt; keine kaskadierten Fehler.
Traces zeigen Versuche/Hedging; p99 ist bei Peaks stabil.
Kanarische Releases verwenden ein „vorsichtiges“ Profil von Retrays.

16) Kurze Beispiele für Konfigurationen

yaml resilience4j:
circuitbreaker:
instances:
psp:
slidingWindowType: COUNT_BASED slidingWindowSize: 100 minimumNumberOfCalls: 50 failureRateThreshold: 50 waitDurationInOpenState: 30s permittedNumberOfCallsInHalfOpenState: 5 retry:
instances:
psp:
maxAttempts: 2 waitDuration: 200ms enableExponentialBackoff: true exponentialBackoffMultiplier: 2. 0 retryExceptions:
- java. net. SocketTimeoutException
- java. io. IOException

yaml rate_limits:
- actions:
- generic_key: { descriptor_value: "api. payments" }

17) Fazit

Nachhaltigkeit ist Disziplin: Timeouts → Retrays (mit Jitter und Budget) → Circuit Breaker + Bulkhead/Quoten und schneller Verzicht. Konfigurieren Sie den Perimeter (outlier-ejection), hängen Sie die RED/CB/Retry Dashboards auf, fixieren Sie die Idempotence Policy und vergessen Sie nicht den Business SLI. Dann bleiben kurze Abstürze unsichtbar, und echte Vorfälle werden nicht zu kaskadierenden Stürzen.