Circuit Breaker და დეგრადაცია

Circuit Breaker (CB) არის დამცავი ნიმუში, რომელიც წყვეტს დეგრადირებული დამოკიდებულების გამოწვევებს, რათა მოხდეს მარცხის ლოკალიზაცია და დაიცვას აფსიდი სერვისები და მომხმარებელი. დეგრადაცია (graceful degradation) არის მიზანმიმართული ფუნქციონირების გამარტივება რესურსების ნაკლებობის ან უარის თქმის დროს (მაგალითად, ქეშირებული/არასრული მონაცემების დაბრუნება, „ძვირადღირებული“ ფიგურების გათიშვა) სრული დასრულების გარეშე.

მთავარი მიზანი: SLO და მომხმარებლის გამოცდილების შენარჩუნება კონტროლირებადი უკმარისობის გამო, კასკადის დაცემის ნაცვლად.

1) გამოყენებისას

დამოკიდებულება არასტაბილურია: ზრდა p95/p99, ტაიმაუტები, მცდარი პასუხები.
გარე API მკაცრი ლიმიტებით/პენალტით.
„მძიმე“ ზურგჩანთები (ძებნა, რეკომენდაციები, მოხსენებები), სადაც რეაგირება აძლიერებს ქარიშხალს.
მაღალი დატვირთული ადგილები ტყვიების ამოწურვის რისკით (ნაერთები, ძაფები).

2) CB მდგომარეობა და გადასვლები

1. Closed - ტრაფიკი მიდის, შეცდომების/ლატენტობის მეტრიკა განიხილება.

2. Open - ზარები დაუყოვნებლივ უარყოფენ (fail-fast) და/ან გადადიან fallback- ზე.

3. Half-Open - „საცდელი“ მოთხოვნების შეზღუდული რაოდენობა განსაზღვრავს თუ არა მიკროსქემის დახურვას.

გახსნის გამომწვევები

შეცდომების/ტაიმაუტების ბარიერი ფანჯრის მიღმა (მაგალითად, ბოლო N 50%).
ლატენტობის ბარიერი (მაგალითად, p95> მიზნობრივი მნიშვნელობა).
კომბინირებული პოლიტიკოსები (შეცდომები - ტაიმუტის ჭარბი რაოდენობა).

შენახვის დრო (cool-down)

ფიქსირებული (მაგალითად, 10-60 წამი) ან ადაპტირებული (ექსპონენციალური ზრდა განმეორებით ოპერაციებში).

3) ტაიმაუტი, რეტრაი და ჯიტერი

Taimauts ყოველთვის უფრო მოკლეა, ვიდრე SLO აფსიდი და შეთანხმებულია ჯაჭვზე (deadline propagation).
Retrai მხოლოდ idempotent ოპერაციებისთვის; უმეტეს შემთხვევაში 1-2 მცდელობა საკმარისია.
Backoff + gitter (სრული jitter) ხელს უშლის გამეორების სინქრონულ ტალღებს.
Hedging (სათადარიგო მოთხოვნები) ეკონომიკურად და მხოლოდ ძალიან კრიტიკული კითხვებისთვის.

4) Bulkhead იზოლაცია და „დაუკრავენ“

გაზიარეთ ნაერთების/workers/რიგები დომენებისა და ტრაფიკის ტიპების მიხედვით (VIP, ფონის დავალებები, საზოგადოებრივი API).
caps concurrency „ძვირადღირებული“ ოპერაციებისთვის.
Admission Control: მარტივი უარი თქვას შესრულებაზე, როდესაც ხაზი გადადის.

5) Fallback და დეგრადაციის სცენარები

პარამეტრები

ქეში/სახელმწიფო პასუხები: 'stale-while-revalidate', მონაცემების დაბრუნება L2/L3 ქეში.
Read-only: წერა/გუნდების ბლოკი, უსაფრთხო კითხვების დაშვება.
სუროგატი პასუხები: არასრული მონაცემები (მაგალითად, რეკომენდაციების/ავატარების გარეშე).
ფუნქციური გამორთვა: დროებით დამალვა არა კრიტიკული ვიჯეტები/ფიჩები.
Feature flags: სწრაფი ქცევის შეცვლა გამოშვების გარეშე.

წესები

Fallback უნდა იყოს დეტერმინირებული, სწრაფი და უსაფრთხო მონაცემების მიხედვით.
აშკარად შეაფასეთ დეგრადირებული გზა ლოგოებში/ტრეისებში/მეტრიკებში.

6) პრიორიტეტიზაცია და ტრეფიკი

VIP/ფასიანი გეგმები - უფრო დიდი პრიორიტეტი/კვოტები დეფიციტით.
Rate limits და throttling ამცირებენ დატვირთვას დეგრადირებულ დამოკიდებულებებზე.
Shed load: ხარისხის რბილი ვარდნა (მაგალითად, ნაკლები შედეგი, შემცირებული სურათები) სტაბილიზაციამდე.

7) დაკვირვება და სიგნალიზაცია

მეტრიკა CB

მდგომარეობა (closed/Open/half-Open) და ხანგრძლივობა მდგომარეობაში.
უარის თქმის წილი მიზეზების გამო: CB Open, timeout, 5xx, retry-exhausted.
p95/p99 ლატენტობა „ადრე“ და „შემდეგ“ გამორთვა.
Col/მოთხოვნის წილი fallback- ის საშუალებით.

ტრეისი

სპანების მენიუ: 'circuit = opened', 'fallback = cache', 'admission = denied'.
კორელაცია ლიმიტებთან (429/RateLimit-), ნაერთების რიგები და ტყვიები.

ლოგიკური/აუდიტი

აღმოჩენის/დახურვის მიზეზი, ბარიერები, დამოკიდებულების იდენტიფიკატორები.

