Comment gérer des modèles partagés entre de nombreux microservices?
Ma question est similaire à celle-ci , mais un peu plus spécifique à un cas.
Disons que j'ai un modèle payments, et ceci est utilisé par mon Service de rapport, ainsi que mon Service de comptabilité.
Est-il inévitable que ces deux services soient maintenant couplés par leur dépendance mutuelle sur le modèle?
Comme l'a mentionné Ewan, les deux services sont couplés par les données échangées et non le modèle (d'une perspective strictement orientée objet). Remarque: je reçois un 404 lorsque je suis votre lien, cela ressemble à un projet privé.
À partir d'une perspective de service Web, des données sont échangées dans un schéma connu. Il pourrait être XML ou JSON, mais c'est moins important que la structure des données et le contenu à l'intérieur. Qui permet un environnement de déploiement hétérogène.
Le service lui-même peut être défini dans Go , sans modèle d'objet du tout. Vous pouvez toujours le consommer avec un client intégré Python qui lie la sortie à un modèle d'objet.
Le partage d'objets de modèle entre client et serveur dans un environnement de service Web n'est qu'une question de commodité pour le développeur. Vous n'avez pas toujours cette option, en particulier si vous consommez une API tierce.
Dans votre exemple spécifique, le fait que les services de rapport et de comptabilité partagent le même schéma pour payments ne les coule pas nécessairement. Plusieurs fois, vous pouvez avoir un schéma de base, puis présenter des extensions dans un but particulier. L'intégration principale se produit dans le schéma de base.
Le service de reporting peut avoir des champs en plus de la base payments schéma qui ne sont que des germes au service de rapport. Identique est vrai pour le service de comptabilité. Pourtant, tant que le schéma Core payments est respecté, des champs supplémentaires non utilisés par ce service seront simplement ignorés.
Les autres réponses sont correctes dans la mesure où le couplage étant au niveau de l'interface de données. Mais ils ne répondent pas vraiment à la question posée dans le titre:
Comment gérer des modèles partagés entre de nombreux microservices?
La sagesse de microservice classique est de err sur le côté du couplage de manière lâche; Partager aussi peu de code que possible .
Un bref aperçu des problèmes liés au partage peut être trouvé directement ici . Cet extrait frappe sur quelques bons points (met l'accent sur la mienne):
David souligne que tous les partage du code joindront vos services ensemble via le code partagé. Créant une source unique de vérité, adhérant au DRY dans un seul service créera un couplage interne mais ne causait pas problème dans un service avec une seule responsabilité. En revanche, lors de la traversée d'une frontière, même si certaines choses ont l'air identique, elles sont dans un contexte différent et doivent être différentes, mises en œuvre par différents cadres et utiliser un magasin de données différent. David exhorte que Peu importe la façon dont les choses semblables regardent, nous devons résister à les attacher car cela signifie que nous sommes couplage à travers les limites et sur différents contextes , un chemin direct vers une grande balle de boue.
Ceci ebook illustre en outre pourquoi le partage du code à travers les microservices est généralement mauvais, mais à travers la lentille étant un mal nécessaire parfois. Il est parfois pragmatique de partager le code avec précaution entre les services. Je recommanderais de lire le "On m'a appris à partager" Antipattern Section complète pour mieux comprendre comment/quand partager le code entre microservices. Pour la postérité, voici les quatre approches qu'il discute pour le partage du code dans de tels cas où il est approprié:
Projet partagé: L'utilisation d'un projet partagé forme une liaison de temps de compilation entre le code source commun qui est situé dans un projet partagé et chaque projet de service. Bien que cela facilite la modification et le développement de logiciels, c'est ma technique de partage la moins favorite, car elle provoque des problèmes potentiels et des surprises pendant les heures d'exécution, ce qui rend les applications moins robustes. Le principal problème avec la technique du projet partagé est celui de la communication et du contrôle - il est difficile de savoir quels modules partagés ont changé et pourquoi, et aussi difficile à contrôler si vous souhaitez que cela change ou non. Imaginez être prêt à libérer votre microservice Juste pour savoir que quelqu'un a fait une nouvelle modification à un module partagé, vous obligeant à modifier et à retenir votre code avant le déploiement.
Bibliothèque partagée: Une meilleure approche si vous devez partager le code consiste à utiliser une bibliothèque partagée (par exemple, montage .NET ou fichier JAR). Cette approche rend le développement plus difficile car chaque modification apportée à un module dans une bibliothèque partagée, le développeur doit d'abord créer la bibliothèque, puis redémarrer le service, puis retester. Cependant, l'avantage de la technique de la bibliothèque partagée est que les bibliothèques peuvent être versées, offrant un meilleur contrôle sur le comportement de déploiement et d'exécution d'un service. Si une modification est faite à une bibliothèque partagée et versionné, le propriétaire du service peut prendre des décisions sur la question de l'intégration de ce changement.
Code répliqué: Une troisième technique commune dans une architecture de Microservices est de violer le principe de ne-même pas-vous-vous-même (sec) et de reproduire le partagé module sur tous les services nécessitant cette fonctionnalité particulière. Bien que la technique de réplication puisse sembler risquée, elle évite le partage de la dépendance et préserve le contexte délimité d'un service. Les problèmes se posent avec cette technique lorsque le module répliqué doit être modifié, en particulier pour un défaut. Dans ce cas, tous les services doivent changer. Par conséquent, cette technique n'est vraiment utile que pour des modules partagés très stables qui ont peu ou pas de changement.
Consolidation de service: Une quatrième technique parfois possible est d'utiliser la consolidation de service. Disons que deux ou trois services partagent tous du code commun et ces modules communs changent fréquemment. Étant donné que tous les services doivent être testés et déployés avec le changement de module commun de toute façon, vous pourriez également simplement consolider la fonctionnalité en un seul service, supprimant ainsi la bibliothèque à charge.
Aussi, connexe: https://softwareEgineering.stackexchange.com/a/366237/209046
Anecdotage, j'ai fait les deux n ° 2 et 3 avant sur différents projets; En partageant le code dans une bibliothèque "Microservices courants" (explicitement identifiée comme anticipée dans le livre électronique ci-dessus), et par des modèles de copie/colle d'un service à un autre (bien que ceux-ci n'étaient pas vraiment "microservices") soient maintenus séparément. L'avantage le plus évident du n ° 3 était que les mises à niveau du cadre pour chaque service pouvaient être effectuées de manière indépendante, avec l'inconvénient de devoir maintenir le code modèle à deux endroits (ce qui n'était pas aussi douloureux avec seulement deux services). En ce qui concerne # 2, je me souviens distinctement que la gestion de notre forfait "Microservices ordinaire" était la partie la plus pénible du développement sur ce projet.
Ils ne sont pas couplés par le modèle.
Ils sont couplés par le format des données qu'ils échangent, qu'ils désérialisent au modèle.
S'ils doivent parler, ils doivent se comprendre. donc oui c'est pratiquement inévitable. Bien que, en théorie, vous pourriez peut-être écrire un IA qui pourrait interpréter des structures variables, je doute qu'il serait plus facile que de simplement échanger le format.
Je vous suggère de créer un repo (git) qui stocke le schéma, défini dans Avro. De cette façon, le schéma/contrat est bien défini et tout développeur pourrait dériver leur représentation spécifique de leur langue du contrat.