Vzory návrhu cloudu, které podporují efektivitu výkonu

  • Článek

Při návrhu architektur úloh byste měli používat oborové vzory, které řeší běžné výzvy. Vzory vám můžou pomoct s úmyslným kompromisem v rámci úloh a optimalizovat požadovaný výsledek. Můžou také pomoct zmírnit rizika vyplývající z konkrétních problémů, které můžou mít vliv na spolehlivost, zabezpečení, náklady a provoz. Pokud se nezmírní, rizika nakonec povedou k nevýkonnosti výkonu. Tyto vzory jsou založené na reálných zkušenostech, jsou navržené pro cloudové škálování a provozní modely a jsou ze své podstaty nezávislé na dodavatelích. Použití známých vzorů jako způsobu standardizace návrhu úloh je součástí efektivity provozu.

Mnoho vzorů návrhu přímo podporuje jeden nebo více pilířů architektury. Vzory návrhu, které podporují pilíř Efektivita výkonu, se zaměřují na škálovatelnost, ladění výkonu, stanovení priority úkolů a odstranění kritických bodů.

Vzory návrhu pro efektivitu výkonu

Následující tabulka shrnuje vzory návrhu cloudu, které podporují cíle efektivity výkonu.

Vzor Souhrn
Asynchronní požadavek-odpověď Zlepšuje odezvu a škálovatelnost systémů oddělením fází žádostí a odpovědí v interakcích pro procesy, které nevyžadují okamžité odpovědi. Pomocí asynchronního vzoru můžete maximalizovat souběžnost na straně serveru. Tento model můžete použít k naplánování dokončení práce, jak to kapacita umožňuje.
Backends for Frontends Individualizuje vrstvu služby úlohy vytvořením samostatných služeb, které jsou výhradní pro konkrétní front-endové rozhraní. Toto oddělení umožňuje optimalizovat způsoby, které nemusí být u vrstvy sdílené služby možné. Když pracujete s jednotlivými klienty odlišně, můžete optimalizovat výkon pro konkrétní omezení a funkce klienta.
Bulkhead Zavádí segmentaci mezi komponentami, aby se izoloval poloměr výbuchu poruch. Tento návrh umožňuje, aby byla každá přepážka individuálně škálovatelná tak, aby vyhovovala potřebám úlohy, která je zapouzdřená v přepážce.
Cache-Aside Optimalizuje přístup k často čtenými datům zavedením mezipaměti, která se naplní na vyžádání. Mezipaměť se pak použije v následných požadavcích na stejná data. Tento model je užitečný zejména u dat náročných na čtení, která se často nemění a můžou tolerovat určitou míru neschůdnosti. Cílem této implementace je zajistit celkově lepší výkon v systému tím, že tento typ dat přesměrovává do mezipaměti, místo aby je bylo možné odebírat z úložiště dat.
Choreografie Koordinuje chování autonomních distribuovaných komponent v úloze pomocí decentralizované komunikace řízené událostmi. Tento model může poskytnout alternativu v případě, že v topologii centralizované orchestrace dochází k kritickým bodům výkonu.
Circuit Breaker Zabraňuje průběžným požadavkům na nefunkční nebo nedostupnou závislost. Přístup s opakováním při chybě může vést k nadměrnému využití prostředků během obnovení závislosti a může také přetížit výkon závislosti, která se pokouší o obnovení.
Kontrola deklarace identity Odděluje data od toku zasílání zpráv a poskytuje způsob, jak samostatně načíst data související se zprávou. Tento model zlepšuje efektivitu a výkon vydavatelů zpráv, odběratelů a samotné sběrnice zpráv, když systém zpracovává velké datové části. Funguje tak, že zmenšuje velikost zpráv a zajišťuje, aby příjemci načítali data datové části pouze v případě potřeby a v vhodném čase.
Competing Consumers Použije distribuované a souběžné zpracování k efektivnímu zpracování položek ve frontě. Tento model podporuje distribuci zatížení napříč všemi uzly příjemce a dynamické škálování založené na hloubce fronty.
Compute Resource Consolidation Optimalizuje a konsoliduje výpočetní prostředky zvýšením hustoty. Tento model kombinuje více aplikací nebo komponent úlohy ve sdílené infrastruktuře. Tato konsolidace maximalizuje využití výpočetních prostředků pomocí volné kapacity uzlu, aby se omezilo nadměrné zřizování. Běžným příkladem jsou orchestrátory kontejnerů. Pro tyto infrastruktury se ve fondu zdrojů často používají velké (vertikálně škálované) výpočetní instance.
Command and Query Responsibility Segregation (CQRS) Odděluje operace čtení a zápisu datového modelu aplikace. Toto oddělení umožňuje cílené optimalizace výkonu a škálování pro konkrétní účel každé operace. Tento návrh je nejužitečnější v aplikacích s vysokým poměrem čtení k zápisu.
Stampy nasazení Poskytuje přístup pro vydání konkrétní verze aplikace a její infrastruktury jako řízené jednotky nasazení na základě předpokladu, že budou souběžně nasazeny stejné nebo různé verze. Tento model často odpovídá definovaným jednotkám škálování ve vaší úloze: vzhledem k tomu, že je potřeba další kapacita nad rámec toho, co poskytuje jedna jednotka škálování, nasadí se další razítko nasazení pro horizontální navýšení kapacity.
Event Sourcing Považuje změny stavu za řadu událostí a zachycuje je v neměnném protokolu jen pro připojení. V závislosti na úlohách může tento model, obvykle v kombinaci s CQRS, návrhem vhodné domény a strategickým vytvářením snímků zvýšit výkon. Vylepšení výkonu jsou způsobená atomovými operacemi jen s připojením a zabráněním zamykání databáze pro zápisy a čtení.
Federated Identity Deleguje vztah důvěryhodnosti na zprostředkovatele identity, který je externí pro danou úlohu za účelem správy uživatelů a poskytování ověřování pro vaši aplikaci. Při snižování zátěže správy a ověřování uživatelů můžete prostředky aplikace věnovat jiným prioritám.
Gatekeeper Přesměruje zpracování požadavků, které je určené speciálně pro vynucování zabezpečení a řízení přístupu před předáním požadavku na back-endový uzel a po jeho předání do back-endového uzlu. Tento model se často používá k implementaci omezování na úrovni brány, nikoli k implementaci kontrol rychlosti na úrovni uzlu. Koordinace stavu rychlosti mezi všemi uzly není ze své podstaty výkonná.
Gateway Aggregation Zjednodušuje interakci klienta s vašimi úlohami tím, že agreguje volání do několika back-endových služeb v jednom požadavku. Tento návrh může mít nižší latenci než návrh, ve kterém klient naváže více připojení. Ukládání do mezipaměti je také běžné v implementacích agregace, protože minimalizuje volání back-endových systémů.
Gateway Offloading Přesměruje zpracování požadavků na zařízení brány před předáním požadavku na back-endový uzel a po jeho předání do back-endového uzlu. Přidání brány pro přesměrování zátěže do procesu žádosti vám umožní používat méně prostředků na uzel, protože funkce jsou centralizované v bráně. Implementaci funkcí se přesměrováním zatížení můžete optimalizovat nezávisle na kódu aplikace. Funkce poskytované platformou se snižováním zatížení už pravděpodobně budou vysoce výkonné.
Gateway Routing Směruje příchozí síťové požadavky do různých back-endových systémů na základě záměrů požadavků, obchodní logiky a dostupnosti back-endu. Směrování brány umožňuje distribuovat provoz mezi uzly v systému a vyrovnávat tak zatížení.
Geode Nasadí systémy, které fungují v režimech dostupnosti aktivní-aktivní napříč několika zeměpisnými oblastmi. Tento model používá replikaci dat k podpoře ideálního připojení klienta k libovolné geografické instanci. Můžete ho použít k poskytování aplikace z oblasti, která je nejblíže vaší distribuované uživatelské základně. Tím se sníží latence díky eliminování dálkového provozu a protože sdílíte infrastrukturu jenom mezi uživateli, kteří aktuálně používají stejnou geodu.
Health Endpoint Monitoring Poskytuje způsob, jak monitorovat stav systému zveřejněním koncového bodu, který je speciálně navržený pro tento účel. Tyto koncové body můžete použít ke zlepšení vyrovnávání zatížení směrováním provozu pouze do uzlů, u které je ověřeno, že jsou v pořádku. S další konfigurací můžete také získat metriky pro dostupnou kapacitu uzlu.
Index Table Optimalizuje načítání dat v distribuovaných úložištích dat tím, že klientům umožňuje vyhledávat metadata tak, aby data bylo možné přímo načíst, takže není nutné provádět úplné prohledávání úložiště dat. Klienti jsou nasměrování na jejich horizontální oddíl, oddíl nebo koncový bod, což umožňuje dynamické dělení dat pro optimalizaci výkonu.
Materialized View Používá předpočítaná zobrazení dat k optimalizaci načítání dat. Materializovaná zobrazení ukládají výsledky složitých výpočtů nebo dotazů bez nutnosti přepočítání databázového stroje nebo klienta pro každý požadavek. Tento návrh snižuje celkovou spotřebu prostředků.
Priority Queue Zajišťuje zpracování a dokončení položek s vyšší prioritou před položkami s nižší prioritou. Oddělení položek na základě obchodní priority vám umožní zaměřit výkon na práci, která je nejvíce citlivá na čas.
Vydavatel/odběratel Oddělí komponenty architektury nahrazením přímé komunikace klient-služba nebo klient-služba za komunikaci prostřednictvím zprostředkujícího zprostředkovatele zpráv nebo sběrnice událostí. Oddělení vydavatelů od příjemců umožňuje optimalizovat výpočetní prostředky a kód speciálně pro úlohu, kterou příjemce musí provést pro konkrétní zprávu.
Queue-Based Load Leveling Řídí úroveň příchozích požadavků nebo úkolů tím, že je ukládá do vyrovnávací paměti ve frontě a procesor fronty je může zpracovávat řízeným tempem. Tento přístup umožňuje záměrné navrhování výkonu propustnosti, protože příjem požadavků nemusí korelovat s rychlostí, ve které se zpracovávají.
Scheduler Agent Supervisor Efektivně distribuuje a redistribuuje úlohy v systému na základě faktorů, které jsou v systému pozorovatelné. Tento model používá metriky výkonu a kapacity ke zjištění aktuálního využití a směrování úloh do agenta, který má kapacitu. Můžete ho také použít k určení priority provádění práce s vyšší prioritou před prací s nižší prioritou.
Sharding Směruje zatížení do konkrétního logického cíle za účelem zpracování konkrétního požadavku a umožňuje optimalizaci kolokace. Když ve strategii škálování použijete horizontální dělení, data nebo zpracování se izolují do horizontálního oddílu, takže soutěží o prostředky pouze s jinými požadavky, které jsou směrovány do daného horizontálního oddílu. K optimalizaci na základě zeměpisné oblasti můžete použít také horizontální dělení.
Sidecar Rozšiřuje funkčnost aplikace zapouzdřením úloh, které nejsou primární nebo průřezové, do doprovodného procesu, který existuje vedle hlavní aplikace. Průřezové úlohy můžete přesunout do jednoho procesu, který se může škálovat napříč několika instancemi hlavního procesu, což snižuje potřebu nasazení duplicitních funkcí pro každou instanci aplikace.
Static Content Hosting Optimalizuje doručování statického obsahu klientům úloh pomocí hostitelské platformy, která je pro tento účel navržená. Přesměrování odpovědnosti na externalizovaného hostitele pomáhá zmírnit zahlcení a umožňuje používat aplikační platformu jenom k zajištění obchodní logiky.
Omezování Omezuje rychlost nebo propustnost příchozích požadavků na prostředek nebo komponentu. Když je systém pod vysokou poptávkou, pomáhá tento model zmírnit zahlcení, které může vést k kritickým bodům výkonu. Můžete ho také použít k tomu, abyste se aktivně vyhnuli situacím s hlučným sousedem.
Valet Key Uděluje přístup k prostředku s omezeným zabezpečením bez použití zprostředkujícího prostředku k proxy přístupu. Tím se zpracování snižuje jako výhradní vztah mezi klientem a prostředkem, aniž by se vyžadovala komponenta ambasador, která musí zpracovávat všechny požadavky klientů výkonným způsobem. Výhodou použití tohoto modelu je, když proxy nepřidává transakci hodnotu.

Další kroky

Projděte si vzory návrhu cloudu, které podporují ostatní pilíře architektury Azure Well-Architected Framework: