Návrh aplikací klíčových úloh v Azure

Při návrhu aplikace jsou důležité požadavky na funkční i nefunkční aplikaci. Tato oblast návrhu popisuje vzory architektury a strategie škálování, které můžou pomoct zajistit odolnost vaší aplikace vůči selháním.

Důležité

Tento článek je součástí klíčové řady úloh architektury Azure Well-Architected Framework. Pokud tuto řadu neznáte, doporučujeme začít s tím, co je kritická úloha?

Architektura jednotek škálování

Všechny funkční aspekty řešení musí být schopné škálovat, aby splňovaly změny v poptávce. Doporučujeme použít architekturu jednotek škálování k optimalizaci komplexní škálovatelnosti prostřednictvím oddělení a také ke standardizaci procesu přidávání a odebírání kapacity. Jednotka škálování je logická jednotka nebo funkce, které lze škálovat nezávisle. Jednotku je možné vytvořit z komponent kódu, hostitelských platforem aplikací, kolků nasazení, které pokrývají související komponenty, a dokonce i předplatná, která podporují požadavky na více tenantů.

Tento přístup doporučujeme, protože řeší omezení škálování jednotlivých prostředků a celé aplikace. Pomáhá se scénáři komplexního nasazení a aktualizace, protože jednotku škálování je možné nasadit jako jednu jednotku. Před nasměrováním uživatelského provozu na něj můžete také otestovat a ověřit konkrétní verze komponent v jednotce.

Předpokládejme, že vaše důležitá aplikace je online katalog produktů. Má tok uživatele pro zpracování komentářů a hodnocení produktů. Tok používá rozhraní API k načtení a publikování komentářů a hodnocení a podpůrných komponent, jako je koncový bod OAuth, úložiště dat a fronty zpráv. Bezstavové koncové body rozhraní API představují podrobné funkční jednotky, které se musí přizpůsobit změnám na vyžádání. Základní aplikační platforma musí být také schopná odpovídajícím způsobem škálovat. Aby se zabránilo kritickým bodům výkonu, musí podřízené komponenty a závislosti také škálovat na odpovídající stupeň. Můžou se škálovat nezávisle, jako samostatné jednotky škálování nebo společně jako součást jedné logické jednotky.

Příklady jednotek škálování

Následující obrázek znázorňuje možné rozsahy jednotek škálování. Rozsahy se liší od podů mikroslužeb až po uzly clusteru a razítka místního nasazení.

Aspekty návrhu

• Rozsah. Rozsah jednotky škálování, vztah mezi jednotkami škálování a jejich komponentami by měl být definován podle modelu kapacity. Vezměte v úvahu nefunkční požadavky na výkon.

• Omezení škálování Limity a kvóty škálování předplatného Azure můžou mít vliv na návrh aplikací, volby technologií a definici jednotek škálování. Jednotky škálování vám můžou pomoct obejít limity škálování služby. Pokud například cluster AKS v jedné jednotce může mít pouze 1 000 uzlů, můžete tento limit zvýšit na 2 000 uzlů pomocí dvou jednotek.

• Očekávané zatížení. Použijte počet požadavků pro každý tok uživatele, očekávanou míru požadavků ve špičce (požadavky za sekundu) a vzorce denního/týdenního/sezónního provozu k informování požadavků na základní škálování. Také je potřeba počítat s očekávaným růstem přenosů i objemu dat.

• Přijatelný snížený výkon. Určete, jestli je při zatížení přijatelná degradovaná služba s vysokou dobou odezvy. Při modelování požadované kapacity je nezbytným faktorem požadovaný výkon řešení při zatížení.

• Požadavky na nefunkční funkce. Technické a obchodní scénáře mají odlišné aspekty odolnosti, dostupnosti, latence, kapacity a pozorovatelnosti. Analyzujte tyto požadavky v kontextu klíčových toků koncových uživatelů. V návrhu, rozhodování a volbě technologií na úrovni toku uživatele budete mít relativní flexibilitu.

Doporučení k návrhu

• Definujte rozsah jednotky škálování a omezení, která aktivují škálování jednotky.

• Zajistěte, aby se všechny komponenty aplikace mohly škálovat nezávisle nebo jako součást jednotky škálování, která zahrnuje další související komponenty.

• Definujte vztah mezi jednotkami škálování na základě modelu kapacity a nefunkčních požadavků.

• Definujte razítko regionálního nasazení pro sjednocení zřizování, správy a provozu prostředků regionální aplikace do heterogenní, ale vzájemně závislé jednotky škálování. S rostoucím zatížením je možné nasadit další razítka ve stejné oblasti Azure nebo v různých oblastech, aby bylo možné řešení horizontálně škálovat.

