Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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, která pocházejí z konkrétních problémů, což může mít vliv na spolehlivost, zabezpečení, náklady a provoz. Pokud se nezmírní, rizika nakonec vedou k nevýkonnosti výkonu. Tyto vzory jsou podporovány reálným prostředím, jsou navržené pro cloudové škálování a provozní modely a jsou ze své podstaty nezávislé na dodavatelích. Použití dobře 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, řeší škálovatelnost, ladění výkonu, stanovení priorit úkolů a odstranění kritických bodů.
Následující tabulka shrnuje vzory návrhu architektury, které podporují cíle efektivity výkonu.
| Vzor | Shrnutí |
|---|---|
| Asynchronní žádost –odpověď | Zlepšuje rychlost odezvy a škálovatelnost systémů oddělením fází interakce požadavků a odpovědí 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, protože to umožňuje kapacita. |
| Back-endy pro front-endy | Individualizuje vrstvu služby úlohy vytvořením samostatných služeb, které jsou exkluzivní pro konkrétní rozhraní front-endu. Toto oddělení umožňuje optimalizovat způsoby, které nemusí být možné s vrstvou sdílených služeb. Když zpracováváte jednotlivé klienty jinak, můžete optimalizovat výkon pro omezení a funkčnost konkrétního klienta. |
| Přepážka lodi | Zavádí segmentaci mezi komponentami za účelem izolace poloměru výbuchu poruch. Tento návrh umožňuje, aby každá přepěťová hlava byla individuálně škálovatelná tak, aby vyhovovala potřebám úkolu zapouzdřeného v přepážce. |
| Doplňování mezipaměti | Optimalizuje přístup k často čitelným datům tím, že zavádí mezipaměť naplněnou na vyžádání. Mezipaměť se pak použije u následných požadavků na stejná data. Tento model je zvláště užitečný u dat náročných na čtení, která se často nemění a dokáže tolerovat určité množství neautnosti. Cílem této implementace je zajistit lepší výkon v systému celkově tím, že tento typ dat přesměruje do mezipaměti místo toho, abyste je z něj získali 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, když dojde k kritickým bodům výkonu v centralizované topologii orchestrace. |
| Jistič | Zabraňuje průběžným požadavkům na špatnou nebo nedostupnou závislost. Přístup k chybě při opakování může vést k nadměrnému využití prostředků během obnovení závislostí 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 uživatelé načítali data datové části pouze v případě potřeby a v době, kdy je to vhodné. |
| Konkurenční spotřebitelé | Použije distribuované a souběžné zpracování pro efektivní zpracování položek ve frontě. Tento model podporuje distribuci zatížení napříč všemi uzly příjemců a dynamickým škálováním, které je založené na hloubkách fronty. |
| Konsolidace výpočetních prostředků | 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í kapacity volného uzlu, aby se snížilo nadměrné zřizování. Běžným příkladem jsou orchestrátory kontejnerů. Velké (vertikálně škálované) výpočetní instance se často používají ve fondu zdrojů pro tyto infrastruktury. |
| Oddělení odpovědnosti příkazů a dotazů (CQRS) | Odděluje operace čtení a zápisu datového modelu aplikace. Toto oddělení umožňuje cílenou optimalizaci 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í a zápisu. |
| Stampy nasazení | Poskytuje přístup k 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 se často shoduje s definovanými jednotkami škálování ve vaší úloze: protože další kapacita je potřeba nad rámec toho, co poskytuje jedna jednotka škálování, nasadí se pro horizontální navýšení kapacity další razítko nasazení. |
| Event Sourcing | Považuje změnu stavu za řadu událostí a zachytává je v neměnném protokolu jen pro připojení. V závislosti na vaší úloze může tento model, obvykle v kombinaci s CQRS, vhodným návrhem domény a strategickým snímkováním zlepšit výkon. Vylepšení výkonu jsou způsobená operacemi jen pro atomické připojení a zabránění uzamčení databáze pro zápisy a čtení. |
| Federovaná identita | Deleguje vztah důvěryhodnosti na zprostředkovatele identity, který je externí pro úlohu pro správu uživatelů a poskytování ověřování pro vaši aplikaci. Když přesměrujete správu a ověřování uživatelů, můžete prostředky aplikace věnovat jiným prioritám. |
| Vrátný | Přesměruje zpracování požadavků, které je určené speciálně pro vynucení řízení přístupu a zabezpečení před předáním požadavku do back-endového uzlu. Tento model se často používá k implementaci omezování na úrovni brány místo implementace kontrol rychlosti na úrovni uzlu. Koordinace stavu rychlosti mezi všemi uzly není ze své podstaty výkonná. |
| Agregace brány | Zjednodušuje interakci klientů s vaší úlohou tím, že agreguje volání více back-endových služeb v rámci jednoho požadavku. Tento návrh může mít menší latenci než návrh, ve kterém klient vytváří více připojení. Ukládání do mezipaměti je také běžné v implementacích agregace, protože minimalizuje volání do back-endových systémů. |
| Přesměrování zpracování brány | Přesměruje zpracování požadavků na zařízení brány před předáním požadavku do back-endového uzlu 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 umožňuje používat méně prostředků na uzel, protože funkce jsou centralizované v bráně. Implementaci přetěžované funkce můžete optimalizovat nezávisle na kódu aplikace. Funkce poskytované přesměrovanou platformou už pravděpodobně budou vysoce výkonné. |
| Směrování brány | 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 ve vašem systému a vyrovnávat zatížení. |
| Geoda | Nasadí systémy, které pracují 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 klienta, který se může připojit k libovolné geografické instanci. Můžete ji použít k poskytování aplikace z oblasti, která je nejblíže vaší distribuované uživatelské bázi. Tím se snižuje latence tím, že eliminujete vzdálený provoz a protože sdílíte infrastrukturu pouze mezi uživateli, kteří aktuálně používají stejnou geode. |
| Monitorování koncových bodů stavu | Poskytuje způsob, jak monitorovat stav nebo stav systému zveřejněním koncového bodu, který je speciálně urč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ů, které jsou ověřeny jako v pořádku. S další konfigurací můžete také získat metriky o dostupné kapacitě uzlu. |
| Indexová tabulka | Optimalizuje načítání dat v distribuovaných úložištích dat tím, že klientům umožňuje vyhledat metadata, aby je bylo možné přímo načíst, a vyhnout se nutnosti provádět úplné kontroly úložiště dat. Klienti odkazují na jejich horizontální oddíl, oddíl nebo koncový bod, což umožňuje dynamické dělení dat pro optimalizaci výkonu. |
| Materializované zobrazení | Používá předem propočí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řekompilace databázového stroje nebo klienta pro každou žádost. Tento návrh snižuje celkovou spotřebu prostředků. |
| Prioritní fronta | 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 umožňuje soustředit se na výkon na většinu práce citlivé na čas. |
| Vydavatel/odběratel | Oddělí komponenty architektury nahrazením přímé komunikace mezi klientem a službami prostřednictvím komunikace 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 potřebuje pro konkrétní zprávu. |
| vyrovnávání zatíženíQueue-Based | Řídí úroveň příchozích požadavků nebo úkolů tím, že je uloží do vyrovnávací paměti ve frontě a nechá procesor fronty zpracovat řízeným tempem. Tento přístup umožňuje záměrný návrh 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 napříč systémem 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 ji také použít k určení priority provádění práce s vyšší prioritou oproti práci s nižší prioritou. |
| Sharding | Nasměruje zatížení do konkrétního logického cíle za účelem zpracování konkrétního požadavku a povolení kolokace pro optimalizaci. Při použití horizontálního dělení ve vaší strategii škálování se data nebo zpracování izolují s horizontálním oddílem, takže soupeří o prostředky pouze s jinými požadavky směrovanými na tento horizontální oddíl. Horizontální dělení můžete použít také k optimalizaci na základě zeměpisné polohy. |
| Postranní vozík motocyklu | Rozšiřuje funkce aplikace zapouzdřením neprimárních nebo průřezových úloh v doprovodném procesu, který existuje společně s hlavní aplikací. Úkoly křížového dělení můžete přesunout do jednoho procesu, který se dá škálovat napříč několika instancemi hlavního procesu, což snižuje potřebu nasadit duplicitní funkce pro každou instanci aplikace. |
| Hostování statického obsahu | Optimalizuje doručování statického obsahu klientům úloh pomocí hostitelské platformy, která je určená pro tento účel. Snižování zodpovědnosti na externalizovaného hostitele pomáhá zmírnit přetížení a umožňuje používat aplikační platformu pouze k poskytová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, tento model pomáhá zmírnit přetížení, které může vést k kritickým bodům výkonu. Můžete ho také použít k proaktivnímu zabránění hlučným scénářům sousedů. |
| Osobní klíč | Uděluje přístup k prostředku s omezeným zabezpečením bez použití zprostředkujícího prostředku pro proxy přístup. Tím se zpracování přesměruje jako výhradní vztah mezi klientem a prostředkem, aniž by bylo nutné komponentu ambasadora, která musí zpracovávat všechny požadavky klientů výkonným způsobem. Výhoda použití tohoto modelu je nejvýznamnější v případě, že proxy nepřidá hodnotu k transakci. |
Další kroky
Projděte si vzory návrhu architektury, které podporují ostatní pilíře architektury Azure Well-Architected: