Che cosa significa "guidato dagli eventi" e qual è la velocità del "tempo reale"?
Se si pensa a questo scenario, è possibile identificare molti scenari basati su eventi. Un sacco di loro richiedono una reazione in tempo reale.
Cosa significa in tempo reale?
Una reazione in tempo reale può essere considerata una risposta immediata. Prendiamo un esempio di cassiere in un bar che ti chiede cosa vuoi bere.
Il cassiere si aspetta una risposta immediata, o almeno una risposta che viene data molto presto. In caso contrario, il cassiere potrebbe riformulare la domanda o sospettare che tu fossi scortese. Viene richiesta una risposta rapida e anche appropriata. Il tempo di risposta può variare leggermente, ma è ancora visto come "in tempo reale". Quindi, tornare un saluto dovrebbe accadere rapidamente, ma è bene pensare brevemente al tuo ordine di rispondere alla domanda del cassiere.
Se lo scenario viene convertito in sistemi software, è importante tenere conto delle tempistiche: Tempo di risposta, Ora di completamento, Ora di accesso, Ora di avvio e così via. L'utente o l'applicazione di accesso definisce tali intervalli.
Annotazioni
In tempo reale, le attività dei sistemi eseguono la loro funzione entro le scadenze previste.
Dovresti essere sempre a conoscenza di ciò che sta accadendo nel tuo sistema. Assicurarsi quindi di non dimenticare l'ovvio, ovvero la registrazione, il monitoraggio e la misurazione dei tempi.
Importante
Assicurarsi di specificare in anticipo le scadenze e i tempi e configurare una soluzione di monitoraggio non bloccante per la verifica.
In sintesi, siamo d'accordo che in tempo reale significa super veloce, in un istante. La velocità esatta specificata dallo scenario specificato.
Applicazioni guidate dagli eventi
Se si pensa a un evento click, si pensa a qualcos'altro. Le applicazioni guidate dagli eventi usano il principio fire e forget . L'evento viene inviato o generato verso il sistema successivo, che può essere un altro servizio, un hub eventi, un flusso o un broker di messaggi come Kafka. Non aspettiamo necessariamente una risposta dalla successiva nel sistema. L'accoppiamento libero si ottiene per il prezzo della coerenza finale, che deve essere curato a un altro livello.
Per identificare la natura delle applicazioni guidate dagli eventi, esaminiamo i modelli di architettura principali usando l'esempio di un cliente, denominato Alex, acquistando un caffè e un cappuccino.
Notifica degli eventi
La notifica degli eventi è la notifica di un evento o di un evento specifico. Ogni evento viene visualizzato separatamente. L'esempio di un cliente di nome Alex che acquista un caffè e un cappuccino potrebbe essere simile al seguente:
1. Evento: Alex compra un caffè.
2. Evento: Alex compra un cappuccino.
Un barista avrebbe dovuto ascoltare attentamente tutti gli eventi per ottenere l'intero ordine di Alex. Ma due baristi potrebbero anche preparare e servire le bevande in modo indipendente.
Trasferimento dello stato trasportato dall'evento
Con il trasferimento dello stato dell'evento, tutte le informazioni necessarie vengono archiviate in un singolo evento. Ciò risulta utile se un evento viene perso o il servizio non è in ascolto di tutti gli eventi. Per questo esempio, gli eventi hanno un aspetto simile al seguente:
1. Evento: Alex compra un caffè.
2. Evento: Alex acquista, oltre al caffè, un cappuccino.
Con un barista, l'ascolto del secondo evento potrebbe essere sufficiente. Con due baristi, il secondo avrebbe dovuto guardare il primo. L'ordine potrebbe essere servito insieme, ma il processo potrebbe richiedere più tempo rispetto all'esecuzione del processo completamente disaccoppiato.
Origine degli eventi
Con l'origine degli eventi, l'archiviazione degli eventi entra in stato attivo. Come si può notare, gli eventi sono uguali a quello del primo esempio. Ma il barista è importante per questo concetto al momento in cui il barista riceve un evento e poi pensa a tutti gli eventi corrispondenti per ottenere lo stato corrente per tutti gli ordini effettuati da Alex.
Con il secondo ordine, il barista sa che l'ordine di Alex è costituito da un caffè, ricordando il primo ordine, e un cappuccino, perché questa bevanda è stata appena ordinata. Lavorare in parallelo con un secondo barista non è il più facile possibile.
Quando aggiungiamo un cassiere per ricevere gli ordini e servire le bevande, i baristi possono lavorare in modo indipendente per preparare le bevande. Non hanno bisogno di sapere nulla sui clienti. Il cassiere è il cosiddetto archivio eventi, che rende persistenti gli eventi, in tale scenario. L'origine eventi aggiunge un altro livello di complessità, ma aggiunge anche il disaccoppiamento.
1. Evento: Alex compra un caffè.
Cassiere: (Primo) ordine (per Alex): Caffè
2. Evento: Alex compra un cappuccino.
Cassiere: (secondo) ordine (per Alex): Cappuccino
I dati di telemetria sono eventi in tempo reale
Ci sono anche altri esempi di cui possiamo pensare. Si immagini lo scenario di esecuzione di un sistema di raffreddamento, ad esempio, per produttori di alimenti o farmaci. È necessario un controllo costante della temperatura e di altri dati rilevanti nel sistema. La consapevolezza dei dati di telemetria e il controllo di questi dati sono fondamentali per il successo. Misurare i dati di telemetria ogni due secondi e quindi inviarli al sistema di controllo in cui i dati vengono analizzati, elaborati e gestiti è un sistema basato su eventi. Inoltre, i dati devono essere elaborati in tempo reale perché è fondamentale reagire rapidamente per evitare conseguenze tragiche per l'azienda.