Co je řízené událostmi a jak rychlá je doba reálného času?
Pokud se nad tím podíváme, můžeme identifikovat mnoho scénářů řízených událostmi. Spousta z nich vyžaduje reakci v reálném čase.
Co znamenáme v reálném čase?
Reakci v reálném čase lze považovat za okamžitou odpověď. Podívejme se na příklad pokladny v kavárně, která se vás zeptá, co chcete pít.
Pokladní očekává okamžitou odpověď, nebo alespoň odpověď, která je dána velmi brzy. V opačném případě by mohl pokladní přeformulovat otázku nebo mít podezření, že jste byl hrubý/hubá. Je požadována rychlá a zároveň vhodná odpověď. Čas na odpověď se může mírně lišit, ale stále se považuje za "v reálném čase". Odpovědět na pozdrav by mělo proběhnout rychle, ale je v pořádku si krátce zamyslet nad objednávkou, abyste odpověděli na otázku pokladní.
Pokud tento scénář přeložíte do softwarových systémů, záleží na načasování: doba odezvy, doba dokončení, doba přístupu, čas spuštění atd. Uživatel nebo přístupová aplikace tyto časování definuje.
Poznámka
V reálném čase úlohy systémů provádějí svou funkci v rámci předepsané lhůty.
Vždy byste měli vědět, co se děje ve vašem systému. Proto se ujistěte, že nezapomenete na zřejmé, což je protokolování, monitorování a měření časování.
Důležitý
Ujistěte se, že předem zadáte konečné termíny a načasování a nastavíte neblokující řešení monitorování pro kontrolu.
V souhrnu souhlasíme s tím, že v reálném čase znamená superrychlé, okamžitě. Přesně jak rychle určuje váš daný scénář.
Aplikace řízené událostmi
Pokud přemýšlíte o události kliknutí, myslíte na něco jiného. Aplikace řízené událostmi používají princip "fire and forget". Událost se odešle nebo aktivuje směrem k dalšímu systému, což může být jiná služba, centrum událostí, stream nebo zprostředkovatel zpráv, jako je Kafka. Nemusíme nutně čekat na odpověď od dalšího v systému. Volné spojení je dosaženo za cenu eventuální konzistence, o kterou se musí postarat na jiné úrovni.
Abychom identifikovali povahu aplikací řízených událostmi, podívejme se na hlavní vzory architektury na příkladu zákazníka Alexe, který si kupuje kávu a cappuccino.
Oznámení události
Oznámení o události je oznámení o konkrétním výskytu nebo události. Každá událost je zobrazena samostatně. Příklad zákazníka jménem Alex, který si koupí kávu a cappuccino, může vypadat takto:
1. Událost: Alex koupí kávu.
2. Událost: Alex koupí cappuccino.
Jeden barista by musel pozorně naslouchat všem výrokům, aby dostal Alexovu celou objednávku. Ale dva barista mohou také připravit a obsluhovat nápoje nezávisle.
Přenos stavu přenášené událostí
Při přenosu stavu události jsou všechny potřebné informace uloženy v jedné události. To se hodí, pokud dojde ke ztrátě události nebo vaše služba neposlouchá všem událostem. V našem příkladu by události vypadaly takto:
1. Událost: Alex koupí kávu.
2. Událost: Alex si koupí kromě kávy i cappuccino.
Poslouchání pouze na druhou událost může být s jedním baristou dostačující. Pokud jsou dva baristé, ten druhý by se měl podívat na toho prvního. Objednávka by mohla být vyřízena společně, ale proces může trvat déle, než kdyby byla zcela oddělena.
Zdrojování událostí
S modelem Event Sourcing se zaměřujeme na úložiště událostí. Jak vidíte, události jsou stejné jako v prvním příkladu. Ale barista je důležitý pro tento koncept v okamžiku, kdy barista obdrží událost a pak si myslí o všech odpovídajících událostech, aby získal aktuální stav pro všechny objednávky provedené Alexem.
Ve druhé objednávce barista ví, že alexova objednávka se skládá z kávy, tím, že si pamatuje první objednávku, a cappuccino, protože tento nápoj byl právě objednán. Práce paralelně s druhým baristou není tak snadná.
Když přidáme pokladnu pro příjem objednávek a obsluhu nápojů, baristas může pracovat nezávisle na přípravě nápojů. Nemusí o zákaznících nic vědět. V tomto scénáři funguje pokladna jako takzvaný obchod s událostmi, který uchovává události. Event Sourcing přidává další vrstvu složitosti, ale přidává také oddělení.
1. Událost: Alex koupí kávu.
Pokladna: (První) objednávka (pro Alex): Káva
2. Událost: Alex koupí cappuccino.
Pokladna: (druhá) objednávka (pro Alex): Cappuccino
Telemetrická data jsou události v reálném čase
Existují i další příklady, o které můžeme uvažovat. Představte si scénář provozování chladicího systému, například pro výrobce potravin nebo léků. Potřebujete konstantní kontrolu nad teplotou a dalšími relevantními daty ve vašem systému. Informovanost o telemetrických datech a jejich řízení by pro váš úspěch byla důležitá. Měření telemetrie každé dvě sekundy a následné odeslání do řídicího systému, kde se data analyzují, zpracovávají a spravují, je událostmi řízený systém. Data musí být také zpracována v reálném čase, protože je důležité rychle reagovat, aby se zabránilo smutným důsledkům pro firmu.