Doporučení pro zpracování přechodných chyb

  • Článek

Platí pro toto doporučení kontrolního seznamu spolehlivosti azure Well-Architected Framework:

RE:07 Posílení odolnosti a obnovitelnosti úloh implementací sebezáchovy a samoopravných opatření Zabudujte do řešení funkce pomocí vzorců spolehlivosti založených na infrastruktuře a softwarových vzorů návrhu pro zpracování selhání komponent a přechodných chyb. Zabudujte do systému funkce, které detekují selhání součástí řešení a automaticky zahájí nápravnou akci, zatímco úloha bude dál fungovat s plnou nebo omezenou funkčností.

Související příručky:Úlohy | na pozadí– sebezáchovy

Tato příručka popisuje doporučení pro zpracování přechodných chyb v cloudových aplikacích. Všechny aplikace, které komunikují se vzdálenými službami a prostředky, musí být citlivé na přechodné chyby. To platí zejména pro aplikace, které běží v cloudu, kde je vzhledem k povaze prostředí a připojení přes internet pravděpodobné, že k tomuto typu chyby dochází častěji. Mezi přechodné chyby patří momentální ztráta síťového připojení k komponentám a službám, dočasná nedostupnost služby a vypršení časových limitů, ke kterým dochází, když je služba zaneprázdněná. Tyto chyby se často samy opravují, takže pokud se akce po vhodném zpoždění opakuje, je pravděpodobné, že bude úspěšná.

Tento článek obsahuje obecné pokyny pro zpracování přechodných chyb. Informace o zpracování přechodných chyb najdete v modelu opakování , a pokud používáte služby Azure, přečtěte si pokyny k opakování pro služby Azure.

Klíčové strategie návrhu

Přechodné chyby můžou nastat v jakémkoli prostředí, na všech platformách a operačních systémech a v jakékoliv aplikaci. U řešení, která běží na místní infrastruktuře, se výkon a dostupnost aplikace a jejích komponent obvykle udržuje prostřednictvím nákladné a často nevyužité redundance hardwaru a komponenty a prostředky jsou umístěné blízko sebe. Tento přístup snižuje pravděpodobnost selhání, ale stále může docházet k přechodným chybám, stejně jako k výpadkům způsobeným nepředvídatelnými událostmi, jako jsou problémy s externím napájením nebo sítí nebo scénáře havárie.

Hostování cloudu, včetně systémů privátního cloudu, může nabídnout vyšší celkovou dostupnost díky využití sdílených prostředků, redundance, automatického převzetí služeb při selhání a dynamického přidělování prostředků napříč mnoha výpočetními uzly komodit. Vzhledem k povaze cloudových prostředí je však pravděpodobnější, že dojde k přechodným chybám. Tady je několik důvodů:

  • Mnoho prostředků v cloudovém prostředí se sdílí a přístup k těmto prostředkům podléhá omezování, aby se prostředky chránily. Některé služby odmítnou připojení, když se zatížení zvýší na určitou úroveň nebo když je dosaženo maximální rychlosti propustnosti, aby bylo možné zpracovávat stávající požadavky a aby se zachoval výkon služby pro všechny uživatele. Omezování pomáhá udržovat kvalitu služby pro sousedy a další tenanty, kteří používají sdílený prostředek.

  • Cloudová prostředí používají velké množství komoditních hardwarových jednotek. Poskytují výkon tím, že dynamicky distribuují zatížení mezi několik výpočetních jednotek a komponent infrastruktury. Zajišťují spolehlivost tím, že automaticky recyklují nebo nahradí neúspěšné jednotky. Kvůli této dynamické povaze může občas dojít k přechodným chybám a dočasným selháním připojení.

  • Mezi aplikací a prostředky a službami, které používá, je často více hardwarových komponent, včetně síťové infrastruktury, jako jsou směrovače a nástroje pro vyrovnávání zatížení. Tato další infrastruktura může příležitostně přidávat další latenci připojení a přechodné chyby připojení.

  • Podmínky sítě mezi klientem a serverem můžou být proměnlivé, zejména při komunikaci přes internet. I v místních umístěních může velké zatížení provozu zpomalit komunikaci a způsobit přerušovaná selhání připojení.

