Che cos'è l'architettura guidata dagli eventi? Modelli, esempi e usi

Le imprese si affidano a varie tecnologie e strumenti per gestire efficacemente il loro business.

Tuttavia, questi possono rapidamente diventare obsoleti, portando a un degrado delle prestazioni, a un aumento dei costi e dell'esposizione al rischio, e a minacce alla sicurezza. Non è difficile vedere come le architetture monolitiche e antiquate spesso rappresentino un collo di bottiglia per la modernizzazione del tuo business.

Un modo per migliorare l'agilità e la scalabilità della tua infrastruttura IT è adottare un architettura basata su eventi. In un'architettura basata su eventi, i sistemi sono costruiti attorno agli eventi, che sono messaggi che indicano che qualcosa è accaduto. Questo rende possibile costruire sistemi che reagiscono rapidamente ai cambiamenti nel loro ambiente, rendendoli più agili e adattabili.

La maggior parte dei sistemi basati su eventi utilizza software di coda di messaggi per comunicare tra sistemi disparati e abilitare la comunicazione in tempo reale su un unico livello.

Il modello di processo dell'architettura basata su eventi sostituisce il design convenzionale "richiesta/risposta" in cui i servizi dovevano attendere una risposta prima di procedere con l'attività successiva. Offre anche approfondimenti sui dati in tempo reale sul comportamento degli utenti, sui processi aziendali e sulle operazioni.

Gli eventi governano il flusso dell'architettura basata su eventi, che è progettata per reagire agli eventi o eseguire operazioni in risposta a un evento.

Cosa significa essere basati su eventi?

Gli eventi sono istanze di azioni. Si verificano quando accade qualcosa all'interno o all'esterno della tua azienda. Queste attività possono includere un acquisto da parte di un consumatore, un aggiornamento dell'inventario di un magazzino, un tentativo di violazione dei dati o un cambiamento di stato per un'applicazione.

Poiché molti eventi sono sensibili al tempo o critici per le operazioni aziendali, le aziende vogliono progettare le loro infrastrutture attorno alla raccolta e alla risposta a tali eventi. Si dice che l'azienda sia basata su eventi quando gli eventi causano una risposta da parte dell'azienda. Nell'era moderna, gli eventi sono elaborati da sistemi IT che raccolgono, analizzano e reagiscono agli eventi in base a una logica preimpostata.

Le architetture basate su eventi sono anche chiamate architetture asincrone collaborative perché si basano su messaggistica asincrona tra le diverse parti di un sistema con risposte in tempo reale. Ora, sistemi come le banche e la telemetria stanno passando al modello centrato sugli eventi, dove iniziano a raccogliere dati in transito e a reagire ad essi in base agli eventi.

Prendiamo un esempio bancario di architettura basata su eventi. Il pagamento avviene in una posizione specifica. In tal caso, l'architettura basata su eventi risponde a quella richiesta più rapidamente e accuratamente rispetto all'approccio tradizionale richiesta/risposta, che richiede di attendere una risposta prima di procedere ulteriormente con la transazione.

Questo aggiunge funzionalità ricche, come avvisi di frode e livelli di sicurezza che aiutano a proteggere i clienti dai ladri informatici.

Importanza dei sistemi basati su eventi

Alto throughput, scalabilità e agilità sono caratteristiche chiave dei leader digitali di oggi, molti dei quali hanno abbracciato microservizi e architettura basata su eventi.

Le infrastrutture IT monolitiche si basano su comunicazioni sincrone in cui due programmi interagiscono direttamente, più tipicamente tramite interfacce di programmazione delle applicazioni (API). D'altra parte, la comunicazione asincrona è basata su eventi, consentendo a diverse applicazioni di interagire contemporaneamente e rapidamente in tempo reale. L'EDA è spesso il metodo più efficace per abilitare l'interazione applicativa asincrona basata su eventi.

Le aziende che utilizzano l'architettura basata su eventi possono godere dei benefici di una comunicazione in tempo reale scalabile e robusta utilizzando code di messaggi. Molti progetti strategici possono beneficiare di questo, inclusi l'internet delle cose (IoT), l'e-commerce, l'integrazione dei dati tra sistemi e il rilevamento delle frodi finanziarie.

