Che cos'è un'architettura basata sugli eventi (EDA)?
L'architettura basata su eventi (EDA) è un modello di architettura moderno sviluppato per piccoli servizi disaccoppiati che pubblicano, consumano o instradano eventi.
Un evento rappresenta un cambio di stato o un aggiornamento. Alcuni esempi: un articolo inserito in un carrello, un file caricato in un sistema di archiviazione o un ordine pronto per la spedizione. Gli eventi possono contenere lo stato (come il nome dell'articolo, il prezzo o la quantità di un ordine) o semplicemente gli identificatori (ad esempio, "l'ordine n.8942 è stato spedito") necessari per cercare le informazioni correlate.
A differenza dei tradizionali modelli basati su richiesta, l'EDA promuove un accoppiamento debole tra servizi produttori e consumatori. In tal modo è più facile scalare, aggiornare e implementare in modo indipendente i componenti separati di un sistema.
Perché l'architettura disaccoppiata è importante?
Molte organizzazioni riscontrano che applicazioni, database e tecnologie di tipo monolitico influiscono negativamente sull'innovazione e sul miglioramento dell'esperienza utente. Le applicazioni e i database legacy riducono le opzioni per adottare framework tecnologici moderni e limitano il potenziale di competitività e innovazione. Grazie alla loro modernizzazione, tuttavia, le applicazioni e i relativi data store consentono un dimensionamento semplificato e uno sviluppo più rapido.
Una strategia basata sul disaccoppiamento dei dati migliora la tolleranza ai guasti e la resilienza, pertanto accelera il time-to-market (TTM) per nuove funzionalità delle applicazioni.
Ulteriori informazioni sui vantaggi inerenti alla modernizzazione delle applicazioni monolitiche sono disponibili in Enabling data persistence in microservices (Attivazione della persistenza dei dati nei microservizi) nel Prontuario AWS.
Quali sono i vantaggi dell'architettura basata su eventi (EDA)?
L'architettura basata su eventi (EDA) promuove l'accoppiamento debole tra componenti di un sistema e consente in tal modo una maggiore agilità. I microservizi possono eseguire il dimensionamento in maniera indipendente, avere esito negativo senza influenzare altri servizi e ridurre la complessità dei flussi di lavoro. Gli eventi possono essere instradati in modo flessibile, sottoposti a buffering e registrati a fini di audit. I flussi di eventi basati su tecnologia push possono agire in tempo reale e tagliare così i costi associati alla creazione e alla gestione di codice che esegua il polling continuo dei sistemi per rilevare modifiche.
Dimensionamento e blocco indipendenti
Attraverso il disaccoppiamento dei servizi, i componenti in un'architettura basata su eventi possono eseguire il dimensionamento e avere esito negativo in modo indipendente, pertanto la resilienza di un'applicazione aumenta. Questo diventa un aspetto sempre più importante man mano che il numero di integrazioni tra servizi aumenta. Se un servizio ha un esito negativo, gli altri possono rimanere in esecuzione.
L'architettura basata su eventi può anche semplificare la progettazione di sistemi aggiornati quasi in tempo reale e aiutare così le organizzazioni a smarcarsi dall'elaborazione basata su batch. Gli eventi vengono generati alla modifica dello stato di un'applicazione. Quando gli eventi si dimensionano verso l'alto, altrettanto può fare il livello che elabora gli eventi.
Gli eventi vengono generalmente pubblicati su servizi di messaggistica che fungono da buffer elastico tra i microservizi e semplificano la gestione del dimensionamento. È inoltre possibile inviare gli eventi a un servizio di instradamento in grado di filtrare e instradare i messaggi in base al contenuto dell'evento. Di conseguenza, le applicazioni basate su eventi possono essere più scalabili e offrire una ridondanza maggiore rispetto alle applicazioni monolitiche.
Sviluppo agile
Grazie all'architettura basata su eventi e agli strumenti di instradamento eventi, gli sviluppatori non sono più tenuti a scrivere il codice personalizzato per eseguire il polling, il filtraggio e l'instradamento degli eventi. Uno strumento di instradamento eventi filtra automaticamente gli eventi e li invia in modalità push ai consumatori. Lo strumento di instradamento elimina anche la necessità di un eccessivo coordinamento tra i servizi produttori e consumatori, per cui l'agilità degli sviluppatori aumenta.
L'architettura basata su eventi si appoggia alla tecnologia push, vale a dire che tutto avviene on demand quando gli eventi vengono inviati verso lo strumento di instradamento e i sistemi a valle, senza la necessità di informare i servizi dipendenti. Per tale motivo, infrastruttura e risorse possono eseguire il dimensionamento verso l'alto e verso il basso con il volume degli eventi, così è possibile ridurre i costi per elaborare carichi di lavoro e gestire le applicazioni implementate.
Creazione di sistemi espandibili
L'architettura basata su eventi è anche altamente espandibile. Altri team possono ampliare le caratteristiche e aggiungere funzionalità senza compromettere i microservizi esistenti. Attraverso la pubblicazione di eventi, un'applicazione può integrarsi con i sistemi esistenti e le future applicazioni potranno integrarsi facilmente come utenti di eventi senza modificare la soluzione esistente.
I produttori di eventi non hanno conoscenze in merito agli utenti di eventi, perciò l'ampliamento del sistema ha una frizione minore e le nuove caratteristiche o integrazioni non aggiungono dipendenze che rischiano di rallentare lo sviluppo futuro.
Riduzione della complessità
I microservizi consentono a sviluppatori e architetti di scomporre i flussi di lavoro complessi. Ad esempio, possono suddividere un monolito di e-commerce in accettazione degli ordini e processi di pagamento con servizi di inventario, adempimento e contabilità separati.
Un carico di lavoro potenzialmente difficile da gestire e orchestrare in un monolito si trasforma in una serie di servizi disaccoppiati semplici che vengono gestiti in modo indipendente e comunicano in modo asincrono attraverso i messaggi degli eventi.
Un approccio basato su eventi rende possibile l'assemblaggio e l'orchestrazione di servizi che elaborano i dati con frequenze diverse. Nell'esempio seguente, un microservizio di accettazione degli ordini interagisce con un sistema di elaborazione dei pagamenti attraverso una coda.
Nell'esempio, il servizio di accettazione degli ordini può archiviare grandi volumi di ordini in entrata eseguendo il buffer dei messaggi in una coda.
Il servizio di elaborazione dei pagamenti, che generalmente è più lento a causa della complessità della gestione dei pagamenti, può prelevare un flusso di messaggi costante dalla coda. Il servizio di pagamento esegue la transizione tra vari stati di sistema a causa della logica di gestione di nuovi tentativi ed errori. Il servizio del flusso di lavoro orchestra e gestisce le fasi di pagamento in base allo stato del sistema e alla fine genera più eventi interessanti per i servizi di inventario, adempimento e contabilità.
Facilità di controllo
Uno strumento di instradamento eventi in un'architettura basata su eventi funge da sede centralizzata per il controllo dell'applicazione e la definizione delle policy. Tali policy possono limitare chi può pubblicare e iscriversi a uno strumento di instradamento e controllano quali utenti e risorse sono autorizzati ad accedere ai dati. Inoltre, permettono di crittografare gli eventi sia in transito che a riposo.
Taglio dei costi
Le EDA utilizzano la tecnologia push, quindi tutto accade on demand quando un evento si presenta nello strumento di instradamento. Per questo motivo, non è necessario pagare per eseguire il polling continuo alla ricerca di un evento. Ciò si traduce in minore consumo di larghezza di banda della rete, minore utilizzo della CPU, minore capacità di parco istanze inattiva e meno handshake SSL/TLS.
Come funziona un'architettura basata su eventi (EDA)?
Di seguito è riportato un esempio di architettura basata su eventi (EDA) per un sito di e-commerce:
%20for%20an%20ecommerce%20site.88b2240905b1b6addd672871b98bcb17bd44d701.jpg)
Questo sito di esempio illustra tre componenti principali di produttori di eventi e gli eventi che producono. Nello scenario proposto, uno strumento di instradamento eventi acquisisce e filtra gli eventi, dopodiché ne invia uno o più agli utenti di eventi.
Questa architettura basata sugli eventi permette al sito di reagire ai cambiamenti da una vasta gamma di origini durante i momenti di picco di domanda, evitando però il collasso dell'applicazione e il provisioning eccessivo delle risorse.
Quali tipi di carico di lavoro sono adatti all'architettura basata su eventi (EDA)?
Le architetture basate su eventi (EDA) possono costituire un metodo efficace per soddisfare le richieste dei carichi di lavoro altamente scalabili e disponibili. L'EDA si applica bene anche ai carichi di lavoro con schemi di traffico imprevedibili o soggetti a picchi.
Quali sono i vantaggi dell'architettura basata su eventi (EDA) per le applicazioni?
L'architettura basata su eventi (EDA) promuove l'accoppiamento debole tra componenti ed è perciò un buon approccio per la creazione di applicazioni distribuite moderne.
I produttori di eventi non sono coscienti, interessati e vincolati da alcuna attività dei consumatori a valle degli eventi che producono. Gli eventi stessi rappresentano un cambio di stato e possono contenere dati o meno. Gli eventi sono ignari delle conseguenze della propria esistenza. I consumatori ascoltano ed elaborano gli eventi interessanti. È possibile portare online nuovi consumatori per fornire nuove funzionalità senza interrompere i flussi di lavoro esistenti.
Le EDA promuovono la scomposizione dei sistemi monolitici in modelli di dominio più piccoli. Gli sviluppatori possono prendere il ritmo con meno carico cognitivo e raggiungere più rapidamente la produttività. Quando le funzioni fondamentali sono disaccoppiate, si riduce inoltre il rischio inerente all'implementazione di aggiornamenti e nuove caratteristiche.
Quali sono alcuni casi d'uso comuni per l'architettura basata su eventi (EDA)?
Comunicazione di microservizi per back-end Web e per dispositivi mobili
Spesso i siti Web di vendita al dettaglio e media e intrattenimento devono eseguire il dimensionamento verso l'alto per gestire il traffico imprevedibile. I clienti visitano un sito Web di e-commerce ed effettuano un ordine. L'evento di ordine viene inviato a uno strumento di instradamento eventi. Tutti i microservizi a valle possono raccogliere l'evento di ordine per elaborarlo. Ecco alcune azioni di esempio: presentazione di un ordine, autorizzazione de pagamento e invio dei dettagli dell'ordine a un corriere.
Poiché ciascun microservizio può eseguire il dimensionamento e gestire gli errori in modo indipendente, il processo può dimensionarsi verso l'alto durante i periodi di picco degli ordini senza singoli punti di errore.
Automazione dei flussi di lavoro aziendali
Molti flussi di lavoro aziendali, tra cui le transazioni dei servizi finanziari, richiedono la ripetizioni delle stesse fasi. Un'architettura basata su eventi (EDA) permette di avviarle e automatizzarle.
Ad esempio, quando un cliente chiede di aprire un nuovo conto presso una banca, questa deve eseguire alcuni controlli di dati (documenti d'identità, indirizzo, ecc.). Alcuni conti necessitano anche di una fase di approvazione umana. È possibile orchestrare tutte le fasi mediante un servizio di flusso di lavoro che esegua le fasi automaticamente alla ricezione di ogni richiesta di apertura di un conto.
Si potrebbe inoltre aggiungere un flusso di lavoro per elaborare i dati di richiesta dei clienti in modo asincrono con il machine learning per estrarre i dati rilevanti, così da ridurre potenzialmente ore di lavoro per la raccolta e la conferma manuali dei dati.
Integrazione di applicazioni SaaS
Uno dei principali ostacoli degli ambienti Software come servizio (SaaS) è la mancanza di visibilità delle attività e dei dati degli utenti. Per sbloccare i dati in silo, le architetture basate su eventi sono in grado di acquisire gli eventi delle applicazioni SaaS o di inviare eventi alle loro applicazioni SaaS. Ad esempio, è possibile creare un middleware per acquisire i dati degli ordini dei partner in entrata e inviare gli ordini direttamente a un'applicazione di elaborazione degli ordini interna all'azienda.
Automazione dell'infrastruttura
Quando si eseguono carichi di lavoro ad alta intensità di calcolo (come analisi finanziarie, ricerca genomica o transcodifica di contenuti multimediali), è possibile configurare le risorse di calcolo in modo che eseguano il dimensionamento verso l'alto per l'elaborazione altamente parallela e verso il basso una volta che il processo è terminato.
Ad esempio, nei settori altamente regolamentati, le aziende con un'EDA possono creare risorse sull'assetto di sicurezza in risposta a un incidente oppure adottare misure correttive quando una policy di sicurezza invia un evento di avviso.
Quando è consigliabile usare un'architettura basata su eventi (EDA)?
Le architetture basate su eventi (EDA) sono ideali per migliorare l'agilità e muoversi rapidamente. In genere si trovano nelle applicazioni moderne che utilizzano microservizi o in qualsiasi applicazione che disponga di componenti disaccoppiati.
Integrazione di sistemi eterogenei
Se si dispone di sistemi in esecuzione su diversi stack, è possibile utilizzare un'EDA per condividere informazioni tra di essi senza accoppiarli. Lo strumento di instradamento eventi stabilisce l'indirezione e l'interoperabilità tra i sistemi, in modo che possano scambiarsi messaggi e dati rimanendo sempre indipendenti.
Replica dei dati tra più regioni e account
È possibile utilizzare un'EDA per coordinare i sistemi tra team che lavorano e implementano su più account e regioni AWS. Utilizzando uno strumento di instradamento eventi per trasferire i dati tra sistemi, si possono sviluppare, dimensionare e implementare servizi in modo indipendente rispetto ad altri team.
Monitoraggio e avvisi sullo stato delle risorse
Invece di controllare costantemente le risorse, è possibile usufruire di un'EDA per monitorare e ricevere avvisi su anomalie, modifiche e aggiornamenti. Queste risorse includono bucket di archiviazione, tabelle di database, funzioni serverless, nodi di calcolo e altro ancora.
Fan-out ed elaborazione in parallelo
Se si dispone di molti sistemi che devono funzionare in risposta a un evento, è possibile utilizzare un'EDA per eseguire il fan-out degli eventi senza dover scrivere codice personalizzato per l'invio push a ogni consumatore. Lo strumento di instradamento inoltra l'evento ai sistemi, ciascuno dei quali può elaborarlo in parallelo a scopi diversi.
Quali sono gli schemi comuni dell'architettura basata su eventi (EDA)?
Tante funzioni brevi
È possibile creare tante funzioni brevi anziché poche funzioni di dimensioni maggiori. Le funzioni altamente specializzate per il carico di lavoro sono concise e generalmente riducono il tempo di elaborazione. Ciascuna funzione dovrebbe gestire l'evento avvenuto nella funzione, senza conoscenze né aspettative circa il flusso di lavoro complessivo o il volume di transazioni. Ciò rende indipendente la funzione rispetto all'origine dell'evento, con un accoppiamento minimo ad altri eventi.
Elaborazione on demand anziché in batch
Molti sistemi tradizionali sono progettati per l'esecuzione periodica e l'elaborazione di batch di transazioni che si accumulano nel tempo. Un'applicazione bancaria, ad esempio, potrebbe essere eseguita con cadenza oraria per elaborare le transazioni degli ATM nei libri mastri centrali.
Nell'architettura basata su eventi (EDA) l'elaborazione personalizzata può reagire a ogni evento. Ciò permette al servizio di dimensionare verso l'alto i processi concomitanti in base alle esigenze per elaborare le transazioni quasi in tempo reale.
Ripristino in caso di interruzione
In caso di interruzione, un servizio potrebbe essere richiamato in automatico per ritentare l'elaborazione di un evento. Poiché il servizio potrebbe ricevere il medesimo evento più di una volta, le funzioni di progettazione devono essere idempotenti. Ciò garantisce che il risultato non cambi dopo la prima ricezione dell'evento da parte del servizio.
Se, ad esempio, un venditore al dettaglio cerca di elaborare una carta di credito due volte a causa di un secondo tentativo, il servizio elabora il pagamento solo al primo. Al nuovo tentativo, il servizio verifica lo stato del pagamento e ignora l'evento.
Quali sono alcune complicazioni dell'architettura basata su eventi (EDA)?
Quando si adotta un'architettura basata su eventi (EDA), può essere necessario ripensare il modo in cui viene concepita la configurazione dell'applicazione.
Latenza variabile
A differenza delle applicazioni monolitiche, che possono elaborare tutto all'interno dello stesso spazio di memoria su un singolo dispositivo, le applicazioni basate su eventi comunicano attraverso reti. Questa configurazione introduce una latenza variabile. Nonostante le applicazioni monolitiche possano avere una latenza minore o meno variabile, ciò di solito va a discapito di scalabilità e disponibilità.
I servizi AWS serverless sono altamente disponibili, vale a dire che sono operativi in più di una zona di disponibilità all'interno di una regione AWS. In caso di interruzione del servizio, i servizi eseguono il failover automatico in altre zone di disponibilità e ritentano le transazioni. Di conseguenza, anziché essere interrotte, le transazioni possono completarsi correttamente ma con una latenza superiore.
I carichi di lavoro che richiedono prestazioni a bassa latenza costanti non sono particolarmente adatte all'EDA. Due esempi sono le applicazioni di trading ad alta frequenza nelle banche o l'automazione robotica con tempi operativi inferiori al millisecondo nei magazzini.
Coerenza finale
Un evento rappresenta un cambio di stato. Considerato il flusso di eventi che attraversa vari servizi di un'architettura in un dato momento, tali carichi di lavoro sono spesso a coerenza finale. Ciò rende più complicato elaborare le transazioni, gestire i duplicati o determinare lo stato complessivo esatto di un sistema.
Alcuni carichi di lavoro non sono particolarmente adatti all'EDA a causa della necessità di proprietà ACID. Tuttavia, molti carichi di lavoro prevedono una combinazione di requisiti che sono a coerenza finale (ad esempio il totale degli ordini nell'ora corrente) o a coerenza elevata (ad esempio l'inventario attuale). Per le funzionalità che esigono una consistenza dei dati elevata, esistono modelli di architettura che supportano tale requisito. Ad esempio:
- DynamoDB può fornire letture a coerenza elevata, a volte a una latenza superiore, e può anche supportare le transazioni per mantenere la consistenza dei dati.
- Per le funzionalità che richiedono proprietà ACID, si possono usare i database relazionali, sebbene siano meno scalabili rispetto a un datastore NoSQL.
Restituzione dei valori ai chiamanti
In molti casi, le applicazioni basate su eventi sono asincrone. Ciò significa che i servizi chiamanti non attendono richieste da altri servizi prima di proseguire con altre operazioni. Questa caratteristica fondamentale delle EDA garantisce scalabilità e flessibilità; tuttavia, rende il passaggio di valori di restituzione o risultati dei flussi di lavoro più complesso rispetto ai flussi sincroni.
In molti casi, restituire un valore è meno importante del garantire il successo o il fallimento dell'elaborazione dell'evento. Le funzionalità che garantiscono l'elaborazione degli eventi potrebbero essere più importanti della restituzione dei valori a un chiamante.
Per i carichi di lavoro interattivi, come applicazioni Web e per dispositivi mobili, l'utente finale generalmente si aspetta di ricevere un valore di ritorno o lo stato attuale di una transazione. Per tali carichi di lavoro, esistono diversi modelli di configurazione in grado di restituire al chiamante numerosi eventi. Tuttavia, implementazioni simili in un'architettura basata su eventi sono più complesse rispetto all'uso di un valore di ritorno asincrono tradizionale. Spesso la piattaforma può ridurre tale complessità.
Debugging di servizi e funzioni
Il debugging dei sistemi basati su eventi è diverso da quello di un'applicazione monolitica. Così come con tutte le applicazioni basate su microservizi e diversi sistemi e servizi che trasmettono eventi, registrare e riprodurre lo stato esatto di più servizi quando si verifica un errore può risultare difficile. Poiché ogni invocazione di servizi e funzioni dispone di file di log separati, può essere più complicato determinare che cos'è accaduto a un particolare evento che ha generato un errore.
Orchestrazione
È comune che i flussi di lavoro semplici diventino più complessi nel corso del tempo. In un monolito tipico, ciò si può tradurre in gruppi di funzioni e servizi accoppiati in modo più serrato e in un codice complesso per la gestione dell'instradamento e delle eccezioni.
Per tenere traccia dello stato del sistema, in genere i flussi di lavoro che prevedono logica ramificata, vari tipi di modelli di errore e logica di ripetizione dei tentativi utilizzano un orchestratore. Quando si crea un'applicazione serverless basata su eventi, è importante individuare quando ciò avviene, in modo da poter trasferire tale logica in una macchina a stati per ottenere un'orchestrazione adeguata.
Quali servizi AWS utilizzano un'architettura basata su eventi (EDA)?
I servizi AWS generalmente producono o consumano eventi, pertanto creare soluzioni con un'architettura basata su eventi (EDA) è facile.
Inoltre, servizi come Amazon EventBridge, Amazon SNS, Amazon SQS e AWS Step Functions includono funzionalità che aiutano i clienti a scrivere meno codice boilerplate e a sviluppare EDA più in fretta.
Amazon EventBridge
È possibile usufruire di Amazon EventBridge per creare router di eventi per applicazioni basate su eventi su larga scala utilizzando eventi provenienti da applicazioni SaaS, altri servizi AWS o applicazioni personalizzate.
EventBridge applica regole per instradare gli eventi dalle origini di eventi a varie destinazioni. Tra queste vi sono servizi AWS come AWS Lambda, Step Functions e Amazon Kinesis o qualsiasi endpoint HTTP attraverso le destinazioni API EventBridge.
Un'integrazione molto apprezzata per i casi d'uso EDA è Step Functions, in cui gli eventi innescano flussi di lavoro specifici.
AWS Step Functions
AWS Step Functions include Workflow Studio, uno strumento di progettazione di flussi di lavoro visivo low-code che gli sviluppatori utilizzano per l'orchestrazione di vari servizi AWS. Con Workflow Studio è possibile creare applicazioni distribuite, automatizzare processi IT e aziendali e creare pipeline di dati e machine learning utilizzando servizi AWS.
Amazon SNS
Consigliamo di utilizzare il Servizio di notifica semplice Amazon (Amazon SNS) per creare applicazioni che reagiscano a eventi con velocità di trasmissione effettiva elevata e bassa latenza pubblicati da altri microservizi, applicazioni o servizi AWS. È inoltre possibile usare Amazon SNS per le applicazioni che necessitano di un fan-out molto elevato verso migliaia o persino milioni di endpoint.
Amazon SQS
Il Servizio di coda semplice Amazon (Amazon SQS) offre un servizio di coda in hosting sicuro, durevole e disponibile che consente di integrare e disaccoppiare sistemi e componenti software distribuiti. Amazon SQS offre costrutti tipici come code DLQ e tag di allocazione dei costi.
Passaggi successivi dell'architettura basata sugli eventi di AWS
Ottieni accesso istantaneo al piano gratuito di AWS.