8) კონტრაქტები და ოქმი

HTTP

Fail-fast: '503 Service Unavailable' s 'Retry-After' (ან '429' შეზღუდვებზე).
ნაწილობრივი შინაარსი/სტილი: '200 '/' 206' დეგრადაციის მეტამონაცემებით (მაგალითად, 'X-Degraded: true').
ქეშის პოლიტიკა: 'Cache Control: stale-if-error, stale-while-revalidate'.

gRPC

'UNAVAILABLE', „DEADLINE _ EXCEEDED“, რეტრატიული სემანტიკა კლიენტის/მარიონეტული პოლისების მიხედვით.
Deadline/timeout მოთხოვნის კონტექსტში; ვადის განაწილება ჯაჭვში.

Idempotenty

'Idempotency-Key' POST ოპერაციებისთვის, საზღვარზე დუპლიკაცია.

9) ტიპიური განხორციელება (ფსევდო კოდი)

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)

Half-Open ტესტი

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) ბარიერების კონფიგურაცია

სათვალთვალო ფანჯარა: მოცურების N წამი/მოთხოვნა.
შეცდომების ბარიერი: ფანჯარაში 20-50% (დამოკიდებულია პროფილზე).
ლატენტობის ბარიერი: p95 სამიზნე SLO (მაგალითად, 300-500 ms); ჭარბი რაოდენობა გათვალისწინებულია, როგორც CB- ს „შეცდომა“.
ადაპტირებული cool-down: 10s-30s-60s განმეორებითი ოპერაციების დროს.

11) ტესტირება და ქაოსის პრაქტიკა

ქაოსი: ლატენტობის/შეცდომების ინექცია დამოკიდებულია DNS- ის ავარიაში, პაკეტების გარღვევაში.
Game days: „აღმოჩენის“ გაშვება საბრძოლო მსგავსი გარემოში, fallback შემოწმება.
Canary: ჩართეთ SV/დეგრადაციის პოლიტიკა, პირველ რიგში, ტრეფიკის 1-5% -ისთვის.
SLO ბიუჯეტი: დაუშვეთ ექსპერიმენტები, სანამ error-budget ამოიწურება.

12) ინტეგრაცია მრავალ ტენანტთან

CB მდგომარეობა შეიძლება შეიცავდეს per-dependence per-tenant (ხმაურიანი მოიჯარეებისთვის) ან გლობალურად - დატვირთვის პროფილის მიხედვით.
Fallback მონაცემები და ქეში სეგმენტირებულია 'tenant _ id' მიხედვით.
პრიორიტეტები/კვოტები - გეგმების მიხედვით (VIP არ უნდა განიცდიან Starter- ის ქცევას).

13) ჩეკის სია გაყიდვამდე

• ტაიმაუტები და ვადები დასრულებულია და შეთანხმებულია.
• Retrai შეზღუდულია მხოლოდ idempotent ოპერაციებისთვის, backoff + gitter- ით.

CB ბარიერი დასაბუთებულია დატვირთვის ტესტის მონაცემებით.

• Fallback ბილიკები არსებობს, სწრაფი და უსაფრთხო; განსაზღვრულია პოლიტიკის ქეში.
• Bulkhead იზოლაცია: ცალკეული აუზები/ხაზები/ლიმიტები.
• მეტრიკა/ტრეისი/ლოგები აღნიშნავენ CB- ს დეგრადაციას და მდგომარეობას.
• პასუხის კონტრაქტების დოკუმენტაცია (HTTP/gRPC) სათაურების/კოდების მაგალითებით.
• ქაოსის სცენარები და თამაშის დღეები რეგულარულად ტარდება; არის runbook.

14) ტიპიური შეცდომები

არ არსებობს ტაიმაუტები - retrais „გაჩერებამდე“ და კასკადის ვარდნა.
ერთი გლობალური CB შერჩევის ნაცვლად (ენდოინტის/მეთოდის მიხედვით) არის ზედმეტი უარი.
ღია ჩამკეტი fallback- ის გარეშე არის „ცარიელი“ ეკრანები დეგრადირებული UX- ის ნაცვლად.
Retrai გარეშე jitter - სინქრონული მოთხოვნის ქარიშხალი.
გრძელი cool-down მოკლევადიანი წარუმატებლობებით ან ძალიან მოკლეა სტაბილური - „flip-flop“ სახელმწიფოები.
Bulkhead- ის არარსებობა არის საერთო ტყვიების გაუარესება და „head-of-line blocking“.

15) სტრატეგიის სწრაფი შერჩევა

მაღალი მნიშვნელობის კითხვებით: CB + ქეში + hedging პასუხები (ეკონომიკურად).
ჩანაწერები/გადასახადები: მკაცრი ტაიმაუტები, მინიმალური რეაგირება, პირადობის მოწმობა, „ბინძური“ fallback- ის არარსებობა.
გარე API: CB აგრესიული რეიდებით, ადაპტირებული cool-down, მკაცრი throttling.
მიკროსერვისები პულსირების დატვირთვით: bulkheads, caps concurrency, პრიორიტეტული VIP.

დასკვნა

Circuit Breaker და კონტროლირებადი დეგრადაცია არქიტექტურის „დაზღვევაა“: ისინი ქაოტურ უარს აკეთებენ პროგნოზირებად ქცევაში. მკაფიო ტაიმაუტები, ჯიტერის შეზღუდული ჭრილობები, იზოლირებული აუზები, გააზრებული fallback ბილიკები და ტელემეტრია ქმნის დამოკიდებულების გაუმართაობის სისტემას და ინარჩუნებს SLO- ს პიკის და გადაუდებელ პერიოდებშიც კი.