Il disaccoppiamento dei microservizi tramite il routing asincrono degli eventi consente di creare sistemi distribuiti che reagiscono ai cambiamenti di stato in modo indipendente. Anziché fare affidamento su chiamate dirette da servizio a servizio, i producer di eventi pubblicano notifiche immutabili, mentre un router di eventi (o broker) filtra e distribuisce i messaggi ai consumer di eventi (o sink) downstream. Questa separazione ti aiuta a eseguire il deployment, scalare e aggiornare i componenti in modo isolato senza interrompere i servizi dipendenti.
Puoi gestire la distribuzione degli eventi definendo le registrazioni quando utilizzi Eventarc Advanced o definendo i trigger quando utilizzi Eventarc Standard.
Panoramica dell'architettura
Un'architettura basata su eventi è un pattern di progettazione software in cui i microservizi reagiscono alle modifiche dello stato, chiamate eventi. Gli eventi possono contenere 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 collaborano per raggiungere un obiettivo comune, ma non devono sapere nulla l'uno dell'altro, ad eccezione del 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:
- È un record di un evento che si è verificato.
- Acquisisce 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 dell'utilizzo.
- Può essere conservato a tempo indeterminato, su larga scala, e utilizzato tutte le volte che è necessario.
Componenti principali
In un sistema basato sugli eventi, tre componenti (producer di eventi, router di eventi e consumer di eventi) sono disaccoppiati e possono essere sottoposti a deployment, aggiornati e scalati in modo indipendente:
Il router degli eventi collega i diversi servizi ed è il mezzo attraverso 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 ai consumer 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 tuo sistema, tieni presente i seguenti utilizzi.
- Per monitorare e ricevere avvisi per eventuali 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ù consumer. Il router di eventi 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 l'interoperabilità tra diversi stack tecnologici mantenendo l'indipendenza di ogni stack.
- Per coordinare i sistemi e i team che operano ed eseguono il deployment in regioni e account diversi. Puoi riorganizzare la proprietà dei microservizi. Ci sono meno dipendenze tra i team e puoi reagire più rapidamente ai cambiamenti che altrimenti verrebbero ostacolati dalle barriere all'accesso ai dati.
Vantaggi delle architetture basate su eventi
Questi sono alcuni dei vantaggi della creazione di un'architettura basata su eventi.
Basso accoppiamento e maggiore agilità degli sviluppatori
I producer di eventi sono separati logicamente dai consumer di eventi. Questo disaccoppiamento tra la produzione e il consumo di eventi significa che i servizi sono interoperabili, ma possono essere scalati, aggiornati e sottoposti a deployment indipendentemente l'uno dall'altro.
Il basso accoppiamento riduce le dipendenze e ti consente di implementare i servizi in linguaggi e framework diversi. Puoi aggiungere o rimuovere producer e receiver di eventi senza dover modificare la logica in un singolo servizio. Non è necessario scrivere codice personalizzato per eseguire il polling, filtrare e instradare gli eventi.
Eventing asincrono e resilienza
In un sistema basato sugli eventi, gli eventi vengono generati in modo asincrono e possono essere emessi man mano che si verificano, senza attendere una risposta. Componenti a basso accoppiamento significa che se un servizio non funziona, gli altri non ne risentono. 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, stream di eventi in tempo reale e costi ridotti
I sistemi basati su eventi consentono la messaggistica basata su push e i client possono ricevere aggiornamenti senza dover eseguire continuamente il polling dei servizi remoti per rilevare le modifiche di stato. Questi messaggi inviati tramite push possono essere utilizzati per l'elaborazione e la trasformazione dei dati on-the-fly e per l'analisi in tempo reale. Inoltre, con un minor numero di polling, si ottiene una riduzione dell'I/O di rete e dei costi.
Audit ed event sourcing semplificati
La posizione centralizzata del router di eventi semplifica l'audit 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 applicate originariamente. L'event sourcing fornisce un log di eventi immutabili che possono essere conservati per scopi di controllo, per ricreare stati storici o come narrazione canonica per spiegare una decisione aziendale.
Considerazioni sull'architettura
Un'architettura basata su eventi potrebbe richiedere un nuovo approccio alla progettazione delle applicazioni. Sebbene sia adatto per le applicazioni che utilizzano microservizi o componenti disaccoppiati, devi considerare anche quanto segue:
La tua origine evento può garantire la distribuzione se devi elaborare ogni singolo evento?
Deve essere un'origine di eventi durevole e affidabile.
La tua applicazione è in grado di gestire più richieste asincrone?
Le prestazioni del sistema non devono dipendere da un ambito globale o da database non elastici.
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 utilizzando l'analisi del codice.
Vuoi utilizzare i dati nell'origine eventi per ricostruire lo stato?
Dovresti valutare come assicurarti che i dati siano 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.