Doporučení pro zpracování přechodných chyb
Platí pro toto doporučení kontrolního seznamu pro spolehlivost architektury Azure Well-Architected Framework:
| RE:07 | Posílení odolnosti a obnovitelnosti úloh implementací samozáchů a samoopravených opatření. S využitím vzorů spolehlivosti založených na infrastruktuře a vzorů návrhu na základě softwaru můžete do řešení problémů se selháními komponent a přechodnými chybami začlenit možnosti. Zabudujte do systému funkce pro detekci selhání komponent řešení a automaticky iniciujte nápravnou akci, zatímco úloha bude fungovat v plné nebo omezené funkčnosti. |
|---|
Související příručky: Samoobslužné zachování úloh | na pozadí
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 kvůli povaze prostředí a připojení přes internet se tento typ chyby pravděpodobně setká častěji. Mezi přechodné chyby patří momentální ztráta síťového připojení ke komponentám a službám, dočasná nedostupnost služby a časové limity, ke kterým dochází, když je služba zaneprázdněná. Tyto chyby se často opravují sami, takže pokud se akce opakuje po vhodném zpoždění, bude pravděpodobně ú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 při používání služeb Azure najdete 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ěží v místní infrastruktuře, se výkon a dostupnost aplikace a jejích komponent obvykle spravují prostřednictvím nákladné a často nedostatečně používané redundance hardwaru a komponenty a prostředky se nacházejí blízko sebe. Tento přístup snižuje pravděpodobnost selhání, ale přechodné chyby mohou stále nastat, protože můžou dojít 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ízet vyšší celkovou dostupnost pomocí 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 komoditním výpočetním uzly. Z důvodu povahy cloudových prostředí ale pravděpodobně 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 bylo možné prostředky chránit. Některé služby odmítnou připojení, když zatížení vzroste na určitou úroveň nebo když dosáhnete maximální propustnosti, aby bylo možné zpracovávat stávající požadavky a udržovat 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 dynamickým rozdělením zatížení mezi několik výpočetních jednotek a komponent infrastruktury. Zajišťují spolehlivost automatickým recyklací nebo nahrazením jednotek, které selhaly. 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á, často existuje 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í.
Síťové podmínky mezi klientem a serverem můžou být proměnné, zejména při komunikaci přes internet. I v místních umístěních může vysoké zatížení provozu zpomalit komunikaci a způsobit občasné selhání připojení.
Přechodné chyby můžou mít významný vliv na vnímanou dostupnost aplikace, i když se důkladně testují za všech předvídatelných okolností. Pokud chcete zajistit, 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é, jsou dlouhodobé nebo jsou selhání terminálu. Různé prostředky budou pravděpodobně vracet různé odpovědi, když dojde k chybě, a tyto odpovědi se také mohou lišit v závislosti na kontextu operace. Například odpověď na chybu při čtení aplikace z úložiště se může lišit od odpovědi pro 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 tyto informace nejsou k dispozici, může být obtížné zjistit povahu chyby a jestli je pravděpodobné, že budou přechodné.
Aplikace musí být schopná operaci zopakovat, pokud zjistí, že chyba bude pravděpodobně přechodná. Musí také sledovat, kolikrát se operace opakuje.
Aplikace musí použít odpovídající strategii pro opakování. Strategie určuje, kolikrát se má aplikace opakovat, zpoždění mezi jednotlivými pokusy a akce, které se mají provést po neúspěšném pokusu. Vhodný počet pokusů a zpoždění mezi jednotlivými pokusy je často obtížné určit. Strategie se liší v závislosti na typu prostředku a na aktuálních provozních podmínkách prostředku a aplikace.
Následující pokyny vám můžou pomoct navrhnout vhodné mechanismy 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 pomůžou určit, jestli je opakování vhodné a jak dlouho čekat před dalším pokusem o opakování.
Pokud nemáte specifické a dobře pochopitelné požadavky, které umožňují vhodnější jiné chování opakování, měli byste použít integrovaný mechanismus opakování.
Určení, jestli je operace vhodná pro opakování
Operace opakování proveďte pouze v případě, že chyby jsou přechodné (obvykle označené povahou chyby) a pokud existuje alespoň určitá pravděpodobnost, že operace bude úspěšná při opakování. V opakovaných operacích, které se pokoušejí o neplatnou operaci, jako je aktualizace databáze na položku, která neexistuje, nebo požadavek na službu nebo prostředek, u kterých došlo k závažné chybě, neexistuje žádný bod.
Obecně platí, že opakování implementujete pouze v případě, že můžete určit úplný účinek tohoto a kdy jsou podmínky dobře srozumitelné a lze je ověřit. Jinak nechte 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é pomáhají klientům určit, jestli by se měly opakovat neúspěšné operace. Konkrétně uveďte, jestli má klient operaci opakovat (třeba vrácením hodnoty isTransient ) a navrhnout 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žeb. I když můžou obecné klienty tyto chyby číst, jsou užitečné při vytváření vlastních klientů.
Určení vhodného počtu opakování a intervalu
Optimalizujte počet opakování a interval podle typu případu použití. Pokud nebudete opakovat dostatek času, aplikace nemůže operaci dokončit a pravděpodobně selže. Pokud to zkusíte příliš mnohokrát nebo s příliš krátkým intervalem mezi pokusy, může aplikace uchovávat prostředky, jako jsou vlákna, připojení a paměť po dlouhou dobu, což nepříznivě ovlivňuje stav aplikace.
Přizpůsobte hodnoty pro časový interval a počet opakovaných pokusů o typ operace. Pokud je operace například součástí interakce uživatele, měl by být interval krátký a mělo by se o to pokoušet jenom několik opakování. Pomocí tohoto přístupu 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 zrušení a restartování procesu je nákladné nebo časově náročné, je vhodné počkat delší dobu mezi pokusy a opakovat vícekrát.
Mějte na paměti, že určení vhodných intervalů mezi opakovanými pokusy je nejobtížnější součástí návrhu úspěšné strategie. Typické strategie používají následující typy intervalu opakování:
Exponenciální regrese. Aplikace chvíli čeká před prvním opakováním a exponenciálním zvýšením času mezi jednotlivými dalšími opakováními. Může například operaci opakovat po 3 sekundách, 12 sekundách, 30 sekundách atd.
Přírůstkové intervaly. Aplikace chvíli čeká před prvním opakováním a pak přírůstkově zvýší čas mezi každým dalším opakováním. Může například operaci opakovat 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 operaci opakovat každých 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 tomto případě je opakování operace okamžitě vhodné, protože může být úspěšné, pokud je chyba vymazána v době, kdy aplikace potřebuje sestavit a odeslat další požadavek. Nikdy by však nemělo existovat 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í zpětná nebo záložní akce.
Randomizace. Každá z dříve uvedených strategií opakování může zahrnovat randomizaci, aby se zabránilo více instancím klienta, které současně odesílají následné pokusy o opakování. Například jedna instance může 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. Randomizace je užitečná technika, která se dá kombinovat s jinými strategiemi.
Obecně platí, že pro operace na pozadí používejte exponenciální back-off strategii a pro interaktivní operace používejte 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 opakování. Mezi tyto faktory patří doba, kterou trvá neúspěšné připojení k vytvoření odpovědi (obvykle nastavená hodnotou časového limitu v klientovi), zpoždění mezi opakovanými pokusy a maximálním počtem opakování. Celkový součet všech těchto časů může mít za následek dlouhou celkovou dobu provozu, zejména když použijete strategii exponenciálního zpoždění, kdy se interval mezi opakovanými pokusy rychle zvětšuje po každém selhání. 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 s intervaly, které jsou příliš krátké nebo opakované pokusy, které jsou příliš časté. Mohou 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í ze svého přetíženého stavu a budou i nadále blokovat nebo odmítnout žádosti. Výsledkem tohoto scénáře je obtěžovaný kruh, kdy se do prostředku nebo služby odesílají další a další požadavky. V důsledku toho se jeho schopnost obnovit dále snižuje.
Pokud zvolíte intervaly opakování, vezměte v úvahu časový limit operací, abyste se vyhnuli okamžitému spuštění následného pokusu (například pokud je období časového limitu podobné intervalu opakování). Zvažte také, jestli potřebujete zachovat celkovou možnou dobu (časový limit plus intervaly opakování) pod konkrétním celkovým časem. Pokud má operace neobvykle krátký nebo dlouhý časový limit, může časový limit ovlivnit dobu čekání a četnost opakování operace.
K optimalizaci počtu opakování 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. Například některé výjimky nebo kódy chyb (například kód HTTP 503, Služba není k dispozici s hlavičkou Opakovat po v odpovědi) můžou znamenat, jak dlouho může chyba trvat, nebo že služba selhala a nebude reagovat na žádný další pokus.
Zvažte použití přístupu fronty nedoručených zpráv, abyste měli jistotu, že se po vyčerpání všech pokusů o opakování neztratí všechny informace z příchozího vyvolání.
Vyhněte se anti-vzorům
Ve většině případů se vyhněte implementaci, které obsahují 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, která pak přistupuje k cílové službě. Pokud implementujete opakování s počtem tří volání obou volání, je celkem devět pokusů o opakování ve službě. Mnoho služeb a prostředků implementuje integrovaný mechanismus opakování. Pokud potřebujete implementovat opakování na vyšší úrovni, měli byste prozkoumat, jak tyto mechanismy zakázat nebo upravit.
Nikdy implementujte mechanismus s nekonečným počtem opakování. Je pravděpodobné, že zabráníte tomu, aby se prostředek nebo služba zotavily z přetížených situací a způsobily omezování a odmítly připojení pokračovat delší dobu. Použijte konečný počet opakování nebo implementujte vzor, jako je Jistič , který službě umožní obnovení.
Nikdy neprovádějte okamžité opakování víc než jednou.
Nepoužívejte pravidelný interval opakování při přístupu ke službám a prostředkům v Azure, zejména pokud máte velký počet pokusů o opakování. Nejlepším přístupem v tomto scénáři je exponenciální back-off strategie s možností přerušení okruhu.
Zabrání souběžné odesílání opakovaných pokusů několika instancí stejného klienta nebo více instancí různých klientů. Pokud k tomuto scénáři pravděpodobně dojde, zaveděte do intervalů opakování randomizaci.
Testování strategií opakování a implementace
Plně otestujte strategii opakování v co nejširším rozsahu, zejména v případě, že aplikace i cílové prostředky nebo služby, které používá, jsou extrémně zatížené. Chcete-li zkontrolovat chování při testování, můžete provést následující:
Do služby vložte přechodné a nepřehledné 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 napodobeni prostředku nebo služby, která vrací celou řadu chyb, které může skutečná služba vrátit. Probíjejte všechny typy chyb, které je vaše strategie opakování navržená tak, aby zjistila.
U vlastních služeb, které vytváříte a nasazujete, vynucujte přechodné chyby 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 nežádoucí scénáře z automatizovaných testů. Testy mohou například přidat další doby odezvy, zahodit pakety, upravit hlavičky nebo dokonce změnit text samotného požadavku. To umožňuje deterministické testování podmnožinu podmínek selhání, pro přechodné chyby a další typy selhání.
Při testování odolnosti klientské webové aplikace vůči přechodným chybám použijte vývojářské nástroje prohlížeče nebo schopnost testovací architektury napodobení nebo blokování síťových požadavků.
Proveďte vysoký zátěžový faktor a souběžné testy, abyste zajistili, že mechanismus opakování a strategie za těchto podmínek správně fungují. Tyto testy také pomáhají zajistit, aby opakování nemělo nepříznivý vliv na provoz klienta nebo aby mezi požadavky způsobovaly křížovou kontaminaci.
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, jestli je chyba pravděpodobně přechodná, typ intervalu, který se má použít (například normální, exponenciální zpět a randomizace), hodnoty skutečných intervalů a počet opakování.
Implementujte opakování 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. Například uložte hodnoty, jako je interval a počet opakování v konfiguračních souborech aplikace, přečtěte si je za běhu a programově sestavte 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 však navrhujte tak, aby hodnoty ukládaly místo opakovaného načítání konfiguračního souboru pokaždé, a pokud hodnoty nelze získat z konfigurace, použijte vhodné výchozí hodnoty.
Uložte hodnoty, které se používají k sestavení zásad opakování za běhu v konfiguračním systému aplikace, abyste je mohli změnit, aniž byste museli aplikaci restartovat.
Využijte integrované nebo výchozí strategie opakování, které jsou dostupné v klientských rozhraních API, která používáte, ale pouze 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šechno, co potřebujete, ale v jiných scénářích nenabízí celou řadu možností, které vyhovují 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ňují vaši aplikaci.
Protokolování a sledování přechodných a nepřehledných chyb
Součástí strategie opakování je zpracování výjimek a další instrumentace, které protokolují pokusy o opakování. Občasné přechodné selhání a opakování jsou očekávané a neoznačují problém. Pravidelné a rostoucí počty opakování jsou ale často indikátorem problému, který může způsobit selhání nebo snížení výkonu a dostupnosti aplikace.
Zaznamenejte přechodné chyby jako položky upozornění, ne jako položky chyb, aby je systémy monitorování nezjistily jako chyby aplikace, které by mohly aktivovat falešná upozornění.
Zvažte uložení hodnoty do položek protokolu, které označují, jestli jsou opakování způsobené omezováním ve službě nebo jinými typy chyb, jako jsou selhání 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živatele, latenci procesu a efektivitu případů použití aplikace. Také protokolujte počet opakovaných pokusů, ke kterým dochází, abyste pochopili faktory, které přispívají k době odezvy.
Zvažte implementaci systému telemetrie a monitorování, který může vyvolat výstrahy, když počet a míra selhání, průměrný počet opakování nebo celkový čas uplynul před úspěšným provozem.
Správa operací, které neustále selhávají
Zvažte, jak zpracovávat operace, které při každém pokusu nadále selhávají. Takové situace jsou nevyhnutelné.
I když strategie opakování definuje maximální počet opakování operace, která by se měla opakovat, nezabrá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 zvážit, že se jedná o přechodnou chybu. Kód opakuje operaci zadaným počtem opakování a pak se vrátí. Pokud ale jiný zákazník zadá objednávku, operace se pokusí znovu, i když se nezdaří pokaždé.
Pokud chcete zabránit neustálému opakování operací, které neustále selhávají, měli byste zvážit implementaci modelu Jistič. Pokud tento vzor použijete, pokud počet selhání v zadaném časovém intervalu překročí prahovou hodnotu, žádosti se okamžitě vrátí volajícímu jako chyby a nedojde k žádnému pokusu o přístup k prostředku nebo službě, který selhal.
Aplikace může službu pravidelně testovat, a to přerušovaně a s dlouhými intervaly mezi požadavky, aby zjistila, kdy je dostupná. Vhodný interval závisí na faktorech, jako je závažnost operace a povaha služby. Může to být cokoli mezi několika minutami a několika hodinami. Když bude test úspěšný, může aplikace pokračovat v normálních operacích a předat žádosti nově obnovené službě.
Mezitím se můžete vrátit k jiné instanci služby (možná v jiném datacentru nebo aplikaci), použít podobnou službu, která nabízí kompatibilní (možná jednodušší) funkce, nebo provést některé alternativní operace na základě naděje, že bude služba brzy dostupná. Může být například vhodné uložit žádosti o službu ve frontě nebo úložišti dat a opakovat je později. Nebo můžete být schopni 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 s oznámením, že aplikace není aktuálně dostupná.
Optimalizace implementace opakování
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. Může být obtížné nebo nákladné kompenzovat všechny ostatní provozní kroky, které už byly úspěšné, když jeden selže. V tomto případě může být velmi dlouhý interval a velký počet opakování přijatelný, pokud tato strategie neblokuje jiné operace tím, že drží nebo zamyká prostředky nedostatku.
Zvažte, jestli opakování stejné operace může způsobit nekonzistence v datech. Pokud se některé části vícekrokového procesu opakují a operace nejsou idempotentní, může dojít k nekonzistenci. Pokud se například operace, která zvýší hodnotu, opakuje, vytvoří neplatný výsledek. Opakování operace, která odesílá zprávu do fronty, může způsobit nekonzistenci příjemce zprávy, pokud příjemce nemůže rozpoznat duplicitní zprávy. Pokud chcete těmto scénářům zabránit, navrhujte 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 v případě selhání. 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í, při určování intervalů opakování při určování intervalů opakování vezměte v úvahu celkovou latenci všech operací a před vyvolání výstrah pro 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ěná zásadami opakování implementovanými jinými uživateli prostředků a služeb. U důležitých obchodních aplikací můžete chtít používat prémiové služby, které nejsou sdílené. Tím získáte větší kontrolu nad zatížením a následným omezováním těchto prostředků a služeb, které vám můžou pomoct odůvodnit dodatečné náklady.
Poznámka:
Další pokyny k kompromisům a rizikům najdete v článku o vzorech 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á různé charakteristiky a požadavky a každý mechanismus opakování je vyladěný na 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í | Nic |
| Azure Cosmos DB | Nativní ve službě | Nejde konfigurovat | Globální | TraceSource |
| Azure Data Lake Storage | Nativní v klientovi | Nejde konfigurovat | Jednotlivé operace | Nic |
| Azure Event Hubs | Nativní v klientovi | Programová | Klient | Nic |
| Azure IoT Hub | Nativní v klientské sadě SDK | Programová | Klient | Nic |
| 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 | Nic |
| 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 | Nic |
| SQL Database s Entity Framework Core | Nativní v klientovi | Programová | Globální na doménu aplikace | Nic |
| Azure Storage | Nativní v klientovi | Programová | Klient a jednotlivé operace | TraceSource |
Poznámka:
U většiny integrovaných mechanismů opakování 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ásadu, která poskytuje optimální průměrný výkon a dostupnost. Jedním ze způsobů, jak vyladit 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ů probíraných v tomto článku, najdete v modelu spolehlivé webové aplikace pro .NET . Existuje také referenční implementace na GitHubu.
Související odkazy
- Model Jistič
- Model Opakování
- Model Omezení využití sítě
- Model kompenzační transakce
- Blogový příspěvek o vzorech idempotence
- Odolnost připojení
- Vložení napodobených služeb
- Vzor fronty nedoručených zpráv
Kontrolní seznam pro spolehlivost
Projděte si kompletní sadu doporučení.