Model tanečního smýšlce

Decentralizovaná logika pracovního postupu a distribuce zodpovědností do jiných komponent v rámci systému.

Kontext a problém

Cloudová aplikace se často dělí na několik malých služeb, které spolupracují na zpracování komplexní obchodní transakce. Dokonce i jedna operace (v rámci transakce) může vést k několika voláním typu point-to-point mezi všemi službami. V ideálním případě by tyto služby měly být volně svázány. Návrh pracovního postupu, který je distribuovaný, efektivní a škálovatelný, je náročný, protože často zahrnuje složitou komunikaci mezi službami.

Běžným vzorem komunikace je použití centralizované služby nebo orchestrátoru. Příchozí požadavky procházejí orchestrátorem, protože deleguje operace na příslušné služby. Každá služba pouze dokončí svou odpovědnost a neví o celkovém pracovním postupu.

Model orchestrátoru se obvykle implementuje jako vlastní software a má znalosti domény o zodpovědnostech těchto služeb. Výhodou je, že orchestrátor může konsolidovat stav transakce na základě výsledků jednotlivých operací prováděných podřízenými službami.

Existují však některé nevýhody. Přidání nebo odebrání služeb může narušit stávající logiku, protože potřebujete převést části komunikační cesty. Díky této závislosti je implementace orchestrátoru složitá a obtížně se udržuje. Orchestrátor může mít negativní dopad na spolehlivost úlohy. Při zatížení může zavádět kritické body výkonu a být jediným bodem selhání. Může také způsobit kaskádové selhání v podřízených službách.

Řešení

Delegujte logiku zpracování transakcí mezi službami. Nechte každou službu rozhodnout a účastnit se pracovního postupu komunikace pro obchodní operaci.

Model je způsob, jak minimalizovat závislost na vlastním softwaru, který centralizuje pracovní postup komunikace. Komponenty implementují společnou logiku, protože mezi sebou vytvoří pracovní postup, aniž by mezi sebou měli přímou komunikaci.

Běžným způsobem implementace hierarchie je použití zprostředkovatele zpráv, který ukládá požadavky do vyrovnávací paměti, dokud podřízené komponenty deklarují a zpracovávají je. Obrázek znázorňuje zpracování žádostí prostřednictvím modelu předplatitele vydavatele.

1. Požadavky klienta se zařadí do fronty jako zprávy ve zprostředkovateli zpráv.

2. Služby nebo odběratel se dotazují zprostředkovatele, aby zjistili, jestli mohou tuto zprávu zpracovat na základě implementované obchodní logiky. Zprostředkovatel může také odesílat zprávy odběratelům, kteří mají zájem o tuto zprávu.

3. Každá předplacená služba provede svou operaci, jak je uvedeno ve zprávě, a reaguje na zprostředkovatele s úspěchem nebo selháním operace.

4. V případě úspěchu může služba odeslat zprávu zpět do stejné fronty nebo do jiné fronty zpráv, aby jiná služba v případě potřeby pokračovala v pracovním postupu. Pokud operace selže, zprostředkovatel zpráv pracuje s dalšími službami a kompenzuje tuto operaci nebo celou transakci.

Problémy a důležité informace

Decentralizovaná orchestrace může způsobit problémy při správě pracovního postupu.

• Ruční selhání může být náročné. Komponenty v aplikaci můžou provádět atomické úlohy, ale můžou mít stále úroveň závislosti. Selhání v jedné komponentě může mít vliv na ostatní, což může způsobit zpoždění při dokončování celkového požadavku.

  Pro řádné zpracování selhání může implementace kompenzačních transakcí zavést složitost.

  

• Vzor je vhodný pro pracovní postup, ve kterém se nezávislé obchodní operace zpracovávají paralelně. Pracovní postup se může komplikovat, když se musí v sekvenci objevit hierarchie. Služba D může například spustit svou operaci až po dokončení operací service B a service C s úspěchem.

  

• Model se stává výzvou, pokud se počet služeb rychle zvětšuje. Vzhledem k vysokému počtu nezávislých pohyblivých částí se pracovní postup mezi službami obvykle zkompiluje. Distribuované trasování je také obtížné.

