Komunikace mezi službami

Tip

Tento obsah je výňatek z eBooku, Architekting Cloud Native .NET Applications for Azure, který je k dispozici na webu Docs pro .NET nebo jako soubor PDF zdarma ke stažení, který si můžete přečíst offline.

Stáhnout PDF

Přechod z front-endového klienta teď řešíme back-endové mikroslužby, které spolu vzájemně komunikují.

Při vytváření aplikace nativní pro cloud budete chtít být citliví na to, jak mezi sebou komunikují back-endové služby. V ideálním případě je lepší komunikace mezi službami. Vyloučení ale není vždy možné, protože back-endové služby často vzájemně spoléhají na dokončení operace.

K implementaci komunikace mezi službami existuje několik široce uznávaných přístupů. Typ komunikace často určuje nejlepší přístup.

Zvažte následující typy interakcí:

• Dotaz – když volající mikroslužba vyžaduje odpověď z volané mikroslužby, například "Hey, give me the buyer information for a given customer ID" (Hey, give me the buyer information for a given customer ID).

• Příkaz – když volající mikroslužba potřebuje k provedení akce jinou mikroslužbu, ale nevyžaduje odpověď, například "Hey, just ship this order" (Ahoj, stačí odeslat tuto objednávku).

• Událost – když mikroslužba, která se nazývá vydavatel, vyvolá událost, která se změnila nebo došlo k akci. Ostatní mikroslužby, označované jako odběratelé, kteří mají zájem, mohou odpovídajícím způsobem reagovat na událost. Vydavatel a předplatitelé si navzájem neuvědomují.

Systémy mikroslužeb obvykle používají kombinaci těchto typů interakcí při provádění operací, které vyžadují interakci mezi službami. Pojďme se na každý z nich podívat a na to, jak je můžete implementovat.

Dotazy

Často může jedna mikroslužba potřebovat dotaz na jinou, což vyžaduje okamžitou reakci na dokončení operace. Mikroslužba nákupního košíku může potřebovat informace o produktu a cenu pro přidání položky do košíku. Existuje mnoho přístupů k implementaci operací dotazů.

Zasílání zpráv žádostí a odpovědí

Jednou z možností implementace tohoto scénáře je, že volající back-endová mikroslužba provede přímé požadavky HTTP na mikroslužby, které potřebuje dotazovat, jak je znázorněno na obrázku 4 až 8.

Obrázek 4–8 Přímá komunikace HTTP

I když jsou přímá volání HTTP mezi mikroslužbami poměrně jednoduchá k implementaci, měli byste vzít v úvahu minimalizaci tohoto postupu. Pokud chcete začít, jsou tato volání vždy synchronní a zablokují operaci, dokud se nevrátí výsledek nebo vyprší časový limit požadavku. To, co bylo jednou samostatné, nezávislé služby, schopné se nezávisle vyvíjet a nasazovat často, se teď vzájemně propojí. S rostoucím propojením mikroslužeb se jejich výhody architektury zmenšují.

Provádění občasné žádosti, která provádí jedno přímé volání HTTP do jiné mikroslužby, může být přijatelné pro některé systémy. Volání s velkým objemem, která volají přímé volání HTTP do více mikroslužeb, se ale nedoporučuje. Můžou zvýšit latenci a negativně ovlivnit výkon, škálovatelnost a dostupnost vašeho systému. Ještě horší je, že dlouhá řada přímé komunikace HTTP může vést k hlubokým a složitým řetězcům synchronních volání mikroslužeb, jak je znázorněno na obrázku 4–9:

Obrázek 4–9 Řetězení dotazů HTTP

Určitě si můžete představit riziko v návrhu zobrazeném na předchozím obrázku. Co se stane, když krok 3 selže? Nebo krok 8 selže? Jak se obnoví? Co když je krok 6 pomalý, protože podkladová služba je zaneprázdněná? Jak pokračovat? I když všechno funguje správně, zamyslete se nad latencí, ke které by toto volání došlo, což je součet latence každého kroku.

Velký stupeň párování na předchozím obrázku naznačuje, že služby nebyly optimálně modelovány. Tým by se mohl vrátit k návrhu.

Model materializovaného zobrazení

