Model tanečního smýšlce

Nechte každou službu rozhodnout, kdy a jak zpracovat obchodní operaci, místo aby se spoléhala na centrální orchestrátor. Tento přístup decentralizovaný logiku pracovního postupu a distribuuje odpovědnost mezi komponenty systému.

Kontext a problém

Cloudovou aplikaci obvykle rozdělíte do několika malých služeb, které spolupracují na zpracování komplexní obchodní transakce. 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ě jsou tyto služby volně svázané. Návrh distribuovaného, efektivního a škálovatelného pracovního postupu je náročný, protože 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 splní svůj úkol, aniž by věděla o celkovém pracovním postupu.

Na levé straně šipka, která představuje požadavek klienta, směřuje z ikony klienta na ikonu orchestrátoru uprostřed diagramu. Tři obousměrné šipky spojují ikonu a ikony orchestrátoru pro službu A, službu B a službu C uspořádané svisle na pravé straně. Tyto šipky ukazují, jak orchestrátor odesílá požadavky na služby a přijímá odpovědi. Diagram znázorňuje, jak centrální komponenta orchestrátoru koordinuje a spravuje komunikaci se všemi podřízenými službami.

Orchestrační vzor obvykle implementujete jako vlastní softwarové řešení, které má doménové znalosti o odpovědnosti služeb v rámci systému. Jednou z výhod tohoto přístupu je, že orchestrátor může konsolidovat stav transakce na základě výsledků jednotlivých operací, které provádí podřízené služby.

Tento přístup také vytváří určité překážky. 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 negativně ovlivnit spolehlivost pracovní zátěže. Při zatížení může zavádět kritické body výkonu a být kritickým bodem selhání (SPoF). Pokud orchestrátor selže nebo se přetíží, může se selhání rozšířit do všech závislých podřízených služeb.

Řešení

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

Model choreografie minimalizuje závislost na vlastním softwaru, který centralizuje komunikační tok práce. Komponenty implementují společnou logiku tak, že choreografují pracovní postupy mezi sebou, aniž by mezi sebou přímo komunikovaly.

Běžným způsobem implementace choreografie je použití zprostředkovatele zpráv, který ukládá požadavky do vyrovnávací paměti, dokud je následné komponenty nevyžádají a nezpracují. Následující obrázek ukazuje zpracování požadavků prostřednictvím modelu předplatitele vydavatele.

Diagram znázorňuje implementaci schématu hierarchie, která ke koordinaci komunikace služby používá zprostředkovatele zpráv. Vlevo šipka ukazuje z ikony žádosti klienta na tři symboly obálek v poli, které představují centrálního zprostředkovatele zpráv. Tři obousměrné šipky spojují zprostředkovatele zpráv a služby A, služby B a službu C. Tyto šipky ukazují, že služby přijímají zprávy od zprostředkovatele i odesílají odpovědi.

1. Klientovy žádosti jsou řazeny jako zprávy ve zprostředkovateli zpráv.

2. Služby nebo odběratel se dotazují zprostředkovatele, aby zjistili, jestli může 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 podle toho, jak to zpráva stanoví, a odpoví brokerovi zprávou o úspěchu nebo selhání operace.

4. Pokud je operace úspěšná, může služba publikovat zprávu 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, služba publikuje chybovou zprávu. Služby, které se přihlásí k odběru této zprávy, můžou spouštět předdefinované kompenzační akce pro neúspěšnou operaci nebo celou transakci.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

• Složitost řešení selhání Komponenty v aplikaci můžou spravovat atomické úlohy a záviset na jiných částech systému. Selhání v jedné komponentě může mít vliv na jiné komponenty, což může způsobit zpoždění při dokončování celkového požadavku.

  Pro řádné zpracování selhání implementujete logiku zpracování selhání, která představuje složitost. Logika zpracování selhání, jako jsou kompenzační transakce, je také náchylná k selháním.

  

  Diagram toku znázorňuje logiku zpracování chyb a kompenzace v choreografickém vzoru, který má sekvenční závislosti služeb. V horní části ukazuje počáteční uzel na službu A. Služba A se připojí ke kosočtverci, který ukazuje na službu B na levé straně a na službu C na pravé straně. Šipky ukazují z každé z těchto služeb na rozhodovací diamant, který se ptá, jestli požadavek selže. Cesta označená ano větví ve smyčce zpět k kosočtverci, která spojuje všechny tři služby. Cesta označená jako "ne" pokračuje do pole, ve kterém je uvedeno, že obě služby uspěly. Z tohoto úspěšného stavu proud pokračuje ke službě D, která se připojí k konečnému rozhodovacímu diagramu, jenž se ptá, zda požadavek selže. Cesta 'ano' z tohoto kosočtverce se vrátí nahoru, aby se tok znovu vstoupil před službou D a cesta 'ne' pokračuje směrem dolů ke koncovému uzlu.