Výzvy

Přechodné chyby mohou mít významný vliv na vnímanou dostupnost aplikace, i když byla důkladně testována za všech předvídatelných okolností. Aby aplikace hostované v cloudu fungovaly spolehlivě, musíte zajistit, aby mohly reagovat na následující výzvy:

  • Aplikace musí být schopná rozpoznat chyby, když k nim dojde, a určit, jestli jsou chyby pravděpodobně přechodné, dlouhodobé nebo zda se jedná o selhání terminálu. Různé prostředky pravděpodobně vrátí různé odpovědi, když dojde k chybě, a tyto odpovědi se mohou také lišit v závislosti na kontextu operace. Například odpověď na chybu, když aplikace čte z úložiště, se může lišit od odpovědi na chybu při zápisu do úložiště. Mnoho prostředků a služeb má dobře zdokumentované kontrakty přechodných selhání. Pokud ale takové informace nejsou k dispozici, může být obtížné zjistit povahu chyby a zjistit, jestli je pravděpodobná přechodná.

  • Aplikace musí být schopna operaci zopakovat, pokud zjistí, že chyba je pravděpodobně přechodná. Musí také sledovat, kolikrát se operace opakuje.

  • Aplikace musí pro opakování použít vhodnou strategii. Strategie určuje, kolikrát by se měla aplikace opakovat, zpoždění mezi jednotlivými pokusy a akce, které se mají provést po neúspěšném pokusu. Často je obtížné určit odpovídající počet pokusů a zpoždění mezi jednotlivými pokusy. Strategie se liší v závislosti na typu prostředku a na aktuálních provozních podmínkách prostředku a aplikace.

Obecné pokyny

Následující pokyny vám můžou pomoct s návrhem vhodných mechanismů zpracování přechodných chyb pro vaše aplikace.

Určení, jestli existuje integrovaný mechanismus opakování

  • Mnoho služeb poskytuje sadu SDK nebo klientskou knihovnu, která obsahuje mechanismu pro zpracování přechodných chyb. Zásady opakovaných pokusů, které používá, jsou obvykle přizpůsobené podstatě a požadavkům cílové služby. Případně rozhraní REST pro služby můžou vracet informace, které vám můžou pomoct určit, jestli je opakování vhodné a jak dlouho čekat na další pokus o opakování.

  • Pokud je k dispozici, měli byste použít integrovaný mechanismus opakování, pokud nemáte konkrétní a dobře pochopitelné požadavky, které umožňují vhodnější jiné chování opakování.

Určení, jestli je operace vhodná pro opakování

  • Operace opakování provádějte pouze v případě, že jsou chyby přechodné (obvykle označené povahou chyby) a pokud existuje alespoň určitá pravděpodobnost, že operace bude úspěšná při opakování. Nemá smysl opakovat operace, které se pokoušejí o neplatnou operaci, jako je aktualizace databáze u položky, která neexistuje, nebo požadavek na službu nebo prostředek, u kterého došlo k závažné chybě.

  • Obecně platí, že opakované pokusy implementujte pouze v případě, že můžete určit úplný účinek a pokud jsou podmínky dobře pochopeny a je možné je ověřit. V opačném případě nechejte volající kód implementovat opakování. Nezapomeňte, že chyby vrácené z prostředků a služeb mimo vaši kontrolu se můžou v průběhu času vyvíjet a možná budete muset znovu navštívit logiku detekce přechodných chyb.

  • Při vytváření služeb nebo komponent zvažte implementaci kódů chyb a zpráv, které klientům pomůžou určit, jestli by se měli neúspěšné operace opakovat. Konkrétně určete, jestli má klient operaci zopakovat (například vrácením hodnoty isTransient ), a navrhněte vhodné zpoždění před dalším pokusem o opakování. Pokud vytváříte webovou službu, zvažte vrácení vlastních chyb definovaných v rámci kontraktů služby. I když obecné klienty nemusí být schopny tyto chyby přečíst, jsou užitečné při vytváření vlastních klientů.

