A lecke végére el tudod magyarázni, hogyan korlátozza a circuit breaker, a bulkhead és a terheléskorlát a hibák terjedését, és mikor melyiket érdemes használni.
Miért kell?
Egy kiesett vagy lassú függőség nemcsak az adott hívást rontja el: a rá váró kérések lefoglalhatnak kapcsolatokat, szálakat és memóriát, majd a hiba továbbterjed más funkciókra. A hibatűrés célja a hibaterjedés korlátozása és a helyreállítás támogatása.
Circuit breaker
A circuit breaker (megszakító) megfigyeli a függőségre irányuló hívások eredményét, és tartós hibánál átmenetileg megszakítja az új próbálkozásokat. Fowler leírása szerint három állapota van:
Closed (zárt): a hívások átmennek; a hibák számlálót növelnek, a siker nullázza.
Open (nyitott): a küszöb elérése után a megszakító azonnal hibát ad, a védett műveletet nem hívja.
Half-open (félig nyitott): egy várakozási idő után egy próbahívást enged át; siker esetén zár, hiba esetén újraindul a várakozás.
stateDiagram-v2
[*] --> Closed
Closed --> Open: hibaküszöb elérve
Open --> HalfOpen: várakozási idő lejárt
HalfOpen --> Closed: a próbahívás sikeres
HalfOpen --> Open: a próbahívás sikertelen
A küszöb lehet rögzített számú egymás utáni hiba vagy hibaarány. Üzleti elutasítás (például „nincs készlet”) nem feltétlenül függőségi meghibásodás; ha technikai hibaként számolják, a megszakító egészséges szolgáltatást is letilthat. A megszakító a műveletet nem hajtja végre később, csak gyorsan elutasít vagy megtervezett kiváltást ad. Fowler szerint a kliensnek kezelnie kell a nyitott állapotot: lehet hiba, vagy egy kiváltó megoldás (például a művelet sorba állítása, vagy elavult, de elfogadható adat). A megszakító jó megfigyelési pont: az állapotváltozásokat naplózni kell.
Bulkhead
A bulkhead (válaszfal) az erőforrásokat különálló készletekre bontja, hogy az egyik hibája ne vigye el a többit. A név a hajótest szakaszolására utal. Az Azure leírása szerint a fogyasztó például szolgáltatásonként külön kapcsolatkészletet kaphat; ha egy szolgáltatás elromlik, csak az ahhoz rendelt készlet telik meg. Aszinkron üzenetküldésnél külön sorokkal is elszigetelhetők a munkák.
Az elszigetelés ára az erőforrás-hatékonyság és a bonyolultság: túl szűk keret normál terhelésnél is elutasíthat, túl tág keret nem véd.
Rate limit és concurrency limit
A rate limit időegységenként korlátozza az elfogadott kérések számát. A concurrency limit az egyszerre folyamatban levő munkát. Egy lassuló rendszerben ugyanaz a másodpercenkénti kérésütem több egyidejű munkát eredményez, ezért a két korlát eltérő problémát kezel. Felhasználónként, bérlőnként, végpontonként vagy külső függőségenként külön korlát indokolt lehet, hogy egy kliens ne foglalhassa le az összes kapacitást. Túlterheléskor világos elutasítás és újrapróbálási jelzés kell (például 429, 503 és Retry-After).
Degradált működés
Fallback lehet gyorsítótárazott adat, részleges válasz vagy egy opcionális funkció kihagyása. Az eredmény jelentését meg kell őrizni: a „fizetési szolgáltatás hibás, ezért sikeres fizetést feltételeznek” elfogadhatatlan; az „értékelések átmenetileg nem elérhetők” helyes részleges működés lehet. Az általános fallback minden végpontra rossz rövidítés.
Gyakori tévhitek
Állítás
Pontosítás
„A circuit breaker később elvégzi a műveletet.”
Gyorsan elutasít; a későbbi végrehajtáshoz tartós sor kell.
„A bulkhead mindig javítja a hatékonyságot.”
Erőforrást foglal le; az elszigetelés ára a kihasználtság.
„A rate limit és a concurrency limit ugyanaz.”
Az egyik a sebességet, a másik az egyidejű munkát korlátozza.
„A fallback mindig jó.”
Csak ha a jelentés megmarad.
Röviden
A circuit breaker gyorsan elutasít tartós hiba esetén; három állapota van.
A bulkhead elkülöníti az erőforrásokat, így a hiba nem terjed.
A rate limit a kérésütemet, a concurrency limit az egyidejű munkát korlátozza.
A fallback csak akkor jó, ha megőrzi az eredmény jelentését.
Ellenőrző kérdések
Mi a különbség a circuit breaker és az ismétlés között?
Miért kell külön korlát a kérésütemre és az egyidejű munkára?
Mikor elfogadhatatlan fallback egy fizetési hiba esetén?
Circuit breaker, bulkhead és terheléskorlát
Célok
A lecke végére el tudod magyarázni, hogyan korlátozza a circuit breaker, a bulkhead és a terheléskorlát a hibák terjedését, és mikor melyiket érdemes használni.
Miért kell?
Egy kiesett vagy lassú függőség nemcsak az adott hívást rontja el: a rá váró kérések lefoglalhatnak kapcsolatokat, szálakat és memóriát, majd a hiba továbbterjed más funkciókra. A hibatűrés célja a hibaterjedés korlátozása és a helyreállítás támogatása.
Circuit breaker
A circuit breaker (megszakító) megfigyeli a függőségre irányuló hívások eredményét, és tartós hibánál átmenetileg megszakítja az új próbálkozásokat. Fowler leírása szerint három állapota van:
A küszöb lehet rögzített számú egymás utáni hiba vagy hibaarány. Üzleti elutasítás (például „nincs készlet”) nem feltétlenül függőségi meghibásodás; ha technikai hibaként számolják, a megszakító egészséges szolgáltatást is letilthat. A megszakító a műveletet nem hajtja végre később, csak gyorsan elutasít vagy megtervezett kiváltást ad. Fowler szerint a kliensnek kezelnie kell a nyitott állapotot: lehet hiba, vagy egy kiváltó megoldás (például a művelet sorba állítása, vagy elavult, de elfogadható adat). A megszakító jó megfigyelési pont: az állapotváltozásokat naplózni kell.
Bulkhead
A bulkhead (válaszfal) az erőforrásokat különálló készletekre bontja, hogy az egyik hibája ne vigye el a többit. A név a hajótest szakaszolására utal. Az Azure leírása szerint a fogyasztó például szolgáltatásonként külön kapcsolatkészletet kaphat; ha egy szolgáltatás elromlik, csak az ahhoz rendelt készlet telik meg. Aszinkron üzenetküldésnél külön sorokkal is elszigetelhetők a munkák.
Az elszigetelés ára az erőforrás-hatékonyság és a bonyolultság: túl szűk keret normál terhelésnél is elutasíthat, túl tág keret nem véd.
Rate limit és concurrency limit
A rate limit időegységenként korlátozza az elfogadott kérések számát. A concurrency limit az egyszerre folyamatban levő munkát. Egy lassuló rendszerben ugyanaz a másodpercenkénti kérésütem több egyidejű munkát eredményez, ezért a két korlát eltérő problémát kezel. Felhasználónként, bérlőnként, végpontonként vagy külső függőségenként külön korlát indokolt lehet, hogy egy kliens ne foglalhassa le az összes kapacitást. Túlterheléskor világos elutasítás és újrapróbálási jelzés kell (például
429,503ésRetry-After).Degradált működés
Fallback lehet gyorsítótárazott adat, részleges válasz vagy egy opcionális funkció kihagyása. Az eredmény jelentését meg kell őrizni: a „fizetési szolgáltatás hibás, ezért sikeres fizetést feltételeznek” elfogadhatatlan; az „értékelések átmenetileg nem elérhetők” helyes részleges működés lehet. Az általános fallback minden végpontra rossz rövidítés.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források