Architektura založená na událostech se skládá z producentů událostí, kteří generují stream událostí, a příjemců událostí, kteří událostem naslouchají.
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.
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.
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í.
- Vysoká škálovatelnost a distribuovanost.
- Subsystémy mají nezávislé zobrazení streamu událostí.
Problémy
- 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 .
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í.
Související prostředky
- Komunitní diskuzní video o aspektech výběru mezi hierarchií a orchestrací.