Hva er hendelsesdrevet, og hvor fort er sanntid?
Hvis vi tenker på det, kan vi identifisere mange hendelsesdrevne scenarier. Mange av dem krever en reaksjon i sanntid.
Hva mener vi med sanntid?
En reaksjon i sanntid kan sees på som et umiddelbart svar. La oss ta et eksempel på en kasserer i en kaffebar som spør deg hva du vil drikke.
Kassereren forventer et øyeblikkelig svar, eller i det minste et svar som er gitt veldig snart. Ellers kan kassereren omformulere spørsmålet eller mistenke at du var uhøflig. Et raskt svar er forespurt og også hensiktsmessig. Tiden for å svare kan variere litt, men det er fortsatt sett på som "i sanntid." Så, returnere en hilsen bør skje raskt, men det er greit å tenke kort om din ordre om å svare på kassererens spørsmål.
Hvis du oversetter dette scenarioet til programvaresystemer, er alt du bryr deg om tidsberegninger: Responstid, Fullføringstid, Tilgangstid, StartUp Times og så videre. Brukeren eller tilgangsprogrammet definerer disse tidsberegningene.
Notat
I sanntid utfører systemoppgaver sin funksjon innenfor foreskrevne tidsfrister.
Du bør alltid være klar over hva som skjer i systemet. Så pass på at du ikke glemmer det åpenbare, som er logging, overvåking og måling av tidsberegninger.
Viktig
Kontroller at du angir tidsfrister og tidsberegninger på forhånd, og konfigurerer en løsning for ikke-blokkering av overvåking for kontroll.
Sammendrag er vi enige om at sanntid betyr superrask, på et øyeblikk. Hvor raskt angis nøyaktig av det angitte scenarioet.
Hendelsesdrevne programmer
Hvis du tenker på en klikkhendelse, kan du tenke på noe annet. Hendelsesdrevne programmer bruker brann og glemmer prinsippet. Arrangementet blir sendt eller avfyrt mot neste system, som kan være en annen tjeneste, en hendelse hub, en strøm eller en melding megler som Kafka. Vi venter ikke nødvendigvis på svar fra den neste i systemet. Løs kobling oppnås for prisen av eventuell konsistens, som må tas vare på på et annet nivå.
For å identifisere arten av hendelsesdrevne programmer, la oss se på de viktigste arkitekturmønstrene ved hjelp av eksemplet på en kunde, kalt Alex, som kjøper en kaffe og en cappuccino.
Hendelsesvarsling
Hendelsesvarsling er varselet om en bestemt hendelse eller hendelse. Hver hendelse vises separat. Eksempelet på en kunde som heter Alex kjøpe en kaffe og en cappuccino kan se slik ut:
1. Arrangement: Alex kjøper en kaffe.
2. Arrangement: Alex kjøper en cappuccino.
En barista måtte lytte nøye til alle hendelser for å få Alex hele bestillingen. Men to baristaer kunne også forberede og servere drinkene uavhengig.
Hendelse gjennomført tilstandsoverføring
Med overføring av hendelsesbært tilstand lagres all nødvendig informasjon i én enkelt hendelse. Dette er nyttig hvis en hendelse går tapt eller tjenesten ikke lytter til alle hendelsene. For eksempel vil hendelsene se slik ut:
1. Arrangement: Alex kjøper en kaffe.
2. Arrangement: Alex kjøper, i tillegg til kaffen, en cappuccino.
Med én barista kan det være nok å lytte bare til den andre hendelsen. Med to baristaer måtte den andre se på den første. Bestillingen kan serveres sammen, men prosessen kan ta lengre tid enn å gjøre den helt frakoblet.
Kilder til arrangementer
Med event sourcing kommer hendelseslagringen i fokus. Som du kan se, er hendelsene de samme som i det første eksemplet. Men baristaen er viktig for dette konseptet for øyeblikket når baristaen mottar et arrangement og deretter tenker på alle tilsvarende hendelser for å få den nåværende tilstanden for alle ordrene gjort av Alex.
Med den andre ordren vet baristaen at Alex ordre består av en kaffe, ved å huske den første rekkefølgen, og en cappuccino, fordi denne drinken nettopp ble bestilt. Å jobbe parallelt med en annen barista er ikke så lett mulig.
Når vi legger til en kasserer for å motta ordrene og servere drinkene, kan baristaene jobbe uavhengig for å forberede drinkene. De trenger ikke å vite noe om kundene. Kassereren er det såkalte hendelseslageret, som vedvarer hendelsene, i det scenariet. Event sourcing legger til et annet lag med kompleksitet, men det legger også til frakobling.
1. Arrangement: Alex kjøper en kaffe.
Kasserer: (Første) bestilling (for Alex): Kaffe
2. Arrangement: Alex kjøper en cappuccino.
Kasserer: (Andre) bestilling (for Alex): Cappuccino
Telemetridata er sanntidshendelser
Det finnes også andre eksempler vi kan tenke på. Tenk deg scenarioet med å kjøre et kjølesystem, for eksempel for mat- eller legemiddelprodusenter. Du trenger konstant kontroll over temperaturen og andre relevante data i systemet. Bevissthet om telemetridataene og å kontrollere dem automatisk vil være avgjørende for at du lykkes. Måling av telemetri annenhver sekund og deretter sende den mot kontrollsystemet der dataene analyseres, behandles og håndteres, er et hendelsesdrevet system. Dataene må også behandles i sanntid fordi det er viktig å reagere raskt for å unngå tragiske konsekvenser for virksomheten.