Întrerupător de circuit și degradare

Circuit Breaker (CB) este un model de securitate care întrerupe apelurile la o dependență degradată pentru a localiza eșecul și pentru a proteja serviciile din amonte și utilizatorul. Degradarea (degradarea grațioasă) - simplificarea deliberată a funcționalității în caz de lipsă de resurse sau eșecuri (de exemplu, returnarea datelor cache/incomplete, dezactivarea caracteristicilor „scumpe”) fără întreruperi complete.

Scopul principal: de a păstra SLO și experiența utilizatorului prin eșecuri controlate, în loc de picături în cascadă.

1) Când se aplică

Dependența este instabilă: p95/p99 creștere, timeout, răspunsuri eronate.
API-uri externe cu limite/sancțiuni stricte.
„Grele” backends (căutare, recomandări, rapoarte), în cazul în care retroproiecte intensifica furtuna.
Zone foarte încărcate, cu risc de epuizare a bazinelor (conexiuni, fire).

2) stările și tranzițiile CB

1. Închis - traficul merge, măsurătorile de eroare/latență sunt numărate.

2. Open - apelurile sunt respinse instantaneu (fail-fast) și/sau transferate în rezervă.

3. Half-Open - Un număr limitat de cereri „trial” determină dacă să închidă comutatorul.

Declanșatoare de deschidere

Pragul de eroare/timeout pe fereastră (de exemplu, ≥ 50% din ultimul N).
Prag de latență (ex. p95> țintă).
Politici combinate (erori ∧ termene depășite).

Timp de așteptare (cool-down)

Fixat (de exemplu, 10-60 secunde) sau adaptiv (creștere exponențială cu acționări repetate).

3) Timeouts, retrageri și jitter

Timeout-urile sunt întotdeauna mai scurte decât SLO-urile din amonte și sunt propagare cu termen limită.
Retrai numai pentru operațiuni idempotente; 1-2 încercări sunt suficiente în cele mai multe cazuri.
Backoff + jitter (jitter complet) previne undele sincrone de repetiții.
Acoperirea (cereri de rezervă) - economică și numai pentru citiri foarte critice.

4) Izolarea pereților etanși și „siguranțe”

Piscine separate de conexiune/lucrător/coadă după domeniu și tip de trafic (VIP, sarcini de fundal, API-uri publice).
Capace pe concurență pentru operațiuni „scumpe”.
Controlul admiterii: eșec ușor înainte de execuție atunci când coada este plină.

5) Scenarii de rezervă și degradare

Opțiuni

Răspunsuri cache/stil: 'stale-while-revalidate', returnarea datelor din memoria cache L2/L3.
Read-only: bloc de scriere/comenzi, permite citiri sigure.
Răspunsurile surogat: date incomplete (de exemplu, fără recomandări/avatare).
Dezactivarea funcțională: ascundeți temporar widget-uri/caracteristici non-critice.
Steaguri caracteristice: schimbare rapidă a comportamentului fără eliberare.

Reguli

Rezerva trebuie să fie deterministă, rapidă și sigură de date.
Marcați în mod explicit calea degradată în jurnalele/pistele/metrica.

6) Prioritizarea și modelarea traficului

Planuri VIP/plătite - prioritate mai mare/cote în caz de penurie.
Limitele ratei și accelerarea reducerii sarcinii asupra dependențelor degradate.
Încărcătură: Reducere moale a calității (de ex. mai puține rezultate, imagini trunchiate) până la stabilizare.

7) Observabilitate și semnalizare

Măsurători CB

Starea (închis/deschis/semi-deschis) și durata în stare.
Ponderea eșecurilor pe cauze: CB-open, timeout, 5xx, re-epuizat.
p95/p99 latență „înainte” și „după” comutatorul.
Numărul/procentul de cereri prin rezervă.

Urmărire

Adnotări de deschidere: 'circuit = deschis', 'rezervă = cache', 'admitere = refuzat'.
Corelație cu limitele (429/RateLimit-), cozi și gloanțe de conectare.

Jurnale/Audituri

Motivul deschiderii/închiderii, pragurile, ID-urile de dependență.

8) Contracte și protocol

HTTP

Fail-fast: '503 Service indisponibil' cu 'Retry-After' (sau '429' la limite).
Conținut parțial/vechi: „200 ”/„ 206” cu metadate de degradare (de exemplu, „X-Degraded: true”).
Politici cache: 'Cache-Control: stale-if-error, stale-în timp ce-revalidate'.

