Che cosa significa "guidato dagli eventi" e qual è la velocità del "tempo reale"?
Se ci pensiamo, possiamo identificare molti scenari guidati dagli eventi. Molti di essi richiedono una reazione in tempo reale.
Che cosa significa "in tempo reale"?
Una reazione in tempo reale può essere considerata una risposta immediata. Si prenda ad esempio il cassiere di un bar che chiede cosa si vuole bere.
Il cassiere si aspetta una risposta immediata o almeno una risposta data in tempi molto brevi. In caso contrario, il cassiere potrebbe riformulare la domanda o pensare che il cliente è scortese. Una risposta rapida è necessaria e anche appropriata. Il tempo della risposta può variare leggermente, ma si considera comunque "tempo reale". Quindi, la risposta a un saluto deve essere immediata, ma è accettabile che si pensi un attimo a cosa ordinare prima di rispondere alla domanda del cassiere.
Se si trasferisce questo scenario nei sistemi software, tutto ciò che conta sono i tempi: tempo di risposta, tempo di completamento, tempo di accesso, tempi di avvio e così via. L'utente o l'applicazione che esegue accesso definisce tali intervalli.
Nota
In tempo reale, le attività di sistema svolgono la loro funzione entro le scadenze previste.
È necessario sapere sempre cosa sta succedendo nel sistema. Quindi, assicurarsi di non dimenticare ciò che è ovvio, ovvero la registrazione, il monitoraggio e la misurazione dei tempi.
Importante
Assicurarsi di specificare prima le scadenze e i tempi e di configurare una soluzione di monitoraggio non bloccante per il controllo.
In sintesi, in tempo reale significa molto velocemente, in un istante. La velocità esatta è definita dallo scenario specifico.
Applicazioni basate su eventi
Se si pensa a un evento di clic, si pensa a qualcosa di diverso. Le applicazioni guidate dagli eventi usano il principio fire and forget. L'evento viene inviato o attivato verso il sistema successivo, che può essere un altro servizio, un hub eventi, un flusso o un broker di messaggi come Kafka. Non è necessario attendere una risposta dall'elemento successivo nel sistema. L'accoppiamento libero si ottiene a scapito della coerenza finale, di cui è necessario occuparsi a un altro livello.
Per identificare la natura delle applicazioni guidate dagli eventi, verranno esaminati i principali modelli di architettura usando l'esempio di un cliente, di nome Alex, che acquista un caffè e un cappuccino.
Notifica degli eventi
La notifica degli eventi è la notifica di un evento o avvenimento specifico. Ogni evento viene visualizzato separatamente. L'esempio del cliente di nome Alex che acquista un caffè e un cappuccino potrebbe essere simile al seguente:
1. Evento: Alex acquista un caffè.
2. Evento: Alex acquista un cappuccino.
Un barista dovrebbe ascoltare con attenzione tutti gli eventi per prendere l'intero ordine di Alex. Ma due baristi possono preparare e servire le bevande indipendentemente l'uno dall'altro.
Trasferimento dello stato guidato dall'evento
Con il trasferimento dello stato guidato dall'evento, tutte le informazioni necessarie vengono archiviate in un singolo evento. Questo può risultare utile se un evento si perde o se il servizio non è in ascolto di tutti gli eventi. Per questo esempio, gli eventi avranno un aspetto simile al seguente:
1. Evento: Alex acquista un caffè.
2. Evento: Alex acquista, oltre al caffè, un cappuccino.
Con un solo barista, l'ascolto solo del secondo evento potrebbe essere sufficiente. Con due baristi, il secondo dovrebbe osservare il primo. L'ordine potrebbe essere servito da entrambi, ma il processo potrebbe richiedere più tempo rispetto agli eventi completamente disaccoppiati.
Origine degli eventi
Con l'origine degli eventi, l'archiviazione degli eventi passa in primo piano. Come si può notare, gli eventi sono gli stessi del primo esempio. Tuttavia, il barista è importante per questo concetto nel momento in cui il barista riceve un evento e pensa a tutti gli eventi corrispondenti per ottenere lo stato corrente per tutti gli ordini fatti da Alex.
Con il secondo ordine, il barista sa che l'ordine di Alex è costituito da un caffè, ricordando il primo ordine, e da un cappuccino, perché questa bevanda è appena stata ordinata. Lavorare in parallelo con un secondo barista non è propriamente facile.
Quando si aggiunge 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 dei clienti. Il cassiere è il cosiddetto archivio eventi, se gli eventi sono persistenti, in quello scenario. L'origine degli eventi aggiunge un altro livello di complessità, ma aggiunge anche il disaccoppiamento.
1. Evento: Alex acquista un caffè.
Cassiere: (primo) ordine (per Alex): caffè
2. Evento: Alex acquista un cappuccino.
Cassiere: (secondo) ordine (per Alex): cappuccino
I dati di telemetria sono eventi in tempo reale
Esistono anche altri esempi che è possibile considerare. Si immagini lo scenario di gestione di un sistema di refrigerazione, ad esempio, per produttori di generi alimentari o farmaci. È necessario un controllo costante della temperatura e di altri dati rilevanti nel sistema. La conoscenza dei dati di telemetria e il controllo automatico degli stessi è essenziale per una buona gestione. Misurare i dati di telemetria ogni due secondi e quindi inviarli verso il sistema di controllo in cui i dati vengono analizzati, elaborati e gestiti rappresenta un sistema guidato dagli eventi. Inoltre, i dati devono essere elaborati in tempo reale perché è fondamentale rispondere rapidamente per evitare conseguenze tragiche per l'azienda.