Architektura řízená událostmi se skládá z producentů událostí, kteří generují stream událostí, příjemci událostí, kteří tyto události naslouchají, a kanály událostí, které přenášejí události od producentů do příjemců.
Události se doručují skoro v reálném čase, takže příjemci můžou reagovat okamžitě, jakmile k události dojde. Producenti jsou odděleni od spotřebitelů – producent neví, kteří spotřebitelé naslouchají. Příjemci jsou taky oddělení od sebe navzájem a každý příjemce vidí všechny události. Tím se liší od modelu konkurujících si příjemců, kde si příjemci vytahují zprávy z fronty a zpráva se zpracuje jenom jednou (pokud nedojde k chybě). U některých systémů, jako je například IoT, je potřeba ingestovat velké objemy událostí.
Architektura řízená událostmi může používat model publikování nebo odběru (označovaný také jako pub/sub) nebo model streamu událostí.
Publikování a odběr: Infrastruktura zasílání zpráv si uchovává informace o odběrech. Při publikování události se událost odešle každému odběrateli. Jakmile dojde k přijetí události, nejde ji přehrát a noví odběratelé událost neuvidí.
Streamování událostí: Události se zapisují do protokolu. Události jsou důsledně řazené (v rámci oddílu) a trvalé. Klienti nejsou přihlášení k odběru streamu, místo toho může klienta číst z jakékoliv části streamu. Klient je zodpovědný za posun své pozice ve streamu. To znamená, že klient se můžete kdykoli připojit a může události znovu přehrát.
Na straně příjemce existuje několik obvyklých variací:
Jednoduché zpracování událostí. Událost okamžitě aktivuje akci u příjemce. Například můžete použít Azure Functions s triggerem Service Bus, takže se funkce provede vždy při publikování zprávy do tématu Service Bus.
Základní korelace událostí Spotřebitel musí zpracovat malý počet diskrétních obchodních událostí, obvykle korelovaný určitým identifikátorem, zachovat některé informace z dřívějších událostí, které se mají 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 zpracovává řadu událostí a hledá vzory v datech událostí pomocí technologie, jako je Azure Stream Analytics. Může například agregovat odečty z vestavěného zařízení během časového okna a vygenerovat oznámení v případě, že klouzavý průměr překročí určitou mez.
Zpracování streamu událostí. Použijte platformu streamování dat, například Azure IoT Hub nebo Apache Kafka, jako kanál k ingestování událostí a jejich vstupu do procesorů streamu. Procesory streamu fungují tak, že zpracovávají nebo transformují stream. Může existovat více procesorů streamu pro různé subsystémy aplikace. Tento přístup je vhodný pro úlohy IoT.
Zdroj událostí může být vzhledem k systému externí, jako jsou například fyzická zařízení v řešení IoT. V takovém případě musí být systém schopný ingestovat takový objem dat a propustnost, jak to vyžaduje zdroj dat.
Existují dva primární přístupy k strukturování datových částí událostí. Pokud máte kontrolu nad příjemci událostí, proveďte toto rozhodnutí o struktuře datové části na příjemce; kombinování přístupů podle potřeby v rámci jedné úlohy.
Zahrnutí všech požadovaných atributů do datové části: Tento přístup se používá, pokud chcete, aby uživatelé měli všechny dostupné informace bez nutnosti dotazovat se na 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.
Zahrnutí pouze klíčů do datové části: 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. I když tato metoda nabízí lepší konzistenci dat z důvodu jednoho systému záznamů, může být horší než první přístup, protože uživatelé se musí často dotazovat na zdroj dat. Existuje méně obav týkajících se párování, šířky pásma, správy kontraktů nebo správy verzí, protože události jsou menší a kontrakty jednodušší.
Ve výše uvedeném logickém diagramu každý typ příjemce se zobrazuje jako jednotlivé pole. V praxi je běžné mít více instancí příjemce, aby se příjemce nestal kritickým prvkem způsobujícím selhání v systému. Více instancí může být také potřeba ke zpracování objemu a četnosti událostí. Jeden příjemce může také zpracovávat události z více vláken. To 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. Přečtěte si téma Minimalizace koordinace.
V mnoha architekturách řízených událostmi existují dvě primární topologie:
Topologie zprostředkovatele. Komponenty vysílají výskyty jako události do celého systému a další komponenty buď působí na 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 velmi 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ě. Distribuované transakce jsou následně rizikové, protože neexistuje žádný nativní způsob restartování nebo přehrání. Zpracování chyb a strategie ručního zásahu je potřeba pečlivě zvážit, 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álostí, 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 vysílají jako příkazy a pouze určeným kanálům, obvykle frontám zpráv. U těchto příkazů se neočekává, že by je uživatelé ignorovali. Tato topologie nabízí větší kontrolu, lepší distribuované zpracování chyb a potenciálně lepší konzistenci dat. Tato topologie zavádí zvýšenou spojku mezi součástmi a mediátor události může být kritickým bodem nebo problémem spolehlivosti.
Kdy použít tuto architekturu
- Více subsystémů musí zpracovat stejné události.
- Zpracování v reálném čase s minimálním zpožděním.
- Komplexní zpracování událostí, například porovnávání vzorů nebo agregace přes časová okna.
- Vysoký objem a vysoká rychlost dat, jako v případě IoT.
Zaměstnanecké výhody
- Producenti a příjemci jsou oddělení.
- Žádné integrace typu point-to-point. Je snadné přidat do systému nové příjemce.
- Příjemci můžou reagovat na události ihned po doručení.
- Vysoce škálovatelné, elastické a distribuované.
- Subsystémy mají nezávislé zobrazení streamu událostí.
Výzvy
Garantované doručení.
U některých systémů, zejména ve scénářích IoT, je nezbytné garantovat, že se události doručují.
Zpracování událostí v daném pořadí nebo právě jednou.
Každý typ příjemce obvykle běží v několika instancích, kvůli odolnosti proti chybám a škálovatelnosti. To může vytvořit výzvu, pokud události musí být zpracovány v pořadí (v rámci typu příjemce) nebo není implementována logika zpracování idempotentní zprávy.
Koordinace zpráv napříč službami.
Obchodní procesy často zahrnují publikování a přihlášení k odběru zpráv více služeb, 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 se dají použít vzory pracovních postupů, jako je model telemetrie a Saga Orchestration .
Zpracování chyb
Architektura řízená událostmi používá hlavně asynchronní komunikaci. Problém s asynchronní komunikací je zpracování chyb. Jedním ze způsobů, jak tento problém vyřešit, je použít samostatný procesor obslužné rutiny chyb. Takže když příjemce události dojde k chybě, okamžitě a asynchronně odešle chybnou událost do procesoru obslužné rutiny chyby a přesune se dál. Procesor obslužné rutiny chyby se pokusí chybu opravit a odešle událost zpět do původního kanálu příjmu dat. Ale pokud procesor obslužné rutiny chyby selže, může odeslat chybnou událost správci k další kontrole. Pokud použijete procesor obslužné rutiny chyby, chybné události budou zpracovány mimo posloupnost při jejich opětovném odeslání.
Ztráta dat.
Dalším problémem s asynchronní komunikací 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 ji neudělí do 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 potvrdila přijetí události. Tyto funkce se obvykle označují jako režim potvrzení klienta a podpora posledního účastníka.
Implementace tradičního vzoru odpovědi na požadavek
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 prostřednictvím zasílání zpráv požadavků a odpovědí.
Tento model se obvykle implementuje pomocí více front – fronty požadavků a fronty odpovědí. Producent událostí odešle asynchronní požadavek do fronty požadavků, pozastaví další operaci na této úloze a čeká na odpověď ve frontě odpovědí; tím, že tento proces účinně převede 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 využí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ém vzájemně odsouhlaseném vlastním atributu.
Udržování odpovídajícího počtu událostí
Generování nadměrného počtu jemně odstupňovaných událostí může zahltit a zahltit systém, což 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ím 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í k publikování pouze dvou typů událostí: vyhovujících předpisům a nedodržování předpisů. Tento přístup umožňuje zpracování každé události pouze relevantními příjemci, což brání zbytečnému zpracování.
Další důležité informace
- Objem dat, která se mají zahrnout do události, může být významným aspektem, který ovlivňuje výkon i náklady. Vložení všech relevantních informací potřebných ke zpracování v samotné události může zjednodušit kód zpracování a uložit další vyhledávání. Umístění minimálního množství informací do události, jako je jen pár identifikátorů, sníží dobu přenosu a náklady, ale vyžaduje kód pro zpracování, aby vyhledaly všechny další informace, které potřebuje. Další informace o tom najdete v tomto blogovém příspěvku.
- Zatímco požadavek je viditelný pouze pro komponentu zpracování požadavků, události jsou často viditelné pro více komponent v úloze, i když tyto komponenty nejsou nebo nemají být určeny k jejich využívání. Mějte na paměti, jaké informace zahrnete do událostí, abyste zabránili neúmyslnému vystavení informací.
- Mnoho aplikací používá architekturu řízenou událostmi jako svou primární architekturu; Tento přístup však lze kombinovat s jinými styly architektury, což vede k hybridním architekturám. Mezi běžné kombinace patří mikroslužby a kanály a filtry. Integrace architektury řízené událostmi vylepšuje výkon systému odstraněním kritických bodů a zajištěním zpětného tlaku během velkých objemů požadavků.
- Konkrétní domény často zahrnují několik producentů událostí, příjemců nebo kanálů událostí. Změny konkrétní domény můžou mít vliv na mnoho komponent.
Související prostředky
- Komunitní diskuzní video o aspektech výběru mezi hierarchií a orchestrací.