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à. # 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.