Asynchronní komunikace založená na zprávách

  • Článek

Tip

Tento obsah je výňatek z eBooku, architektury mikroslužeb .NET pro kontejnerizované aplikace .NET, které jsou k dispozici na .NET Docs nebo jako zdarma ke stažení PDF, které lze číst offline.

Stáhnout PDF

Architektura mikroslužeb .NET pro kontejnerizované eBooky aplikací .NET

Asynchronní zasílání zpráv a komunikace řízená událostmi jsou důležité při šíření změn napříč několika mikroslužbami a jejich souvisejícími doménovými modely. Jak už bylo zmíněno dříve v diskuzích mikroslužeb a ohraničených kontextů, modely (Uživatel, Zákazník, Produkt, Účet atd.) můžou znamenat různé věci pro různé mikroslužby nebo řadiče BCS. To znamená, že když dojde ke změnám, potřebujete nějaký způsob, jak odsouhlasit změny v různých modelech. Řešení je konečná konzistence a komunikace založená na událostech založená na asynchronním zasílání zpráv.

Při použití zasílání zpráv komunikují procesy asynchronní výměnou zpráv. Klient odešle příkaz nebo požadavek službě odesláním zprávy. Pokud služba potřebuje odpovědět, odešle klientovi jinou zprávu. Vzhledem k tomu, že se jedná o komunikaci založenou na zprávách, klient předpokládá, že odpověď nebude přijata okamžitě a že nemusí vůbec existovat žádná odpověď.

Zpráva se skládá z hlavičky (metadat, jako jsou identifikační nebo bezpečnostní údaje) a těla. Zprávy se obvykle odesílají prostřednictvím asynchronních protokolů, jako je AMQP.

Upřednostňovanou infrastrukturou pro tento typ komunikace v komunitě mikroslužeb je jednoduchý zprostředkovatel zpráv, který se liší od velkých zprostředkovatelů a orchestrátorů používaných v SOA. V odlehčeném zprostředkovateli zpráv je infrastruktura obvykle "hloupá", která funguje jenom jako zprostředkovatel zpráv, s jednoduchými implementacemi, jako je RabbitMQ nebo škálovatelná sběrnice služeb v cloudu, jako je Azure Service Bus. V tomto scénáři většina "inteligentního" myšlení stále žije v koncových bodech, které vytvářejí a využívají zprávy– to znamená v mikroslužbách.

Dalším pravidlem, které byste měli co nejvíce sledovat, je použít pouze asynchronní zasílání zpráv mezi interními službami a používat synchronní komunikaci (například HTTP) pouze z klientských aplikací do front-endových služeb (brány rozhraní API a první úroveň mikroslužeb).

Existují dva druhy asynchronní komunikace zasílání zpráv: komunikace založená na jediném příjemci a více příjemců komunikace na základě zpráv. Následující části obsahují podrobnosti o nich.

Komunikace založená na zprávách s jedním příjemcem

Asynchronní komunikace založená na zprávách s jedním příjemcem znamená, že existuje komunikace typu point-to-point, která doručuje zprávu přesně jednomu ze příjemců, kteří čtou z kanálu, a že zpráva se zpracuje jen jednou. Existují však zvláštní situace. Například v cloudovém systému, který se pokusí automaticky zotavit ze selhání, může být stejná zpráva znovu odeslána vícekrát. Kvůli selhání sítě nebo jiným selháním musí být klient schopný opakovat odesílání zpráv a server musí implementovat operaci, která má být idempotentní , aby mohla zpracovat konkrétní zprávu jen jednou.

Komunikace založená na zprávách s jedním příjemcem je obzvláště vhodná pro odesílání asynchronních příkazů z jedné mikroslužby do druhé, jak je znázorněno na obrázku 4–18, které tento přístup ilustruje.

Jakmile začnete odesílat komunikaci založenou na zprávách (buď s příkazy nebo událostmi), měli byste se vyhnout kombinování komunikace založené na zprávách s synchronní komunikací HTTP.

Jedna mikroslužba, která přijímá asynchronní zprávu