• Sekvenční procesy. Tento model vyhovuje pracovnímu postupu, který zpracovává nezávislé obchodní operace paralelně. Pracovní postup se může komplikovat, když je třeba choreografii provést v určitém pořadí. Služba D může například spustit svou operaci až po úspěšném dokončení operací služby B a služby C.

  

  Diagram znázorňuje tok zpráv v choreografickém vzoru, v němž služby zpracovávají operace paralelně a sekvenčně. Nahoře je pět komponent uspořádaných vodorovně: služba A, zprostředkovatel zpráv, služba B, služba C a služba D. Úplně vlevo odešle uživatel žádost službě A. Služba A převede požadavek na zprávu m1_a a publikuje ji do zprostředkovatele zpráv. Pod zprostředkovatelem zpráv ukazuje svislá časová osa, jak každá služba zpracovává zprávy. Ve stínované oblasti označené jako par pro paralelní zpracování doručí zprostředkovatel zpráv m1_a službě B i službě C současně přes přerušované šipky. Služba B zpracuje zprávu a vrátí m1_b do zprostředkovatele zpráv. Služba C zpracuje zprávu a vrátí m1_c do zprostředkovatele zpráv. Na pravé straně diagramu představují dvě malá pole podmínky čekání pro službu D. První podmínka uvádí čekání na m1_b a m1_c, což znamená, že služba D nemůže pokračovat, dokud neobdrží obě zprávy. Druhá podmínka uvádí čekání na m1_b. Po dokončení paralelního zpracování a odpovědi služby B i služby C odešle zprostředkovatel zpráv m1_c do služby D a potom m1_b. Služba D tyto zprávy zpracovává a vrací m1_d do zprostředkovatele zpráv. Pod diagramem legenda vysvětluje jednotlivé zápisy. Požadavek odkazuje na původní požadavek HTTP odeslaný do veřejného koncového bodu. M1_a je požadavek HTTP převedený na zprávu. M1_b je zpráva zpracována a odeslána zpět do zprostředkovatele zpráv ze služby B. M1_c je zpráva zpracována a odeslána zpět do zprostředkovatele zpráv ze služby C a m1_d označuje, že m1_b a m1_c se zpracovávají a odesílají zpět jako poslední potvrzení pro zprostředkovatele zpráv. Plné šipky označují publikování zpráv a přerušované šipky označují odběr zpráv.

• Pozorovatelnost ve velkém měřítku. Tento model představuje výzvy, pokud počet služeb rychle roste. Mnoho nezávislých pohyblivých částí komplikuje pracovní postup mezi službami. Bez centrálního orchestrátoru, který drží úplný stav transakce, nemá žádná jedna komponenta úplný přehled o provozu v letu. Kvůli zachování pozorovatelnosti je nutné konzistentně používat distribuované trasování a identifikátory korelace.

• Komunikace obsluhy odolnosti V architektuře řízené orchestrátorem může centrální komponenta delegovat odpovědnost za zajištění odolnosti, například za zpracování opakovaných pokusů při přechodných, nepřechodných a časových selháních, na vyhrazenou komponentu pro zajištění odolnosti.

  Když v návrhu založeném na choreografii odeberete orchestrátor, navazující komponenty nepřebírají odpovědnost za zajištění odolnosti. Zůstávají soustředěné v mechanismu odolnosti. Následné komponenty ale musí s touto obslužnou rutinou komunikovat přímo, což zvyšuje komunikaci bod-bod.

• Vývoj schématu událostí Vývoj schématu událostí může v průběhu času způsobit zásadní změny uživatelů. V tomto modelu spotřebovávají více nezávislých služeb stejné události. Pokud producent změní datovou strukturu události, může narušit podřízené příjemce, kteří závisí na starém schématu. Použijte registr schémat ke správě kontraktů událostí a k podpoře zpětně kompatibilní evoluce, když se služby vyvíjejí nezávisle.

• Idempotence a řazení událostí. Aspoň jedno doručení a opakování může vytvářet duplicitní zprávy a souběžní příjemci můžou zpracovávat zprávy mimo pořadí. Navrhněte příjemce tak, aby byli idempotentní, a to sledováním stabilních identifikátorů zpráv. Pokud je vyžadováno zpracování v daném pořadí, použijte funkce brokera, například relace Service Bus, nebo zahrňte údaje o pořadí či verzi, které příjemcům umožní odmítnout zastaralé události a zjistit mezery.

• Atomický stav a publikování událostí. Služba, která aktualizuje své úložiště dat a publikuje událost v samostatných operacích, může potvrdit jednu operaci, zatímco druhá selže. Použijte vzor Transactional Outbox nebo ekvivalentní atomický mechanismus ke společnému trvalému uložení změny stavu a události předtím, než událost publikuje samostatný proces.