• Jako jednotku škálování použijte předplatné Azure, aby se limity škálování v rámci jednoho předplatného neomezují škálovatelností. Tento přístup se vztahuje na scénáře aplikací ve velkém měřítku, které mají velký objem provozu.

• Modeluje požadovanou kapacitu kolem identifikovaných vzorů provozu, aby se zajistila dostatečná kapacita ve špičce, aby se zabránilo snížení výkonu služby. Případně můžete optimalizovat kapacitu mimo špičku.

• Změřte čas potřebný k provádění operací horizontálního navýšení kapacity a horizontálního snížení kapacity, abyste zajistili, že přirozené variace provozu nevytvoří nepřijatelnou úroveň snížení výkonu služby. Sledujte dobu trvání operace škálování jako provozní metriku.

Poznámka:

Když nasadíte v cílové zóně Azure, ujistěte se, že je předplatné cílové zóny vyhrazené pro aplikaci, aby poskytovalo jasnou hranici správy a zabránilo antipatternu Noisy Neighbor.

Globální distribuce

V jakémkoli vysoce distribuovaném prostředí není možné se vyhnout selhání. Tato část obsahuje strategie pro zmírnění mnoha scénářů selhání. Aplikace musí být schopná odolat oblastním a zónovým selháním. Musí být nasazený v aktivním/aktivním modelu, aby se zatížení distribuoval mezi všechny oblasti.

V tomto videu se dozvíte, jak naplánovat selhání v důležitých aplikacích a maximalizovat odolnost:

Aspekty návrhu

• Redundance. Vaše aplikace musí být nasazená do více oblastí. Kromě toho v rámci oblasti důrazně doporučujeme používat zóny dostupnosti, které umožňují odolnost proti chybám na úrovni datacentra. Zóny dostupnosti mají latenci kratší než 2 milisekundy mezi zónami dostupnosti. U úloh, které jsou "chatty" napříč zónami, může tato latence představovat snížení výkonu pro přenos dat mezi pásmy.

• Aktivní/aktivní model. Doporučuje se strategie aktivního/aktivního nasazení, protože maximalizuje dostupnost a poskytuje vyšší kombinovanou smlouvu o úrovni služeb (SLA). Může ale představovat problémy související se synchronizací dat a konzistencí pro mnoho scénářů aplikací. Řešit problémy na úrovni datové platformy a současně zvážit kompromisy zvýšeného nákladového a technického úsilí.

  Aktivní/aktivní nasazení napříč několika poskytovateli cloudu je způsob, jak potenciálně zmírnit závislost na globálních prostředcích v rámci jednoho poskytovatele cloudu. Strategie nasazení typu aktivní/aktivní ve vícecloudu ale představuje značné množství složitosti související s CI/CD. Vzhledem k rozdílům ve specifikacích prostředků a možnostech mezi poskytovateli cloudu byste také potřebovali specializované razítka nasazení pro každý cloud.

• Zeměpisné rozdělení. Úloha může mít požadavky na dodržování předpisů pro geografickou rezidenci dat, ochranu dat a uchovávání dat. Zvažte, jestli existují konkrétní oblasti, ve kterých se musí data nacházet nebo kde je potřeba nasadit prostředky.

• Požádat o původ. Geografická blízkost a hustota uživatelů nebo závislých systémů by měla informovat rozhodnutí o návrhu globální distribuce.

• Připojení. Způsob přístupu k úloze uživateli nebo externími systémy ovlivní váš návrh. Zvažte, jestli je aplikace dostupná přes veřejný internet nebo privátní sítě, které používají okruhy VPN nebo Azure ExpressRoute.

Doporučení k návrhu a volby konfigurace na úrovni platformy najdete v tématu Aplikační platforma: Globální distribuce.

Volně svázaná architektura řízená událostmi

Spojka umožňuje komunikaci mezi službami prostřednictvím dobře definovaných rozhraní. Volné spojení umožňuje, aby komponenta aplikace fungovala nezávisle. Styl architektury mikroslužeb je konzistentní s důležitými požadavky. Usnadňuje vysokou dostupnost tím, že brání kaskádové selhání.

Pro volné párování důrazně doporučujeme začlenit návrh řízený událostmi. Asynchronní zpracování zpráv prostřednictvím zprostředkujícího může vytvořit odolnost.

V některých scénářích můžou aplikace kombinovat volné a těsné párování v závislosti na obchodních cílech.

Aspekty návrhu

• Závislosti modulu runtime Volně vázané služby by neměly být omezené na používání stejné výpočetní platformy, programovacího jazyka, modulu runtime nebo operačního systému.

• Škálování. Služby by měly být schopné škálovat nezávisle. Optimalizujte využití prostředků infrastruktury a platformy.

• Odolnost proti chybám: Chyby by se měly zpracovávat samostatně a neměly by mít vliv na transakce klienta.

• Transakční integrita. Vezměte v úvahu účinek vytváření a trvalosti dat, ke kterým dochází v samostatných službách.

• Distribuované trasování Kompletní trasování může vyžadovat složitou orchestraci.

Doporučení k návrhu

• Zarovnejte hranice mikroslužeb s důležitými toky uživatelů.

• Pokud je to možné, používejte asynchronní komunikaci řízenou událostmi k podpoře udržitelného škálování a optimálního výkonu.

• Pomocí vzorů, jako je Pošta k odeslání a Transakční relace, zaručujete konzistenci, aby byla každá zpráva zpracována správně.

Příklad: Přístup řízený událostmi

Referenční implementace Mission-Critical Online používá mikroslužby ke zpracování jedné obchodní transakce. Používá operace zápisu asynchronně pomocí zprostředkovatele zpráv a pracovního procesu. Operace čtení jsou synchronní a výsledek se vrátí přímo volajícímu.

Vzory odolnosti a zpracování chyb v kódu aplikace

Nepostradatelná aplikace musí být navržená tak, aby byla odolná, aby řešila co nejvíce scénářů selhání. Tato odolnost maximalizuje dostupnost a spolehlivost služeb. Aplikace by měla mít možnosti samoopravení, které můžete implementovat pomocí vzorů návrhu, jako jsou opakování s backoffem a jističem.

V případě ne přechodných selhání, která nemůžete plně zmírnit v logice aplikace, musí model stavu a provozní obálky provést nápravnou akci. Kód aplikace musí obsahovat správnou instrumentaci a protokolování, aby informoval model stavu a usnadnil následné řešení potíží nebo analýzu původní příčiny podle potřeby. Potřebujete implementovat distribuované trasování , aby volajícímu poskytl komplexní chybovou zprávu, která obsahuje ID korelace, když dojde k selhání.

Nástroje, jako je application Přehledy, vám můžou pomoct dotazovat, korelovat a vizualizovat trasování aplikací.

Aspekty návrhu

• Správné konfigurace. U přechodných problémů není neobvyklé způsobit kaskádové selhání. Zkuste to například znovu bez vhodného zpětného vypnutí, což zhoršuje problém, když je služba omezena. Opakovaný pokus o opakování můžete zpožďovat lineárně nebo je exponenciálně zvýšit, aby se odpovídaly rostoucím zpožděním.

• Koncové body stavu Funkční kontroly v kódu aplikace můžete zveřejnit pomocí koncových bodů stavu, které externí řešení můžou dotazovat, aby načetla stav součásti aplikace.

Doporučení k návrhu

Tady jsou některé běžné vzory softwarového inženýrství pro odolné aplikace:

Vzor	Shrnutí
Queue-Based Load Leveling	Zavádí vyrovnávací paměť mezi příjemci a požadovanými prostředky, aby se zajistily konzistentní úrovně zatížení. Vzhledem k tomu, že jsou požadavky příjemců zařazené do fronty, zpracovává je pracovní proces s požadovaným prostředkem tempem nastaveným pracovním procesem a schopností požadovaného prostředku požadavky zpracovat. Pokud spotřebitelé očekávají odpovědi na své požadavky, musíte implementovat samostatný mechanismus odpovědi. Použijte pořadí podle priority, aby se nejprve prováděly nejdůležitější aktivity.
Circuit Breaker	Poskytuje stabilitu tím, že buď čeká na obnovení, nebo rychle odmítne požadavky a neblokuje při čekání na nedostupnou vzdálenou službu nebo prostředek. Tento model také zpracovává chyby, které můžou trvat různou dobu, než se obnoví při připojení ke vzdálené službě nebo prostředku.
Bulkhead	Pokouší se rozdělit instance služby do skupin na základě požadavků na zatížení a dostupnost a izolování selhání pro zajištění funkčnosti služby.
Sága	Spravuje konzistenci dat napříč mikroslužbami, které mají nezávislé úložiště dat, tím, že zajišťuje, aby se služby navzájem aktualizovaly prostřednictvím definovaných kanálů událostí nebo zpráv. Každá služba provádí místní transakce, aby aktualizovala svůj vlastní stav a publikuje událost, která aktivuje další místní transakci v ságě. Pokud se aktualizace služby nezdaří, sága spouští kompenzační transakce, aby se zabránilo předchozím krokům aktualizace služby. Jednotlivé kroky aktualizace služeb můžou samy implementovat vzorce odolnosti, například opakování.
Health Endpoint Monitoring	Implementuje funkční kontroly v aplikaci, ke které můžou externí nástroje přistupovat prostřednictvím vystavených koncových bodů v pravidelných intervalech. Odpovědi z koncových bodů můžete interpretovat pomocí klíčových provozních metrik k informování stavu aplikace a aktivaci provozních odpovědí, jako je vyvolání výstrahy nebo provedení kompenzačního nasazení vrácení zpět.
Opakovat	Zpracovává přechodné chyby elegantně a transparentně. – Zrušení, pokud chyba není pravděpodobně přechodná a je nepravděpodobné, že by byla úspěšná, pokud se operace pokusí znovu. – Zkuste to znovu, pokud je chyba neobvyklá nebo vzácná a operace bude pravděpodobně úspěšná, pokud se o to pokusíte znovu okamžitě. – Zkuste to znovu po zpoždění, pokud je chyba způsobená podmínkou, která může vyžadovat krátkou dobu k obnovení, jako je připojení k síti nebo selhání vysokého zatížení. Použijte vhodnou strategii pro zpožďování, jakmile se zvětší zpoždění opakování.
Omezování	Řídí spotřebu prostředků používaných komponentami aplikace a chrání je před tím, aby se přetížily. Když prostředek dosáhne prahové hodnoty zatížení, odvrací operace s nižší prioritou a sníží základní funkčnost, aby základní funkce mohly pokračovat, dokud nebudou k dispozici dostatečné prostředky pro návrat k normálnímu provozu.

