Styl architektury založené na událostech

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ělení od příjemců – producent neví, kteří příjemci 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 založená na událostech může využívat model publikování a odběru 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. Po přijetí nelze událost znovu přehrát a novým odběratelům se událost nezobrazí.

• 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.

• Komplexní zpracování událostí. Příjemce zpracovává řadu událostí a hledá vzory v datech událostí pomocí technologie, jako je Azure Stream Analytics nebo Apache Storm. 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í datového proudu 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 vytvářet problémy, pokud je nutné zpracovávat události v daném pořadí nebo vyžadovat sémantiku právě 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.

Výhody

• Producenti a příjemci jsou oddělení.
• Žádná integrace 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í.

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 způsobit potíže, pokud je nutné zpracovávat události v daném pořadí (v rámci typu příjemce) nebo pokud logika zpracování není idempotentní.

Další aspekty

• Množství dat, která se mají zahrnout do události, může být významným faktorem, 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í. Vložení minimálního množství informací v události, například jenom u několika identifikátorů, omezí dobu přenosu a náklady, ale vyžaduje, aby kód pro zpracování vyhledal jakékoli další informace, které potřebuje. Další informace najdete v tomto blogovém příspěvku.