• Emergentní chování a příval událostí. Decentralizované topologie událostí můžou ve velkém vytvářet nově vznikající chování. Když řada služeb reaguje na události ostatních, systém může neúmyslně vytvářet smyčky zpětné vazby nebo bouře událostí. Vedlejší událost může aktivovat kaskádu podřízených reakcí. Pokud chcete zabránit cyklovým řetězům událostí, použijte ochranné mantinely, jako je filtrování událostí, omezení souběžnosti uživatelů, omezování a explicitní pravidla.

Kdy použít tento vzor

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

• Navazující komponenty zpracovávají atomické operace nezávisle stylem fire and forget. Každá komponenta dokončí úlohu a pak prostřednictvím zprostředkovatele zpráv signalizuje dokončení do jiných komponent. Iniciační služba po odeslání aktivně nespravuje ani nesleduje úlohu, ale podřízené služby stále komunikují výsledky prostřednictvím událostí.

• Očekáváte, že budete často aktualizovat a nahradit komponenty. Tento model umožňuje upravit aplikaci s menším úsilím a minimálním přerušením stávajících služeb.

• Pro jednoduché pracovní postupy používáte bezserverové architektury. Komponenty mohou být krátkodobé a řízené událostmi. Když dojde k události, služba vytvoří komponenty, které dělají úlohu, a služba po dokončení této úlohy odebere komponenty.

• Komunikace mezi ohraničenými kontexty vyžaduje volné párování přes hranice domény. Pro komunikaci uvnitř jednoho ohraničeného kontextu zvažte místo toho vzor orchestrátoru v závislosti na složitosti a předvolbě týmu.

• Centrální orchestrátor představuje kritický bod výkonu.

Tento vzor nemusí být vhodný v těchto 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é.

• Komunikace typu point-to-point mezi komponentami je nevyhnutelná.

• Ke konsolidaci všech operací, které zpracovávají podřízené komponenty, musíte použít obchodní logiku.

Návrh úloh

Vyhodnoťte, jak v návrhu pracovního zatížení použít choreografický vzor k dosažení cílů a principů zahrnutých v pilířích Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Efektivita provozu pomáhá poskytovat kvalitu úloh prostřednictvím standardizovaných procesů a týmové soudržnosti.	Distribuované komponenty v tomto modelu jsou autonomní a navržené tak, aby byly nahraditelné, takže můžete upravit úlohu s méně celkovou změnou systému. - OE:04 Nástroje a procesy
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu.	Tento model nabízí alternativu, když dochází k kritickým bodům výkonu v centralizované topologii orchestrace. - PE:02 Plánování kapacity - PE:05 Škálování a dělení

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 choreografie vytvořením úlohy, která je událostmi řízená a nativní pro cloud, a která spouští funkce společně 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, zahájí se proces doručení. Během přepravy balíčku se úloha zabývá doručením, dokud neobdrží stav expedice. Úplnou referenční architekturu najdete v tématu Mikroslužby s Azure Container Apps.

Diagram znázorňuje implementaci hierarchií řízenou událostmi pro systém doručování pomocí dronů, který používá služby Azure. Úplně vlevo je šipka, která představuje požadavek klienta, směřuje od ikony uživatele k poli označenému jako ingest, což je vstupní bod do prostředí Azure Container Apps. V prostředí Container Apps propojují šipky službu příjmu dat, mikroslužbu balíčku, plánovač dronů a mikroslužbu doručování prostřednictvím služby Azure Service Bus. Další šipka odkazuje z mikroslužby balíčku na pole označeného službou Azure Cosmos DB nad prostředím Container Apps. Šipka označená jako odeslaná teče ze služby doručování směrem nahoru do Azure Event Grid. Pod polem označeným Service Busem ukazuje šipka dolů na frontu nedoručených zpráv (DLQ) reprezentovanou ikonou kruhu.

Služba příjmu dat přijímá požadavky klientů a převádí je na zprávy, které obsahují podrobnosti o doručení. Obchodní transakce začínají poté, co služby tyto nové zprávy spotřebovávají.

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

• Vytvořte nebo aktualizujte balíček.

• Přiřaďte dron k doručení balíčku.

• Zpracujte doručení, včetně kontroly a odeslání oznámení, když se balíček odešle.

Balíček, plánovač dronů a doručovací mikroslužby provádějí obchodní zpracování. Služby používají zasílání zpráv místo centrálního orchestrátoru ke vzájemné komunikaci. Každá služba musí předem implementovat protokol, který koordinuje obchodní pracovní postup decentralizovaným způsobem.

Design