Obrázek 4–18 Jedna mikroslužba, která přijímá asynchronní zprávu

Když příkazy pocházejí z klientských aplikací, je možné je implementovat jako synchronní příkazy HTTP. Příkazy založené na zprávách použijte, pokud potřebujete vyšší škálovatelnost nebo když už jste v obchodním procesu založeném na zprávách.

Komunikace založená na více přijímačích zpráv

Jako flexibilnější přístup můžete také chtít použít mechanismus publikování/přihlášení k odběru , aby vaše komunikace od odesílatele byla k dispozici pro další mikroslužby odběratelů nebo pro externí aplikace. To vám tedy pomůže dodržovat otevřený/uzavřený princip v odesílající službě. Tímto způsobem je možné do budoucna přidat další předplatitele, aniž by bylo nutné upravovat službu odesílatele.

Při použití komunikace s publikováním nebo odběrem můžete k publikování událostí libovolnému odběrateli použít rozhraní sběrnice událostí.

Asynchronní komunikace řízená událostmi

Při použití asynchronní komunikace řízené událostmi mikroslužba publikuje událost integrace, když se něco stane v rámci své domény, a další mikroslužba si o ní musí být vědoma, například změna ceny v mikroslužbě katalogu produktů. Další mikroslužby se přihlásí k odběru událostí, aby je mohly přijímat asynchronně. V takovém případě můžou příjemci aktualizovat vlastní entity domény, což může způsobit publikování dalších událostí integrace. Tento systém publikování/odběru se provádí pomocí implementace sběrnice událostí. Sběrnice událostí může být navržena jako abstrakce nebo rozhraní s rozhraním API, které je potřeba k přihlášení k odběru nebo odhlášení odběru událostí a k publikování událostí. Sběrnice událostí může mít také jednu nebo více implementací na základě jakéhokoli zprostředkovatele komunikace mezi procesy a zasílání zpráv, jako je fronta zasílání zpráv nebo sběrnice služby, která podporuje asynchronní komunikaci a model publikování/odběru.

Pokud systém používá konečnou konzistenci řízenou událostmi integrace, doporučuje se, aby byl tento přístup pro koncového uživatele jasný. Systém by neměl používat přístup, který napodobuje integrační události, jako jsou SignalR nebo systémy dotazování z klienta. Koncový uživatel a vlastník firmy musí explicitně přijmout konečnou konzistenci v systému a uvědomit si, že v mnoha případech firma nemá s tímto přístupem žádný problém, pokud je explicitní. Tento přístup je důležitý, protože uživatelé můžou očekávat okamžité zobrazení některých výsledků a tento aspekt nemusí nastat s konečnou konzistencí.

Jak jsme si poznamenali dříve v části Výzvy a řešení pro správu distribuovaných dat , můžete pomocí integračních událostí implementovat obchodní úlohy, které zahrnují více mikroslužeb. Proto budete mít konečnou konzistenci mezi těmito službami. Nakonec konzistentní transakce se skládá z kolekce distribuovaných akcí. V každé akci související mikroslužba aktualizuje entitu domény a publikuje další událost integrace, která vyvolá další akci ve stejné komplexní obchodní úloze.

Důležitým bodem je, že můžete chtít komunikovat s několika mikroslužbami, které se přihlašují k odběru stejné události. K tomu můžete použít zasílání zpráv publikování a odběru na základě komunikace řízené událostmi, jak je znázorněno na obrázku 4–19. Tento mechanismus publikování/přihlášení k odběru není výhradní pro architekturu mikroslužeb. Podobá se způsobu komunikace ohraničených kontextů v DDD nebo způsobu, jakým rozšíříte aktualizace z databáze zápisu do databáze pro čtení v architektuře Command and Query Responsibility Segregation (CQRS). Cílem je mít konečnou konzistenci mezi více zdroji dat v distribuovaném systému.

Diagram znázorňující asynchronní komunikaci řízenou událostmi

Obrázek 4–19 Asynchronní komunikace zpráv řízená událostmi