Oblíbenou možností pro odebrání párování mikroslužeb je model materializovaného zobrazení. V tomto modelu mikroslužba ukládá vlastní místní denormalizované kopie dat vlastněných jinými službami. Místo mikroslužby nákupního košíku dotazující se na mikroslužby Katalogu produktů a cen udržuje vlastní místní kopii těchto dat. Tento model eliminuje zbytečné párování a zlepšuje spolehlivost a dobu odezvy. Celá operace se provede uvnitř jednoho procesu. Tento vzor a další otázky týkající se dat prozkoumáme v kapitole 5.

Model agregátoru služeb

Další možností pro odstranění párování mikroslužeb mezi mikroslužbami je mikroslužba agregátoru, která je zobrazená na fialové obrázku 4–10.

Obrázek 4–10 Mikroslužba agregátoru

Model izoluje operaci, která provádí volání více back-endových mikroslužeb a centralizuje logiku do specializované mikroslužby. Fialová pokladna mikroslužby agregátoru na předchozím obrázku orchestruje pracovní postup pro operaci pokladny. Zahrnuje volání několika back-endových mikroslužeb v sekvencovaném pořadí. Data z pracovního postupu se agregují a vrací volajícímu. I když stále implementuje přímé volání HTTP, mikroslužba agregátoru snižuje přímé závislosti mezi back-endovými mikroslužbami.

Model žádosti a odpovědi

Dalším přístupem pro oddělení synchronních zpráv HTTP je model odpovědi na požadavek, který používá komunikaci front. Komunikace pomocí fronty je vždy jednosměrný kanál s producentem, který zprávu posílá a příjemce obdrží. V tomto modelu se implementuje fronta požadavků i fronta odpovědí, která je znázorněna na obrázku 4–11.

Obrázek 4–11 Model odpovědi na žádost

V tomto případě vytvoří producent zpráv zprávu založenou na dotazu, která obsahuje jedinečné ID korelace a umístí ji do fronty požadavků. Spotřeba služby odřadí zprávy, zpracuje ji a umístí odpověď do fronty odpovědí se stejným ID korelace. Služba producenta zprávu vyřadit z fronty, odpovídá id korelace a pokračuje ve zpracování. Fronty probereme podrobně v další části.

Příkazy

Dalším typem komunikace je příkaz. Mikroslužba může k provedení akce potřebovat jinou mikroslužbu. Mikroslužba Objednávání může vyžadovat, aby mikroslužba Shipping vytvořila zásilku pro schválenou objednávku. Na obrázku 4–12 odešle jedna mikroslužba označovaná jako Producent zprávu do jiné mikroslužby, příjemce a příkazem k tomu, aby něco udělala.

Obrázek 4–12 Interakce příkazů s frontou

Producent většinou nevyžaduje odpověď a může zprávu aktivovat a zapomenout . Pokud je potřeba odpověď, příjemce odešle samostatnou zprávu zpět producentovi v jiném kanálu. Zpráva příkazu se nejlépe odesílá asynchronně s frontou zpráv. podporuje odlehčený zprostředkovatel zpráv. V předchozím diagramu si všimněte, jak fronta odděluje a odděluje obě služby.

Fronta zpráv je zprostředkující konstruktor, prostřednictvím kterého producent a příjemce předávají zprávu. Fronty implementují asynchronní vzor zasílání zpráv typu point-to-point. Producent ví, kde je potřeba příkaz odeslat a správně směrovat. Fronta zaručuje, že zpráva je zpracována přesně jednou z instancí příjemce, které čtou z kanálu. V tomto scénáři může producent nebo spotřebitelská služba škálovat na více instancí, aniž by to mělo vliv na ostatní. Technologie můžou být na každé straně různorodé, což znamená, že můžeme mít mikroslužbu Java, která volá mikroslužbu Jazyka Go.

V kapitole 1 jsme mluvili o záložních službách. Backing services jsou doplňkové prostředky, na kterých závisí nativní cloudové systémy. Fronty zpráv jsou backingové služby. Cloud Azure podporuje dva typy front zpráv, které mohou vaše nativní systémy cloudu využívat k implementaci zasílání zpráv: fronty Azure Storage a fronty služby Azure Service Bus.

Fronty Azure Storage