Služby zpracovávají obchodní transakce v posloupnosti prostřednictvím několika mezistupni. Každý uzel 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 ji na zprávu a pak ji publikuje do sdílené sběrnice zpráv. Odběratelské obchodní služby využívají nové zprávy přidané do datové sběrnice. Když obchodní služba obdrží zprávu, dokončí operaci úspěšně nebo požadavek selže nebo vyprší časový limit. Pokud požadavek proběhne úspěšně, služba odpoví sběrnici se stavovým kódem Ok , vyvolá novou zprávu operace a odešle ji do sběrnice zpráv. Pokud požadavek selže nebo vyprší časový limit požadavku, služba nahlásí do sběrnice zpráv kód důvodu selhání a přesune zprávu do fronty nedoručených zpráv prostřednictvím Azure Service Bus. Služba také nedoručí zprávy, které nemůže přijímat nebo zpracovávat během určitého časového intervalu.

Tento návrh používá více sběrnic zpráv ke zpracování celé obchodní transakce. Azure Service Bus a Azure Event Grid poskytují platformu služby zasílání zpráv pro tento návrh. Úloha běží na Azure Container Apps. Služba příjmu dat běží jako Azure Funkce hostovaná v Container Apps, zatímco balíček, plánovač dronů a služby doručování běží jako mikroslužby ve stejném prostředí Container Apps. Container Apps zpracovává zpracování řízené událostmi , které spouští obchodní logiku.

Tento návrh také zajišťuje, aby choreografie probíhala v sekvenci. Jeden obor názvů služby Service Bus obsahuje téma, které má dvě předplatná a frontu s podporou relací. Služba příjmu dat publikuje zprávy na téma. Služba balíčků a služba plánovače dronů se přihlásí k odběru tématu a publikují zprávy, které informují frontu o úspěšných požadavcích. Zahrňte společný identifikátor relace, který přidruží identifikátor GUID k identifikátoru doručení, aby služba doručování mohl korelovat dvě zprávy, které potřebuje pro každou transakci. Jedna zpráva potvrzuje, že je balíček připraven, druhá zpráva potvrzuje, že je dron naplánován. Bez této korelace založené na relaci nemá doručovací služba žádný způsob, jak přiřadit související zprávy napříč nezávislými předáními, protože stav transakce nesleduje žádný centrální koordinátor. Služba doručování čeká na dvě související zprávy pro každou transakci. První zpráva označuje, že balíček je připravený k odeslání, a druhá zpráva signalizuje, že je naplánován dron.

V tomto návrhu služba Service Bus zpracovává zprávy s vysokou hodnotou, které nesmí být během celého procesu doručování ztraceny nebo duplikovány. Po odeslání balíčku se do Event Gridu publikuje změna stavu. Odesílatel události nemá žádné očekávání ohledně způsobu zpracování změny stavu. Podřízené organizační služby, které tento návrh neobsahuje, můžou naslouchat tomuto typu události a spouštět konkrétní obchodní logiku, jako je odeslání e-mailu o stavu objednávky uživateli.

Pokud tento vzor nasadíte v jiné výpočetní službě, jako je AKS, můžete nasadit ambassador jako sidecar ve stejném podu jako podnikovou aplikaci. Kolokace minimalizuje latenci komunikace, ale proxy zvyšuje režii zpracování a nároky na prostředky a škáluje spolu s aplikací. Tento přístup použijte v případě, že potřebujete problémy s připojením nezávislé na jazyce, které platforma neposkytuje.

Aby se zabránilo kaskádové operaci opakování, které by mohly vést k několika pokusům, měly by obchodní služby okamžitě označit nepřijatelné zprávy. Tyto zprávy můžete obohatit pomocí běžných kódů důvodů nebo definovaného kódu aplikace, aby je služby mohly přesunout do DLQ. Zvažte implementaci modelu Saga pro správu problémů konzistence z podřízených služeb. Jiná služba například zpracovává zprávy o nedoručených zprávách pro účely nápravy pouze prostřednictvím kompenzační, opakované nebo kontingenční transakce.

Obchodní služby jsou idempotentní, aby zajistily, že opakované operace nevytvoří duplicitní prostředky. Například balíčková služba používá operace upsert k přidání dat do úložiště dat.

Další krok

• Projděte si možnosti asynchronního zasílání zpráv v Azure a seznamte se s různými možnostmi infrastruktury, které jsou k dispozici pro implementaci decentralizovaného pracovního postupu.

Související prostředky

Zvažte tyto vzory ve vašem návrhu pro choreografii:

• Pomocí vzoru Ambassador můžete modulárně uspořádat komunikaci podnikových služeb se sběrnicí zpráv.

• Implementujte model vyrovnávání zatíženíQueue-Based pro zvládnutí špiček v úloze.

• Použití asynchronního distribuovaného zasílání zpráv prostřednictvím vzoruPublisher-Subscriber.

• 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í.