Home
topics
Architettura basata sugli eventi
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:
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.
Una soluzione software di integrazione basata sull'AI, IBM® Cloud Pak for Integration offre una serie completa di strumenti di integrazione all'interno di un'unica esperienza unificata per connettere applicazioni e dati in qualsiasi ambiente cloud oppure on-premise.
IBM Cloud Pak for Data è una piattaforma di dati aperta ed estensibile che fornisce una struttura per rendere tutti i dati disponibili per AI e analytics, su qualsiasi cloud.
Le API REST forniscono un modo flessibile e leggero per integrare le applicazioni e sono emerse come il metodo più comune per connettere i componenti nelle architetture di microservizi.
In un'architettura di microservizi, ogni applicazione è composta da diversi servizi più piccoli, con un legame debole e implementabili in modo indipendente.
Un broker di messaggi è un software che consente ad applicazioni, sistemi e servizi di comunicare tra loro e scambiare informazioni.