Fronty úložiště Azure nabízejí jednoduchou infrastrukturu front, která je rychlá, cenově dostupná a podporovaná účty úložiště Azure.

Fronty služby Azure Storage obsahují mechanismus řízení front založený na REST se spolehlivým a trvalým zasíláním zpráv. Poskytují minimální sadu funkcí, ale jsou levné a ukládají miliony zpráv. Jejich kapacita je až 500 TB. Jedna zpráva může mít velikost až 64 kB.

Ke zprávům můžete přistupovat odkudkoli na světě prostřednictvím ověřených volání pomocí protokolu HTTP nebo HTTPS. Fronty úložiště se můžou škálovat na velký počet souběžných klientů, aby zvládly špičky provozu.

To znamená, že služba má určitá omezení:

• Pořadí zpráv není zaručeno.

• Zpráva může trvat jenom sedm dní, než se automaticky odebere.

• Podpora správy stavu, detekce duplicit nebo transakcí není dostupná.

Obrázek 4–13 znázorňuje hierarchii fronty služby Azure Storage.

Obrázek 4–13 Hierarchie front úložiště

Na předchozím obrázku si všimněte, jak fronty úložiště ukládají své zprávy do základního účtu Azure Storage.

Pro vývojáře poskytuje Microsoft několik klientských a serverových knihoven pro zpracování fronty úložiště. Většina hlavních platforem se podporuje včetně .NET, Java, JavaScriptu, Ruby, Pythonu a Go. Vývojáři by s těmito knihovnami nikdy neměli komunikovat přímo. Tím pevně propojite kód mikroslužby se službou Fronta služby Azure Storage. Je lepší izolovat podrobnosti implementace rozhraní API. Představte si zprostředkující vrstvu nebo zprostředkující rozhraní API, která zpřístupňuje obecné operace a zapouzdřuje konkrétní knihovnu. Tato volná spojka umožňuje prohodit jednu službu řízení front za jinou, aniž byste museli provádět změny v kódu hlavní služby.

Fronty Azure Storage představují úspornou možnost implementace zasílání příkazů v aplikacích nativních pro cloud. Zvláště pokud velikost fronty překročí 80 GB nebo je přijatelná jednoduchá sada funkcí. Platíte pouze za ukládání zpráv; neexistují žádné pevné hodinové poplatky.

Fronty služby Azure Service Bus

Pro složitější požadavky na zasílání zpráv zvažte fronty služby Azure Service Bus.

Služba Azure Service Bus, která je součástí robustní infrastruktury zpráv, podporuje zprostředkovaný model zasílání zpráv. Zprávy jsou spolehlivě uloženy ve zprostředkovateli (frontě), dokud příjemce neobdrží. Fronta zaručuje doručení zpráv typu First-In/First-Out (FIFO), přičemž respektuje pořadí, ve kterém byly zprávy přidány do fronty.

Velikost zprávy může být mnohem větší až 256 kB. Zprávy se uchovávají ve frontě po neomezenou dobu. Service Bus podporuje nejen volání založená na protokolu HTTP, ale také poskytuje úplnou podporu protokolu AMQP. AMQP je open-standard napříč dodavateli, který podporuje binární protokol a vyšší stupně spolehlivosti.

Service Bus poskytuje bohatou sadu funkcí, včetně podpory transakcí a funkce detekce duplicit. Fronta zaručuje "nanejvýš jedno doručení" pro každou zprávu. Automaticky zahodí zprávu, která už byla odeslána. Pokud je výrobce pochybný, může znovu odeslat stejnou zprávu a Service Bus zaručuje, že bude zpracována pouze jedna kopie. Detekce duplicit vám umožňuje vytvářet další instalatérské infrastruktury.

Další dvě podnikové funkce jsou dělení a relace. Konvenční fronta služby Service Bus je zpracována jedním zprostředkovatelem zpráv a uložena v jednom úložišti zpráv. Dělení služby Service Bus ale rozdělí frontu do několika zprostředkovatelů zpráv a úložišť zpráv. Celková propustnost už není omezena výkonem jednoho zprostředkovatele zpráv nebo úložištěm zpráv. Dočasný výpadek úložiště zpráv nevykreslí dělenou frontu nedostupnou.

