Styl architektury řízené událostmi

Architektura řízená událostmi se skládá z výrobců událostí , které generují stream událostí, konzumenty událostí , které naslouchají těmto událostem, a kanály událostí (často implementované jako zprostředkovatelé událostí nebo služby příjmu událostí), které přenášejí události od producentů do příjemců.

Architecture

Diagram znázorňující styl architektury řízené událostmi

Události se doručují téměř v reálném čase, takže příjemci můžou okamžitě reagovat na události, když k nim dojde. Producenti jsou odděleni od spotřebitelů, což znamená, že producent neví, kteří spotřebitelé naslouchají. Spotřebitelé jsou také odděleni od sebe a v modelu publikování a odběru uvidí všichni příjemci všechny události.

Tento proces se liší od modelu Konkurenční spotřebitelé. V modelu vzoru Konkurující spotřebitelé vybírají zprávy z fronty. Každá zpráva se zpracovává pouze jednou za předpokladu, že nedojde k žádným chybám. V některých systémech, například Azure IoT, musí být události zpracovávány ve vysokých objemech.

Architektura řízená událostmi může používat model publikování a odběru nebo model streamu událostí.

  • Publikace a odběr: Infrastruktura pro zasílání zpráv sleduje odběry. Když je událost publikovaná, odešle událost každému odběrateli. Po přijetí události se neuloží do odolného protokolu, takže noví odběratelé neuvidí minulé události. Pro scénáře publikování a odběru doporučujeme používat Azure Event Grid.

  • Streamování událostí: Události se zapisují do protokolu. Události jsou v rámci oddílu přísně uspořádané a jsou trvalé. Klienti se k odběru streamu nepřihlásí. Místo toho může klient číst z libovolné části datového proudu. Klient je zodpovědný za zlepšení své pozice ve streamu, což znamená, že se klient může kdykoli připojit a přehrávat události. Tato opakovaná možnost podporuje scénáře obnovy, pozdě příchozí zákazníky a opětovné zpracování po opravě chyby. Azure Event Hubs je určená pro streamování událostí s vysokou propustností.

Na straně spotřebitele existují některé běžné varianty:

  • Jednoduché zpracování událostí: Událost okamžitě aktivuje akci příjemce. Můžete například použít Azure Functions s triggerem Event Grid nebo triggerem Azure Service Bus tak, aby se kód spustil při publikování zprávy.

  • Základní korelace událostí: Příjemce zpracovává několik diskrétních obchodních událostí, koreluje je identifikátorem a udržuje informace z dřívějších událostí, aby je bylo možné použít při zpracování pozdějších událostí. Tento model podporují knihovny jako NServiceBus a MassTransit.

  • Komplexní zpracování událostí: Příjemce používá technologii, jako je Azure Stream Analytics k analýze řady událostí a identifikaci vzorů v datech událostí. Můžete například agregovat čtení z vloženého zařízení v časovém intervalu a generovat oznámení, pokud klouzavý průměr překročí určitou prahovou hodnotu.

  • Event stream processing: Použít platformu streamování dat například Azure IoT Hub, Event Hubs nebo Event Hubs for Apache Kafka, jako kanál pro příjem událostí a jejich podávání do streamu procesorů. Procesory datových proudů zpracovávají nebo transformují datový proud. Pro různé subsystémy aplikace může existovat více procesorů datových proudů. Tento přístup je vhodný pro úlohy IoT.

Zdroj událostí může být pro systém externí, například fyzická zařízení v řešení IoT. V takovém případě musí být systém schopen přijímat data ve svazku a s propustností, kterou zdroj dat vyžaduje.

Existují dva primární přístupy ke strukturování datových částí událostí. Pokud máte kontrolu nad příjemci událostí, můžete se rozhodnout o struktuře datové části pro každého příjemce. Tato strategie umožňuje kombinovat přístupy podle potřeby v rámci jedné úlohy.

  • Do datové části zahrňte všechny požadované atributy: Tento přístup použijte, pokud chcete, aby uživatelé měli všechny dostupné informace, aniž by museli dotazovat externí zdroj dat. Větší datové části zvyšují náklady na přenos a spotřebu šířky pásma a můžou vést k problémům s konzistencí dat kvůli více systémům záznamů, zejména po aktualizacích. Správa kontraktů a správa verzí se také můžou stát složitým.

  • Do datové části zahrňte jenom klíče: V tomto přístupu konzumenti načítají potřebné atributy, jako je primární klíč, aby mohli nezávisle získat zbývající data ze zdroje dat. Tato metoda poskytuje lepší konzistenci dat, protože má jeden systém záznamů. Může ale mít horší výkon než první přístup, protože uživatelé se musí často dotazovat na zdroj dat. Máte menší obavy týkající se párování, šířky pásma, správy kontraktů nebo správy verzí, protože menší události a jednodušší kontrakty snižují složitost. Další informace naleznete v tématu Put your events on a diet.

