J'ai 2 services (service1 et service2), et les deux services utilisent le même modèle de données "studentModel", je me demande comment partager le studentModel entre les deux services.
1.Créez un studentModel.jar, et tous les services se réfèrent à ce jar
2.Copier et coller du code
Aidez-moi à réutiliser du code dans l'architecture de microservices.
3 Réponses :
En ce qui concerne les microservices, il est normal de conserver les fichiers dupliqués car vous pourriez vous retrouver avec un monolithe distribué. Souvenez-vous du contexte borné de DDD et utilisez votre processus de réflexion. Aucune bibliothèque partagée signifie pas de couplage.
Mais encore une fois, le DRY (Don't Repeat Yourself) dit que vous ne devriez pas avoir de doublon, mais dans quelle mesure?
Un échec dans une bibliothèque ne devrait pas entraîner l'échec de tous vos microservices en utilisant cette bibliothèque, alors tout le but du microservice est inutile.
Il existe des outils pour partager du code entre les microservices, vous pouvez jeter un œil sur https://bitsrc.io/
Tout cela est ma pensée, il doit y avoir un meilleur moyen.
Oui, le couplage et le DRY ne sont pas compatibles dans l'architecture des microservices.
Je pense que DRY et Decoupling sont parfaitement compatibles. Dans un environnement Microservice, chaque service doit avoir un objectif dans le système, de sorte que le module ne peut pas être une duplication car il peut diverger à l'avenir. La raison d'utiliser le même pot avec le même modèle est uniquement liée au fait qu'ils n'ont qu'une seule raison de changer. S'ils en ont plus, ce n'est pas une duplication.
Voir mon commentaire sur la question des PO. Traitez simplement la dépendance comme une dépendance externe avec une gestion des versions correcte. La duplication de fichiers vous plongera rapidement dans l'enfer des mises à jour.
SI vous implémentez votre bibliothèque commune avec une version, vous ne violerez pas le couplage sans MS.
Pour un meilleur contrôle de version, je vous recommande de créer un fichier jar et de l'ajouter en tant que dépendance de vos microservices. Vous pouvez également explorer les sous-modules git en plaçant des codes en double dans des sous-modules et en les utilisant dans votre module de microservice respectif.
Je recommanderais d'aller encore plus loin. D'après mon expérience, la meilleure approche serait la suivante:
En suivant cette approche, vous pouvez publier une nouvelle bibliothèque cliente chaque fois que vous modifiez votre micro-service - elle sera facile à maintenir et à gérer.
De plus, cela vous aidera à gagner beaucoup de temps lorsque votre système se développera. Imaginez, vous allez utiliser votre service principal (par exemple, le service utilisateur ou le service de profil) comme dépendance pour tous les autres services. Le copier-coller n'est certainement pas une option dans ce cas.
Mise à jour. Actuellement, nous avons des éléments tels que OpenAPI et GraphQL dans nos outils. Il suffit de concevoir un bon schéma pour le service fournisseur et d'utiliser simplement des outils de génération de code pour les consommateurs.
créez un fichier jar et ajoutez-le en tant que dépendance à vos projets de service
Vous devez traiter toute dépendance de code comme vous traiteriez une dépendance externe, par exemple un composant open source de github. Cela signifie que vous devez effectuer correctement la version des composants et augmenter les versions comme vous le feriez avec une dépendance externe.