L'architettura non-pilota (EDA) è diventata un paradigma di progettazione fondamentale per l'edilizia distribuita, scalabile e sistemi reattivi. Piuttosto che affidarsi a stretto accoppiamento tra i componenti attraverso chiamate dirette di metodo o invocazioni di procedura remote, la comunicazione EDA alla produzione, il rilevamento e il consumo di eventi.

Cos'è l'architettura a conduzione di eventi?

Un evento è un record immutabile di qualcosa che è accaduto in passato — per esempio, ] OrdinePlaced], ], ]I consumatori di UserRegistered], o PaymentFailed eventi

Questa architettura si contraddistingue per i modelli tradizionali di richiesta-responsabilità sincroni, dove un servizio chiama direttamente un altro servizio e aspetta una risposta. La comunicazione sincrona crea un accoppiamento stretto: se il servizio a valle è lento o non disponibile, il chiamante è bloccato. Con EDA, produttori eventi di fuoco e immediatamente continuare il loro lavoro.

EDA è particolarmente potente negli ecosistemi di microservice, negli ambienti poliglot e in qualsiasi dominio che richieda un elevato rendimento, una bassa latenza o flussi di lavoro a gestione eventi come l'elaborazione degli ordini, l'ingestione dei dati IoT e il rilevamento delle frodi.

Modelli core in Architettura a livello di eventi

Pubblicazione/Subscribe (Pub/Sub)

Il modello Publish/Subscribe (Pub/Sub) è il modello EDA più semplice e più ampiamente adottato. In questo modello, gli editori emettono eventi a un argomento o un canale. Gli abbonati registrano interesse per tali argomenti e ricevono tutti gli eventi pubblicati a loro. Il broker gestisce fan-out, le garanzie di consegna e il filtraggio. Editori e abbonati non hanno conoscenza di ciascuno - questa è l'essenza di un accoppiamento sciolto.

Per esempio, consideri una piattaforma di e-commerce. Quando un cliente pone un ordine, il servizio di ordine pubblica un [OrderPlaced evento a un argomento "ordinari".

  • Il servizio di inventario deduce le scorte.
  • Il servizio di fatturazione addebita al cliente.
  • Il servizio di notifica invia una conferma email.
  • Il servizio di analisi registra l'evento per la segnalazione.

Ogni abbonato elabora l'evento in modo indipendente e al proprio ritmo. Se il servizio di notifica è lento, non influisce sul servizio di ordine o sul servizio di inventario. Questo modello supporta naturalmente la scalatura; è possibile aggiungere più istanze del servizio di inventario per gestire il carico aumentato senza toccare altri componenti.

Gli strumenti più popolari per l'implementazione di Pub/Sub includono Apache Kafka, che fornisce flussi di eventi ad alta produttività, persistenti e riproducibili; RabbitMQ]] con i suoi cambi di argomento e di routing; e servizi cloud-nativi come AWS

Segregazione di responsabilità della coda di comando (CQRS)

Segregazione di responsabilità di coda di comando (CQRS) è un modello che separa le operazioni di scrittura (comandi) dalle operazioni di lettura (querie) in modelli diversi. Nei sistemi tradizionali CRUD, lo stesso modello di dati viene utilizzato sia per gli aggiornamenti che per le letture, che possono portare a problemi di prestazioni quando il carico di lavoro è sbilanciato - per esempio, un percorso di scrittura complesso che ha anche bisogno di servire le query di lettura ottimizzate per un altro schema.

In un sistema basato su CQRS, un comando come PlaceOrder[]] attiva un modello di scrittura che convalida le regole aziendali e produce un evento (ad esempio, OrderCreated). Questo evento aggiorna il database di scrittura.

