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à.
Scomponi i monoliti in microservizi utilizzando CQRS e l'event sourcing
Creato da Rodolfo Jr. Cerrada (AWS), Dmitry Gulin (AWS) e Tabby Ward (AWS)
Riepilogo
Questo modello combina due modelli, utilizzando sia il pattern Command Query Responsibility Separation (CQRS) sia il pattern di event sourcing. Il pattern CQRS separa le responsabilità dei modelli di comando e di interrogazione. Il pattern di approvvigionamento degli eventi sfrutta la comunicazione asincrona basata sugli eventi per migliorare l'esperienza utente complessiva.
Puoi utilizzare i servizi CQRS e Amazon Web Services (AWS) per mantenere e scalare ogni modello di dati in modo indipendente, rifattorizzando al contempo la tua applicazione monolitica in un'architettura di microservizi. È quindi possibile utilizzare il pattern di approvvigionamento degli eventi per sincronizzare i dati dal database dei comandi al database delle query.
Questo modello utilizza un codice di esempio che include un file di soluzione (*.sln) che è possibile aprire utilizzando l'ultima versione di Visual Studio. L'esempio contiene il codice API Reward per mostrare come funzionano CQRS e l'event sourcing nelle applicazioni serverless e tradizionali o locali di AWS.
Prerequisiti e limitazioni
Prerequisiti
Un account AWS attivo
Amazon CloudWatch
Tabelle Amazon DynamoDB
Amazon DynamoDB Streams
Chiave di accesso e chiave segreta di AWS Identity and Access Management (IAM); per ulteriori informazioni, guarda il video nella sezione Risorse correlate
AWS Lambda
Familiarità con Visual Studio
Familiarità con AWS Toolkit for Visual Studio; per ulteriori informazioni, guarda il video dimostrativo di AWS Toolkit for Visual Studio nella sezione Risorse correlate
Versioni del prodotto
.NET Core 3.1. Questo componente è un'opzione nell'installazione di Visual Studio. Per includere.NET Core durante l'installazione, seleziona lo sviluppo multipiattaforma NET Core.
Limitazioni
Il codice di esempio per un'applicazione locale tradizionale (API Web ASP.NET Core e oggetti di accesso ai dati) non viene fornito con un database. Tuttavia, viene fornito con l'oggetto
CustomerDatain memoria, che funge da database fittizio. Il codice fornito è sufficiente per testare il modello.
Architettura
Stack di tecnologia di origine
Progetto API Web ASP.NET Core
Server Web IIS
Oggetto di accesso ai dati
Modello CRUD
Architettura di origine
Nell'architettura di origine, il modello CRUD contiene interfacce di comando e di interrogazione in un'unica applicazione. Per un esempio di codice, vedere CustomerDAO.cs (allegato).
Stack tecnologico Target
Amazon DynamoDB
Amazon DynamoDB Streams
AWS Lambda
(Opzionale) Amazon API Gateway
(Opzionale) Amazon Simple Notification Service (Amazon SNS)
Architettura Target
Nell'architettura di destinazione, le interfacce di comando e di interrogazione sono separate. L'architettura mostrata nel diagramma seguente può essere estesa con API Gateway e Amazon SNS. Per ulteriori informazioni, consulta la sezione Informazioni aggiuntive.
Le funzioni Command Lambda eseguono operazioni di scrittura, come creare, aggiornare o eliminare, sul database.
Le funzioni Query Lambda eseguono operazioni di lettura, come get o select, sul database.
Questa funzione Lambda elabora i flussi DynamoDB dal database Command e aggiorna il database Query per le modifiche.
Strumenti
Strumenti
Amazon DynamoDB — Amazon DynamoDB è un servizio di database NoSQL completamente gestito che offre prestazioni veloci e prevedibili con una scalabilità perfetta.
Amazon DynamoDB Streams — DynamoDB Streams acquisisce una sequenza ordinata nel tempo di modifiche a livello di elemento in qualsiasi tabella DynamoDB. Quindi memorizza queste informazioni in un registro per un massimo di 24 ore. La crittografia a riposo crittografa i dati in DynamoDB Streams.
AWS Lambda: AWS Lambda è un servizio di elaborazione che supporta l'esecuzione di codice senza effettuare il provisioning o la gestione di server. Lambda esegue il codice solo quando è necessario e si dimensiona automaticamente, da poche richieste al giorno a migliaia al secondo. Verrà addebitato soltanto il tempo di calcolo consumato e non verrà addebitato alcun costo quando il codice non è in esecuzione.
Console di gestione AWS: la Console di gestione AWS è un'applicazione Web che comprende un'ampia raccolta di console di servizio per la gestione dei servizi AWS.
Visual Studio 2019 Community Edition
— Visual Studio 2019 è un ambiente di sviluppo integrato (IDE). La Community Edition è gratuita per i contributori open source. In questo modello, utilizzerai Visual Studio 2019 Community Edition per aprire, compilare ed eseguire codice di esempio. Solo per la visualizzazione, puoi utilizzare qualsiasi editor di testo o Visual Studio Code. AWS Toolkit for Visual Studio — AWS Toolkit for Visual Studio è un plug-in per l'IDE di Visual Studio. AWS Toolkit for Visual Studio semplifica lo sviluppo, il debug e la distribuzione di applicazioni.NET che utilizzano i servizi AWS.
Codice
Il codice di esempio è allegato. Per istruzioni sulla distribuzione del codice di esempio, consulta la sezione Epics.
Poemi epici
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Aprire la soluzione. |
| Sviluppatore di app |
Crea la soluzione. | Apri il menu contestuale (fai clic con il pulsante destro del mouse) per la soluzione, quindi scegli Crea soluzione. Questo creerà e compilerà tutti i progetti della soluzione. Dovrebbe essere compilato correttamente. Visual Studio Solution Explorer dovrebbe mostrare la struttura delle cartelle.
| Sviluppatore di app |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Fornire le credenziali. | Se non disponi ancora di una chiave di accesso, guarda il video nella sezione Risorse correlate.
| Sviluppatore di app, ingegnere dei dati, DBA |
Compilare il progetto. | Per creare il progetto, apri il menu contestuale (fai clic con il pulsante destro del mouse) per il progetto aws.apg.cqrses.BUILD, quindi scegli Build. | Sviluppatore di app, ingegnere dei dati, DBA |
Crea e popola le tabelle. | Per creare le tabelle e popolarle con i dati iniziali, apri il menu contestuale (fai clic con il pulsante destro del mouse) per il progetto aws.apg.cqrses.Build, quindi scegli Debug, Avvia nuova istanza. | Sviluppatore di app, ingegnere dei dati, DBA |
Verifica la struttura della tabella e i dati. | Per verificare, accedi ad AWS Explorer ed espandi Amazon DynamoDB. Dovrebbe visualizzare le tabelle. Apri ogni tabella per visualizzare i dati di esempio. | Sviluppatore di app, ingegnere dei dati, DBA |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Costruisci il progetto CQRS. |
| Sviluppatore di app, tecnico di test |
Crea il progetto di event-sourcing. |
| Sviluppatore di app, tecnico di test |
Esegui i test. | Per eseguire tutti i test, scegliete Visualizza, Test Explorer, quindi scegliete Esegui tutti i test in visualizzazione. Tutti i test devono essere superati, come indicato da un'icona verde con un segno di spunta. | Sviluppatore di app, tecnico di test |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Pubblica la prima funzione Lambda. |
| Sviluppatore di app, DevOps ingegnere |
Verifica il caricamento della funzione. | (Facoltativo) Puoi verificare che la funzione sia stata caricata correttamente accedendo ad AWS Explorer ed espandendo AWS Lambda. Per aprire la finestra di test, scegliete la funzione Lambda (doppio clic). | Sviluppatore di app, ingegnere DevOps |
Prova la funzione Lambda. |
Tutti i progetti CQRS Lambda si trovano nelle cartelle | Sviluppatore di app, DevOps ingegnere |
Pubblica le funzioni rimanenti. | Ripetete i passaggi precedenti per i seguenti progetti:
| Sviluppatore di app, DevOps ingegnere |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Pubblica i gestori di eventi Customer and Reward Lambda. | Per pubblicare ogni gestore di eventi, segui i passaggi dell'epopea precedente. I progetti si trovano nelle cartelle | Sviluppatore di app |
Collega il listener di eventi Lambda event-sourcing. |
Dopo che il listener è stato collegato correttamente alla tabella DynamoDB, verrà visualizzato nella pagina di progettazione Lambda. | Sviluppatore di app |
Pubblica e allega la funzione EventSourceReward Lambda. | Per pubblicare e allegare la funzione | Sviluppatore di app |
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Prova lo stream e il trigger Lambda. |
| Sviluppatore di app |
Convalida utilizzando la tabella delle query di ricompensa di DynamodDB. |
| Sviluppatore di app |
Convalida, utilizzando i registri. CloudWatch |
| Sviluppatore di app |
Convalida il trigger. EventSourceCustomer | Per convalidare il | Sviluppatore di app |
Risorse correlate
Riferimenti
Video
Informazioni aggiuntive
CQRS e sourcing di eventi
CQRS
Il pattern CQRS separa un singolo modello di operazioni concettuali, ad esempio un modello CRUD (create, read, update, delete) a oggetti di accesso ai dati, in modelli di operazioni di comando e interrogazione. Il modello di comando si riferisce a qualsiasi operazione, come la creazione, l'aggiornamento o l'eliminazione, che modifica lo stato. Il modello di interrogazione si riferisce a qualsiasi operazione che restituisce un valore.
Il modello Customer CRUD include le seguenti interfacce:
Create Customer()UpdateCustomer()DeleteCustomer()AddPoints()RedeemPoints()GetVIPCustomers()GetCustomerList()GetCustomerPoints()
Man mano che le tue esigenze diventano più complesse, puoi passare da questo approccio a modello singolo. CQRS utilizza un modello di comandi e un modello di interrogazione per separare la responsabilità della scrittura e della lettura dei dati. In questo modo, i dati possono essere mantenuti e gestiti in modo indipendente. Con una chiara separazione delle responsabilità, i miglioramenti apportati a ciascun modello non influiscono sull'altro. Questa separazione migliora la manutenzione e le prestazioni e riduce la complessità dell'applicazione man mano che cresce.
Interfacce nel modello Customer Command:
Create Customer()UpdateCustomer()DeleteCustomer()AddPoints()RedeemPoints()
Interfacce nel modello Customer Query:
GetVIPCustomers()GetCustomerList()GetCustomerPoints()GetMonthlyStatement()
Per un esempio di codice, vedi Directory del codice sorgente.
Il pattern CQRS quindi disaccoppia il database. Questo disaccoppiamento porta alla totale indipendenza di ogni servizio, che è l'ingrediente principale dell'architettura dei microservizi.
Utilizzando CQRS nel cloud AWS, puoi ottimizzare ulteriormente ogni servizio. Ad esempio, puoi impostare diverse impostazioni di elaborazione o scegliere tra un microservizio serverless o basato su container. Puoi sostituire la memorizzazione nella cache locale con Amazon. ElastiCache Se disponi di un messaggio di pubblicazione/sottoscrizione locale, puoi sostituirlo con Amazon Simple Notification Service (Amazon SNS). Inoltre, puoi sfruttare pay-as-you-go i prezzi e l'ampia gamma di servizi AWS che paghi solo per ciò che usi.
CQRS include i seguenti vantaggi:
Scalabilità indipendente: ogni modello può avere la propria strategia di scalabilità adattata per soddisfare i requisiti e la domanda del servizio. Analogamente alle applicazioni ad alte prestazioni, la separazione di lettura e scrittura consente al modello di scalare in modo indipendente per soddisfare ogni esigenza. È inoltre possibile aggiungere o ridurre le risorse di elaborazione per soddisfare la richiesta di scalabilità di un modello senza influire sull'altro.
Manutenzione indipendente: la separazione dei modelli di query e comando migliora la manutenibilità dei modelli. È possibile apportare modifiche e miglioramenti al codice di un modello senza influire sull'altro.
Sicurezza: è più semplice applicare le autorizzazioni e le politiche a modelli separati per la lettura e la scrittura.
Letture ottimizzate: è possibile definire uno schema ottimizzato per le query. Ad esempio, è possibile definire uno schema per i dati aggregati e uno schema separato per le tabelle dei fatti.
Integrazione: CQRS si adatta bene ai modelli di programmazione basati su eventi.
Complessità gestita: la separazione in modelli di query e comandi è adatta a domini complessi.
Quando utilizzate CQRS, tenete presente le seguenti avvertenze:
Il pattern CQRS si applica solo a una parte specifica di un'applicazione e non all'intera applicazione. Se implementato in un dominio che non corrisponde al modello, può ridurre la produttività, aumentare i rischi e introdurre complessità.
Il pattern funziona meglio per i modelli utilizzati di frequente che presentano uno squilibrio nelle operazioni di lettura e scrittura.
Per le applicazioni che richiedono molta lettura, come i report di grandi dimensioni che richiedono tempo per l'elaborazione, CQRS offre la possibilità di selezionare il database giusto e creare uno schema per archiviare i dati aggregati. Ciò migliora il tempo di risposta di lettura e visualizzazione del report elaborando i dati del report una sola volta e scaricandoli nella tabella aggregata.
Per le applicazioni che richiedono molta scrittura, è possibile configurare il database per le operazioni di scrittura e consentire al comando microservice di scalare in modo indipendente quando la richiesta di scrittura aumenta. Per esempi, consulta and microservices.
AWS.APG.CQRSES.CommandRedeemRewardLambdaAWS.APG.CQRSES.CommandAddRewardLambda
Approvvigionamento di eventi
Il passaggio successivo consiste nell'utilizzare l'origine degli eventi per sincronizzare il database delle query quando viene eseguito un comando. Ad esempio, considerate i seguenti eventi:
Viene aggiunto un punto premio cliente che richiede l'aggiornamento dei punti premio totali o aggregati del cliente nel database delle query.
Il cognome di un cliente viene aggiornato nel database dei comandi, il che richiede l'aggiornamento delle informazioni sostitutive sul cliente contenute nel database delle query.
Nel modello CRUD tradizionale, si garantisce la coerenza dei dati bloccandoli fino al termine di una transazione. Nell'event sourcing, i dati vengono sincronizzati mediante la pubblicazione di una serie di eventi che verranno utilizzati da un abbonato per aggiornare i rispettivi dati.
Il modello di sourcing degli eventi garantisce e registra una serie completa di azioni intraprese sui dati e le pubblica attraverso una sequenza di eventi. Questi eventi rappresentano un insieme di modifiche ai dati che i sottoscrittori di quell'evento devono elaborare per mantenere aggiornato il proprio record. Questi eventi vengono utilizzati dal sottoscrittore, sincronizzando i dati nel database del sottoscrittore. In questo caso, si tratta del database delle interrogazioni.
Il diagramma seguente mostra il sourcing degli eventi utilizzato con CQRS su AWS.
Le funzioni Command Lambda eseguono operazioni di scrittura, come creare, aggiornare o eliminare, sul database.
Le funzioni Query Lambda eseguono operazioni di lettura, come get o select, sul database.
Questa funzione Lambda elabora i flussi DynamoDB dal database Command e aggiorna il database Query per le modifiche. Puoi utilizzare questa funzione anche per pubblicare un messaggio su Amazon SNS in modo che i suoi abbonati possano elaborare i dati.
(Facoltativo) L'abbonato all'evento Lambda elabora il messaggio pubblicato da Amazon SNS e aggiorna il database Query.
(Facoltativo) Amazon SNS invia una notifica e-mail dell'operazione di scrittura.
Su AWS, il database delle query può essere sincronizzato tramite DynamoDB Streams. DynamoDB acquisisce una sequenza ordinata nel tempo di modifiche a livello di elemento in una tabella DynamoDB quasi in tempo reale e archivia le informazioni in modo duraturo entro 24 ore.
L'attivazione di DynamoDB Streams consente al database di pubblicare una sequenza di eventi che rende possibile lo schema di sourcing degli eventi. Il pattern di origine degli eventi aggiunge il sottoscrittore dell'evento. L'applicazione Event Subscriber utilizza l'evento e lo elabora in base alla responsabilità del sottoscrittore. Nel diagramma precedente, il sottoscrittore dell'evento invia le modifiche al database Query DynamoDB per mantenere i dati sincronizzati. L'uso di Amazon SNS, del broker di messaggi e dell'applicazione Event Subscriber mantiene l'architettura disaccoppiata.
L'event sourcing include i seguenti vantaggi:
Coerenza per i dati transazionali
Una pista di controllo e una cronologia delle azioni affidabili, che possono essere utilizzate per monitorare le azioni intraprese nei dati
Consente alle applicazioni distribuite come i microservizi di sincronizzare i dati in tutto l'ambiente
Pubblicazione affidabile degli eventi ogni volta che lo stato cambia
Ricostruzione o riproduzione degli stati passati
Entità liberamente accoppiate che scambiano eventi per la migrazione da un'applicazione monolitica ai microservizi
Riduzione dei conflitti causati dagli aggiornamenti simultanei; l'event sourcing evita la necessità di aggiornare gli oggetti direttamente nell'archivio dati
Flessibilità ed estensibilità grazie al disaccoppiamento tra attività ed evento
Aggiornamenti di sistema esterni
Gestione di più attività in un unico evento
Quando utilizzi il sourcing degli eventi, tieni presente le seguenti avvertenze:
Poiché si verifica un certo ritardo nell'aggiornamento dei dati tra i database degli abbonati di origine, l'unico modo per annullare una modifica consiste nell'aggiungere un evento di compensazione all'archivio eventi.
L'implementazione dell'event sourcing presenta una curva di apprendimento a causa del suo diverso stile di programmazione.
Dati di test
Utilizza i seguenti dati di test per testare la funzione Lambda dopo una corretta implementazione.
CommandCreate Cliente
{ "Id":1501, "Firstname":"John", "Lastname":"Done", "CompanyName":"AnyCompany", "Address": "USA", "VIP":true }CommandUpdate Cliente
{ "Id":1501, "Firstname":"John", "Lastname":"Doe", "CompanyName":"Example Corp.", "Address": "Seattle, USA", "VIP":true }CommandDelete Cliente
Inserisci l'ID cliente come dati della richiesta. Ad esempio, se l'ID cliente è 151, inserisci 151 come dati della richiesta.
151
QueryCustomerList
Questo campo è vuoto. Quando viene richiamato, restituirà tutti i clienti.
CommandAddReward
Ciò aggiungerà 40 punti al cliente con ID 1 (Richard).
{
"Id":10101,
"CustomerId":1,
"Points":40
} CommandRedeemReward
In questo modo verranno detratti 15 punti dal cliente con ID 1 (Richard).
{
"Id":10110,
"CustomerId":1,
"Points":15
} QueryReward
Inserisci l'ID del cliente. Ad esempio, inserisci 1 per Richard, 2 per Arnav e 3 per Shirley.
2
Directory del codice sorgente
Usa la tabella seguente come guida alla struttura di directory della soluzione Visual Studio.
Directory della soluzione CQRS On-Premises Code Sample
Modello CRUD del cliente
Esempio di codice locale CQRS\ Modello CRUD\ Progetto AWS.APG.CQRSES.DAL
Versione CQRS del modello Customer CRUD
Comando cliente: progetto
CQRS On-Premises Code Sample\CQRS Model\Command Microservice\AWS.APG.CQRSES.CommandRichiesta del cliente:
CQRS On-Premises Code Sample\CQRS Model\Query Microservice\AWS.APG.CQRSES.Queryprogetto
Microservizi Command and Query
Il microservizio Command si trova nella cartella della soluzione: CQRS On-Premises Code Sample\CQRS Model\Command Microservice
AWS.APG.CQRSES.CommandMicroserviceIl progetto ASP.NET Core API funge da punto di ingresso in cui i consumatori interagiscono con il servizio.AWS.APG.CQRSES.CommandIl progetto.NET Core è un oggetto che ospita oggetti e interfacce relativi ai comandi.
Il microservizio di interrogazione si trova nella cartella della soluzione: CQRS On-Premises Code Sample\CQRS Model\Query Microservice
AWS.APG.CQRSES.QueryMicroserviceIl progetto ASP.NET Core API funge da punto di ingresso in cui i consumatori interagiscono con il servizio.AWS.APG.CQRSES.QueryIl progetto.NET Core è un oggetto che ospita oggetti e interfacce relativi alle query.
Directory di soluzioni di codice serverless CQRS AWS
Questo codice è la versione AWS del codice locale che utilizza i servizi serverless AWS.
In C# .NET Core, ogni funzione Lambda è rappresentata da un progetto.NET Core. Nel codice di esempio di questo pattern, esiste un progetto separato per ogni interfaccia nei modelli di comando e query.
CQRS che utilizza i servizi AWS
Puoi trovare la directory della soluzione principale per CQRS che utilizza i servizi serverless AWS nella CQRS AWS Serverless\CQRS cartella. L'esempio include due modelli: Customer e Reward.
Le funzioni di comando Lambda per Customer e Reward si trovano nelle cartelle CQRS\Command Microservice\Customer eCQRS\Command Microservice\Reward. Contengono i seguenti progetti Lambda:
Comando cliente:
CommandCreateLambdaCommandDeleteLambda, eCommandUpdateLambdaComando di ricompensa:
CommandAddRewardLambdaeCommandRedeemRewardLambda
Le funzioni di interrogazione Lambda per Customer e Reward si trovano nelle cartelle CQRS\Query Microservice\Customer andCQRS\QueryMicroservice\Reward. Contengono i progetti QueryCustomerListLambda e QueryRewardLambda Lambda.
Progetto di test CQRS
Il progetto di test si trova nella CQRS\Tests cartella. Questo progetto contiene uno script di test per automatizzare il test delle funzioni CQRS Lambda.
Approvvigionamento di eventi tramite i servizi AWS
I seguenti gestori di eventi Lambda vengono avviati dai flussi DynamoDB Customer e Reward per elaborare e sincronizzare i dati nelle tabelle di query.
La funzione
EventSourceCustomerLambda è mappata sul flussocqrses-customer-cmdDynamoDB della tabella Customer ().La funzione
EventSourceRewardLambda è mappata sul flussocqrses-reward-cmdDynamoDB della tabella Reward ().
Allegati
