Modello di origine evento

Il pattern di approvvigionamento degli eventi viene in genere utilizzato per Modello CQRS separare i carichi di lavoro di lettura da quelli di scrittura e ottimizzare le prestazioni, la scalabilità e la sicurezza. I dati vengono archiviati come una serie di eventi, anziché come aggiornamenti diretti agli archivi dati. I microservizi riproducono gli eventi da un archivio eventi per calcolare lo stato appropriato dei propri archivi di dati. Il modello fornisce visibilità sullo stato corrente dell'applicazione e un contesto aggiuntivo sul modo in cui l'applicazione è arrivata a quello stato. Il pattern di origine degli eventi funziona in modo efficace con il pattern CQRS perché i dati possono essere riprodotti per un evento specifico, anche se gli archivi di dati di comando e query hanno schemi diversi.

Scegliendo questo modello, è possibile identificare e ricostruire lo stato dell'applicazione in qualsiasi momento. Ciò produce una traccia di controllo persistente e semplifica il debug. Tuttavia, alla fine i dati diventano coerenti e ciò potrebbe non essere appropriato per alcuni casi d'uso.

Questo modello può essere implementato utilizzando Amazon Kinesis Data Streams EventBridge o Amazon.

Implementazione di Amazon Kinesis Data Streams

Nella figura seguente, Kinesis Data Streams è il componente principale di un archivio eventi centralizzato. L'event store acquisisce le modifiche delle applicazioni come eventi e le memorizza in modo persistente su Amazon Simple Storage Service (Amazon S3).

Il flusso di lavoro consiste nei seguenti passaggi:

1. Quando i microservizi «/withdraw» o «/credit» subiscono una modifica dello stato dell'evento, pubblicano un evento scrivendo un messaggio in Kinesis Data Streams.

2. Altri microservizi, come «/balance» o «/CreditLimit», leggono una copia del messaggio, lo filtrano in base alla pertinenza e lo inoltrano per un'ulteriore elaborazione.

EventBridge Implementazione Amazon

L'architettura nella figura seguente utilizza EventBridge. EventBridge è un servizio serverless che utilizza gli eventi per connettere i componenti dell'applicazione, il che semplifica la creazione di applicazioni scalabili e basate sugli eventi. L'architettura basata sugli eventi è uno stile di creazione di sistemi software liberamente accoppiati che interagiscono emettendo e rispondendo agli eventi. EventBridge fornisce un bus di eventi predefinito per gli eventi pubblicati dai AWS servizi ed è inoltre possibile creare un bus di eventi personalizzato per bus specifici del dominio.

Il flusso di lavoro consiste nei seguenti passaggi:

1. gli eventi OrderPlaced "" vengono pubblicati dal microservizio «Ordini» nel bus eventi personalizzato.

2. I microservizi che devono intervenire dopo l'invio di un ordine, come il microservizio «/route», vengono avviati da regole e obiettivi.

3. Questi microservizi generano un percorso per spedire l'ordine al cliente ed emettono un evento "». RouteCreated

4. I microservizi che richiedono ulteriori azioni vengono inoltre avviati dall'evento "». RouteCreated

5. Gli eventi vengono inviati a un archivio di eventi (ad esempio, EventBridge archivio) in modo che possano essere riprodotti per essere rielaborati, se necessario.

6. Gli eventi storici degli ordini vengono inviati a una nuova coda Amazon SQS (coda di replay) per la rielaborazione, se necessario.

7. Se gli obiettivi non vengono avviati, gli eventi interessati vengono inseriti in una coda di lettere morte (DLQ) per ulteriori analisi e rielaborazioni.

Dovresti prendere in considerazione l'utilizzo di questo modello se:

• Gli eventi vengono utilizzati per ricostruire completamente lo stato dell'applicazione.

• È necessario che gli eventi vengano riprodotti nel sistema e che lo stato dell'applicazione possa essere determinato in qualsiasi momento.

• Volete essere in grado di annullare eventi specifici senza dover iniziare con uno stato dell'applicazione vuoto.

• Il sistema richiede un flusso di eventi che possa essere facilmente serializzato per creare un registro automatico.

• Il sistema richiede operazioni di lettura complesse ma richiede poche operazioni di scrittura; le operazioni di lettura più complesse possono essere indirizzate a un database in memoria, che viene mantenuto aggiornato con il flusso di eventi.

Importante

Se si utilizza lo schema di sourcing degli eventi, è necessario Sagamodello implementarlo per mantenere la coerenza dei dati tra i microservizi.