Microservices avec base de données partagée? en utilisant plusieurs ORM?
J'apprends les microservices et je vais construire un projet avec une architecture de microservices.
Le fait est que l’un de mes coéquipiers souhaite utiliser une base de données pour tous les services, partageant toutes les tables de sorte que "les données ne se répètent pas", chaque service étant construit avec différents frameworks et langages comme Django et Rails qui utilisent des normes ORM très différentes.
Quelle serait la bonne approche? Puisque je pense que travailler avec une base de données impliquerait beaucoup de "piratage" des ORM afin de les faire fonctionner correctement.
Vous ne bénéficierez probablement pas d'une architecture Microservices si tous les services partagent les mêmes tables de base de données. En effet, vous associez efficacement les services. Si une table de base de données change, tous les services devront être modifiés.
Vous devez comprendre que toute l’architecture de Microservices a pour but de réduire les dépendances entre les équipes de développement et de leur permettre d’avancer de manière indépendante avec des versions rapides.
Voici une citation de Werner Vogels, le CTO d'Amazon (Amazon a mis au point de nombreuses architectures de style Microservices):
Pour nous, orientation service signifie encapsuler les données avec la logique métier qui les exploite, avec le seul accès possible via une interface de service publiée. Aucun accès direct à la base de données n’est autorisé en dehors du service et il n’ya pas de partage de données entre les services.
En général, un microservice devrait être responsable de ses propres données. C'est un scénario mondial parfait.
En pratique, certains des services peuvent être étroitement liés les uns aux autres. Par exemple. Les services CustomerShippingDetails et CustomerShoppingCheckout peuvent tous deux accéder aux mêmes données, à savoir l'adresse du client. Comment pouvez-vous alors résoudre un problème de fourniture d'adresse client au service de paiement client? Si le service de paiement interroge directement les détails des achats, vous rompez tout couplage entre les services. Une autre option consiste à introduire une base de données partagée.
Il devra toujours y avoir une sorte de compromis sur l’architecture. Ce qui est sacrifié, c'est une décision architecturale qui dépend fortement de la vue d'ensemble (la conception de l'ensemble du système).
N'ayant pas trop de détails sur votre système, j'adopterais une approche mixte. En d'autres termes, disposer d'une base de données partagée pour les services prenant en charge une logique métier similaire. Ainsi, CustomerShippingDetails et CustomerShoppingCheckout peuvent partager une base de données. Mais un StoreItemsDetails aurait une base de données séparée.
Pour en savoir plus sur le modèle de base de données partagée pour microservices, consultez Microservice Architecture .