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à.
Un modello hared-database-per-service
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 gli hot table (tabelle singole condivise tra 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».
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).
-
Desideri 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.