Určení vhodného počtu a intervalu opakování

  • Optimalizujte počet opakování a interval podle typu případu použití. Pokud to nezopakujete dostatečně často, aplikace nemůže operaci dokončit a pravděpodobně selže. Pokud to budete opakovat příliš mnohokrát nebo s příliš krátkým intervalem mezi pokusy, může aplikace po dlouhou dobu uchovávat prostředky, jako jsou vlákna, připojení a paměť, což nepříznivě ovlivňuje stav aplikace.

  • Přizpůsobte hodnoty časového intervalu a počtu opakovaných pokusů na typ operace. Pokud je například operace součástí interakce uživatele, měl by být interval krátký a měl by se pokusit o několik opakování. Tímto přístupem se můžete vyhnout tomu, aby uživatelé čekali na odpověď, která obsahuje otevřená připojení a může snížit dostupnost pro ostatní uživatele. Pokud je operace součástí dlouhotrvajícího nebo kritického pracovního postupu, kdy je zrušení a restartování procesu nákladné nebo časově náročné, je vhodné mezi pokusy počkat déle a opakovat vícekrát.

  • Mějte na paměti, že určení vhodných intervalů mezi opakováními je nejobtížnější částí návrhu úspěšné strategie. Typické strategie používají následující typy intervalu opakování:

    • Exponenciální zápětí. Aplikace chvíli počká před prvním opakováním a pak exponenciálně prodlouží čas mezi každým dalším opakováním. Může například opakovat operaci po 3 sekundách, 12 sekundách, 30 sekundách atd.

    • Přírůstkové intervaly. Aplikace chvíli počká před prvním opakováním a pak postupně prodlouží čas mezi každým dalším opakováním. Může například opakovat operaci po 3 sekundách, 7 sekundách, 13 sekundách atd.

    • Pravidelné intervaly. Aplikace čeká mezi jednotlivými pokusy stejnou dobu. Může například opakovat operaci každé 3 sekundy.

    • Okamžité opakování. Někdy je přechodná chyba krátká, pravděpodobně způsobená událostí, jako je kolize síťových paketů nebo špička v hardwarové komponentě. V takovém případě je vhodné operaci okamžitě zopakovat, protože může být úspěšná, pokud se chyba vymaže v době, kdy aplikace potřebuje sestavit a odeslat další požadavek. Nikdy by však nemělo proběhnout více než jeden okamžitý pokus o opakování. Pokud okamžité opakování selže, měli byste přepnout na alternativní strategie, jako jsou exponenciální akce zpětného vypnutí nebo záložní akce.

    • Náhodnost. Kterákoli z výše uvedených strategií opakování může zahrnovat náhodnou náhodnost, aby se zabránilo více instancím klienta odesílaných následných opakovaných pokusů najednou. Jedna instance může například operaci opakovat po 3 sekundách, 11 sekundách, 28 sekundách atd., zatímco jiná instance může operaci opakovat po 4 sekundách, 12 sekundách, 26 sekundách atd. Náhodnost je užitečná technika, kterou lze kombinovat s jinými strategiemi.

  • Obecně platí, že pro operace na pozadí použijete exponenciální strategii back-off a pro interaktivní operace použijete strategie opakování okamžitého nebo pravidelného intervalu. V obou případech je třeba vybrat zpoždění a počet opakování tak, aby maximální latence pro všechny pokusy o opakování odpovídala požadavku na celkovou požadovanou latenci.

  • Vezměte v úvahu kombinaci všech faktorů, které přispívají k celkovému maximálnímu vypršení časového limitu pro operaci s opakovaným opakováním. Mezi tyto faktory patří doba potřebná k vytvoření odpovědi neúspěšného připojení (obvykle nastavená hodnotou časového limitu v klientovi), zpoždění mezi opakovanými pokusy a maximální počet opakování. Celkový počet těchto časů může vést k dlouhému celkovému provozu, zejména pokud použijete strategii exponenciálního zpoždění, kdy interval mezi opakováními po každém selhání rychle narůstá. Pokud proces musí splňovat konkrétní smlouvu o úrovni služeb (SLA), celková doba provozu, včetně všech časových limitů a zpoždění, musí být v mezích definovaných ve smlouvě SLA.

  • Neimplementujte příliš agresivní strategie opakování. Jedná se o strategie, které mají příliš krátké intervaly nebo příliš časté opakování. Můžou mít nepříznivý vliv na cílový prostředek nebo službu. Tyto strategie můžou bránit prostředku nebo službě v zotavení z přetíženého stavu a budou dál blokovat nebo odmítat požadavky. Výsledkem tohoto scénáře je začarovaný kruh, kdy se do prostředku nebo služby odesílá více a více požadavků. V důsledku toho se jeho schopnost zotavit se dále snižuje.

  • Při volbě intervalů opakování vezměte v úvahu časový limit operací, aby se zabránilo okamžitému spuštění následného pokusu (například pokud je časový limit podobný intervalu opakování). Zvažte také, jestli je potřeba udržovat celkové možné období (časový limit a intervaly opakování) pod konkrétním celkovým časem. Pokud má operace neobvykle krátký nebo dlouhý časový limit, může tento časový limit ovlivnit, jak dlouho se má čekat a jak často se má operace opakovat.

  • K optimalizaci počtu opakovaných pokusů a intervalu mezi nimi použijte typ výjimky a všechna data, která obsahuje, nebo kódy chyb a zprávy vrácené službou. Některé výjimky nebo kódy chyb (například kód HTTP 503, Nedostupná služba s hlavičkou Retry-After v odpovědi) můžou udávat, jak dlouho může chyba trvat nebo že služba selhala a nebude reagovat na další pokus.

  • Zvažte použití fronty nedoručených zpráv, abyste měli jistotu, že se po vyčerpání všech opakovaných pokusů neztratí všechny informace z příchozího volání.

