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) o possono essere identificatori (ad esempio, una notifica che indica che un ordine è stato ricevuto o spedito). Gli eventi attivano microservizi che collaborano per raggiungere un obiettivo comune, ma non devono sapere nulla l'uno dell'altro, tranne il formato dell'evento. Sebbene operino insieme, ogni microservizio può applicare una logica di business diversa ed emettere i propri eventi di output.
Un evento ha le seguenti caratteristiche:
- È la registrazione di un evento.
- Registra 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.
- Può essere reso persistente a tempo indeterminato, su larga scala e utilizzato tutte le volte necessarie.
In un sistema basato sugli eventi, gli eventi vengono generati dai produttori di eventi, inseriti e filtrati da un router di eventi (o broker), quindi distribuiti ai consumatori di eventi (o sink) appropriati. Gli eventi vengono inoltrati ai consumer in base agli abbonamenti definiti da una o più registrazioni corrispondenti (quando si utilizza Eventarc Advanced) o uno o più trigger corrispondenti (quando si utilizza Eventarc Standard). Questi tre componenti (produttori di eventi, router di eventi e consumatori di eventi) sono disaccoppiati e possono essere implementati, 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 loro risultati vengono decisi 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, considera i seguenti utilizzi.
- Per monitorare e ricevere avvisi in caso di anomalie o modifiche ai bucket di archiviazione, alle tabelle di database, alle macchine virtuali o ad altre risorse.
- Per distribuire un singolo evento a più consumatori. Il router eventi trasmetterà 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 mantenendo l'indipendenza di ciascuno stack.
- Per coordinare sistemi e team che operano ed eseguono il deployment in diverse regioni e account. Puoi riorganizzare la proprietà dei microservizi. Ci sono meno dipendenze tra i team e puoi reagire più rapidamente ai cambiamenti che altrimenti sarebbero ostacolati 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 debole e maggiore agilità degli 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 l'uno dall'altro.
L'accoppiamento debole riduce le dipendenze e consente di implementare i servizi in linguaggi e framework diversi. Puoi aggiungere o rimuovere produttori e destinatari di eventi senza dover modificare la logica in un servizio. Non devi scrivere codice personalizzato per eseguire il polling, filtrare e indirizzare gli eventi.
Eventi asincroni e resilienza
In un sistema basato sugli eventi, questi vengono generati in modo asincrono e possono essere essere emessi man mano che si verificano senza attendere una risposta. I componenti con accoppiamento debole significano 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 basata su push, flussi di eventi in tempo reale e costi inferiori
I sistemi basati su eventi consentono la messaggistica basata su push e i client possono ricevere aggiornamenti senza dover eseguire il polling continuo dei servizi remoti per le modifiche dello stato. Questi messaggi push possono essere utilizzati per l'elaborazione e la trasformazione dei dati al volo e per l'analisi in tempo reale. Inoltre, con meno polling, si verifica una riduzione dell'I/O di rete e una diminuzione dei costi.
Semplificazione dell'audit e dell'event sourcing
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 architetturale che registra tutte le modifiche apportate allo stato di un'applicazione, nella stessa sequenza in cui sono state originariamente applicate. 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 sull'attività.
Considerazioni architettoniche
Un'architettura basata sugli eventi potrebbe richiedere un nuovo approccio alla progettazione dell'applicazione. Sebbene sia adatta alle applicazioni che utilizzano microservizi o componenti disaccoppiati, devi anche considerare quanto segue:
L'origine eventi può garantire la distribuzione se devi elaborare ogni singolo evento?
Deve essere un'origine evento duratura e affidabile.
La tua applicazione può gestire più richieste asincrone?
Le prestazioni del sistema non devono dipendere dall'ambito globale o da database inelastici.
Come vuoi monitorare il flusso di 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 eventi per ricreare lo stato?
Devi valutare come assicurarti che i dati vengano deduplicati e ordinati.
Passaggi successivi
- Per capire come Eventarc Advanced gestisce gli eventi, consulta la panoramica di Eventarc Advanced.
- Per capire come Eventarc Standard gestisce gli eventi, consulta la panoramica di Eventarc Standard.