Tady je několik dalších doporučení:

• K připojení k závislým službám použijte sady SDK poskytované dodavatelem, jako jsou sady Sdk Azure. Místo implementace vlastních funkcí používejte integrované možnosti odolnosti.

• Při opakování neúspěšných volání závislostí použijte vhodnou strategii zpětného ukončení, abyste se vyhnuli vlastnímu scénáři DDoS.

• Definujte společná technická kritéria pro všechny týmy mikroslužeb aplikací, které budou řídit konzistenci a rychlost používání vzorů odolnosti na úrovni aplikace.

• Implementujte vzory odolnosti pomocí osvědčených standardizovaných balíčků, jako je Polly pro C# nebo Sentinel pro Javu.

• Pomocí ID korelace můžete propojit všechny události trasování a protokolovat zprávy, které je propojí s daným požadavkem. Vrátí ID korelace volajícímu pro všechna volání, nejen neúspěšné žádosti.

• Používejte strukturované protokolování pro všechny zprávy protokolu. Vyberte jednotnou jímku provozních dat pro trasování aplikací, metriky a protokoly, aby operátoři mohli snadno ladit problémy. Další informace najdete v tématu Shromažďování, agregace a ukládání dat monitorování pro cloudové aplikace.

• Ujistěte se, že se provozní data používají společně s obchodními požadavky k informování modelu stavu aplikace.

Výběr programovacího jazyka

Je důležité vybrat správné programovací jazyky a architektury. Tato rozhodnutí jsou často řízena sadami dovedností nebo standardizovanými technologiemi v organizaci. Je však nezbytné vyhodnotit výkon, odolnost a celkové schopnosti různých jazyků a architektur.

Aspekty návrhu

• Možnosti vývojové sady. Existují rozdíly v možnostech nabízených sadami SDK služeb Azure v různých jazycích. Tyto rozdíly můžou ovlivnit vaši volbu služby Azure nebo programovacího jazyka. Pokud je například služba Azure Cosmos DB proveditelnou možností, go nemusí být vhodný vývojový jazyk, protože neexistuje žádná sada SDK první strany.

• Aktualizace funkcí Zvažte, jak často se sada SDK aktualizuje o nové funkce pro vybraný jazyk. Běžně používané sady SDK, jako jsou knihovny .NET a Java, se často aktualizují. Jiné sady SDK nebo sady SDK pro jiné jazyky se můžou aktualizovat méně často.

• Více programovacích jazyků nebo architektur. K podpoře různých složených úloh můžete použít více technologií. Měli byste se však vyhnout rozrůstaní, protože přináší složitost správy a provozní výzvy.

• Výpočetní možnost. Starší verze nebo proprietární software nemusí běžet ve službách PaaS. Také možná nebudete moct do kontejnerů zahrnout starší nebo proprietární software.

Doporučení k návrhu

• Vyhodnoťte všechny relevantní sady Azure SDK pro funkce, které potřebujete, a zvolených programovacích jazyků. Ověřte soulad s nefunkčními požadavky.

• Optimalizujte výběr programovacích jazyků a architektur na úrovni mikroslužeb. Podle potřeby používejte více technologií.

• Určete prioritu sady .NET SDK pro optimalizaci spolehlivosti a výkonu. Sady .NET Azure SDK obvykle poskytují více funkcí a často se aktualizují.

Další krok

Projděte si důležité informace o aplikační platformě.

Aplikační platforma