Návrh pro samoopravení

Navrhněte svou aplikaci tak, aby se v případě chyby mohla sama opravit.

V distribuovaném systému může dojít k selhání. Může selhat hardware. Síť může mít přechodné výpadky. K zasažení celé služby nebo oblasti může dojít jen zřídka, ale i na tyto případy je třeba se připravit.

Navrhněte proto aplikaci tak, aby se v případě chyby mohla sama opravit. To vyžaduje přístup založený na třech aspektech:

• Zjišťování chyb
• Přiměřená reakce na chyby
• Protokolování a sledování chyb kvůli provoznímu přehledu

Reakce na konkrétní typ chyby může záviset na požadavcích dostupnosti vaší aplikace. Například pokud budete potřebovat velmi vysokou dostupnost, může během místního výpadku automaticky dojít k převzetí služeb při selhání v sekundární oblasti. To ale vyžaduje vyšší náklady než nasazení v jedné oblasti.

Neuvažujte jen o velkých událostech, jako jsou regionální výpadky, které jsou obecně výjimečné. Měli byste se také (a možná víc) zaměřit na zpracování místních, krátkodobých selhání, jako je například selhání připojení k síti nebo k databázi.

Doporučení

Opakování neúspěšných operací. Přechodná selhání můžou být způsobená momentální ztrátou připojení k síti či k databázi nebo vypršením časového limitu žádosti, když je služba přetížená. Vložte do své aplikace logiku opakovaných pokusů pro zpracování přechodných selhání. Pro řadou služeb Azure klientská sada SDK implementuje automatická opakování. Další informace najdete v tématu zpracování přechodných chyb a vzor opakování.

Chraňte selhávající vzdálené služby (jistič). Je vhodné po přechodném selhání pokus opakovat, ale pokud chyba přetrvává, můžete skončit tak, že velké množství volajících bombarduje selhávající službu. Jak se požadavky hromadí, může to vést ke kaskádovým selháním. Použijte vzorek pro dělení na okruhy , který rychle selže (bez vzdáleného volání), když je operace pravděpodobně neúspěšná.

Izolujte důležité prostředky (Bulkhead). Selhání v jednom subsystému se můžou někdy kaskádově přenést. To může nastat, když kvůli selhání nejsou včas uvolněny některé prostředky, například vlákna nebo sokety, což vede k vyčerpání prostředků. Abyste tomu předešli, rozdělte systém na izolované skupiny tak, aby selhání v jedné skupině nezbortilo celý systém.

Provádějte vyrovnávání zátěže. V aplikacích může docházet k nečekaným špičkám provozu, které můžou zahlcovat back-endové služby. Aby k tomu nedocházelo, použijte model vyrovnávání zatížení založený na frontě a zařadit pracovní položky do fronty, aby běžely asynchronně. Fronta funguje jako vyrovnávací paměť, která vyrovnává provozní špičky.

Provádějte převzetí služeb při selhání. Pokud je instance nedostupná, proveďte převzetí služeb při selhání jinou instancí. U věcí, které jsou bezstavové, jako je webový server, umístěte několik instancí za nástroj pro vyrovnávání zatížení nebo správce provozu. U věcí, které ukládají stav, jako jsou databáze, použijte repliky a převzetí služeb při selhání. V závislosti na úložišti dat a způsobu replikace může být potřeba, aby aplikace pracovala s konečnou konzistencí.

Kompenzujte nezdařené transakce. Obecně se vyhýbejte distribuovaným transakcím, protože vyžadují koordinaci v rámci služeb a prostředků. Místo toho tvořte operace z menších jednotlivých transakcí. Pokud se operace nezdaří ve své polovině, použijte kompenzaci transakcí, abyste vrátili všechny dokončené kroky.

Vytvářejte kontrolní body dlouhotrvajících transakcí. Kontrolní body můžou poskytovat odolnost, pokud dojde k selhání dlouhotrvajících operací. Při restartování operace (například když ji převezme jiný virtuální počítač) ji jde obnovit od posledního kontrolního bodu.

Degradujte bez problémů. V některých případech nejde problém vyřešit, ale můžete poskytovat omezenou funkčnost, která je stále užitečná. Vezměme si aplikaci, která zobrazuje katalog knih. Pokud aplikace nedokáže načíst miniatury obálek, může zobrazovat zástupné obrázky. Pro aplikaci můžou být nekritické celé subsystémy. Například na webu elektronického obchodu je zobrazování doporučení produktů pravděpodobně méně kritické než zpracování objednávek.

Omezte klienty. Někdy malý počet uživatelů vytváří nadměrné zatížení, čímž se může omezit dostupnost vaší aplikace pro ostatní uživatele. V takovém případě klienta po určitou dobu omezte. Podívejte se na model omezování.

Blokujte nesprávně se chovající účastníky. Když klienta omezíte, neznamená to, že se klient chová závadně. Znamená to je to, že klient překročil pro službu svou kvótu. Ale pokud klient soustavně překračuje svou kvótu nebo se chová jinak nesprávně, můžete ho zablokovat. Definujte samostatný postup pro uživatele, kteří žádají o odblokování.

Používejte volbu vedoucího procesu. Pokud potřebujete úlohu koordinovat, použijte volbu vedoucího procesu a vyberte koordinátora. Tímto způsobem není koordinátor kritickým prvkem způsobujícím selhání. Pokud koordinátor selže, vybere se nový. Místo úplně nové implementace algoritmu volby vedoucího procesu zvažte možnost použít dodávané řešení, jako je Zookeeper.

Testujte vkládáním selhání. Velmi často se stává, že úspěšná cesta je dobře otestovaná, ale cesta selhání není. Systém může běžet v produkčním prostředí po dlouhou dobu, než se provede cesta selhání. Pomocí vkládání selhání otestujte odolnost systému proti chybám tak, že buď vyvoláte skutečné poruchy, nebo je budete jen simulovat.

Zapojte řízený chaos. Řízený chaos rozšiřuje koncept vkládání selhání tak, že do produkčních instancí náhodně vkládá selhání nebo nestandardní podmínky.

Strukturovaný přístup k vlastním opravám vašich aplikací najdete v tématu Návrh spolehlivých aplikací pro Azure.