gRPC

'INDISPONIBIL', 'DEADLINE _ EXCEED', semantica retraiului prin politicile client/proxy.
Termen limită/timeout privind contextul solicitării; împrăştierea termenului limită în lanţ.

Idempotenta

"Idempotency-Key 'pentru operațiunile POST, eliminarea duplicatelor la frontieră.

9) Punerea în aplicare tipic (pseudo cod)

pseudo onRequest(req):
if circuit. isOpen(dep):
return fallbackOrFail(req)

with timeout(T):
try:
resp = call(dep, req)
circuit. recordSuccess(dep, latency=resp. latency)
return resp except TimeoutError or 5xx as e:
circuit. recordFailure(dep)
if circuit. shouldOpen(dep):
circuit. open(dep, coolDown=adaptive())
return fallbackOrFail(req)

Proba semi-deschisă

pseudo onTimer():
if circuit. state(dep) == OPEN and coolDownExpired():
circuit. toHalfOpen(dep)

onRequestHalfOpen(req):
if circuit. allowTrial (dep): # e.g. 1 try: call -> success => close catch: reopen with longer coolDown else:
return fallbackOrFail(req)

10) Stabilirea pragurilor

Fereastra de observare: alunecare N secunde/interogări.
Pragul de eroare: 20-50% în fereastră (în funcție de profil).
Prag de latență: p95 ≤ țintă SLO (de exemplu, 300-500 ms); excesul este considerat o „eroare” pentru CB.
Răcire adaptivă: 10s → 30s → 60s cu acționări repetate.

11) Testarea și practicile haosului

Haos: injecție de eroare de latență/dependență, defalcare DNS, cădere de pachete.
Zile de joc: începe „deschiderea” comutatorului pe un mediu de luptă, verificarea rezervă.
Canare: Activați mai întâi politicile POC/degradare pentru 1-5% din trafic.
Bugetul SLO: permite experimente până când bugetul de eroare este epuizat.

12) Integrarea cu multi-chirie

Starea CB poate fi stocată per dependență per chiriaș (pentru chiriașii zgomotoși) sau la nivel global - în funcție de profilul de încărcare.
Segmentați datele de rezervă și cache-urile prin 'chiriaș _ id'.
Priorități/cote - conform planurilor (VIP-urile nu ar trebui să sufere de comportamentul Starter).

13) Lista de verificare pre-vânzare

• Termenele și termenele limită sunt end-to-end și consecvente.
• Retraiele sunt limitate, numai pentru operații idempotente, cu backoff + jitter.
• Pragurile CB sunt justificate de datele testului de încărcare.
• Căile de rezervă există, rapide și sigure; cache-ul politicii definit.
• Izolarea pereților etanși: piscine/cozi/limite separate.
• Metrica/trasee/busteni degradarea pavilionului și stările CB.
• Documentația contractului de răspuns (HTTP/gRPC) cu anteturi/coduri de eșantion.
• Scenariile de haos și zilele de joc au loc în mod regulat; Există un runbook.

14) Erori tipice

Nu există perioade de timp → se retrage „până la capăt” și cade în cascadă.
Un singur CB global în loc de selectiv (prin endpoint/metodă) - eșecuri inutile.
Deschideți comutatorul fără rezervă → ecrane „goale” în loc de UX degradat.
Retrai fără jitter → furtuni sincrone de cereri.
Răcirea lungă cu eșecuri pe termen scurt sau prea scurtă cu stări stabile - „flip-flop”.
Absența pereților etanși - epuizarea bazinelor comune și „blocarea capului de linie”.

15) Selectarea rapidă a strategiei

Citește de mare importanță: CB + cache de răspunsuri vechi + acoperire (economic).
Înregistrări/plăți: termene stricte, retribuții minime, chei de idempotență, fără rezerve murdare.
API-uri externe: CB cu praguri agresive, răcire adaptivă, limitare strictă.
Microservicii de sarcină pulsatoare: pereți etanși, capace per concurență, prioritizare VIP.

Concluzie

Circuit Breaker și degradarea gestionată sunt arhitectura „asigurare”: ele transpun eșecurile haotice în comportament previzibil. Temporizările clare, retragerile limitate ale jitter-ului, piscinele izolate, căile de rezervă grijulii și telemetria fac ca sistemul să fie rezistent la eșecurile de dependență și să dețină SLO-uri chiar și în timpul perioadelor de vârf și de avarie.