Architettura basata su eventi vs. architettura tradizionale

Le architetture basate su eventi e tradizionali differiscono fondamentalmente negli approcci di comunicazione e progettazione del sistema. L'EDA si basa su comunicazione asincrona, dove gli eventi innescano interazioni tra componenti debolmente accoppiati, consentendo una reattività in tempo reale e un'alta scalabilità. Questo la rende ideale per sistemi complessi e distribuiti come IoT, analisi in tempo reale e rilevamento delle frodi finanziarie.

Al contrario, l'architettura tradizionale segue un modello richiesta-risposta che coinvolge l'interazione diretta tra componenti strettamente accoppiati. Sebbene più facile da implementare per flussi di lavoro semplici come i sistemi transazionali, le architetture sincrone spesso faticano con la latenza e la scalabilità in ambienti distribuiti.

La scelta tra questi approcci dipende dai requisiti del sistema. L'EDA è preferita per sistemi dinamici, scalabili e resilienti, mentre le architetture tradizionali si adattano ad applicazioni con modelli di comunicazione più semplici e prevedibili.

Come funziona l'architettura basata su eventi?

Un modello di architettura basata su eventi aiuta a sviluppare e distribuire applicazioni e sistemi che trasferiscono eventi tra componenti e servizi di sistema debolmente accoppiati. Un'infrastruttura basata su eventi ha tre componenti principali:

1. Produttori di eventi, noti anche come emettitori di eventi e agenti
2. Consumatori di eventi o sink
3. Broker o canale

Un produttore di eventi monitora o rileva un evento e lo converte in un messaggio. Dopo aver rilevato un evento, il produttore invia il messaggio al consumatore tramite canali di eventi. Il produttore non conosce i consumatori dell'evento e non saprà mai l'esito dell'evento.

I consumatori di eventi sono responsabili di innescare una risposta quando si verifica un evento. Un consumatore di eventi può fornire o meno una risposta completa. Ad esempio, il consumatore potrebbe essere responsabile dello screening, dell'elaborazione e della trasmissione dell'evento al componente successivo (di solito piattaforme di streaming di eventi) o offrire una risposta autonoma a un evento.

La piattaforma di elaborazione degli eventi determina la risposta appropriata a un evento e trasmette l'attività a valle ai consumatori pertinenti, dove il risultato dell'evento è visibile.

L'architettura basata su eventi promuove il disaccoppiamento delle applicazioni attraverso un broker di eventi, simile a un broker di messaggi, che instrada gli eventi dai produttori ai consumatori. Questi broker possono essere implementati utilizzando middleware orientato ai messaggi, garantendo che app e dispositivi non abbiano bisogno di conoscere la fonte o la destinazione dei dati. Sebbene il disaccoppiamento ponga delle sfide, migliora significativamente la flessibilità e la scalabilità.

Nell'EDA, gli eventi vengono inviati senza aspettarsi una risposta a parte un riconoscimento dal broker di eventi. Questo disaccoppiamento garantisce che trasmettitori e ricevitori operino indipendentemente.

Connessioni dirette tra produttori e consumatori possono bypassare la necessità di un broker, come un produttore che interagisce direttamente con un database per memorizzare eventi per l'analisi. Tuttavia, nella maggior parte delle configurazioni, più emettitori di eventi generano vari eventi, con uno o più sink che li elaborano.

Modelli di architettura basata su eventi

Un modello di EDA specifica come i produttori di eventi, i consumatori e i broker interagiscono tra loro. Esistono due principali modelli di architettura basata su eventi: publisher/subscriber e streaming di eventi.

Architettura publisher/subscriber

Questa architettura basata su code di messaggi dipende dalle sottoscrizioni ai flussi di eventi per la comunicazione. Il router di eventi in un'architettura publisher/subscriber (il modello pub/sub) registra le sottoscrizioni dei clienti ai canali di eventi. Questo modello invia notifiche agli abbonati che devono essere avvisati quando si verifica o viene pubblicato un evento.

Poiché gli eventi non possono essere riprodotti, un consumatore che si iscrive dopo che un evento si è verificato non può accedervi in seguito. Da quel momento in poi, il consumatore riceve nuovi eventi. ActiveMQ e RabbitMQ sono due broker ben noti per il modello pub/sub.