Vyhněte se anti-vzorům

  • Ve většině případů se vyhněte implementaci, která obsahuje duplicitní vrstvy kódu opakování. Vyhněte se návrhům, které zahrnují kaskádové mechanismy opakování nebo které implementují opakování v každé fázi operace, která zahrnuje hierarchii požadavků, pokud nemáte specifické požadavky, které to vyžadují. Za těchto výjimečných okolností použijte zásady, které brání nadměrnému počtu opakovaných pokusů a období zpoždění, a ujistěte se, že chápete důsledky. Řekněme například, že jedna komponenta odešle požadavek na jinou komponentu, která pak přistupuje k cílové službě. Pokud implementujete opakování s počtem tří u obou volání, existuje celkem devět pokusů o opakování vůči službě. Mnoho služeb a prostředků implementuje integrovaný mechanismus opakování. Měli byste prozkoumat, jak můžete tyto mechanismy zakázat nebo upravit, pokud potřebujete implementovat opakování na vyšší úrovni.

  • Nikdy implementujte mechanismus s nekonečným počtem opakování. Tím pravděpodobně zabráníte prostředku nebo službě v zotavení z přetížení a dojde k omezování a zamítnutí připojení po delší dobu. Použijte konečný počet opakování nebo implementujte model, jako je Jistič , aby se služba mohla zotavit.

  • Nikdy neprovádějte okamžité opakování víc než jednou.

  • Při přístupu ke službám a prostředkům v Azure nepoužívejte pravidelný interval opakování, zejména pokud máte velký počet pokusů o opakování. Nejlepším přístupem v tomto scénáři je exponenciální re-off strategie s schopností přerušení okruhu.

  • Zabrání více instancím stejného klienta nebo více instancím různých klientů v odesílání opakovaných pokusů současně. Pokud je pravděpodobné, že k tomuto scénáři dojde, zavedněte do intervalů opakování náhodnost.