Relace služby Service Bus poskytují způsob, jak seskupovat zprávy. Představte si scénář pracovního postupu, ve kterém musí být zprávy zpracovány společně a operace se dokončila na konci. Aby bylo možné využít výhod, musí být relace pro frontu explicitně povolené a každá související zpráva musí obsahovat stejné ID relace.

Existuje však několik důležitých upozornění: Velikost front Service Bus je omezená na 80 GB, což je mnohem menší než to, co je k dispozici ve frontách úložiště. Fronty služby Service Bus navíc účtují základní náklady a poplatky za operaci.

Obrázek 4–14 popisuje architekturu vysoké úrovně fronty Service Bus.

Obrázek 4–14 Fronta služby Service Bus

Na předchozím obrázku si všimněte relace typu point-to-point. Dvě instance stejného poskytovatele zařadí zprávy do jedné fronty Service Bus. Každá zpráva je spotřebována pouze jednou ze tří instancí příjemce napravo. Dále probereme, jak implementovat zasílání zpráv, kde mohou mít různí příjemci zájem o stejnou zprávu.

Událost

Řízení front zpráv je efektivní způsob, jak implementovat komunikaci, kde producent může asynchronně odeslat příjemce zprávy. Co se ale stane, když má mnoho různých příjemců zájem o stejnou zprávu? Vyhrazená fronta zpráv pro každého příjemce by nebyla dobře škálovat a bylo by obtížné ji spravovat.

Abychom tento scénář vyřešili, přesuneme se na třetí typ interakce se zprávou, událostí. Jedna mikroslužba oznámí, že došlo k akci. Ostatní mikroslužby, pokud vás zajímají, reagují na akci nebo na událost. Označuje se také jako styl architektury řízený událostmi.

Eventing je dvoustupňový proces. U dané změny stavu mikroslužba publikuje událost do zprostředkovatele zpráv a zpřístupní ji všem ostatním zúčastněným mikroslužbám. Zájemce o mikroslužbu obdrží oznámení přihlášením k odběru události ve zprostředkovateli zpráv. K implementaci komunikace založené na událostech se používá model Publikovat/Přihlásit k odběru.

Obrázek 4–15 ukazuje mikroslužbu nákupního košíku, která publikuje událost se dvěma dalšími mikroslužbami, které se k odběru přihlašují.

Obrázek 4–15 Zasílání zpráv řízených událostmi

Všimněte si komponenty sběrnice událostí, která se nachází uprostřed komunikačního kanálu. Je to vlastní třída, která zapouzdřuje zprostředkovatele zpráv a odděluje ji od podkladové aplikace. Objednávání a inventarizační mikroslužby nezávisle provozují událost bez znalostí, ani mikroslužby nákupního košíku. Když se zaregistrovaná událost publikuje do sběrnice událostí, bude s ní pracovat.

S událostmi přecházíme od technologie řazení do fronty na témata. Téma se podobá frontě, ale podporuje model zasílání zpráv 1:N. Jedna mikroslužba publikuje zprávu. Více předplacených mikroslužeb se může rozhodnout přijímat a reagovat na tuto zprávu. Obrázek 4–16 ukazuje architekturu tématu.

Obrázek 4–16 Architektura témat

Na předchozím obrázku odesílají vydavatelé zprávy do tématu. Na konci odběratelé přijímají zprávy z odběrů. Uprostřed téma předává zprávy odběrům na základě sady pravidel zobrazených v tmavě modrých polích. Pravidla fungují jako filtr, který přeposílá konkrétní zprávy odběru. V této části by se na cenu a protokolování odběrů odeslala událost GetPrice, protože odběr protokolování se rozhodl přijímat všechny zprávy. Událost GetInformation by se odeslala do informací a protokolování odběrů.

Cloud Azure podporuje dvě různé tematické služby: Témata služby Azure Service Bus a Azure EventGrid.

Téma služby Azure Service Bus

Témata služby Azure Service Bus najdete nad stejným robustním zprostředkovaným modelem zprostředkovaných zpráv ve frontách Azure Service Bus. Téma může přijímat zprávy od více nezávislých vydavatelů a posílat zprávy až 2 000 odběratelům. Odběry je možné dynamicky přidávat nebo odebírat za běhu bez zastavení systému nebo opětovného vytvoření tématu.