Architettura di streaming di eventi

Lo streaming di eventi trascende il modello basato su sottoscrizioni. Questa tecnica memorizza gli eventi in un registro a cui tutti i consumatori possono accedere per scoprire eventi importanti. I consumatori possono leggere da qualsiasi area del flusso e riprodurre eventi precedenti.

Apache Kafka è una soluzione di elaborazione di flussi ben nota. Molte aziende scelgono Kafka perché è una soluzione consolidata e robusta. Come piattaforma di elaborazione di flussi industriale di riferimento, Kafka ha una vasta base di utenti, una comunità di supporto e un set di strumenti avanzato.

Altre piattaforme offrono una combinazione di elaborazione di flussi e pub/sub o la loro soluzione distintiva. Pulsar, un recente prodotto Apache, è una piattaforma di messaggistica pub/sub open-source e ricca di funzionalità che facilita sia i flussi che la messa in coda degli eventi, tutto con una velocità eccezionalmente alta.

NATS è un sistema di messaggistica pub/sub che utilizza la "messa in coda sintetica". NATS, o sistema di trasporto autonomico neurale, è costruito per fornire comunicazioni brevi e frequenti. Offre prestazioni eccellenti e latenza ridotta. Tuttavia, NATS considera accettabile una certa perdita di dati, ponendo le prestazioni davanti alle promesse di consegna.

Esempio di architettura basata su eventi

Di seguito è riportato un esempio di approccio basato su eventi per un sito di e-commerce. Questa architettura consente al sito web di rispondere agli aggiornamenti da diverse fonti durante l'alta domanda senza interrompere il sistema o sovrapprovisionare le risorse.

Considera come un rivenditore online possa utilizzare l'architettura basata su eventi come esempio. I clienti stanno per effettuare il checkout online e l'inserimento delle loro informazioni di pagamento su una piattaforma di e-commerce è un'azione frequente e cruciale. L'interfaccia utente (UI) genera l'evento "Pagamento Inviato" con le informazioni della carta di credito, e il router di eventi sa di indirizzare la notifica dell'evento al servizio di pagamento in base ai metadati dell'evento.

Dopo aver ricevuto la notifica, il servizio di pagamento elabora l'evento e crea un nuovo evento "Pagamento Elaborato" che indica il successo o il fallimento dell'operazione.

Il router di eventi restituisce le informazioni all'UI, mostrando lo stato del consumatore e chiedendo loro di intraprendere azioni predefinite. Ad esempio, se un pagamento fallisce, l'UI può riaprire il modulo per correggere i dettagli. Ma se il pagamento ha successo, l'UI fornisce le informazioni finali dell'ordine e la data di consegna stimata.

Né il sito front-end né i servizi back-end sono a conoscenza dell'esistenza dei loro equivalenti. Si iscrivono agli eventi "Pagamento Inviato" e "Pagamento Elaborato", che il router di eventi mantiene.

Casi d'uso dell'architettura basata su eventi

Le aziende si affidano all'EDA per creare sistemi che soddisfano una varietà di casi d'uso. I più popolari potrebbero includere:

• Monitoraggio in tempo reale: I sistemi possono creare eventi mentre i loro stati cambiano, consentendo alle aziende di cercare irregolarità e comportamenti sospetti.
• Replica dei dati: Un singolo evento può essere utilizzato da numerosi servizi che richiedono la replica dei dati nei loro database.
• Ridondanza: Se un servizio non è disponibile, gli eventi possono essere memorizzati nel router fino a quando il servizio non è pronto a consumare l'evento.
• Elaborazione parallela: Un singolo evento può avviare più processi ed eseguire in modo asincrono.
• Interoperabilità: Gli eventi possono essere memorizzati e distribuiti indipendentemente dal linguaggio in cui sono costruite le applicazioni.
• Microservizi: L'EDA è frequentemente integrata con i microservizi per trasferire dati tra processi disaccoppiati su larga scala in modo efficace.

Vantaggi di un'architettura basata su eventi

L'EDA semplifica lo sviluppo da parte delle aziende di un sistema flessibile che risponde ai cambiamenti e prende decisioni in tempo reale. Diamo un'occhiata ad alcuni modi in cui un'architettura basata su eventi si rende utile.

