Microservices: comment gérer les relations clés étrangères
L'architecture des Microservices suggère que chaque service devrait traiter ses propres données. Par conséquent, tout service (Service A) dépendant de données détenues par un autre service (service B) devrait accéder à ces données non pas en faisant des appels directs de type DB, mais par l'intermédiaire de l'api fournie par le second service (service B).
Qu'est-ce donc que les bonnes pratiques de microservices suggèrent sur la vérification des contraintes de clé étrangère.
exemple: je développe une fonction de livraison (microservice 1) pour les produits et certains produits ne sont livrables qu'à certains endroits comme indiqué dans le tableau des produits accessible uniquement aux produits micro-service (mircoservice 2).
Comment puis-je m'assurer que microservice 1 (I. E fonction de livraison) ne prend pas une commande à un endroit non desservi. J'ai cette question parce que la fonction de livraison ne peut pas accéder directement à la base de données des produits, de sorte qu'il n'y a pas de contraintes applicables AU NIVEAU DE LA BASE DE DONNÉES DE LIVRAISON LORSQU'un ordre de livraison est placé à la base de données de livraison (non il est possible de vérifier s'il existe une correspondance de clé étrangère dans la base de données ou la table des produits.
2 réponses
Il est possible d'utiliser une base de données partagée pour plusieurs microservices. Vous pouvez trouver des modèles pour la gestion des données de microservices dans ce lien: http://microservices.io/patterns/data/database-per-service.html. En passant, c'est un blog très utile pour les microservices architecture.
dans votre cas, vous préférez utiliser la base de données par motif de service. Cela rend les microservices plus autonomes. Dans cette situation, vous devriez dupliquer certaines de vos données parmi plusieurs microservices. Vous pouvez partager les données avec les appels d'api entre les microservices ou vous pouvez le partager avec async messagerie. Cela dépend de votre infrastructure et de la fréquence de changement des données. Si elle ne change pas souvent, vous devriez dupliquer les données avec des événements asynchrones.
dans votre exemple, le service de livraison peut dupliquer les lieux de livraison et les renseignements sur les produits. Service produit Gérer les produits et les emplacements. Ensuite, les données requises sont copiées dans la base de données du service de livraison avec messages async (par exemple, vous pouvez utiliser rabbit mq ou apache kafka). Le service de livraison ne modifie pas les données sur les produits et les emplacements, mais il utilise les données lorsqu'il fait son travail. Si la partie des données sur le produit qui est utilisée par le service de livraison change souvent, la duplication des données avec la messagerie asynchrone sera très coûteuse. Dans ce cas, vous devez faire des appels api entre le produit et le service de livraison. Le service de livraison demande au service produit de vérifier si un produit est livrable à un lieu ou pas. Service de livraison Demande produits service avec un identifiant (nom, id, etc.))) d'un produit et l'emplacement. Ces identificateurs peuvent être empruntés à l'utilisateur final ou partagés entre des microservices. Parce que les bases de données de microservices sont différentes ici, nous ne pouvons pas définir des clés étrangères entre les données de ces microservices.
appels Api peut-être plus facile à implémenter mais le coût du réseau est plus élevé dans cette option. De plus, vos services sont moins autonomes lorsque vous faites des appels api. Parce que, dans votre exemple, lorsque le service produit est en baisse, le service de livraison ne peut pas faire son travail. Si vous dupliquez les données avec la messagerie async, les données nécessaires pour effectuer la livraison est situé dans la base de données de livraison microservice. Lorsque le service Produit ne fonctionne pas, vous serez en mesure de faire la livraison.
lors de la distribution de votre code pour obtenir un couplage réduit, vous voulez éviter le partage de ressources, et les données sont une ressource que vous voulez éviter le partage.
un autre point est qu'un seul composant dans votre système possède les données (pour les opérations de changement d'état), d'autres composants peuvent lire mais pas écrire, ils peuvent avoir des copies des données ou vous pouvez partager un modèle de vue qu'ils peuvent utiliser pour obtenir l'état le plus récent d'un objet.
création de l'intégrité référentielle réintroduira coupler, à la place vous voulez utiliser quelque chose comme des Guids pour vos clés primaires, ils seront créés par le créateur de l'objet, le reste est tout au sujet de la gestion de la cohérence éventuelle.
jetez un oeil à l'Udi Dahan parlez-en à la SDN Oslo pour plus de détails
Espérons que cette aide