I vantaggi del CQRS includono:

  • Performance:[] I carichi di lavoro a lettura pesante possono essere serviti da negozi specializzati senza alcuna soddisfazione da scrivanie.
  • Sicurezza:[]] È possibile esporre comandi e query a diversi pubblico; ad esempio, un comando potrebbe richiedere l'autenticazione, mentre una query pubblica è in sola lettura.
  • Scalability:[ I lati letti e scrittura possono scalare in modo indipendente su hardware o cluster diversi.
  • Flessibilità:[] È possibile evolvere lo schema di lettura senza influenzare la logica del lato di comando.

Tuttavia, CQRS aggiunge complessità perché introduce una consistenza eventuale e richiede spesso la sincronizzazione tra i due lati. Si abbina naturalmente con Event Sourcing, dove il lato di scrittura memorizza una sequenza di eventi piuttosto che una istantanea dello stato corrente. Martin Fowler's article on CQRS[]]] è una risorsa eccellente per comprendere i trade-off del modello.

Sourcing evento

Event Sourcing è un modello in cui i cambiamenti di stato vengono memorizzati come una sequenza cronologica di eventi, non come una snapshot dello stato attuale. Piuttosto che sovrascrivere un record in un database, ogni mutazione genera un nuovo evento allegato a un registro eventi. Lo stato attuale può essere derivato rigiocando tutti gli eventi dall'inizio - o utilizzando istantanee a intervalli per accelerare il recupero.

Event Sourcing offre diversi vantaggi:

  • Corso completo di audit: Ogni cambiamento viene registrato, permettendo di vedere la storia completa di un'entità.
  • Debugging e debugging:[] È possibile rigiocare gli eventi in un ambiente di sviluppo per riprodurre bug o testare nuove logiche aziendali.
  • Domande tempestive:[] Si può chiedere che cosa lo stato era in qualsiasi momento.
  • Ease of using CQRS:[] Il negozio di eventi serve come modello di scrittura e i modelli di lettura possono iscriversi agli eventi per aggiornamenti in tempo reale.

Il principale trade-off è l'accresciuta archiviazione e la complessità. L'analisi diretta del negozio di eventi è spesso inefficiente, quindi in genere si costruisce modelli di lettura (Progetzioni) che materializzano le viste. Event Sourcing è comune in domini come contabilità finanziaria, banca e editing di documenti collaborativi dove ogni cambiamento deve essere registrato.

Streaming degli eventi

Lo streaming di eventi tratta gli eventi come flusso di dati continuo e non-bounded. Questo modello viene utilizzato per l'analisi in tempo reale, il monitoraggio e l'integrazione dei dati in scala. In caso di streaming, gli eventi vengono ingeriti da più produttori e trattati in tempo reale da processori di flusso che filtrano, aggregano e trasformano i dati. I risultati trattati possono essere memorizzati, inviati ad un altro flusso, o utilizzati per attivare azioni a valle.

Apache Kafka è lo standard de facto per lo streaming degli eventi. Conserva eventi in log immutabili attraverso partizioni per la tolleranza dei guasti e scalabilità orizzontale. I framework di elaborazione in streaming come Kafka Streams, Apache Flink e Spark Streaming consentono un'elaborazione complessa degli eventi con esattamente una volta semantica. Ad esempio, una società di condivisione del giro potrebbe trasmettere le posizioni GPS per calcolare i prezzi di sovratensione, rilevare la disponibilità dei driver e aggiornare il rider ETAs.

Lo streaming di eventi è anche fondamentale per i microservizi mesh dati e basati su eventi in cui si desidera decouplare i produttori di dati dai consumatori a livello di infrastruttura dati.

Altri importanti modelli e modelli in combinazione

Modello Saga

Nelle transazioni distribuite, soprattutto all'interno di microservizi, il modello Saga gestisce flussi di lavoro multi-step. Ogni passo in una saga pubblica un evento o esegue un'azione. Se un passo non riesce, la saga corre eventi compensativi per rimboccare i passi precedenti. Sagas può essere orchestrato (un coordinatore centrale dice a ogni servizio che fare) o coreografato (ogni servizio ascolta per eventi e decide di fallimento sul proprio evento).

Programmazione reattiva

Sebbene non sia strettamente un modello architettonico, la programmazione reattiva è un modello di programmazione che si allinea bene con EDA. Quadri come RxJS, Reactor e Akka Streams permettono agli sviluppatori di comporre logica asincrona e basata su eventi utilizzando sequenze osservabili. Ciò è particolarmente utile nei client (ad esempio, aggiornamenti UI in tempo reale) e in flussi server-side dove è necessario elaborare volumi elevati di eventi con backure.

Collaborazione di eventi

Event Collaboration è un modello in cui i servizi condividono un modello comune di eventi e comunicano esclusivamente attraverso eventi. Ogni servizio mantiene la propria logica di dominio e proietta eventi nei propri data stores. Non c'è un servizio diretto-a-service API chiamate. Questo modello massimizza l'autonomia e viene spesso utilizzato nel design a dominio con contesti delimitati. La sfida principale è la versione: quando lo schema dell'evento cambia, tutti i consumatori devono essere aggiornati o l'evoluzione dello schema Probuto, utilizzando Avrof.

Scegliere il giusto modello

La selezione di un modello EDA dipende dalle vostre specifiche esigenze.

  • Coupling e indipendenza:[] Se avete bisogno di decoupling elevato e molti consumatori, Pub/Sub è semplice. Se avete bisogno di modelli di lettura e scrittura separati, combinate CQRS con Event Sourcing.
  • La coerenza ha bisogno di:[ Per una forte coerenza, evitare EDA; utilizzare transazioni distribuite o un database con ACID rigoroso.
  • Potenza e latenza:[[] Lo streaming di eventi (Kafka) dà il miglior throughput, mentre Pub/Sub con un broker come RabbitMQ offre una latenza inferiore per i messaggi più piccoli.
  • Auditability:[] Event Sourcing è ideale per le industrie a forte rendimento.
  • Maturità del team:[[] CQRS e Sourcing degli eventi aumentano la complessità. Assicurare che il vostro team comprenda la consistenza, l'evoluzione degli schemi e l'idempotency.

Vantaggi dell'architettura Event-Driven

Oltre ai vantaggi immediati di decoupling e scalabilità, EDA offre diversi vantaggi operativi e aziendali:

  • Scalability:[] Ogni componente scala indipendentemente sulla base del proprio carico. Durante una vendita flash, è possibile scalare il servizio di ordine e i suoi abbonati senza toccare i servizi di fatturazione o spedizione.
  • Flessibilità:[] L'aggiunta di un nuovo consumatore (ad esempio, un nuovo canale di analisi) non richiede modifiche ai produttori, rendendo più facile l'evoluzione del sistema nel tempo.
  • Risulenza in tempo reale:[ EDA supporta naturalmente esperienze utente in tempo reale, come dashboard dal vivo, notifiche e aggiornamenti istantanei.
  • Risilienza:[] Se un consumatore fallisce, gli eventi sono perseverati nel broker e possono essere riprodotti. I produttori continuano a lavorare. Questo isolamento impedisce errori di fuga.
  • Observabilità:[ I registri degli eventi forniscono una ricca fonte di dati per il monitoraggio, l'avviso e il debug delle tracce distribuite.
  • Integrazione dei dati:[] Gli eventi possono essere trasmessi a laghi di dati, magazzini o tubazioni di apprendimento automatico per l'analisi, rendendo il sistema una fonte di verità per l'intera organizzazione.

Sfide e migliori pratiche

L'EDA è potente ma non senza insidie. Le sfide comuni includono:

  • Consistenza avventuale:[] I consumatori possono vedere dati stanti. È necessario progettare processi aziendali che tollerano ritardi e implementano i gestori idempote.
  • Complessità:[]] La gestione degli schemi degli eventi, la versione e più flussi di eventi può essere scoraggiante.
  • Debug e monitoraggio:[ I flussi di eventi distribuiti sono più difficili da tracciare. Investi in strumenti di osservabilità come il tracciamento distribuito (Jaeger, OpenTelemetry) e l'aggregazione dei log.
  • Data duplication:[] Gli eventi possono essere duplicati; rendere i vostri consumatori idempotent in modo da elaborare un evento due volte ha lo stesso effetto di elaborarlo una volta.
  • Ordering:[] Non tutti i flussi di eventi hanno bisogno di un ordine rigoroso, ma quando lo fanno (ad esempio, transizioni di stato di un'unica entità), partizione per chiave (ad esempio, ID entità) e garantire il broker conserva l'ordine all'interno di una partizione.

Le migliori pratiche includono: avviare semplice — utilizzare Pub/Sub prima e aggiungere solo CQRS o Event Sourcing quando giustificato; investire in un buon registro di schema; applicare le code di lettere morte per eventi falliti; e simulare i guasti regolarmente per garantire la vostra saga compensando le funzioni logiche.

Conclusioni

I modelli di architettura basati su eventi, dal Pub/Sub alla CQRS più specializzata, alla Sourcing degli eventi e allo streaming di eventi, offrono un robusto toolkit per sistemi di costruzione scalabili, resilienti e reattivi.