Un'architettura basata su eventi è un pattern di progettazione software in cui i microservizi reagiscono alle modifiche dello stato, chiamate eventi. Gli eventi possono indicare uno stato (ad esempio il prezzo di un articolo o un indirizzo di consegna) o essere identificatori (ad esempio una notifica che indica che un ordine è stato ricevuto o spedito). Gli eventi attivano microservizi che lavorano insieme per raggiungere un obiettivo comune, ma non devono sapere nulla l'uno dell'altro, tranne il formato dell'evento. Sebbene funzionino insieme, ogni microservizio può applicare una logica di business diversa ed emettere i propri eventi di output.
Un evento presenta le seguenti caratteristiche:
- È un record di qualcosa che è successo.
- Cattura un fatto immutabile che non può essere modificato o eliminato.
- Si verifica indipendentemente dal fatto che un servizio applichi o meno una logica al momento del consumo.
- Possono essere mantenuti indefinitamente, su larga scala e utilizzati tutte le volte che è necessario.
In un sistema basato su eventi, gli eventi vengono generati dai produttori di eventi, importati e filtrati da un router di eventi (o broker) e poi distribuiti ai consumatori di eventi (o sink) appropriati. Gli eventi vengono inoltrati ai consumatori in base alle iscrizioni definite da uno o più registrazioni corrispondenti (se utilizzi Eventarc Advanced) o da uno o più attivatori corrispondenti (se utilizzi Eventarc Standard). Questi tre componenti (produttori di eventi, router di eventi e consumatori di eventi) sono disaccoppiati e possono essere dispiacchiati, aggiornati e scalati in modo indipendente:
Il router di 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 invia questa risposta a valle ai consumatori appropriati. Gli eventi vengono gestiti in modo asincrono e i relativi risultati vengono stabiliti quando un servizio reagisce a un evento o ne è interessato, come nel seguente diagramma di un flusso di eventi molto semplificato:
Quando utilizzare le architetture basate su eventi
Quando progetti il sistema, tieni presenti i seguenti utilizzi.
- Per monitorare e ricevere avvisi in caso di anomalie o modifiche a bucket di archiviazione, tabelle di database, macchine virtuali o altre risorse.
- Per suddividere un singolo evento in più consumatori. Il router degli eventi spingerà 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 l'interoperabilità tra diversi stack tecnologici mantenendo al contempo l'indipendenza di ciascun stack.
- Per coordinare sistemi e team che operano e vengono implementati in regioni e account diversi. Puoi riorganizzare la proprietà dei microservizi. Esistono meno dipendenze tra team e puoi reagire più rapidamente alle modifiche che altrimenti sarebbero ostacolate da barriere all'accesso ai dati.
Vantaggi delle architetture basate su eventi
Questi sono alcuni dei vantaggi della creazione di un'architettura basata su eventi.
Accoppiamento lasco e maggiore agilità per gli sviluppatori
I produttori di eventi sono separati logicamente dai consumatori di eventi. Questo disaccoppiamento tra la produzione e il consumo di eventi significa che i servizi sono interoperabili, ma possono essere scalati, aggiornati e implementati indipendentemente tra loro.
Il disaccoppiamento riduce le dipendenze e ti consente di implementare i servizi in diversi linguaggi e framework. Puoi aggiungere o rimuovere produttori e visualizzatori di eventi senza dover modificare la logica in un servizio. Non è necessario scrivere codice personalizzato per eseguire polling, filtrare e instradare gli eventi.
Eventi asincroni e resilienza
In un sistema basato su eventi, gli eventi vengono generati in modo asincrono e possono essere emessi man mano che si verificano senza attendere una risposta. Componenti con accoppiamento lasco significa che se un servizio non funziona, gli altri non sono 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 consentono la messaggistica push e i client possono ricevere aggiornamenti senza dover eseguire continuamente il polling dei servizi remoti per rilevare le modifiche dello stato. Questi messaggi inviati possono essere utilizzati per l'elaborazione e la trasformazione dei dati in tempo reale e per l'analisi in tempo reale. Inoltre, con meno polling si riduce l'I/O di rete e i costi.
Controllo e origine eventi semplificati
La posizione centralizzata del router di 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 dati sia in transito che at-rest.
Inoltre, puoi utilizzare l'event sourcing, un pattern di architettura che registra tutte le modifiche apportate allo stato di un'applicazione, nella stessa sequenza in cui sono state applicate inizialmente. L'event sourcing fornisce un log di eventi immutabili che possono essere conservati a fini di controllo, per ricreare stati storici o come narrazione canonica per spiegare una decisione basata sulle esigenze aziendali.
Considerazioni sull'architettura
Un'architettura basata sugli eventi potrebbe richiedere un nuovo approccio alla progettazione dell'applicazione. Sebbene sia molto adatto per le applicazioni che utilizzano microservizi o componenti disaccoppiati, devi anche considerare quanto segue:
La sorgente evento può garantire la consegna 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 su database inelastici.
Come vuoi monitorare il flusso di eventi?
Un'architettura basata su eventi supporta il monitoraggio dinamico mediante servizi di monitoraggio, ma non il monitoraggio statico mediante analisi del codice.
Vuoi utilizzare i dati nell'origine evento per ricostruire lo stato?
Devi valutare come assicurarti che i dati siano deduplicati e ordinati.
Passaggi successivi
- Per capire in che modo Eventarc Advanced gestisce gli eventi, consulta la panoramica di Eventarc Advanced.
- Per capire in che modo Eventarc Standard gestisce gli eventi, consulta la panoramica di Eventarc Standard.