Testování strategie opakování a implementace

  • Plně otestujte strategii opakování za co nejširší sady okolností, zejména v případě, že aplikace i cílové prostředky nebo služby, které používá, jsou pod extrémní zátěží. Chcete-li zkontrolovat chování při testování, můžete provést následující:

    • Vložte do služby přechodné a nepřechází chyby. Například odešlete neplatné požadavky nebo přidejte kód, který zjišťuje požadavky testu a odpovídá různými typy chyb.

    • Vytvořte model prostředku nebo služby, který vrátí rozsah chyb, které může vrátit skutečná služba. Probívejte všechny typy chyb, ke kterým je vaše strategie opakování navržená.

    • U vlastních služeb, které vytvoříte a nasadíte, vynuťte, aby dočasně došlo k přechodným chybám tím, že službu dočasně zakážete nebo přetížíte. (Nepokoušejte se přetížit žádné sdílené prostředky nebo sdílené služby v Azure.)

    • Pomocí knihoven nebo řešení, které zachycují a upravují síťový provoz, můžete replikovat nepříznivé scénáře z automatizovaných testů. Testy mohou například přidat dodatečné doby odezvy, zahodit pakety, upravit hlavičky nebo dokonce změnit text samotného požadavku. Tím umožníte deterministické testování podmnožiny podmínek selhání, přechodných chyb a dalších typů selhání.

    • Při testování odolnosti klientské webové aplikace vůči přechodným chybám využijte vývojářské nástroje prohlížeče nebo schopnost vaší testovací architektury napodobeniny nebo blokování síťových požadavků.

    • Proveďte testy s vysokým zatížením a souběžné testy, abyste zajistili, že mechanismus a strategie opakování za těchto podmínek fungují správně. Tyto testy také pomáhají zajistit, aby opakování nemělo nepříznivý vliv na fungování klienta nebo nezpůsobí křížovou kontaminaci mezi požadavky.

Správa konfigurací zásad opakování

  • Zásady opakování jsou kombinací všech prvků vaší strategie opakování. Definuje mechanismus detekce, který určuje, zda je chyba pravděpodobně přechodná, typ intervalu, který se má použít (například pravidelné, exponenciální zpoždování a randomizace), skutečné hodnoty intervalů a počet opakování.

  • Opakované pokusy implementujte na mnoha místech, a to i v nejjednodušší aplikaci, a v každé vrstvě složitějších aplikací. Místo pevného kódování prvků jednotlivých zásad na více místech zvažte použití centrálního bodu k uložení všech zásad. Můžete například ukládat hodnoty, jako je interval a počet opakování, do konfiguračních souborů aplikace, číst je za běhu a programově vytvářet zásady opakování. To usnadňuje správu nastavení a úpravu a vyladění hodnot tak, aby odpovídaly měnícím se požadavkům a scénářům. Systém ale navrhujte tak, aby ukládaly hodnoty a nepřečítá pokaždé znovu konfigurační soubor, a pokud hodnoty nelze získat z konfigurace, použijte vhodné výchozí hodnoty.

  • Hodnoty, které se použijí k sestavení zásad opakování za běhu, uložte v konfiguračním systému aplikace, abyste je mohli změnit, aniž byste museli aplikaci restartovat.

  • Využijte předdefinované nebo výchozí strategie opakování, které jsou dostupné v klientských rozhraních API, která používáte, ale jenom v případě, že jsou vhodné pro váš scénář. Tyto strategie jsou obvykle obecné. V některých scénářích můžou být vše, co potřebujete, ale v jiných scénářích nenabízí celou škálu možností, které by vyhovovaly vašim konkrétním požadavkům. Pokud chcete určit nejvhodnější hodnoty, musíte provést testování, abyste pochopili, jak nastavení ovlivňuje vaši aplikaci.