• Při návrhu řízeném orchestrátorem se centrální komponenta může částečně účastnit a delegovat logiku odolnosti na jinou komponentu, která opakuje přechodné, nepřehledné a trvalé selhání časového limitu. S rozpuštěním orchestrátoru v modelu hierarchie by podřízené komponenty neměly tyto úlohy odolnosti vyzvednout. Ty musí stále zpracovávat obslužná rutina odolnosti. Podřízené komponenty ale musí přímo komunikovat s obslužnou rutinou odolnosti a zvýšit komunikaci typu point-to-point.

Kdy se má tento model použít

Tento model použijte v těchto případech:

• Podřízené komponenty zpracovávají atomické operace nezávisle. Představte si to jako mechanismus "požáru a zapomenutí". Komponenta zodpovídá za úlohu, která nemusí být aktivně spravována. Po dokončení úkolu odešle oznámení ostatním komponentám.

• Očekává se, že se komponenty aktualizují a často nahradí. Model umožňuje úpravu aplikace s menším úsilím a minimálním přerušením stávajících služeb.

• Vzor je přirozeným způsobem vhodný pro bezserverové architektury, které jsou vhodné pro jednoduché pracovní postupy. Komponenty mohou být krátkodobé a řízené událostmi. Když dojde k události, komponenty se provedou, provádějí své úkoly a po dokončení úkolu se odeberou.

• Centrální orchestrátor zavádí kritické body výkonu.

Tento model nebude pravděpodobně vhodný v následujících případech:

• Aplikace je složitá a vyžaduje centrální komponentu pro zpracování sdílené logiky, aby podřízené komponenty zůstaly odlehčené.

• Existují situace, kdy komunikace mezi komponentami typu point-to-point je nevyhnutelné.

• Potřebujete konsolidovat všechny operace zpracovávané podřízenými komponentami pomocí obchodní logiky.

Návrh úloh

Architekt by měl vyhodnotit, jak lze v návrhu své úlohy použít model hierarchie k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklad

Tento příklad ukazuje model hierarchie vytvořením řízené události, nativní cloudové úlohy běžící funkce spolu s mikroslužbami. Když klient požádá o odeslání balíčku, úloha přiřadí dron. Jakmile je balíček připravený k vyzvednutí naplánovaným dronem, proces doručení se spustí. Během přenosu úloha zpracovává doručení, dokud nezískne stav odeslání.

Tento příklad je refaktoringem implementace doručování pomocí dronů, která nahrazuje model Orchestrator vzorem Hierarchie.

Služba Ingestování zpracovává požadavky klientů a převádí je na zprávy včetně podrobností o doručení. Obchodní transakce se zahájí po využívání těchto nových zpráv.

Jedna klientská obchodní transakce vyžaduje tři různé obchodní operace:

1. Vytvoření nebo aktualizace balíčku
2. Přiřazení dronu k doručení balíčku
3. Zpracujte dodávku, která se skládá z kontroly a nakonec zvýšení povědomí při odeslání.

Tři mikroslužby provádějí obchodní zpracování: balíček, plánovač dronů a služby doručování. Místo centrálního orchestrátoru služby komunikují mezi sebou pomocí zasílání zpráv. Každá služba by byla zodpovědná za implementaci protokolu předem, který koordinuje decentralizovaným způsobem obchodní pracovní postup.

Návrh

Obchodní transakce se zpracovává v posloupnosti prostřednictvím více segmentů směrování. Každý segment směrování sdílí jednu sběrnici zpráv mezi všemi obchodními službami.

Když klient odešle žádost o doručení prostřednictvím koncového bodu HTTP, služba příjmu dat ji přijme, převede takový požadavek na zprávu a pak zprávu publikuje do sdílené sběrnice zpráv. Předplacené obchodní služby budou využívat nové zprávy přidané do sběrnice. Při přijetí zprávy můžou obchodní služby dokončit operaci s úspěchem, selháním nebo vypršením časového limitu požadavku. V případě úspěchu služby reagují na sběrnici se stavovým kódem OK, vytvoří novou zprávu operace a odešlou ji do sběrnice zpráv. Pokud dojde k selhání nebo vypršení časového limitu, služba hlásí selhání odesláním kódu důvodu do sběrnice zpráv. Zpráva se navíc přidá do fronty nedoručených zpráv. Zprávy, které nelze přijmout nebo zpracovat v přiměřeném a přiměřeném časovém intervalu, se také přesouvají knihovnu DLQ.