V předchozím diagramu se každý typ příjemce zobrazí jako jedno pole. Aby se konzument nestal jediným bodem selhání v systému, je obvyklé mít více instancí konzumenta. Ke zpracování objemu a četnosti událostí může být potřeba také více instancí. Jeden příjemce může zpracovávat události na více vláknech. Toto nastavení může způsobit problémy v případě, že události musí být zpracovány v pořadí nebo vyžadují přesná jednorázová sémantiku. Další informace naleznete v tématu Minimalizace koordinace.

V architekturách řízených událostmi existují dvě primární topologie:

  • Topologie zprostředkovatele: Komponenty vysílaly události do celého systému. Jiné komponenty buď fungují s událostí, nebo událost ignorují. Tato topologie je užitečná, když je tok zpracování událostí relativně jednoduchý. Neexistuje žádná centrální koordinace ani orchestrace, takže tato topologie může být dynamická.

    Tato topologie je vysoce oddělená, což pomáhá zajistit škálovatelnost, rychlost odezvy a odolnost komponent proti chybám. Žádná komponenta nevlastní ani neví o stavu žádné obchodní transakce ve více krocích a akce se provádějí asynchronně. V důsledku toho jsou distribuované transakce rizikové, protože neexistuje žádný integrovaný mechanismus pro restartování nebo přehrání. Je potřeba pečlivě zvážit zpracování chyb a strategie ručního zásahu, protože tato topologie může být zdrojem nekonzistence dat.

  • Mediátor topologie: Tato topologie řeší některé nedostatky topologie zprostředkovatele. Existuje mediátor události, který spravuje a řídí tok událostí. Zprostředkovatel události udržuje stav a spravuje možnosti zpracování chyb a restartování. Na rozdíl od topologie zprostředkovatele odesílá mediátor příkazy do určených kanálů místo vysílání do celého systému. Tyto kanály jsou často fronty zpráv. Očekává se, že uživatelé budou tyto příkazy zpracovávat.

    Tato topologie poskytuje větší kontrolu, lepší distribuované zpracování chyb a potenciálně lepší konzistenci dat. Tato topologie však zavádí zvýšenou vazbu mezi součástmi a mediátorem události se může stát kritickým bodem nebo problémem spolehlivosti.

Kdy použít tuto architekturu

Tuto architekturu byste měli použít, pokud jsou splněny následující podmínky:

  • Stejné události musí zpracovat více subsystémů.

  • Vyžaduje se zpracování v reálném čase s minimální prodlevou času.

  • Vyžaduje se komplexní zpracování událostí, například porovnávání vzorů nebo agregace v časových oknech.

  • Je potřeba vysoký objem a rychlý tok dat, jako je tomu u IoT.

  • Pro nezávislé cíle škálovatelnosti a spolehlivosti je potřeba oddělit producenty a spotřebitele.

Tato architektura nemusí být vhodná v těchto případech:

  • Zatížení má jednoduché pracovní postupy pro zpracování požadavků a odpovědí, ve kterých synchronní volání splňují vaše požadavky na latenci a propustnost. Provozní režie zprostředkovatelů událostí, asynchronní zpracování chyb a konečná konzistence není odůvodněná pro přímé interakce.

  • Obchodní transakce vyžadují silnou konzistenci napříč službami. Pokud nemůžete tolerovat okna, ve kterých různé části systému nesouhlasí s aktuálním stavem, konečná konzistence, kterou architektura řízená událostmi (EDA) zavádí, proti vám funguje.

  • Váš tým nemá zkušenosti s provozem distribuovaných asynchronních systémů. Vzorce ladění, monitorování a zotavení po chybách, které vyžadují EDA, se smysluplně liší od postupů v synchronních architekturách a křivka učení ovlivňuje časové osy doručení.

Výhody

Tato architektura poskytuje následující výhody:

  • Producenti a spotřebitelé jsou odděleni.
  • Neexistují žádné integrace typu point-to-point. Noví spotřebitelé je možné přidávat bez úprav výrobců nebo jiných spotřebitelů.
  • Příjemci mohou okamžitě reagovat na události, jakmile k nim dojde.
  • Je vysoce škálovatelná, elastická a distribuovaná.
  • Subsystémy mají nezávislá zobrazení streamu událostí.

Výzvy

  • Zaručené doručení

    V některých systémech, zejména ve scénářích IoT, je zásadní zaručit doručení událostí.

  • Případná konzistence

    Vzhledem k tomu, že producenti a příjemci jsou odděleni prostřednictvím asynchronních kanálů událostí, data napříč službami nejsou okamžitě konzistentní po publikování události. Příjemci zpracovávají události vlastním tempem a mezi časem, kdy producent generuje změnu stavu, a časem, kdy tato změna odráží všichni spotřebitelé, může být měřitelné zpoždění. V tomto okně mají různé části systému jiný pohled na aktuální stav.

    Toto chování je záměrný architektonický kompromis. V mnoha návrzích řízených událostmi se architekti rozhodnou upřednostnit dostupnost a odolnost vůči rozdělení, pro určité pracovní postupy přijmout konečnou konzistenci jako kompromis, zatímco jiné pracovní postupy můžou stále upřednostňovat silnější konzistenci. Architekti musí navrhnout konzumenty a následná čtení, aby tolerovali zastaralá nebo částečně aktualizovaná data, kde je aplikována konečná konzistence. Další informace naleznete v tématu Minimalizace koordinace.

  • Zpracovávání událostí v pořadí nebo jen jednou.

    Pro zajištění odolnosti a škálovatelnosti se každý typ příjemce obvykle spouští v několika instancích. Spuštění více instancí může vytvořit problém v případě, že události musí být zpracovány v pořadí v rámci typu konzumenta nebo pokud není implementována logika zpracování idempotentní zprávy.

  • Koordinace zpráv napříč službami

    Obchodní procesy často mají více služeb, které publikují zprávy a přihlašují se k odběru zpráv, aby bylo dosaženo konzistentního výsledku v rámci celé úlohy. K spolehlivé správě toků zpráv napříč různými službami můžete použít vzory pracovních postupů, jako jsou Choreografie a Saga Orchestration.

  • Zpracování chyb

    Architektura řízená událostmi primárně spoléhá na asynchronní komunikaci. Běžnou výzvou, kterou asynchronní komunikace představuje, je zpracování chyb. Jedním ze způsobů, jak tento problém vyřešit, je použít speciální procesor pro zpracování chyb.

    Když příjemce události narazí na chybu, okamžitě a asynchronně odešle problematickou událost zpracovateli obslužné rutiny chyby a pokračuje ve zpracování dalších událostí. Procesor zpracování chyb se pokusí problém vyřešit. Pokud je úspěšný, procesor pro zpracování chyb znovu odešle událost do původního kanálu pro příjem. Pokud selže, procesor může událost předat frontě nedoručených zpráv (DLQ) za účelem kontroly správce. Při použití procesoru pro obsluhu chyb se znovu odesílané události zpracovávají mimo posloupnost.

    Pokud obchodní proces pokrývá více služeb, zvažte použití kompenzační transakce k logickému obrácení dokončených kroků, pokud selže pozdější krok.

  • Ztráta dat

    Dalším problémem, který představuje asynchronní komunikace, je ztráta dat. Pokud dojde k chybě v některé z komponent před úspěšným zpracováním a předáním události k dalšímu komponentu, událost se vynechá a nikdy nedosáhne konečného cíle. Chcete-li minimalizovat pravděpodobnost ztráty dat, uchovávejte události během jejich přenosu a odeberte nebo dequeue události pouze v případě, že další komponenta potvrdí přijetí události. Tyto funkce se označují jako režim potvrzení klienta a podpora posledního účastníka.

  • Pozorovatelnost napříč oddělenými komponentami

    Ve synchronních architekturách můžete sledovat požadavek pomocí zásobníku volání. V architekturách řízených událostmi může jedna obchodní transakce zahrnovat více výrobců, kanálů a příjemců, které běží nezávisle a asynchronně. Když něco selže nebo se chová neočekávaně, určení, která komponenta se nesprávně chovala a proč, je obtížnější, protože neexistuje sdílený volací kontext.

    Pokud chcete zachovat viditelnost, zahrňte do každé události ID korelace, aby všichni podřízení příjemci a systémy protokolování mohli spojit související operace do jednoho trasování. Naplánujte tuto instrumentaci od začátku návrhu, protože dodatečné přidání pozorovatelnosti do odděleného systému je podstatně obtížnější než jeho začlenění od počátku.

    Tato složitost má vliv na testování. Ověření kompletního chování mezi asynchronními a oddělenými komponentami vyžaduje více záměrných testovacích strategií než synchronní řetězy volání.

  • Implementace tradičního vzoru odpovědi na požadavky

    Někdy producent události vyžaduje okamžitou odpověď od příjemce události, například získání způsobilosti zákazníka před pokračováním v objednávce. V architektuře řízené událostmi můžete dosáhnout synchronní komunikace pomocí zasílání zpráv požadavků a odpovědí.

    Tento model se implementuje s frontou požadavků a frontou odpovědí. Producent událostí odešle asynchronní požadavek do fronty požadavků, pozastaví další operace na této úloze a čeká na odpověď ve frontě odpovědí. Tento přístup tento model efektivně změní na synchronní proces. Příjemci událostí pak požadavek zpracují a odešlou odpověď zpět prostřednictvím fronty odpovědí. Tento přístup obvykle používá ID relace ke sledování, takže producent událostí ví, která zpráva ve frontě odpovědí souvisí s konkrétním požadavkem. Původní požadavek může také zadat název fronty odpovědí, potenciálně dočasné, v hlavičce odpovědi nebo jiný vzájemně odsouhlasený vlastní atribut.

  • Údržba odpovídajícího počtu událostí

    Generování nadměrného množství podrobných událostí může systém přesytit a přetížit. Nadměrný objem událostí znesnadňuje efektivní analýzu celkového toku událostí. Tento problém se zhoršuje, když je potřeba vrátit změny zpět. Naopak nadměrné konsolidace událostí může také způsobit problémy, což vede k zbytečnému zpracování a odpovědí od příjemců událostí.

    Pokud chcete dosáhnout správné rovnováhy, zvažte důsledky událostí a to, jestli uživatelé potřebují zkontrolovat datové části událostí, aby zjistili své odpovědi. Pokud máte například součást kontroly dodržování předpisů, může být dostačující publikovat pouze dva typy událostí: vyhovující předpisům a nedodržování předpisů. Tento přístup pomáhá zajistit, aby jednotlivé události zpracovávaly pouze relevantní příjemci, což brání zbytečnému zpracování.

  • Vývoj schématu událostí

    Producenti a spotřebitelé jsou nasazeni nezávisle, takže není možné aktualizovat všechny najednou. Když producent změní strukturu události, příjemci, kteří ještě nerozumí novému schématu, můžou přerušit. Definujte strategii vytváření verzí schématu v rané fázi a navrhujte uživatele pro zpracování verzí událostí, které nerozpoznávají.

Ostatní úvahy

  • Požadavek je viditelný pouze pro komponentu zpracování požadavků. Události jsou ale často viditelné pro více komponent v úloze, i když je tyto komponenty nespotřebovávají nebo je nemají využívat. Chcete-li pracovat s myšlením "předpokládat porušení zabezpečení", mějte na paměti, jaké informace zahrnete do událostí, aby se zabránilo neúmyslnému vystavení informací.

  • Mnoho aplikací používá architekturu řízenou událostmi jako svou primární architekturu. Tento přístup můžete kombinovat s jinými styly architektury a vytvořit tak hybridní architekturu. Mezi typické kombinace patří mikroslužby, kanály a filtry a záznam událostí. Integrujte architekturu řízenou událostmi za účelem zvýšení výkonu systému odstraněním kritických bodů a zajištěním zpětného tlaku během svazků s vysokými požadavky.

  • Konkrétní domény často zahrnují několik producentů událostí, příjemců nebo kanálů událostí. Změny v konkrétní doméně můžou mít vliv na mnoho komponent.

Další krok

Možnosti asynchronního zasílání zpráv

  • Last updated on