Protokolování a sledování přechodných a nepřenosných chyb

  • Jako součást strategie opakování zahrňte zpracování výjimek a další instrumentaci, která protokoluje opakované pokusy. Občasné přechodné selhání a opakované pokusy se očekávají a neoznačují problém. Pravidelné a zvyšující se počty opakování jsou však často indikátorem problému, který může způsobit selhání nebo který snižuje výkon a dostupnost aplikace.

  • Protokolujte přechodné chyby jako položky upozornění, nikoli jako chybové položky, aby je monitorovací systémy nezjistily jako chyby aplikace, které by mohly aktivovat falešná upozornění.

  • Zvažte uložení hodnoty do položek protokolu, která označuje, jestli jsou opakování způsobená omezováním ve službě nebo jinými typy chyb, jako jsou chyby připojení, abyste je mohli během analýzy dat odlišit. Zvýšení počtu chyb omezení často slouží v aplikaci jako ukazatel problémů návrhu nebo nutnosti přechodu na službu úrovně Premium, která nabízí vyhrazený hardware.

  • Zvažte měření a protokolování celkového uplynulého času pro operace, které zahrnují mechanismus opakování. Tato metrika je dobrým indikátorem celkového vlivu přechodných chyb na dobu odezvy uživatelů, latenci procesů a efektivitu případů použití aplikací. Protokolujte také počet opakovaných pokusů, ke kterým dojde, abyste pochopili faktory, které přispívají k době odezvy.

  • Zvažte implementaci telemetrie a monitorovacího systému, který může vyvolat výstrahy v případě, že se zvýší počet a četnost selhání, průměrný počet opakovaných pokusů nebo celkový čas, po který uplynou úspěšné operace.

Správa operací, které neustále selhávají

  • Zvažte, jak zpracovávat operace, které při každém pokusu stále selhávají. Podobné situace jsou nevyhnutelné.

    • I když strategie opakování definuje maximální počet opakování operace, nebrání aplikaci v opakování operace se stejným počtem opakování. Pokud například služba zpracování objednávek selže se závažnou chybou, která ji trvale vyřadí z provozu, strategie opakování může zjistit vypršení časového limitu připojení a považovat ho za přechodnou chybu. Kód opakuje operaci zadaným počtem opakování a pak se zřeknou. Když ale objednávku zadá jiný zákazník, pokusí se o operaci znovu, i když pokaždé selže.

    • Pokud chcete zabránit neustálému opakování operací, které neustále selhávají, měli byste zvážit implementaci modelu Jistič. Pokud použijete tento model a počet selhání v zadaném časovém intervalu překročí prahovou hodnotu, požadavky se volajícímu okamžitě vrátí jako chyby a nedojde k žádnému pokusu o přístup k neúspěšným prostředkům nebo službě.

    • Aplikace může službu pravidelně testovat, přerušovaně a s dlouhými intervaly mezi požadavky, aby zjistila, kdy je k dispozici. Vhodný interval závisí na faktorech, jako je důležitost operace a povaha služby. Může se jednat o několik minut až několik hodin. Když je test úspěšný, aplikace může obnovit normální provoz a předávat požadavky nově obnovené službě.

    • Mezitím se můžete vrátit k jiné instanci služby (třeba v jiném datacentru nebo aplikaci), použít podobnou službu, která nabízí kompatibilní (možná jednodušší) funkce, nebo provádět některé alternativní operace založené na naději, že služba bude brzy dostupná. Může být například vhodné ukládat požadavky na službu do fronty nebo úložiště dat a opakovat je později. Nebo můžete uživatele přesměrovat na alternativní instanci aplikace, snížit výkon aplikace, ale přesto nabídnout přijatelné funkce, nebo uživateli vrátit zprávu, že aplikace není aktuálně dostupná.

