Wat is gebeurtenisgestuurd en hoe snel is realtime?
Als we erover nadenken, kunnen we veel gebeurtenisgestuurde scenario's identificeren. Veel van hen vereisen een reactie in realtime.
Wat bedoelen we in realtime?
Een reactie in realtime kan worden gezien als een direct antwoord. Laten we een voorbeeld nemen van een kassier in een koffiebar die u vraagt wat u wilt drinken.
De kassier verwacht een direct antwoord, of ten minste een antwoord dat binnenkort wordt gegeven. Anders kan de kassier de vraag herformuleren of vermoeden dat u onbeleefd was. Er wordt een snel antwoord aangevraagd en ook geschikt. De tijd om te antwoorden kan enigszins variëren, maar het wordt nog steeds gezien als 'in realtime'. Dus, het retourneren van een begroeting zou snel moeten gebeuren, maar het is prima om kort na te denken over uw bestelling om de vraag van de kassier te beantwoorden.
Als u dat scenario vertaalt naar softwaresystemen, is het enige wat u belangrijk vindt tijdsinstellingen: reactietijd, voltooiingstijd, toegangstijd, opstarttijden, enzovoort. De gebruiker of de toegangstoepassing definieert deze tijdsinstellingen.
Notitie
In realtime voeren systeemtaken hun functie uit binnen voorgeschreven deadlines.
U moet altijd op de hoogte zijn van wat er in uw systeem gebeurt. Zorg er dus voor dat u het voor de hand liggende niet vergeet, wat de logboekregistratie, bewaking en meting van uw tijdsinstellingen is.
Belangrijk
Zorg ervoor dat u de deadlines en tijdsinstellingen vooraf opgeeft en een niet-blokkerende bewakingsoplossing instelt voor controle.
Kortom, we gaan ermee akkoord dat realtime super snel betekent, in een oogwenk. Hoe snel precies wordt opgegeven door uw opgegeven scenario.
Door gebeurtenissen gestuurde toepassingen
Als u nadenkt over een klikgebeurtenis, denkt u aan iets anders. Gebeurtenisgestuurde toepassingen maken gebruik van het brand- en vergeetprincipe . De gebeurtenis wordt verzonden of geactiveerd naar het volgende systeem, dat een andere service, een Event Hub, een stream of een berichtenbroker zoals Kafka kan zijn. We wachten niet noodzakelijkerwijs op een reactie van de volgende in het systeem. Losse koppeling wordt bereikt voor de prijs van uiteindelijke consistentie, die op een ander niveau moet worden geregeld.
Om de aard van gebeurtenisgestuurde toepassingen te identificeren, kijken we naar de belangrijkste architectuurpatronen met behulp van het voorbeeld van een klant met de naam Alex, het kopen van een koffie en een cappuccino.
Gebeurtenismelding
Gebeurtenismelding is de melding van een specifieke gebeurtenis of gebeurtenis. Elke gebeurtenis wordt afzonderlijk gezien. Het voorbeeld van een klant met de naam Alex die een koffie en een cappuccino koopt, kan er als volgt uitzien:
1. Evenement: Alex koopt een koffie.
2. Evenement: Alex koopt een cappuccino.
Eén barista zou zorgvuldig moeten luisteren naar alle evenementen om Alex's hele bestelling te krijgen. Maar twee barista's kunnen de drankjes ook onafhankelijk bereiden en serveren.
Gebeurtenis overgedragen statusoverdracht
Bij overdracht van gebeurtenisstatus wordt alle benodigde informatie opgeslagen in één gebeurtenis. Dit is handig als een gebeurtenis verloren gaat of als uw service niet naar alle gebeurtenissen luistert. In ons voorbeeld zien de gebeurtenissen er als volgt uit:
1. Evenement: Alex koopt een koffie.
2. Evenement: Alex koopt, naast de koffie, een cappuccino.
Met één barista kan het luisteren naar het tweede evenement voldoende zijn. Met twee barista's zou de tweede naar de eerste moeten kijken. De bestelling kan samen worden geleverd, maar het proces kan langer duren dan volledig ontkoppeld.
Gebeurtenisbronnen
Met gebeurtenisbronnen treedt de gebeurtenisopslag in de focus. Zoals u ziet, zijn de gebeurtenissen hetzelfde als in het eerste voorbeeld. Maar de barista is belangrijk voor dit concept op het moment dat de barista een gebeurtenis ontvangt en vervolgens nadenkt over alle bijbehorende gebeurtenissen om de huidige status te krijgen voor alle orders van Alex.
Met de tweede bestelling weet de barista dat Alex's bestelling bestaat uit een koffie, door de eerste bestelling en een cappuccino te onthouden, omdat dit drankje net is besteld. Parallel werken met een tweede barista is niet zo gemakkelijk mogelijk.
Wanneer we een kassier toevoegen om de bestellingen te ontvangen en de drankjes te serveren, kunnen de barista's onafhankelijk werken om de drankjes voor te bereiden. Ze hoeven niets te weten over de klanten. De kassier is het zogenaamde gebeurtenisarchief, dat de gebeurtenissen in dat scenario persistent maakt. Gebeurtenisbronnen voegt een andere complexiteitslaag toe, maar voegt ook ontkoppeling toe.
1. Evenement: Alex koopt een koffie.
Kassier: (Eerste) bestelling (voor Alex): Koffie
2. Evenement: Alex koopt een cappuccino.
Kassier: (Tweede) bestelling (voor Alex): Cappuccino
Telemetriegegevens zijn realtimegebeurtenissen
Er zijn ook andere voorbeelden die we kunnen bedenken. Stel dat het scenario van het uitvoeren van een koelsysteem, bijvoorbeeld voor voedsel- of geneesmiddelenfabrikanten, wordt uitgevoerd. U hebt constante controle over de temperatuur en andere relevante gegevens in uw systeem nodig. Bewustzijn van de telemetriegegevens en het automatisch beheren ervan zou essentieel zijn voor uw succes. Het meten van de telemetrie om de twee seconden en deze vervolgens naar het besturingselementsysteem verzenden waar de gegevens worden geanalyseerd, verwerkt en verwerkt, is een gebeurtenisgestuurd systeem. Bovendien moeten de gegevens in realtime worden verwerkt, omdat het essentieel is om snel te reageren om tragische gevolgen voor het bedrijf te voorkomen.