Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Shared-database-per-service motif
Dans le shared-database-per-service modèle, la même base de données est partagée par plusieurs microservices. Vous devez évaluer soigneusement l'architecture de l'application avant d'adopter ce modèle et vous assurer d'éviter les hot tables (tables uniques partagées entre plusieurs microservices). Toutes les modifications apportées à votre base de données doivent également être rétrocompatibles ; par exemple, les développeurs peuvent supprimer des colonnes ou des tables uniquement si les objets ne sont pas référencés par les versions actuelles et précédentes de tous les microservices.
Dans l'illustration suivante, une base de données d'assurance est partagée par tous les microservices et une politique IAM permet d'accéder à la base de données. Cela crée un couplage des temps de développement ; par exemple, une modification du microservice « Ventes » doit coordonner les modifications du schéma avec le microservice « Client ». Ce modèle ne réduit pas les dépendances entre les équipes de développement et introduit le couplage d'exécution, car tous les microservices partagent la même base de données. Par exemple, les transactions « Ventes » de longue durée peuvent verrouiller la table « Client », bloquant ainsi les transactions « Client ».
Vous devriez envisager d'utiliser ce modèle si :
-
Vous ne voulez pas trop refactoriser votre base de code existante.
-
Vous renforcez la cohérence des données en utilisant des transactions garantissant l'atomicité, la cohérence, l'isolation et la durabilité (ACID).
-
Vous souhaitez gérer et exploiter une seule base de données.
-
La mise en œuvre du database-per-service modèle est difficile en raison des interdépendances entre vos microservices existants.
-
Vous ne souhaitez pas repenser complètement votre couche de données existante.