V asynchronní komunikaci řízené událostmi jedna mikroslužba publikuje události do sběrnice událostí a mnoho mikroslužeb se k jejímu odběru může přihlásit, dostávat oznámení a reagovat na ni. Vaše implementace určí, jaký protokol se má použít pro komunikaci založenou na událostech a zprávách. AMQP může pomoct dosáhnout spolehlivé komunikace ve frontě.

Množství dat, která se mají v těchto událostech sdílet, je dalším důležitým aspektem, ať už jen identifikátor nebo také různé prvky obchodních dat. Tyto aspekty jsou popsány v tomto blogovém příspěvku o tenkých a tlustých integračních událostech.

Při použití sběrnice událostí můžete chtít použít úroveň abstrakce (například rozhraní sběrnice událostí) na základě související implementace ve třídách s kódem pomocí rozhraní API zprostředkovatele zpráv, jako je RabbitMQ nebo service bus, jako je Azure Service Bus s tématy. Alternativně můžete chtít použít sběrnici služeb vyšší úrovně, jako je NServiceBus, MassTransit nebo Brighter , a vyjádřit tak sběrnici událostí a publikovat nebo přihlásit se k odběru systému.

Poznámka o technologiích zasílání zpráv pro produkční systémy

Technologie zasílání zpráv dostupné pro implementaci abstraktní sběrnice událostí jsou na různých úrovních. Například produkty jako RabbitMQ (přenos zprostředkovatele zasílání zpráv) a Azure Service Bus se nacházejí na nižší úrovni než jiné produkty, jako je NServiceBus, MassTransit nebo Brighter, které můžou fungovat nad RabbitMQ a Azure Service Bus. Vaše volba závisí na tom, kolik bohatých funkcí na úrovni aplikaceach Pro implementaci pouze testování konceptu sběrnice událostí pro vaše vývojové prostředí, protože to bylo provedeno v ukázce eShopOnContainers, jednoduchá implementace nad RabbitMQ běžící na kontejneru Docker může stačit.

V případě důležitých a produkčních systémů, které vyžadují hyperšupability, ale možná budete chtít vyhodnotit Službu Azure Service Bus. Pro abstrakce a funkce vysoké úrovně, které usnadňují vývoj distribuovaných aplikací, doporučujeme vyhodnotit další komerční a opensourcové servisní autobusy, jako je NServiceBus, MassTransit a Brighter. Samozřejmě můžete vytvářet vlastní funkce sběrnice služeb nad technologiemi nižší úrovně, jako je RabbitMQ a Docker. Tato instalatérské práce ale může stát příliš mnoho pro vlastní podnikovou aplikaci.

Odolné publikování do sběrnice událostí

Výzvou při implementaci architektury řízené událostmi napříč několika mikroslužbami je, jak atomicky aktualizovat stav v původní mikroslužbě a zároveň odolné publikování související integrační události do sběrnice událostí, a to nějakým způsobem na základě transakcí. Tady je několik způsobů, jak tuto funkci dosáhnout, i když můžou existovat i další přístupy.

  • Použití transakční fronty (založené na DTC), jako je MSMQ. (Toto je ale starší přístup.)

  • Použití dolování transakčních protokolů.

  • Použití úplného vzoru Event Sourcing

  • Použití vzoru Pošta k odeslání: transakční databázová tabulka jako fronta zpráv, která bude základem pro komponentu tvůrce událostí, která by vytvořila událost a publikovala ji.

Podrobnější popis výzev v tomto prostoru, včetně toho, jak se můžou publikovat zprávy s potenciálně nesprávnými daty, najdete v tématu Platforma dat pro klíčové úlohy v Azure: Každá zpráva musí být zpracována.

Další témata, která je potřeba zvážit při použití asynchronní komunikace, jsou idempotenci zpráv a odstranění duplicitních dat zpráv. Tato témata jsou popsána v části Implementace komunikace založené na událostech mezi mikroslužbami (integračními událostmi) dále v této příručce.

Další materiály

PředchozíDalší