• Disaccoppiamento: I servizi non devono più essere a conoscenza dell'esistenza di altri sistemi per interagire. Devono essere a conoscenza degli eventi, ma il broker distribuisce gli eventi appropriati ai sistemi corretti. Questo produce microservizi molto disaccoppiati che sono facili da adattare, testare e distribuire.
• Immutabilità: Poiché gli eventi non possono essere modificati dopo essere stati generati, nessuno deve preoccuparsi che qualcun altro modifichi il loro contenuto in seguito.
• Riduzione delle spese: Le architetture basate su eventi sono basate su push, quindi tutto avviene non appena l'evento appare nel broker. Gli utenti non devono pagare per il polling continuo per verificare la presenza di un evento. Questo porta a un minore utilizzo della larghezza di banda di rete, a un minore consumo di CPU e a meno SSL/TLS handshake.
• Tolleranza ai guasti: Se un consumatore cessa improvvisamente di funzionare o non riesce a elaborare un evento, il broker di eventi non lo considera elaborato con successo. L'evento non viene perso; piuttosto, viene ri-consumato da un'altra istanza del consumatore o elaborato di nuovo quando il consumatore è disponibile.
• Tempo reale: Un design basato su eventi fornisce una visibilità in tempo reale senza pari su tutto ciò che accade nel sistema. La capacità di consumare questa conoscenza, derivare intuizioni mentre accadono e automatizzare il processo decisionale è semplice come aggiungere consumatori agli eventi attuali. Aggiungere funzionalità in tempo reale ad architetture alternative è fattibile ma richiede ulteriore sforzo, nuovi strumenti e modifiche ai componenti esistenti.
• Scalabilità: Un singolo evento può essere sfruttato per attivare numerose azioni per vari consumatori, consentendo l'esecuzione parallela dei lavori e migliori prestazioni. Non è necessario modificare la logica per ogni servizio o sistema, quindi puoi facilmente adattare lo stack tecnologico per soddisfare nuovi requisiti o esigenze.
• Recupero: Quando utilizzi un broker di eventi che fornisce flussi di eventi continui e resilienti, puoi "riprodurre" eventi passati per ripristinare il lavoro mancante o ricostruire la configurazione del sistema.

Le sfide di un'architettura basata su eventi

Ora che abbiamo coperto tutti i vantaggi dell'infrastruttura basata su eventi, esaminiamo le sue limitazioni. Alcuni di questi compromessi esistono in approcci di design alternativi, come lo sviluppo di microservizi REST, ma sono accentuati in un design basato su eventi.

• Complessità: Il disaccoppiamento elimina la necessità di tracciare le dipendenze e altri ostacoli a un modello di microservizi. L'onere dei servizi indipendenti è che diventa più difficile comprendere il progresso degli eventi attraverso molte applicazioni, rispetto alla dipendenza diretta, dove le relazioni sono più chiare.
• Flussi sincroni: Poiché gli eventi sono asincroni, questo paradigma fatica a supportare attività sincrone quando il risultato delle azioni dovrebbe essere inviato all'interno dello stesso ambito di richiesta-risposta.
• Design degli eventi: Progettare eventi è difficile. Poiché ogni consumatore può iscriversi all'evento, deve essere riutilizzabile, il che sacrifica la personalizzazione. Allo stesso tempo, il design non può essere così generale da rendere oscuro lo scopo.
• Evoluzione degli eventi: Man mano che i sistemi si sviluppano nel tempo, gli eventi devono tenere il passo per adattarsi alle caratteristiche in evoluzione del sistema. Aggiornare gli eventi senza influenzare altri microservizi può essere complicato, in particolare in uno scenario distribuito in cui i team non sono in contatto con le persone che elaborano gli eventi che creano.

Scala la tua infrastruttura per il successo

Le architetture basate su eventi impilano i servizi su un unico livello di transazione. Questo approccio consente alle imprese di rilevare problemi, rispondere rapidamente alle risoluzioni e supportare processi aziendali dinamici più velocemente.

Dati, dati ovunque. Ottieni software di elaborazione dei flussi di eventi per aiutarti a comprendere ed elaborare i dati aziendali in transito.

L'articolo è stato originariamente pubblicato nel 2022. È stato aggiornato con nuove informazioni.