Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
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:
-
Quando i microservizi «/withdraw» o «/credit» subiscono una modifica dello stato dell'evento, pubblicano un evento scrivendo un messaggio in Kinesis Data Streams.
-
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:
-
gli eventi OrderPlaced "" vengono pubblicati dal microservizio «Ordini» nel bus eventi personalizzato.
-
I microservizi che devono intervenire dopo l'invio di un ordine, come il microservizio «/route», vengono avviati da regole e obiettivi.
-
Questi microservizi generano un percorso per spedire l'ordine al cliente ed emettono un evento "». RouteCreated
-
I microservizi che richiedono ulteriori azioni vengono inoltre avviati dall'evento "». RouteCreated
-
Gli eventi vengono inviati a un archivio di eventi (ad esempio, EventBridge archivio) in modo che possano essere riprodotti per essere rielaborati, se necessario.
-
Gli eventi storici degli ordini vengono inviati a una nuova coda Amazon SQS (coda di replay) per la rielaborazione, se necessario.
-
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.
