Co je řízené událostmi a jak rychle je v reálném čase?
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 velmi brzy udělena. V opačném případě může pokladna přeformulovat otázku nebo podezření, že jste hrubá. Vyžaduje se rychlá odpověď a také je vhodná. Čas na odpověď se může mírně lišit, ale stále se považuje za "v reálném čase". Takže vrácení pozdravu by mělo proběhnout rychle, ale je v pořádku si krátce myslet na vaši objednávku, aby odpověděl na otázku pokladníka.
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ě. Jak rychle přesně 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 požáru a zapomenutí . Událost se odešle nebo aktivuje do dalšího 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ěď z další v systému. Volné párování je dosaženo pro cenu konečné konzistence, která se musí postarat na jinou úroveň.
Abychom identifikovali povahu aplikací řízených událostmi, podívejme se na hlavní vzory architektury pomocí příkladu zákazníka, jménem Alex, zakoupení kávy 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 událostem, aby dostal Alexovo celé pořadí. 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 koupí kromě kávy, cappuccino.
S jedním barista, naslouchání pouze druhé události může být dostačující. Se dvěma baristay by se druhý musel podívat na první. Objednávka by mohla být obsluhována společně, ale proces může trvat déle, než se úplně oddělí.
Event Sourcing
S modelem Event Sourcing se úložiště událostí zaměřuje na pozornost. 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í co nejjednodušší.
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. Pokladní je takzvaný obchod s událostmi, který v tomto scénáři 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ých dva sekundy a následné odeslání do řídicího systému, kde se data analyzují, zpracovávají a zpracovávají, jsou systémem řízeným událostmi. 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.