Architetture basate su eventi

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Un'architettura basata su eventi è un pattern di progettazione software in cui i microservizi reagiscono ai cambiamenti di stato, chiamati eventi. Gli eventi possono avere uno stato, ad esempio il prezzo di un articolo o un indirizzo di consegna, oppure gli eventi possono essere identificatori (una notifica che indica che l'ordine è stato ricevuto o spedito, ad esempio). Gli eventi attivano microservizi che lavorano in sinergia per raggiungere un obiettivo comune, ma non hanno bisogno di informazioni reciproche, ad eccezione del formato evento. Anche se operano in sinergia, ogni microservizio può applicare una logica di business diversa ed emettere propri eventi di output.

Un evento ha le seguenti caratteristiche:

  • Si tratta di un resoconto di ciò che è accaduto.
  • Acquisisce un fatto immutabile che non può essere modificato o eliminato.
  • Si verifica se un servizio applica o meno una logica al momento del suo utilizzo.
  • Può essere mantenuto a tempo indeterminato su vasta scala e consumato tutte le volte necessarie.

In un sistema basato su eventi, gli eventi vengono generati dai produttori di eventi, importati e filtrati da un router eventi (o intermediario), quindi trasferiti in vento ai consumatori (o sink) appropriati. Gli eventi vengono inoltrati agli iscritti definiti da uno o più attivatori corrispondenti. Questi tre componenti (produttore di eventi, router di eventi, consumer di eventi) sono disaccoppiati e possono essere implementati, aggiornati e scalati in modo indipendente:

Intermediari di eventi e iscritti

Il router degli eventi collega i diversi servizi ed è il mezzo attraverso il quale vengono inviati e ricevuti i messaggi. Esegue una risposta all'evento originale generato da un produttore di eventi e la invia a valle ai consumatori appropriati. Gli eventi vengono gestiti in modo asincrono e i relativi risultati vengono decisi quando un servizio reagisce a un evento o ne è interessato, come nel seguente diagramma di un flusso di eventi molto semplificato:

Architettura basata sugli eventi

Quando utilizzare architetture basate sugli eventi

Prendi in considerazione i seguenti utilizzi durante la progettazione dell'impianto.

  • Per monitorare e ricevere avvisi per rilevare eventuali anomalie o modifiche a bucket di archiviazione, tabelle di database, macchine virtuali o altre risorse.
  • Per aggiungere un solo evento a più consumatori. Il router dell'evento invia l'evento a tutti i consumatori appropriati, senza che tu debba scrivere codice personalizzato. Ogni servizio può quindi elaborare l'evento in parallelo, ma in modo diverso.
  • Fornire interoperabilità tra diversi stack tecnologici mantenendo l'indipendenza di ogni stack.
  • Coordinare sistemi e team che operano in diverse aree geografiche e account. Puoi riorganizzare facilmente la proprietà dei microservizi. Ci sono meno dipendenze tra i team e puoi reagire più rapidamente ai cambiamenti che altrimenti sarebbero ostacolati dalle barriere di accesso ai dati.

Vantaggi delle architetture basate sugli eventi

Ecco alcuni vantaggi della creazione di un'architettura basata sugli eventi.

Basso accoppiamento e migliore agilità dello sviluppatore

I produttori di eventi sono logicamente separati dai consumatori di eventi. Il disaccoppiamento tra la produzione e il consumo di eventi implica che i servizi sono interoperabili, ma che possono essere scalati, aggiornati e di cui è stato eseguito il deployment in modo indipendente l'uno dall'altro.

Il basso accoppiamento riduce le dipendenze e consente di implementare i servizi in linguaggi e framework diversi. Puoi aggiungere o rimuovere produttori e ricevitori di eventi senza dover modificare la logica in alcun servizio. Non è necessario scrivere codice personalizzato per condurre eventi di sondaggio, filtri e route.

Resistenza agli eventi asincroni

In un sistema basato su eventi, gli eventi vengono generati in modo asincrono e possono essere emessi nel momento in cui accadono senza attendere una risposta. Componenti a basso accoppiamento significa che se un servizio ha esito negativo, gli altri non saranno interessati. Se necessario, puoi registrare gli eventi in modo che il servizio di ricezione possa riprendere dal punto di errore o riprodurre gli eventi passati.

Messaggistica push, flussi di eventi in tempo reale e costi inferiori

I sistemi basati su eventi facilitano la messaggistica push e i client possono ricevere gli aggiornamenti senza dover consultare continuamente i servizi remoti in caso di modifiche dello stato. Questi messaggi push possono essere utilizzati per l'elaborazione e la trasformazione di dati in tempo reale e l'analisi in tempo reale. Inoltre, con meno sondaggi, la rete I/O si riduce e i costi si riducono.

Controllo semplificato e approvvigionamento di eventi

La posizione centralizzata del router degli eventi semplifica il controllo e ti consente di controllare chi può interagire con un router e quali utenti e risorse possono accedere ai tuoi dati. Puoi anche criptare i tuoi dati sia in transito che a riposo.

Inoltre, puoi utilizzare l'approvvigionamento di eventi, un pattern architetturale che registra tutte le modifiche apportate allo stato di un'applicazione, nella stessa sequenza in cui sono state applicate in origine. L'approvvigionamento di eventi fornisce un log di eventi immutabili che possono essere conservati per scopi di controllo, per ricreare gli stati storici o come narrativa canonica per spiegare una decisione di business.

Considerazioni architettoniche

Un'architettura basata su eventi potrebbe richiedere di affrontare il progetto della tua applicazione in un nuovo modo. Sebbene sia adatto alle applicazioni che utilizzano microservizi o componenti disaccoppiati, considera anche i seguenti aspetti:

  • La tua origine evento può garantire la pubblicazione se devi elaborare ogni singolo evento?

    Deve essere un'origine evento durevole e affidabile.

  • La tua applicazione può gestire più richieste asincrone?

    Le prestazioni del sistema non devono basarsi su un ambito globale o database anelastici.

  • In che modo vuoi monitorare il flusso dell'evento?

    Un'architettura basata su eventi supporta il monitoraggio dinamico con servizi di monitoraggio, ma non quello statico con l'analisi del codice.

  • Vuoi utilizzare i dati dell'origine evento per ricreare lo stato?

    Ti consigliamo di verificare come vengono deduplicati e ordinati i dati.

Passaggi successivi