Stile di architettura guidato dagli eventi

Un'architettura guidata dagli eventi è costituita da producer eventi che generano un flusso di eventi e consumer eventi che sono in ascolto degli eventi.

Gli eventi vengono recapitati praticamente in tempo reale, in modo che i consumer possano rispondervi immediatamente non appena si verificano. I produttori sono separati dai consumatori: un produttore non sa quali consumatori sono in ascolto. Anche i consumer sono separati tra loro e ognuno visualizza tutti gli eventi. Questo comportamento differisce da un modello con consumer concorrenti, in cui i consumer eseguono il pull di messaggi da una coda e un messaggio viene elaborato solo una volta (presupponendo l'assenza di errori). In alcuni sistemi, ad esempio IoT, gli eventi devono essere inseriti a volumi molto elevati.

Un'architettura basata su eventi può usare un modello di pubblicazione/sottoscrizione (detto anche pub/sub) o un modello di flusso di eventi.

• Pubblicazione/sottoscrizione: l'infrastruttura di messaggistica tiene traccia delle sottoscrizioni. Quando viene pubblicato un evento, il modello lo invia a ogni sottoscrittore. Dopo la ricezione di un evento, non può essere riprodotto e i nuovi sottoscrittori non visualizzano l'evento.

• Flusso di eventi: gli eventi vengono scritti in un log. Gli eventi sono rigorosamente ordinati (in una partizione) e durevoli. I client non sottoscrivono il flusso, ma un client può invece leggere da qualsiasi parte del flusso. Il client è responsabile di far avanzare la propria posizione nel flusso. Questo significa che un client può aggiungersi in qualsiasi momento e può riprodurre gli eventi.

Sul lato consumer si applicano alcune variazioni comuni:

• Elaborazione semplice degli eventi. Un evento attiva immediatamente un'azione nel consumer. Ad esempio, è possibile usare Funzioni di Azure con un trigger del bus di servizio, in modo da eseguire una funzione ogni volta che viene pubblicato un messaggio in un argomento del bus di servizio.

• Correlazione di eventi di base. Un consumer deve elaborare un numero ridotto di eventi aziendali discreti, in genere correlati da un identificatore, per rendere persistenti alcune informazioni degli eventi precedenti da usare durante l'elaborazione di eventi successivi. Questo modello è supportato da librerie come NServiceBus e MassTransit.

• Elaborazione complessa degli eventi. Un consumer elabora una serie di eventi, cercando modelli nei dati degli eventi, usando una tecnologia come Analisi di flusso di Azure. Ad esempio, è possibile aggregare letture da un dispositivo incorporato in base a un intervallo di tempo e quindi generare una notifica se la media mobile supera una determinata soglia.

• Elaborazione di flussi di eventi. Usare una piattaforma di flussi di dati, come l'hub IoT di Azure o Apache Kafka, come pipeline per inserire gli eventi e fornirli agli elaboratori di flussi. Gli elaboratori di flussi intervengono per elaborare o trasformare il flusso. Possono essere presenti più elaboratori di flussi per sottosistemi diversi nell'applicazione. Questo approccio è ideale per i carichi di lavoro IoT.

L'origine degli eventi può essere esterna al sistema, ad esempio può essere costituita da dispositivi fisici in una soluzione IoT. In questo caso, il sistema deve essere in grado di inserire i dati in base alla velocità effettiva e al volume richiesti dall'origine dati.

Nel diagramma logico precedente ogni tipo di consumer viene visualizzato come una singola casella. In pratica, è normale che siano presenti più istanze di un consumer, per evitare che il consumer diventi un singolo punto di guasto nel sistema. Potrebbero essere necessarie più istanze anche per gestire il volume e la frequenza degli eventi. Un singolo consumer potrebbe inoltre elaborare eventi in più thread. Questo può creare problemi se gli eventi devono essere elaborati in ordine o richiedono una semantica di una sola volta. Vedere Ridurre al minimo il coordinamento.

Quando usare questa architettura

• Più sottosistemi devono elaborare gli stessi eventi.
• Elaborazione in tempo reale con ritardo minimo.
• Elaborazione complessa degli eventi, ad esempio con criteri di ricerca o aggregazione in base a intervalli di tempo.
• Volume elevato e alta velocità dei dati, ad esempio in sistemi IoT.

Vantaggi

• I producer e i consumer sono separati.
• Nessuna integrazione da punto a punto. È facile aggiungere nuovi consumer al sistema.
• I consumer possono rispondere agli eventi immediatamente, non appena arrivano.
• Scalabilità e distribuzione elevate.
• I sottosistemi hanno viste indipendenti del flusso di eventi.

Sfide

• Recapito garantito. In alcuni sistemi, in particolare in scenari IoT, è essenziale garantire che gli eventi vengano recapitati.
• Elaborazione degli eventi in ordine o esattamente una volta. In genere, ogni tipo di consumer viene eseguito in più istanze, per motivi di resilienza e scalabilità. Ciò può creare una richiesta di verifica se gli eventi devono essere elaborati in ordine (all'interno di un tipo di consumer) o la logica di elaborazione dei messaggi idempotenti non viene implementata.
• Coordinamento dei messaggi tra i servizi. I processi aziendali spesso implicano la pubblicazione e la sottoscrizione di più servizi ai messaggi per ottenere un risultato coerente in un intero carico di lavoro. I modelli di flusso di lavoro, ad esempio il modello Coreografia e Saga Orchestration , possono essere usati per gestire in modo affidabile i flussi di messaggi tra vari servizi.

Considerazioni aggiuntive

• La quantità di dati da includere in un evento può essere una considerazione significativa che influisce sulle prestazioni e sui costi. L'inserimento di tutte le informazioni pertinenti necessarie per l'elaborazione nell'evento stesso può semplificare il codice di elaborazione e salvare ricerche aggiuntive. L'inserimento della quantità minima di informazioni in un evento, come solo un paio di identificatori, ridurrà il tempo di trasporto e i costi, ma richiede al codice di elaborazione di cercare eventuali informazioni aggiuntive necessarie. Per altre informazioni su questo argomento, vedere questo post di blog.
• Anche se una richiesta è visibile solo al componente di gestione delle richieste, gli eventi sono spesso visibili a più componenti in un carico di lavoro, anche se tali componenti non sono o non sono destinati a utilizzarli. Operare con una mentalità "presupporre la violazione", tenere presente quali informazioni includere negli eventi per evitare l'esposizione imprevista delle informazioni.

Risorse correlate

• Video di discussione della community sulle considerazioni sulla scelta tra coreografia e orchestrazione.