Vad är händelsedriven och hur snabbt är realtid?
Om vi tänker på det kan vi identifiera många händelsedrivna scenarier. Många av dem kräver en reaktion i realtid.
Vad menar vi med realtid?
En reaktion i realtid kan ses som ett omedelbart svar. Låt oss ta ett exempel på en kassörska i ett kafé som frågar dig vad du vill dricka.
Kassören förväntar sig ett omedelbart svar, eller åtminstone ett svar som ges mycket snart. Annars kan kassören omformulera frågan eller misstänka att du var oförskämd. Ett snabbt svar begärs och är också lämpligt. Tiden att svara kan variera något, men det ses fortfarande som "i realtid". Så att returnera en hälsning bör ske snabbt, men det är bra att tänka kort på din order att svara på kassörens fråga.
Om du översätter det scenariot till programvarusystem är allt du bryr dig om tidsinställningar: svarstid, slutförandetid, åtkomsttid, starttider och så vidare. Användaren eller programmet som kommer åt definierar dessa tidsinställningar.
Kommentar
I realtid utför systemuppgifter sin funktion inom föreskrivna tidsgränser.
Du bör alltid vara medveten om vad som händer i systemet. Så se till att du inte glömmer det uppenbara, vilket är loggning, övervakning och mätning av dina tidpunkter.
Viktigt!
Se till att du anger tidsgränser och tidsinställningar i förväg och konfigurerar en övervakningslösning som inte är blockerad för kontroll.
Sammanfattningsvis är vi överens om att realtid innebär supersnabbt, på ett ögonblick. Hur snabbt exakt anges av ditt givna scenario.
Händelsedrivna program
Om du tänker på en klickhändelse tänker du på något annat. Händelsedrivna program använder principen för eldsvåda och glöm . Händelsen skickas eller utlöses mot nästa system, vilket kan vara en annan tjänst, en händelsehubb, en dataström eller en meddelandekö som Kafka. Vi väntar inte nödvändigtvis på ett svar från nästa i systemet. Lös koppling uppnås för priset av slutlig konsekvens, som måste tas om hand på en annan nivå.
För att identifiera typen av händelsedrivna program ska vi titta på de viktigaste arkitekturmönstren genom att använda exemplet med en kund med namnet Alex, köpa en kaffe och en cappuccino.
Händelsemeddelande
Händelsemeddelande är meddelandet om en specifik händelse eller händelse. Varje händelse visas separat. Exemplet på en kund med namnet Alex som köper en kaffe och en cappuccino kan se ut så här:
1. Händelse: Alex köper en kaffe.
2. Händelse: Alex köper en cappuccino.
En barista skulle behöva lyssna noga på alla händelser för att få Alex hela beställning. Men två baristor kunde också förbereda och servera dryckerna självständigt.
Tillståndsöverföring för händelseförd
Med händelseförd tillståndsöverföring lagras all nödvändig information i en enda händelse. Det är praktiskt om en händelse går förlorad eller om tjänsten inte lyssnar på alla händelser. I vårt exempel skulle händelserna se ut så här:
1. Händelse: Alex köper en kaffe.
2. Händelse: Alex köper, förutom kaffet, en cappuccino.
Med en barista kan det räcka att bara lyssna på den andra händelsen. Med två baristor skulle den andra behöva titta på den första. Ordern kan hanteras tillsammans, men processen kan ta längre tid än att göra den helt frikopplad.
Händelsekällor
Med händelsekällor hamnar händelselagringen i fokus. Som du ser är händelserna samma som i det första exemplet. Men baristan är viktig för detta koncept just nu när barista får ett evenemang och sedan tänker på alla motsvarande händelser för att få det nuvarande tillståndet för alla beställningar som gjorts av Alex.
Med den andra ordern vet barista att Alex beställning består av en kaffe, genom att komma ihåg den första beställningen och en cappuccino, eftersom denna drink just beställdes. Det är inte så lätt att arbeta parallellt med en andra barista.
När vi lägger till en kassör för att ta emot beställningarna och servera dryckerna kan baristorna arbeta självständigt för att förbereda dryckerna. De behöver inte veta något om kunderna. Kassören är det så kallade händelsearkivet som bevarar händelserna i det scenariot. Händelsekällor lägger till ytterligare ett lager av komplexitet, men det lägger också till avkoppling.
1. Händelse: Alex köper en kaffe.
Kassör: (Första) beställning (för Alex): Kaffe
2. Händelse: Alex köper en cappuccino.
Kassör: (Second) order (för Alex): Cappuccino
Telemetridata är realtidshändelser
Det finns också andra exempel som vi kan komma på. Föreställ dig scenariot med att köra ett kylsystem, till exempel för livsmedels- eller läkemedelstillverkare. Du behöver konstant kontroll över temperaturen och andra relevanta data i systemet. Att känna till telemetridata och kontrollera dem automatiskt skulle vara avgörande för att du ska lyckas. Att mäta telemetrin varannan sekund och sedan skicka den mot kontrollsystemet där data analyseras, bearbetas och hanteras är ett händelsestyrt system. Dessutom måste data bearbetas i realtid eftersom det är viktigt att reagera snabbt för att undvika tragiska konsekvenser för verksamheten.