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à. # Modelli per abilitare la persistenza dei dati I modelli seguenti vengono utilizzati per abilitare la persistenza dei dati nei microservizi. **Topics** + [ # Database-per-service modello ](database-per-service.md) + [ # Modello di composizione delle API ](api-composition.md) + [ # Modello CQRS ](cqrs-pattern.md) + [ # Modello di origine evento ](service-per-team.md) + [ # Sagamodello ](saga-pattern.md) + [ # Shared-database-per-service modello ](shared-database.md) # Database-per-service modello L'accoppiamento libero è la caratteristica principale di un'architettura di microservizi, poiché ogni singolo microservizio può archiviare e recuperare informazioni in modo indipendente dal proprio archivio dati. Implementando il database-per-service pattern, si scelgono gli archivi di dati più appropriati (ad esempio database relazionali o non relazionali) per le applicazioni e i requisiti aziendali. Ciò significa che i microservizi non condividono un livello di dati, le modifiche al database individuale di un microservizio non influiscono sugli altri microservizi, i singoli archivi dati non sono accessibili direttamente da altri microservizi e i dati persistenti sono accessibili solo da. APIs Il disaccoppiamento degli archivi dati migliora anche la resilienza dell'intera applicazione e garantisce che un singolo database non possa essere un singolo punto di errore. Nella figura seguente, i microservizi «Vendite», «Clienti» e «Conformità» utilizzano diversi AWS database. Questi microservizi vengono distribuiti come AWS Lambda funzioni e vi si accede tramite un'API Amazon API Gateway. AWS Identity and Access Management Le policy (IAM) garantiscono che i dati siano mantenuti privati e non condivisi tra i microservizi. Ogni microservizio utilizza un tipo di database che soddisfa i suoi requisiti individuali; ad esempio, «Sales» utilizza Amazon Aurora, «Customer» utilizza Amazon DynamoDB e «Compliance» utilizza Amazon Relational Database Service (Amazon RDS) per SQL Server. ![\[Database-per-service diagramma del modello\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram1.png) Dovresti prendere in considerazione l'utilizzo di questo modello se: + È necessario un accoppiamento libero tra i microservizi. + I microservizi hanno requisiti di conformità o sicurezza diversi per i loro database. + È necessario un controllo più granulare della scalabilità. L'utilizzo del pattern presenta i seguenti svantaggi: database-per-service + Potrebbe essere difficile implementare transazioni e query complesse che si estendono su più microservizi o archivi di dati. + È necessario gestire più database relazionali e non relazionali. + *I tuoi archivi dati devono soddisfare due dei requisiti del [teorema CAP](https://www.ibm.com/cloud/learn/cap-theorem): *coerenza*, *disponibilità* o tolleranza delle partizioni.* **Nota** Se si utilizza il database-per-service pattern, è necessario implementare un altro pattern per implementare query che si estendono su più microservizi. È possibile utilizzare il [pattern [Modello di composizione delle API](api-composition.md) (che è possibile velocizzare[Modello CQRS](cqrs-pattern.md)) o l'event sourcing](service-per-team.md) per creare risultati aggregati. # Modello di composizione delle API Questo modello utilizza un compositore, o aggregatore di API, per implementare una query richiamando singoli microservizi proprietari dei dati. Quindi combina i risultati eseguendo un join in memoria. Il diagramma seguente illustra come viene implementato questo modello. ![\[Diagramma del modello di composizione delle API\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram2.png) Il diagramma mostra il flusso di lavoro seguente: 1. Un gateway API serve l'API «/customer», che dispone di un microservizio «Ordini» che tiene traccia degli ordini dei clienti in un database Aurora. 1. Il microservizio «Support» tiene traccia dei problemi di assistenza clienti e li archivia in un database Amazon OpenSearch Service. 1. Il microservizio CustomerDetails "" mantiene gli attributi del cliente (ad esempio, indirizzo, numero di telefono o dettagli di pagamento) in una tabella DynamoDB. 1. La funzione «GetCustomer» Lambda esegue APIs per questi microservizi ed esegue un join in memoria sui dati prima di restituirli al richiedente. Ciò consente di recuperare facilmente le informazioni sui clienti in una sola chiamata di rete all'API rivolta all'utente e mantiene l'interfaccia molto semplice. Il modello di composizione delle API offre il modo più semplice per raccogliere dati da più microservizi. Tuttavia, l'utilizzo del modello di composizione dell'API presenta i seguenti svantaggi: + Potrebbe non essere adatto per query complesse e set di dati di grandi dimensioni che richiedono join in memoria. + L'intero sistema diventa meno disponibile se si aumenta il numero di microservizi collegati all'API Composer. + L'aumento delle richieste di database crea più traffico di rete, con un conseguente aumento dei costi operativi. # Modello CQRS Il pattern CQRS (command query responsibility segregation) separa la mutazione dei dati, o la parte di comando di un sistema, dalla parte della query. È possibile utilizzare il pattern CQRS per separare gli aggiornamenti e le query se hanno requisiti diversi in termini di velocità effettiva, latenza o coerenza. Il pattern CQRS divide l'applicazione in due parti, il lato comando e il lato query, come illustrato nel diagramma seguente. Il lato comando gestisce e richiede. `create` `update` `delete` Il lato interrogazione esegue la `query` parte utilizzando le repliche di lettura. ![\[Vista di alto livello del pattern CQRS\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-data-persistence/images/cqrs.png) Il diagramma mostra il seguente processo: 1. L'azienda interagisce con l'applicazione inviando comandi tramite un'API. I comandi sono azioni come la creazione, l'aggiornamento o l'eliminazione di dati. 1. L'applicazione elabora il comando in entrata sul lato comando. Ciò comporta la convalida, l'autorizzazione e l'esecuzione dell'operazione. 1. L'applicazione mantiene i dati del comando nel database write (command). 1. Dopo l'archiviazione del comando nel database di scrittura, vengono attivati eventi per aggiornare i dati nel database read (query). 1. Il database read (query) elabora e mantiene i dati. I database di lettura sono progettati per essere ottimizzati per requisiti di interrogazione specifici. 1. L'azienda interagisce con la lettura APIs per inviare domande al lato query dell'applicazione. 1. L'applicazione elabora la query in entrata sul lato della query e recupera i dati dal database di lettura. È possibile implementare il pattern CQRS utilizzando varie combinazioni di database, tra cui: + Utilizzo dei database del sistema di gestione dei database relazionali (RDBMS) sia per il lato dei comandi che per quello delle interrogazioni. Le operazioni di scrittura vanno al database principale e le operazioni di lettura possono essere indirizzate alle repliche di lettura. Esempio: repliche di [lettura di Amazon RDS](https://aws.amazon.com/rds/features/read-replicas/) + Utilizzo di un database RDBMS per il lato comando e un database NoSQL per il lato query. Esempio: [modernizza i database legacy utilizzando](https://aws.amazon.com/blogs/database/modernize-legacy-databases-using-event-sourcing-and-cqrs-with-aws-dms/) l'event sourcing e CQRS con AWS DMS + Utilizzo di database NoSQL sia per il lato dei comandi che per quello delle query. Esempio: [crea un archivio di eventi CQRS con Amazon](https://aws.amazon.com/blogs/database/build-a-cqrs-event-store-with-amazon-dynamodb/) DynamoDB + Utilizzo di un database NoSQL per il lato comando e un database RDBMS per il lato query, come illustrato nell'esempio seguente. Nella figura seguente, un data store NoSQL, come DynamoDB, viene utilizzato per ottimizzare la velocità di scrittura e fornire funzionalità di interrogazione flessibili. Ciò consente di ottenere un'elevata scalabilità di scrittura su carichi di lavoro con schemi di accesso ben definiti quando si aggiungono dati. Un database relazionale, come Amazon Aurora, offre funzionalità di interrogazione complesse. Un flusso DynamoDB invia dati a una funzione Lambda che aggiorna la tabella Aurora. ![\[Pattern CQRS implementato con i servizi AWS\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram3.png) L'implementazione del pattern CQRS con DynamoDB e Aurora offre questi vantaggi chiave: + DynamoDB è un database NoSQL completamente gestito in grado di gestire operazioni di scrittura ad alto volume e Aurora offre un'elevata scalabilità di lettura per query complesse sul lato delle query. + DynamoDB offre un accesso ai dati a bassa latenza e ad alto throughput, il che lo rende ideale per la gestione di operazioni di comando e aggiornamento, mentre le prestazioni di Aurora possono essere ottimizzate e ottimizzate per query complesse. + Sia DynamoDB che Aurora offrono opzioni serverless, che consentono alle aziende di pagare le risorse solo in base all'utilizzo. + DynamoDB e Aurora sono servizi completamente gestiti, che riducono il carico operativo di gestione di database, backup e scalabilità. È consigliabile prendere in considerazione l'utilizzo del pattern CQRS se: + Hai implementato il database-per-service modello e desideri unire i dati di più microservizi. + I tuoi carichi di lavoro di lettura e scrittura hanno requisiti separati di scalabilità, latenza e coerenza. + La coerenza finale è accettabile per le query di lettura. **Importante** Il pattern CQRS si traduce in genere in una eventuale coerenza tra gli archivi di dati. # Modello di origine evento Il pattern di approvvigionamento degli eventi viene in genere utilizzato per [Modello CQRS](cqrs-pattern.md) 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 su come 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). ![\[Implementazione di Amazon Kinesis Data Streams\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram4.png) 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. 1. 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](https://docs.aws.amazon.com//eventbridge/latest/userguide/create-event-bus.html) per gli eventi pubblicati dai AWS servizi ed è inoltre possibile creare un bus di eventi [personalizzato](https://docs.aws.amazon.com//eventbridge/latest/userguide/create-event-bus.html) per bus specifici del dominio. ![\[EventBridge Implementazione Amazon\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram5.png) Il flusso di lavoro consiste nei seguenti passaggi: 1. gli eventi OrderPlaced "" vengono pubblicati dal microservizio «Ordini» nel bus eventi personalizzato. 1. I microservizi che devono intervenire dopo l'invio di un ordine, come il microservizio «/route», vengono avviati da regole e obiettivi. 1. Questi microservizi generano un percorso per spedire l'ordine al cliente ed emettono un evento "». RouteCreated 1. I microservizi che richiedono ulteriori azioni vengono inoltre avviati dall'evento "». RouteCreated 1. Gli eventi vengono inviati a un archivio di eventi (ad esempio, EventBridge archivio) in modo che possano essere riprodotti per essere rielaborati, se necessario. 1. Gli eventi storici degli ordini vengono inviati a una nuova coda Amazon SQS (coda di replay) per la rielaborazione, se necessario. 1. 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](saga-pattern.md) implementarlo per mantenere la coerenza dei dati tra i microservizi. # Sagamodello Il saga pattern è un modello di gestione degli errori che aiuta a stabilire la coerenza nelle applicazioni distribuite e coordina le transazioni tra più microservizi per mantenere la coerenza dei dati. Un microservizio pubblica un evento per ogni transazione e la transazione successiva viene avviata in base al risultato dell'evento. Può seguire due percorsi diversi, a seconda del successo o del fallimento delle transazioni. La seguente illustrazione mostra come il saga modello implementa un sistema di elaborazione degli ordini utilizzando. AWS Step Functions Ogni fase (ad esempio «ProcessPayment») prevede anche passaggi separati per gestire il successo (ad esempio, "UpdateCustomerAccount«) o il fallimento (ad esempio," SetOrderFailure «) del processo. ![\[Sagamodello\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram6.png) Dovresti prendere in considerazione l'utilizzo di questo modello se: + L'applicazione deve mantenere la coerenza dei dati su più microservizi senza un collegamento stretto. + Esistono transazioni di lunga durata e non si desidera che altri microservizi vengano bloccati se un microservizio viene eseguito per un lungo periodo di tempo. + È necessario essere in grado di eseguire il rollback se un'operazione non riesce nella sequenza. **Importante** È difficile eseguire il debug del saga pattern e la sua complessità aumenta con il numero di microservizi. Il pattern richiede un modello di programmazione complesso che sviluppi e progetti transazioni compensative per il rollback e l'annullamento delle modifiche. Per ulteriori informazioni sull'implementazione del saga pattern in un'architettura di microservizi, consulta il pattern [Implementare il pattern serverless using AWS Step Functions sul sito Web saga Prescriptive](https://docs.aws.amazon.com//prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html) Guidance. AWS # Shared-database-per-service modello Nello shared-database-per-service schema, lo stesso database è condiviso da diversi microservizi. È necessario valutare attentamente l'architettura dell'applicazione prima di adottare questo modello e assicurarsi di evitare le hot table (tabelle singole su cui scrivono più microservizi). Tutte le modifiche al database devono inoltre essere compatibili con le versioni precedenti; ad esempio, gli sviluppatori possono eliminare colonne o tabelle solo se agli oggetti non fanno riferimento la versione corrente e precedente di tutti i microservizi. Nella figura seguente, un database assicurativo è condiviso da tutti i microservizi e una policy IAM fornisce l'accesso al database. Ciò crea un accoppiamento dei tempi di sviluppo; ad esempio, una modifica nel microservizio «Vendite» deve coordinare le modifiche allo schema con il microservizio «Cliente». Questo modello non riduce le dipendenze tra i team di sviluppo e introduce l'accoppiamento in fase di esecuzione perché tutti i microservizi condividono lo stesso database. Ad esempio, le transazioni «Vendite» di lunga durata possono bloccare la tabella «Cliente» e ciò blocca le transazioni «Clienti». ![\[Shared-database-per-service modello\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram7.png) Dovresti prendere in considerazione l'utilizzo di questo modello se: + Non vuoi rifattorizzare troppo la tua base di codice esistente. + Implementate la coerenza dei dati utilizzando transazioni che garantiscono atomicità, coerenza, isolamento e durabilità (ACID). + Vuoi mantenere e gestire un solo database. + L'implementazione del database-per-service modello è difficile a causa delle interdipendenze tra i microservizi esistenti. + Non vuoi riprogettare completamente il tuo livello di dati esistente.