Mnoho pokročilých funkcí z front Azure Service Bus je také k dispozici pro témata, včetně podpory detekce duplicit a transakcí. Ve výchozím nastavení se témata služby Service Bus zpracovávají jedním zprostředkovatelem zpráv a ukládají se do jednoho úložiště zpráv. Dělení služby Service Bus ale škáluje téma tím, že ho rozšíří do mnoha zprostředkovatelů zpráv a úložišť zpráv.

Naplánované doručování zpráv označí zprávu určitým časem ke zpracování. Zpráva se před tímto časem nezobrazí v tématu. Funkce Message Deferral umožňuje odložení načtení zprávy na pozdější dobu. Obě se běžně používají ve scénářích zpracování pracovních postupů, ve kterých se operace zpracovávají v určitém pořadí. Zpracování přijatých zpráv můžete odložit až do dokončení předchozí práce.

Témata služby Service Bus jsou robustní a prověřenou technologií pro povolení komunikace publikování a odběru v nativních cloudových systémech.

Azure Event Grid

I když je Azure Service Bus zprostředkovatelem zasílání zpráv o testování bitvy s plnou sadou podnikových funkcí, azure Event Grid je nový kluk na bloku.

Event Grid může na první pohled vypadat jako jiný systém zasílání zpráv založený na tématu. Je to ale v mnoha ohledech jiné. Zaměřuje se na úlohy řízené událostmi, umožňuje zpracování událostí v reálném čase, hlubokou integraci Azure a otevřenou platformu – vše na bezserverové infrastruktuře. Je navržená pro současné aplikace nativní pro cloud a bezserverové aplikace.

Jako centralizované backplane nebo kanálu událostí event Grid reaguje na události uvnitř prostředků Azure a z vašich vlastních služeb.

Oznámení událostí se publikují do tématu Event Gridu, které následně směruje každou událost do odběru. Odběratelé se mapují na předplatná a využívají události. Podobně jako Service Bus služba Event Grid podporuje filtrovaný model odběratele, ve kterém odběr nastavuje pravidlo pro události, které chce dostávat. Event Grid poskytuje rychlou propustnost se zárukou 10 milionů událostí za sekundu, které umožňují doručování téměř v reálném čase – mnohem více než to, co azure Service Bus dokáže vygenerovat.

Velmi milým místem pro Event Grid je její hlubokou integraci do infrastruktury Azure. Prostředek Azure, například Cosmos DB, může publikovat předdefinované události přímo do jiných zúčastněných prostředků Azure – bez nutnosti vlastního kódu. Event Grid může publikovat události z předplatného Azure, skupiny prostředků nebo služby, což vývojářům poskytuje podrobnou kontrolu nad životním cyklem cloudových prostředků. Event Grid se ale neomezuje na Azure. Jedná se o otevřenou platformu, která může využívat vlastní události HTTP publikované z aplikací nebo služeb třetích stran a směrovat události externím odběratelům.

Při publikování a přihlášení k odběru nativních událostí z prostředků Azure se nevyžaduje kódování. S jednoduchou konfigurací můžete integrovat události z jednoho prostředku Azure do druhého s využitím integrovaného instalatérství pro témata a předplatná. Obrázek 4–17 znázorňuje anatomii Event Gridu.

Obrázek 4–17 Anatomie Event Gridu

Hlavní rozdíl mezi EventGrid a Service Bus je základní vzor výměny zpráv.

Service Bus implementuje starší model vyžádání změn stylu, ve kterém odběratel podřízeného uživatele aktivně dotazuje odběr tématu na nové zprávy. Na straně straně tohoto přístupu získáte předplatiteli plnou kontrolu nad tempem, kterým zpracovává zprávy. Určuje, kdy a kolik zpráv se má zpracovat v daném okamžiku. Nepřečtené zprávy zůstanou v odběru, dokud se nezpracují. Významnou prodlevou je latence mezi časem vygenerování události a operací dotazování, která tuto zprávu načte odběrateli ke zpracování. Režie konstantního dotazování na další událost také spotřebovává prostředky a peníze.

