Model tanečního smýšlce

Každá komponenta systému se účastní rozhodovacího procesu týkajícího se pracovního postupu obchodní transakce místo toho, aby se spoléhala na centrální bod řízení.

Kontext a problém

V architektuře mikroslužeb se často jedná o případ, že je cloudová aplikace rozdělená do několika malých služeb, které spolupracují na zpracování komplexní obchodní transakce. Za účelem snížení párování mezi službami zodpovídá každá služba za jednu obchodní operaci. Mezi výhody patří rychlejší vývoj, menší základ kódu a škálovatelnost. Návrh efektivního a škálovatelného pracovního postupu je ale výzvou a často vyžaduje složitou komunikaci mezi službami.

Služby vzájemně komunikují pomocí dobře definovaných rozhraní API. Dokonce i jedna obchodní operace může vést k několika voláním typu point-to-point mezi všemi službami. Běžným vzorem komunikace je použití centralizované služby, která funguje jako orchestrátor. Bere na vědomí všechny příchozí požadavky a deleguje operace na příslušné služby. Tím také spravuje pracovní postup celé obchodní transakce. Každá služba právě dokončí operaci a neví o celkovém pracovním postupu.

Model orchestrátoru snižuje komunikaci mezi službami typu point-to-point, ale má určité nevýhody z důvodu úzké vazby mezi orchestrátorem a dalšími službami, které se účastní zpracování obchodní transakce. Aby mohl orchestrátor spouštět úlohy v sekvenci, musí mít určité znalosti domény o zodpovědnostech těchto služeb. Pokud chcete přidat nebo odebrat služby, stávající logika se přeruší a budete muset znovu připojit části komunikační cesty. I když můžete pracovní postup nakonfigurovat, snadno přidávat nebo odebírat služby pomocí dobře navrženého orchestrátoru, taková implementace je složitá a obtížně se udržuje.

Řešení

Zajistěte si nezávislost na centrálním orchestrátoru a dejte každé službě na výběr, kdy a jak se zpracuje obchodní operace.

Jedním ze způsobů implementace hierarchie je použití vzoru asynchronního zasílání zpráv ke koordinaci obchodních operací.

Požadavek klienta publikuje zprávy do fronty zpráv. Při doručení zpráv se odsílají odběratelům nebo službám, které se zajímají o tuto zprávu. Každá předplacená služba provede svou operaci, jak je uvedeno ve zprávě, a reaguje na frontu zpráv s úspěchem nebo selháním operace. 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, může sběrnice zpráv tuto operaci opakovat.

Díky tomu služby mezi sebou navzájem tančí pracovní postup bez závislosti na orchestrátoru nebo přímé komunikaci mezi nimi.

Vzhledem k tomu, že neexistuje komunikace typu point-to-point, tento model pomáhá snížit propojení mezi službami. Může také odebrat kritické body výkonu způsobené orchestrátorem, když musí řešit všechny transakce.

Kdy se má tento model použít

Pokud očekáváte, že budete služby často aktualizovat nebo nahrazovat, použijte model hierarchie a nakonec přidejte nebo odeberte některé služby. Celou aplikaci je možné upravit s menším úsilím a minimálním přerušením stávajících služeb.

Tento model zvažte, pokud dochází k kritickým bodům výkonu v centrálním orchestrátoru.

Tento model je přirozený model pro architekturu bez serveru, kde můžou být všechny služby krátkodobé nebo řízené událostmi. Služby se můžou aktivovat z důvodu události, provést úkol a po dokončení úkolu se odeberou.

Problémy a důležité informace

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

Pokud se službě nepodaří dokončit obchodní operaci, může být obtížné ji obnovit z této chyby. Jedním ze způsobů je mít službu indikující selhání aktivací události. Jiná služba se přihlásí k odběru těchto neúspěšných událostí, provádí nezbytné akce, jako je použití kompenzačních transakcí k vrácení úspěšných operací v požadavku zpět. Neúspěšná služba může také selhat při spuštění události selhání. V takovém případě zvažte použití mechanismu opakování nebo vypršení časového limitu k rozpoznání této operace jako selhání. Příklad najdete v části Příklad .

Pracovní postup je jednoduchý implementovat, když chcete zpracovávat nezávislé obchodní operace paralelně. Můžete použít jednu sběrnici zpráv. Pracovní postup se ale může komplikovat, když se musí v sekvenci objevit hierarchie. Například služba C může svou operaci spustit až po úspěšném dokončení operací služby A a služby B. Jedním z přístupů je mít více sběrnic zpráv nebo front, které získávají zprávy v požadovaném pořadí. Další informace najdete v části Příklad .

Pokud se počet služeb rychle rozrůstá, stane se vzorem telemetrie výzvu. 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é.

Orchestrátor centrálně spravuje odolnost pracovního postupu a může se stát jediným bodem selhání. Na druhou stranu, pro hierarchii je role rozdělena mezi všechny služby a odolnost se stává méně robustní.

Každá služba nejen zodpovídá za odolnost její operace, ale také za pracovní postup. Tato odpovědnost může být pro službu náročná a těžko se implementuje. Každá služba musí opakovat přechodné, netransientní a vypršení časového limitu, aby se požadavek v případě potřeby řádně ukončil. Služba musí také pečlivě komunikovat o úspěchu nebo selhání operace, aby ostatní služby mohly jednat odpovídajícím způsobem.

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 klienta 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: vytvoření nebo aktualizace balíčku, přiřazení dronu k doručení balíčku a správné zpracování doručení, 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 bude navíc nedoručována kvůli pozdějšímu zpracování. 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