Hvad er hændelsesdrevet, og hvor hurtigt er realtid?
Hvis vi tænker over det, kan vi identificere mange hændelsesdrevne scenarier. Masser af dem kræver en reaktion i realtid.
Hvad mener vi med realtid?
En reaktion i realtid kan ses som et øjeblikkeligt svar. Lad os tage et eksempel på en kasserer i en kaffebar, der spørger dig, hvad du vil drikke.
Kasserer forventer et øjeblikkeligt svar eller i det mindste et svar, der gives meget snart. Ellers kasserer kan omformulere spørgsmålet eller mistanke om, at du var uhøflig. Der anmodes om et hurtigt svar, og det er også passende. Tiden til at svare kan variere en smule, men det ses stadig som værende "i realtid". Så returnering af en hilsen bør ske hurtigt, men det er fint at tænke kort over din ordre til at besvare kassererens spørgsmål.
Hvis du oversætter dette scenarie til softwaresystemer, er det eneste, du bekymrer dig om, tidsindstillinger: svartid, afslutningstid, adgangstid, starttidspunkter osv. Brugeren eller adgangsprogrammet definerer disse tidsindstillinger.
Seddel
I realtid udfører systemopgaver deres funktion inden for de foreskrevne tidsfrister.
Du skal altid være opmærksom på, hvad der sker i dit system. Så sørg for, at du ikke glemmer det åbenlyse, som er logføring, overvågning og måling af dine timinger.
Vigtig
Sørg for at angive deadlines og tidsindstillinger på forhånd, og konfigurer en overvågningsløsning, der ikke blokerer, til kontrol.
Kort sagt er vi enige om, at realtid betyder superhurtigt på et øjeblik. Hvor hurtigt det præcist er angivet i dit givne scenarie.
Hændelsesdrevne programmer
Hvis du tænker på en klikhændelse, tænker du på noget andet. Hændelsesdrevne programmer bruger brand og glemmer princip. Hændelsen sendes eller udløses mod det næste system, som kan være en anden tjeneste, en hændelseshub, en stream eller en meddelelsesmægler som Kafka. Vi venter ikke nødvendigvis på et svar fra den næste i systemet. Løs kobling opnås for prisen på eventuel konsistens, som skal tages hånd om på et andet niveau.
For at identificere arten af eventdrevne programmer, lad os se på de vigtigste arkitekturmønstre ved hjælp af eksemplet på en kunde, der hedder Alex, købe en kop kaffe og en cappuccino.
Hændelsesmeddelelse
Hændelsesmeddelelse er meddelelsen om en bestemt hændelse eller hændelse. Hver hændelse ses separat. Eksemplet på en kunde med navnet Alex, der køber en kop kaffe og en cappuccino, kan se sådan ud:
1. Begivenhed: Alex køber en kop kaffe.
2. Arrangement: Alex køber en cappuccino.
En barista ville have til at lytte omhyggeligt til alle begivenheder for at få Alex's hele orden. Men to baristaer kunne også forberede og servere drikkevarer uafhængigt af hinanden.
Overførsel af hændelsestransporttilstand
Med hændelsestransport med tilstandsoverførsel gemmes alle de nødvendige oplysninger i en enkelt hændelse. Det er praktisk, hvis en begivenhed går tabt, eller din tjeneste ikke lytter til alle hændelserne. I vores eksempel ser hændelserne sådan ud:
1. Begivenhed: Alex køber en kop kaffe.
2. Arrangement: Alex køber, ud over kaffen, en cappuccino.
Med én barista kan det være nok kun at lytte til den anden begivenhed. Med to baristaer, ville den anden nødt til at se på den første. Ordren kunne serveres sammen, men processen kan tage længere tid end at gøre det helt afkoblet.
Hændelses sourcing
Med event sourcing kommer eventlageret i fokus. Som du kan se, er hændelserne de samme som i det første eksempel. Men barista er vigtig for dette koncept i det øjeblik, hvor barista modtager en begivenhed og derefter tænker på alle tilsvarende begivenheder for at få den aktuelle tilstand for alle ordrer foretaget af Alex.
Med den anden ordre ved baristaen, at Alex' ordre består af en kop kaffe, ved at huske den første ordre og en cappuccino, fordi denne drink netop blev bestilt. Det er ikke så nemt at arbejde parallelt med en anden barista.
Når vi tilføjer en kasserer for at modtage ordrerne og servere drikkevarerne, kan baristaerne arbejde selvstændigt for at forberede drikkevarerne. De behøver ikke at vide noget om kunderne. Kasserer er den såkaldte hændelsesbutik, der fastholder hændelserne i dette scenarie. Event sourcing tilføjer endnu et lag af kompleksitet, men det tilføjer også afkobling.
1. Begivenhed: Alex køber en kop kaffe.
kasserer: (Første) ordre (for Alex): Kaffe
2. Arrangement: Alex køber en cappuccino.
kasserer: (anden) ordre (for Alex): Cappuccino
Telemetridata er hændelser i realtid
Der er også andre eksempler, vi kan tænke på. Forestil dig scenariet med at køre et kølesystem, f.eks. Du har brug for konstant kontrol af temperaturen og andre relevante data i dit system. Opmærksomhed om telemetridata og automatisk styring af dem ville være afgørende for din succes. Måling af telemetrien hvert andet sekund og derefter sender den mod kontrolsystemet, hvor dataene analyseres, behandles og håndteres, er et hændelsesdrevet system. Dataene skal også behandles i realtid, fordi det er vigtigt at reagere hurtigt for at undgå tragiske konsekvenser for virksomheden.