EventGrid se ale liší. Implementuje model nabízených oznámení, ve kterém se události odesílají do EventHandlers jako přijaté a poskytují doručení událostí téměř v reálném čase. Snižuje také náklady, protože se služba aktivuje jenom v případě, že je potřeba využívat událost – ne nepřetržitě jako při dotazování. To znamená, že obslužná rutina události musí zpracovávat příchozí zatížení a poskytovat mechanismy omezování, které chrání sebe před zahlcením. Mnoho služeb Azure, které tyto události spotřebovávají, jako jsou Azure Functions a Logic Apps, poskytují automatické možnosti automatického škálování pro zpracování zvýšeného zatížení.

Event Grid je plně spravovaná cloudová služba bez serveru. Dynamicky se škáluje na základě vašeho provozu a účtuje poplatky jenom za vaše skutečné využití, nikoli za předem zakoupenou kapacitu. Prvních 100 000 operací za měsíc je bezplatných – operace definované jako příchozí přenos dat událostí (příchozí oznámení událostí), pokusy o doručení odběru, volání správy a filtrování podle předmětu. Díky 99,99% dostupnosti eventGrid zaručuje doručení události během 24 hodin s integrovanou funkcí opakování pro neúspěšné doručení. Nedoručené zprávy je možné přesunout do fronty "nedoručených zpráv" pro účely řešení. Na rozdíl od služby Azure Service Bus je Event Grid vyladěný pro rychlý výkon a nepodporuje funkce, jako je seřazené zasílání zpráv, transakce a relace.

Streamování zpráv v cloudu Azure

Azure Service Bus a Event Grid poskytují skvělou podporu pro aplikace, které zpřístupňují jednotlivé diskrétní události, jako je nový dokument, byl vložen do cosmos DB. Co když ale váš nativní systém cloudu potřebuje zpracovat datový proud souvisejících událostí? Streamy událostí jsou složitější. Obvykle jsou časově uspořádané, vzájemně propojené a musí být zpracovány jako skupina.

Azure Event Hub je platforma pro streamování dat a služba pro příjem událostí, která shromažďuje, transformuje a ukládá události. Je vyladěný tak, aby zaznamenával streamovaná data, jako jsou průběžná oznámení událostí vygenerovaná z kontextu telemetrie. Služba je vysoce škálovatelná a může ukládat a zpracovávat miliony událostí za sekundu. Na obrázku 4–18 je to často front door pro kanál událostí, který odděluje ingestování datového proudu od spotřeby událostí.

Obrázek 4–18 Azure Event Hub

Centrum událostí podporuje nízkou latenci a konfigurovatelné uchovávání času. Na rozdíl od front a témat služba Event Hubs uchovává data událostí po přečtení příjemcem. Tato funkce umožňuje dalším analytickým službám dat, interním i externím, přehrání dat pro další analýzu. Události uložené v centru událostí se odstraní pouze po vypršení platnosti doby uchovávání, což je ve výchozím nastavení jeden den, ale je možné je konfigurovat.

Centrum událostí podporuje běžné protokoly publikování událostí, včetně HTTPS a AMQP. Podporuje také Kafka 1.0. Stávající aplikace Kafka můžou komunikovat s centrem událostí pomocí protokolu Kafka, který poskytuje alternativu ke správě velkých clusterů Kafka. Mnoho opensourcových systémů nativních pro cloud zahrnuje Kafka.

Služba Event Hubs implementuje streamování zpráv prostřednictvím modelu dělených příjemců, ve kterém každý příjemce čte pouze konkrétní podmnožinu nebo oddíl streamu zpráv. Tento model umožňuje obrovské horizontální škálování pro zpracování událostí a poskytuje další funkce zaměřené na stream, které nejsou ve frontách a tématech k dispozici. Oddíl je seřazená posloupnost událostí, která se nachází v centru událostí. Při příchodu novějších událostí se na konec této sekvence přidají. Obrázek 4–19 znázorňuje dělení v centru událostí.

Obrázek 4–19 Dělení centra událostí

Místo čtení ze stejného prostředku čte každá skupina příjemců v podmnožině nebo oddílu datového proudu zpráv.

Pro aplikace nativní pro cloud, které musí streamovat velký počet událostí, může být Azure Event Hub robustním a cenově dostupným řešením.

PředchozíDalší