Microservices: comment gérer les relations de clé étrangère
L'architecture de Microservices suggère que chaque service doit gérer ses propres données. Par conséquent, tout service (service A) dépendant de données appartenant à un autre service (service B) devrait accéder à ces données non pas en effectuant des appels directs à la base de données, mais par l’intermédiaire de l’API fournie par le second service (service B).
Que suggèrent donc les meilleures pratiques de microservices pour vérifier les contraintes de clé étrangère?
Exemple: je développe une fonctionnalité de livraison (microservice 1) pour les produits et certains produits ne peuvent être livrés que dans certains emplacements, comme indiqué dans le tableau des produits accessible uniquement aux produits micro service (mircoservice 2).
Comment puis-je m'assurer que microservice 1 (c'est-à-dire la fonctionnalité de livraison) ne prend pas la commande dans un lieu non desservi? J'ai cette question parce que la fonctionnalité de livraison ne peut pas accéder directement à la base de données de produits, il n'y a donc aucune contrainte applicable au niveau de la base de données lorsqu'un bon de livraison est placé dans la base de données de livraison (aucune vérification n'est possible pour voir si une correspondance de clé étrangère existe dans la base de données de produits ou table).
Il est possible d'utiliser une base de données partagée pour plusieurs microservices. Vous pouvez trouver les modèles de gestion de données de microservices dans ce lien: http://microservices.io/patterns/data/database-per-service.html . À propos, c’est un blog très utile pour l’architecture de microservices.
Dans votre cas, vous préférez utiliser une base de données par modèle de service. Cela rend les microservices plus autonomes. Dans ce cas, vous devez dupliquer certaines de vos données sur plusieurs microservices. Vous pouvez partager les données avec des appels API entre microservices ou avec une messagerie asynchrone. Cela dépend de votre infrastructure et de la fréquence de changement des données. Si cela ne change pas souvent, vous devez dupliquer les données avec des événements asynchrones.
Dans votre exemple, le service de livraison peut dupliquer les emplacements de livraison et les informations sur le produit. Le service produit gère les produits et les emplacements. Les données requises sont ensuite copiées dans la base de données du service de livraison avec des messages asynchrones (vous pouvez par exemple utiliser rabbit mq ou Apache kafka). Le service de livraison ne modifie pas les données sur le produit et l'emplacement, mais il utilise les données pour effectuer son travail. Si la partie des données du produit utilisée par le service de livraison change souvent, la duplication de données avec la messagerie async sera très coûteuse. Dans ce cas, vous devez passer 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 emplacement spécifique ou non. Le service de livraison demande le service Produits avec un identifiant (nom, identifiant, etc.) d'un produit et d'un emplacement. Ces identifiants peuvent être empruntés à l'utilisateur final ou partagés entre microservices. Les bases de données des microservices étant différentes ici, nous ne pouvons pas définir de clés étrangères entre les données de ces microservices.
Les appels Api sont peut-être plus faciles à mettre en œuvre, mais le coût du réseau est plus élevé avec cette option. De plus, vos services sont moins autonomes lorsque vous passez des appels api. Parce que, dans votre exemple, lorsque le service Produit est en panne, le service de livraison ne peut pas faire son travail. Si vous dupliquez les données avec la messagerie asynchrone, les données requises pour effectuer la livraison se trouvent dans la base de données Delivery Microservice. Lorsque le service produit ne fonctionne pas, vous pourrez effectuer la livraison.
Lorsque vous distribuez votre code pour réduire le couplage, vous souhaitez éviter le partage de ressources. Les données sont une ressource que vous souhaitez éviter de partager.
Un autre point est qu'un seul composant de votre système possède les données (pour les opérations de changement d'état), les 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.
L'introduction de l'intégrité référentielle réintroduira le couplage. Au lieu de cela, vous voudrez utiliser quelque chose comme les guides pour vos clés primaires, ils seront créés par le créateur de l'objet, le reste consiste à gérer la cohérence éventuelle.
Jetez un coup d'œil à Udi Dahan donnez plus de détails à NDC Oslo
J'espère que cela t'aides