Další důležité informace

  • Při rozhodování o hodnotách počtu opakování a intervalů opakování pro zásadu zvažte, jestli je operace ve službě nebo prostředku součástí dlouhotrvající nebo vícekrokové operace. Kompenzace všech ostatních provozních kroků, které už byly úspěšné, v případě selhání může být obtížné nebo nákladné. V takovém případě může být přijatelný velmi dlouhý interval a velký počet opakování, pokud tato strategie neblokuje jiné operace tím, že drží nebo uzamkne omezené prostředky.

  • Zvažte, jestli opakování stejné operace může způsobit nekonzistence dat. Pokud se některé části vícekrokového procesu opakují a operace nejsou idempotentní, může dojít k nekonzistenci. Pokud se například opakuje operace, která zvýší hodnotu, vytvoří neplatný výsledek. Opakování operace, která odešle zprávu do fronty, může způsobit nekonzistence příjemce zprávy, pokud příjemce nedokáže rozpoznat duplicitní zprávy. Pokud chcete těmto scénářům zabránit, navrhněte každý krok jako idempotentní operaci. Další informace najdete v tématu Vzory idempotence.

  • Zvažte rozsah operací, které se budou opakovat. Může být například jednodušší implementovat kód opakování na úrovni, která zahrnuje několik operací, a opakovat je všechny, pokud jedna selže. To ale může vést k problémům s idempotenci nebo zbytečným operacím vrácení zpět.

  • Pokud zvolíte rozsah opakování, který zahrnuje několik operací, vezměte v úvahu celkovou latenci všech operací při určování intervalů opakování, při monitorování uplynulých časů operace a před vyvolání upozornění na selhání.

  • Zvažte, jak vaše strategie opakování může ovlivnit sousedy a další tenanty ve sdílené aplikaci a kdy používáte sdílené prostředky a služby. Agresivní zásady opakování můžou způsobit růst počtu přechodných chyb, ke kterým dochází pro tyto ostatní uživatele a pro aplikace, které sdílejí prostředky a služby. Podobně může být vaše aplikace ovlivněna zásadami opakování implementovanými jinými uživateli prostředků a služeb. U důležitých podnikových aplikací můžete chtít použít prémiové služby, které nejsou sdílené. Získáte tak větší kontrolu nad zatížením a následným omezováním těchto prostředků a služeb, což může pomoct ospravedlnit dodatečné náklady.

Poznámka

Další pokyny týkající se kompromisů a rizik najdete v tématu Problémy a důležité informace v článku Model opakování.

Usnadnění Azure

Většina služeb Azure a klientských sad SDK poskytuje mechanismus opakování. Tyto mechanismy se ale liší, protože každá služba má jiné vlastnosti a požadavky a každý mechanismus opakování je vyladěný pro konkrétní službu. Tato část shrnuje funkce mechanismu opakování pro některé běžně používané služby Azure.

Služba Funkce opakování Konfigurace zásad Obor Telemetrické funkce
Microsoft Entra ID Nativní v knihovně Microsoft Authentication Library (MSAL) Vložené do knihovny MSAL Interní Žádné
Azure Cosmos DB Nativní ve službě Nejde konfigurovat Globální TraceSource
Azure Data Lake Storage Nativní v klientovi Nejde konfigurovat Jednotlivé operace Žádné
Azure Event Hubs Nativní v klientovi Programová Klient Žádné
Azure IoT Hub Nativní v klientské sadě SDK Programová Klient Žádné
Azure Cache for Redis Nativní v klientovi Programová Klient TextWriter
Azure Cognitive Search Nativní v klientovi Programová Klient Trasování událostí pro Windows nebo vlastní
Azure Service Bus Nativní v klientovi Programová NamespaceManager, MessagingFactory a klient Trasování událostí pro Windows
Azure Service Fabric Nativní v klientovi Programová Klient Žádné
Azure SQL Database s ADO.NET Polly Deklarativní a programová Jednotlivé příkazy nebo bloky kódu Vlastní
SQL Database s Entity Framework Nativní v klientovi Programová Globální na doménu aplikace Žádné
SQL Database s Entity Framework Core Nativní v klientovi Programová Globální na doménu aplikace Žádné
Azure Storage Nativní v klientovi Programová Klient a jednotlivé operace TraceSource

Poznámka

U většiny předdefinovaných mechanismů opakování v Azure v současné době neexistuje způsob, jak použít jiné zásady opakování pro různé typy chyb nebo výjimek. Měli byste nakonfigurovat zásady, které poskytují optimální průměrný výkon a dostupnost. Jedním ze způsobů, jak doladit zásady, je analyzovat soubory protokolu a určit typ přechodných chyb, ke kterým dochází.

Příklad

Příklad, který používá mnoho vzorů popsaných v tomto článku, najdete v tématu Model spolehlivé webové aplikace pro .NET . K dispozici je také referenční implementace na GitHubu.

Kontrolní seznam pro spolehlivost

Projděte si kompletní sadu doporučení.

Kontrolní seznam pro spolehlivost