Návrh používá více sběrnic zpráv ke zpracování celé obchodní transakce. Microsoft Azure Service Bus a Microsoft Azure Event Grid se skládají, aby pro tento návrh poskytovaly platformu služby zasílání zpráv. Úloha se nasadí v Azure Container Apps hostující službu Azure Functions pro příjem dat a aplikace zpracovávající zpracování řízené událostmi, které spouští obchodní logiku.

Návrh zajišťuje, aby se scéna v sekvenci chytá k hierarchii. Jeden obor názvů služby Azure Service Bus obsahuje téma se dvěma předplatnými a frontou pracující s relacemi. Služba Ingestování publikuje zprávy do tématu. Služba Package Service a služba Plánovač dronů se přihlašují k odběru tématu a publikují zprávy, které sdělují úspěch frontě. Včetně běžného identifikátoru relace, který identifikátor GUID přidružený k identifikátoru doručení, umožňuje uspořádané zpracování nevázaných sekvencí souvisejících zpráv. Služba doručování čeká na každou transakci dvě související zprávy. První zpráva indikuje, že balíček je připravený k odeslání, a druhý signál, že je naplánovaný dron.

Tento návrh používá Azure Service Bus ke zpracování vysoce hodnotných zpráv, které nelze během celého procesu doručování ztratit ani duplikovat. Po odeslání balíčku se také publikuje změna stavu ve službě Azure Event Grid. V tomto návrhu odesílatel události nemá žádné očekávání o způsobu zpracování změny stavu. Podřízené organizační služby, které nejsou součástí tohoto návrhu, můžou naslouchat tomuto typu události a reagovat na provádění konkrétní logiky obchodního účelu (to znamená odeslat e-mailem stav odeslané objednávky uživateli).

Pokud plánujete tento postup nasadit do jiné výpočetní služby, jako je například varná deska aplikace v podu, může být implementována se dvěma kontejnery ve stejném podu. Jeden kontejner spouští ambasadora, který komunikuje s vaší sběrnici předvoleb zpráv, zatímco druhý spouští obchodní logiku. Přístup se dvěma kontejnery ve stejném podu zlepšuje výkon a škálovatelnost. Ambasador a obchodní služba sdílejí stejnou síť, která umožňuje nízkou latenci a vysokou propustnost.

Aby nedocházelo k kaskádným operacím opakování, které by mohly vést k vícenásobnému úsilí, měly by obchodní služby okamžitě označit nepřijatelné zprávy. Tyto zprávy je možné rozšířit pomocí dobře známých kódů důvodů nebo definovaného kódu aplikace, takže je možné je přesunout do fronty nedoručených zpráv (DLQ). Zvažte správu problémů s konzistencí při implementaci Saga z podřízených služeb. Jiná služba může například zpracovávat nedoručené zprávy pro účely nápravy pouze provedením kompenzace, rety nebo kontingenční transakce.

Obchodní služby jsou idempotentní, aby se zajistilo, že operace opakování nebudou mít za následek duplicitní prostředky. Například služba Package používá operace upsert k přidání dat do úložiště dat.

Související prostředky

Zvažte tyto vzory ve vašem návrhu pro hierarchii.

• Modularizace obchodních služeb pomocí vzoru návrhu ambasadora.

• Implementujte model vyrovnávání zatížení založený na frontě pro zpracování špiček zatížení.

• Používejte asynchronní distribuované zasílání zpráv prostřednictvím vzoru odběratele vydavatele.

• Kompenzační transakce slouží k vrácení řady úspěšných operací zpět v případě selhání jedné nebo více souvisejících operací.

• Informace o použití zprostředkovatele zpráv v infrastruktuře zasílání zpráv najdete v tématu Možnosti asynchronního zasílání zpráv v Azure.

• Volba mezi službami zasílání zpráv Azure