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

Šipka ukazuje z oddílu Producenti událostí do oddílu Příjem událostí. Tři šipky ukazují z oddílu Pro příjem událostí na tři oddíly, které jsou všechny označené příjemci událostí.

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í. Příjemci jsou také odděleni od sebe a každý příjemce vidí všechny události.

Tento proces se liší od modelu Konkurenční spotřebitelé. V modelu Konkurující spotřebitelé přetahují 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, jako je Azure IoT, se události musí ingestovat ve velkých objemech.

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

• Publikování a přihlášení k odběru: Infrastruktura zasílání zpráv publikování a odběru sleduje odběry. Když je událost publikovaná, odešle událost každému odběrateli. Jakmile se událost doručí, nejde ji přehrát a noví odběratelé událost neuvidí. Ke scénářům publikování a odběru doporučujeme použít 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 odolné. 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. Služba Azure Event Hubs je navrž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. Azure Functions můžete například použít s triggerem Event Gridu nebo triggerem služby Azure Service Bus , 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 je NServiceBus a MassTransit .

• Komplexní zpracování událostí: Spotřebitel 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.

• Zpracování datových proudů událostí: Použijte platformu streamování dat, jako je Azure IoT Hub, Event Hubs nebo Event Hubspro Apache Kafka, jako kanál pro příjem událostí a jejich podávání do streamovaných 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 schopný ingestovat data na svazku a propustnosti, 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. Může ale 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 uživatelé načítají potřebné atributy, jako je primární klíč, aby nezávisle načetli zbývající data ze zdroje dat. Tato metoda poskytuje lepší konzistenci dat, protože má jeden systém záznamů. Může ale fungovat méně 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.

V předchozím diagramu se každý typ příjemce zobrazí jako jedno pole. Abyste se vyhnuli tomu, že se spotřebitel stane jediným bodem selhání v systému, je typické mít více instancí příjemce. 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í sémantiku přesně jednou. Další informace naleznete v tématu Minimalizace koordinace.

V mnoha 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 se komponenty v mediátorové topologii vysílaly jako příkazy a pouze určeným kanálům. 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.

• Vyžaduje se vysoký objem a vysoká rychlost dat, jako je ioT.

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

Výhody

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

• Producenti a spotřebitelé jsou odděleni.
• Neexistují žádné integrace typu point-to-point. Do systému můžete snadno přidávat nové uživatele.
• 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í.

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

  Pro zajištění odolnosti a škálovatelnosti se každý typ příjemce obvykle spouští v několika instancích. Tento proces může vytvořit výzvu, pokud události musí být zpracovány v pořadí v rámci typu příjemce nebo pokud není implementovaná 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 telemetrie a Saga Orchestraation .

• 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 vyhrazený procesor obslužné rutiny chyb.

  Když příjemce události narazí na chybu, okamžitě a asynchronně odešle problematickou událost procesoru obslužné rutiny chyby a pokračuje ve zpracování dalších událostí. Procesor obslužné rutiny chyby se pokusí problém vyřešit. Pokud je úspěšný, procesor obslužné rutiny chyby znovu odešle událost do původního kanálu příjmu dat. Pokud selže, může procesor událost předat správci k další kontrole. Při použití procesoru obslužné rutiny chyby se znovu odsílané události zpracovávají mimo posloupnost.

• Ztráta dat

  Dalším problémem, který představuje asynchronní komunikace, je ztráta dat. Pokud se některá z komponent před úspěšným zpracováním a předáním události do další komponenty chybově ukončí, událost se zahodí a nikdy nedosáhne konečného cíle. Chcete-li minimalizovat pravděpodobnost ztráty dat, zachovejte události během přenosu a odstraňte nebo odstraňte 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.

• 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 je možné synchronní komunikaci dosáhnout 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 počtu jemně odstupňovaných událostí může systém zahltit a zahltit. 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í.

Ostatní úvahy

• Objem dat, která se mají zahrnout do události, může být významným aspektem, který ovlivňuje výkon a náklady. Kód pro zpracování můžete zjednodušit a eliminovat další vyhledávání tak, že umístíte všechny relevantní informace potřebné ke zpracování přímo v události. Když do události přidáte jenom minimální množství informací, například několik identifikátorů, zkrátíte dobu přenosu a náklady. Tento přístup ale vyžaduje, aby kód zpracování načetl všechny další informace, které potřebuje. Další informace naleznete v tématu Put your events on a diet.

• 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 a kanály a filtry. 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

• Komunitní diskuzní video