atabase-per-service Motif en D

Le couplage souple est la principale caractéristique d'une architecture de microservices, car chaque microservice peut indépendamment stocker et récupérer des informations à partir de son propre magasin de données. En déployant le database-per-service modèle, vous choisissez les magasins de données les plus appropriés (par exemple, des bases de données relationnelles ou non relationnelles) pour votre application et les besoins de votre entreprise. Cela signifie que les microservices ne partagent pas de couche de données, que les modifications apportées à la base de données individuelle d'un microservice n'ont aucune incidence sur les autres microservices, que les banques de données individuelles ne sont pas directement accessibles par d'autres microservices et que les données persistantes ne sont accessibles que par les API. Le découplage des magasins de données améliore également la résilience de l'ensemble de votre application et garantit qu'une base de données unique ne peut pas être un point de défaillance unique.

Dans l'illustration suivante, différentes AWS bases de données sont utilisées par les microservices « Ventes », « Client » et « Conformité ». Ces microservices sont déployés sous forme de AWS Lambda fonctions et accessibles via une API Amazon API Gateway. AWS Identity and Access Management Les politiques (IAM) garantissent que les données restent privées et ne sont pas partagées entre les microservices. Chaque microservice utilise un type de base de données qui répond à ses exigences individuelles ; par exemple, « Sales » utilise Amazon Aurora, « Customer » utilise Amazon DynamoDB et « Compliance » utilise Amazon Relational Database Service (Amazon RDS) pour SQL Server.

Vous devriez envisager d'utiliser ce modèle si :

• Un couplage souple est nécessaire entre vos microservices.

• Les microservices ont des exigences de conformité ou de sécurité différentes pour leurs bases de données.

• Un contrôle plus précis de la mise à l'échelle est nécessaire.

L'utilisation du database-per-service modèle présente les inconvénients suivants :

• Il peut être difficile de mettre en œuvre des transactions et des requêtes complexes couvrant plusieurs microservices ou magasins de données.

• Vous devez gérer plusieurs bases de données relationnelles et non relationnelles.

• Vos magasins de données doivent répondre à deux des exigences du théorème CAP : cohérence, disponibilité ou tolérance de partition.

Note

Si vous utilisez le database-per-service modèle, vous devez déployer le Modèle de composition de l'API ou le Motif CQRS pour implémenter des requêtes couvrant plusieurs microservices.