L'architettura basata sugli eventi è un modello di integrazione costruito intorno alla pubblicazione, acquisizione e storage (o persistenza) di eventi. In particolare, quando un'applicazione o un servizio esegue un'azione o subisce una modifica di cui un'altra applicazione o servizio potrebbe voler essere a conoscenza, pubblica un evento - un record di tale azione o modifica - che un'altra applicazione o servizio può utilizzare ed elaborare per eseguire a sua volta una o più azioni.

L'architettura basata sugli eventi consente un legame debole tra applicazioni e servizi connessi - possono comunicare tra loro pubblicando e consumando eventi senza conoscere nulla l'uno dell'altro tranne il formato dell'evento. Questo modello offre vantaggi significativi rispetto a un'architettura di richiesta/risposta (o modello di integrazione), in cui un'applicazione o un servizio deve richiedere informazioni specifiche da un'altra applicazione o un altro servizio specifici che attendono la richiesta specifica.

L'architettura basata sugli eventi massimizza il potenziale delle applicazioni native del cloud e consente potenti tecnologie applicative, come l'analytics in tempo reale e il supporto decisionale.

In un'architettura basata sugli eventi, le applicazioni agiscono come produttori di eventi o consumatori di eventi (e spesso come entrambi).

Un produttore di eventi trasmette un evento - sotto forma di messaggio - a un broker o a qualche altra forma di router di eventi, dove viene mantenuto l'ordine cronologico dell'evento rispetto ad altri eventi. Un consumatore di eventi acquisisce il messaggio - in tempo reale (mentre si verifica) o in qualsiasi altro momento desidera - ed elabora il messaggio per attivare un'altra azione, un altro flusso di lavoro o un altro evento a sé stanti.

In un semplice esempio, un servizio bancario può trasmettere un evento di "deposito", che un altro servizio della banca consuma e a cui risponde scrivendo un deposito sull'estratto conto del cliente. Ma le integrazioni basate sugli eventi possono anche attivare risposte in tempo reale basate su analisi complesse di enormi volumi di dati, ad esempio quando l'"evento" di un cliente che fa clic su un prodotto su un sito di e-commerce genera consigli istantanei sui prodotti basati sugli acquisti di altri clienti.

Esistono due modelli di base per la trasmissione di eventi in un'architettura basata sugli eventi

Messaggistica di eventi o pubblicazione/sottoscrizione

Nel modello di messaggistica degli eventi o di pubblicazione/sottoscrizione, i consumatori di eventi si iscrivono a una o più classi di messaggi pubblicati dai produttori di eventi. Quando un produttore di eventi pubblica un evento, il messaggio viene inviato direttamente a tutti i sottoscrittori che desiderano consumarlo.

In genere, un broker di messaggi gestisce la trasmissione di messaggi di evento tra autori e sottoscrittori. Il broker riceve ogni messaggio di evento, lo converte se necessario, ne mantiene l'ordine rispetto agli altri messaggi, lo rende disponibile ai sottoscrittori per il consumo, quindi lo elimina una volta consumato (in modo che non possa essere nuovamente consumato).

Streaming di eventi

Nel modello di streaming di eventi, i produttori di eventi pubblicano flussi di eventi su un broker. I consumatori di eventi sottoscrivono i flussi, ma invece di ricevere e consumare ogni evento non appena viene pubblicato, possono entrare in ogni flusso in qualsiasi momento e consumare solo gli eventi che desiderano consumare. La differenza fondamentale qui è che gli eventi vengono conservati dal broker anche dopo che i consumatori li hanno ricevuti.

Una piattaforma di streaming di dati, come Apache Kafka, gestisce la registrazione e la trasmissione di enormi volumi di eventi ad una velocità molto elevata (letteralmente bilioni di record di eventi al giorno, in tempo reale, senza ritardi nelle prestazioni). Una piattaforma di streaming offre alcune caratteristiche di cui un broker di messaggi non dispone:

• Persistenza degli eventi: poiché i consumatori possono consumare gli eventi in qualsiasi momento dopo la loro pubblicazione, i record di streaming degli eventi sono persistenti - vengono mantenuti per un periodo di tempo configurabile, da frazioni di secondo a un tempo infinito. Ciò consente alle applicazioni del flusso di eventi di elaborare dati cronologici e dati in tempo reale.
  
  
• Elaborazione di eventi complessi: come la messaggistica di eventi, il flusso di eventi può essere utilizzato per l'elaborazione di eventi semplici, in cui ogni evento pubblicato attiva la trasmissione e l'elaborazione da parte di uno o più consumatori specifici. Tuttavia, può essere utilizzato anche per l'elaborazione di eventi complessi, in cui i consumatori di eventi elaborano intere serie di eventi ed eseguono azioni in base al risultato.

Rispetto all'architettura dell'applicazione di richiesta/risposta, l'architettura basata sugli eventi offre numerosi vantaggi e opportunità per sviluppatori e organizzazioni.

Potente risposta e analisi in tempo reale: lo streaming di eventi consente applicazioni che rispondono alle mutevoli situazioni aziendali nel momento in cui si verificano e fanno previsioni e prendono decisioni basate su tutti i dati attuali e cronologici disponibili in tempo reale. Ciò offre vantaggi in numerose aree - dall'elaborazione di flussi di dati generati da una miriade di dispositivi IoT, alla previsione e all'eliminazione immediata delle minacce alla sicurezza e all'automazione delle supply chain per un'efficienza ottimale.

Tolleranza degli errori, scalabilità, manutenzione semplificata, versatilità e altri vantaggi del legame debole: le applicazioni e i componenti in un articolo basato su eventi non dipendono dalla reciproca disponibilità; possono essere aggiornati, testati e implementati in modo indipendente senza interruzione del servizio e, quando un componente non funziona, è possibile portare online un backup. La persistenza degli eventi consente la "riproduzione" di eventi passati, che può aiutare a recuperare dati o funzionalità in caso di un'interruzione a carico del consumatore di eventi. I componenti possono essere scalati facilmente e indipendentemente l'uno dall'altro attraverso la rete e gli sviluppatori possono rivedere o arricchire applicazioni e sistemi aggiungendo e rimuovendo produttori e consumatori di eventi.

Messaggistica asincrona: l'architettura basata sugli eventi consente ai componenti di comunicare in modo asincrono - i produttori pubblicano messaggi di eventi, secondo la propria pianificazione, senza attendere che i consumatori li ricevano (o addirittura senza sapere se i consumatori li hanno ricevuti). Oltre a semplificare l'integrazione, ciò migliora l'esperienza dell'applicazione per gli utenti. Un utente che completa un'attività in un componente può passare all'attività successiva senza attendere, indipendentemente da eventuali integrazioni downstream tra quel componente e gli altri nel sistema.

Nei microservizi - un'architettura applicativa nativa del cloud fondamentale - le applicazioni sono assemblate da servizi con un legame debole, distribuibili in modo indipendente. I principali vantaggi dei microservizi sono essenzialmente i vantaggi del legame debole - facilità di manutenzione, flessibilità di implementazione, scalabilità indipendente e tolleranza ai guasti.

Non sorprende che l'architettura basata sugli eventi sia ampiamente considerata una best practice per le implementazioni di microservizi. I microservizi possono comunicare tra loro utilizzando le API REST. Ma REST, un modello di integrazione richiesta/risposta, mina molti dei vantaggi dell'architettura di microservizi a legame debole forzando un'integrazione sincrona e strettamente accoppiata tra i  microservizi.