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, denominati eventi. Gli eventi possono essere associati a uno stato (ad esempio il prezzo di un articolo o a un indirizzo di consegna) oppure possono essere identificatori (una notifica che indica che un ordine è stato ricevuto o spedito, ad esempio). Gli eventi attivano i microservizi che lavorano insieme per raggiungere un obiettivo comune, ma non hanno bisogno di sapere nulla l'uno dell'altro tranne il formato dell'evento. Anche se operano insieme, ogni microservizio può applicare una logica di business diversa ed emettere propri eventi di output.

Un evento ha le seguenti caratteristiche:

  • È un resoconto di quanto 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 per un tempo indeterminato, su larga scala e consumato per il tempo necessario.

In un sistema basato su eventi, gli eventi vengono generati dai produttori di eventi, importati e filtrati da un router eventi (o broker), quindi vengono aggiunti in blocco ai consumatori di eventi appropriati (o sink). Gli eventi vengono inoltrati agli abbonati definiti da uno o più trigger corrispondenti. I tre componenti (produttori di eventi, router di eventi, consumer di eventi) sono disaccoppiati e possono essere implementati, aggiornati e scalati in modo indipendente:

Intermediari per eventi e abbonati

Il router degli eventi collega i diversi servizi ed è il mezzo tramite il quale i messaggi vengono inviati e ricevuti. Esegue una risposta all'evento originale generato da un producer di eventi e la invia a valle dei consumatori appropriati. Gli eventi vengono gestiti in modo asincrono e i loro risultati vengono decisi quando un servizio reagisce a un evento o viene interessato da quest'ultimo, come nel di seguito che illustra 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 del sistema.

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

Vantaggi delle architetture basate sugli eventi

Di seguito sono riportati alcuni dei vantaggi offerti dalla creazione di un'architettura basata su eventi.

accoppiamento lento e maggiore agilità dello sviluppatore

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

Il basso accoppiamento riduce le dipendenze e consente di implementare servizi in diversi linguaggi e framework. Puoi aggiungere o rimuovere i producer e i destinatari di eventi senza dover modificare la logica in alcun servizio. Non è necessario scrivere codice personalizzato per effettuare sondaggi, filtrare e creare eventi.

Eventi e resilienza asincroni

In un sistema basato su eventi, gli eventi vengono generati in modo asincrono e possono essere emessi mentre si verificano senza attendere una risposta. I componenti a basso accoppiamento significano che se un servizio non va a buon fine, gli altri rimangono invariati. Se necessario, puoi registrare gli eventi in modo che il servizio di destinazione possa riprendere dal punto di errore o riprodurre gli eventi passati.

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

I sistemi basati su eventi consentono un facile messaggistica basato su push e i client possono ricevere gli aggiornamenti senza dover eseguire il polling continuo dei servizi remoti per modifiche dello stato. Questi messaggi push possono essere utilizzati per l'elaborazione e la trasformazione immediata di dati e per l'analisi in tempo reale. Inoltre, con un minor numero di sondaggi, si riduce l'I/O di rete e si riducono i costi.

Controlli semplificati e approvvigionamento 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 hanno accesso ai tuoi dati. Puoi anche criptare i tuoi dati sia in transito che at-rest.

Inoltre, puoi utilizzare l'approvvigionamento 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 eventi fornisce un log di eventi immutabili che possono essere conservati per scopi di controllo, per ricreare gli stati storici o come narrazione canonica per spiegare una decisione basata su un'attività.

Considerazioni architettoniche

Un'architettura basata su eventi potrebbe richiedere un approccio alla progettazione della tua applicazione in un nuovo modo. Sebbene sia adatto per applicazioni che utilizzano microservizi o componenti disaccoppiati, considera anche i seguenti elementi:

  • La tua origine evento può garantire la pubblicazione se hai bisogno di elaborare ogni singolo evento?

    Deve essere un'origine evento duratura e affidabile.

  • La tua applicazione è in grado di gestire più richieste asincrone?

    Le prestazioni del sistema non devono basarsi sull'ambito globale o sui database anelastici.

  • In che modo vuoi monitorare il flusso degli eventi?

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

  • Vuoi utilizzare i dati nell'origine evento per ricostruire lo stato?

    Dovresti valutare come assicurarti che i tuoi dati vengano deduplicati e ordinati.

Passaggi successivi