Microservices et bibliothèques partagées

9

Nous concevons un système basé sur des microservices indépendants (connectés via un bus RabbitMq). Le code sera (au moins pour les premiers composants) écrit en python (à la fois python2 et python3). Nous avons déjà une application monolithique implémentant une partie de la logique métier, que nous souhaitons refactoriser en microservices et étendre. Une question qui m'inquiète est:

Quelle est la meilleure façon de partager du code entre les différents microservices. Nous avons des fonctions d'assistance communes (traitement des données, journalisation, analyse de configuration, etc.), qui doivent être utilisées par plusieurs microservices.

Les microservices eux-mêmes vont être développés en tant que projets séparés (référentiels git). Les bibliothèques communes peuvent également être développées en tant que projet autonome. Comment partager ces bibliothèques entre les microservices?

Je vois plusieurs approches:

copier autour de la version de la bibliothèque qui est nécessaire pour chaque microservice et mettre à jour si nécessaire
libérer les bibliothèques communes sur un PyPi interne et répertorier ces bibliothèques en tant que dépendances dans les exigences du microservice
inclure le référentiel de bibliothèque en tant que sous-module git

Je voudrais en savoir un peu plus sur les approches suggérées, les meilleures pratiques, les expériences passées avant de décider comment procéder. Avez-vous une suggestion ou un lien?

python microservices

— dangonfast
source

Je ne connais pas assez bien les microservices moi-même (mon entreprise a récemment commencé à faire quelque chose de similaire) pour répondre, mais voici un lien vers une présentation sur pourquoi ce que vous décrivez est un drapeau rouge et peut conduire à un "monolithe distribué" . Les microservices ne devraient pas nécessiter de bibliothèques partagées. Ils ne devraient vraiment communiquer qu'entre une API bien définie comme Swagger (maintenant appelée Open API ).

— Captain Man

@CaptainMan: Bien sûr, mais disons que vous avez cette fonction simple: fib(n)(implémentation de la série fibonacci). Vous ne souhaitez pas répéter cette implémentation dans chaque microservice. Cela appartient à une utilsbibliothèque (versionnée, pour les fonctionnalités et les corrections de bugs). Ce n'est pas un monolithe distribué, c'est juste une couche de fonctionnalités communes. Ma question est de savoir comment gérer cette couche au niveau de la mise en œuvre?

— dangonfast

Nos microservices ont des bibliothèques partagées pour garantir qu'ils parlent de la même manière à tous les autres microservices de notre système. Je ne sais pas comment il serait possible de le faire avec des bibliothèques non partagées; au minimum, tout le monde aurait besoin de bibliothèques de manipulation XML / JSON / etc. Je n'ai pas encore regardé cette présentation, mais aviez-vous une signification plus spécifique de «bibliothèque partagée» à l'esprit que celle à laquelle je pense?

— Ixrec

1

@ jeckyll2hide Nous utilisons C ++, mais notre infrastructure pour cela est à peu près équivalente à votre deuxième puce: repo séparé, tout le monde déclare ses dépendances, système de construction standard qui sait comment trouver ces dépendances au moment de la construction, etc.

— Ixrec

1

Je me sens comme un mannequin, votre question ne concerne pas vraiment le partage de bibliothèques de microservices en particulier, mais la question de savoir comment partager les bibliothèques de votre équipe avec l'équipe. J'en sais assez pour publier une réponse.

— Captain Man

5

Votre deuxième option est certainement la voie à suivre. Répartissez les bibliothèques courantes et installez-les sur votre serveur PyPi local.

L'option 1 est horrible car les améliorations apportées aux bibliothèques seront difficiles à propager à d'autres personnes qui pourraient l'utiliser.

L'option 3 est similaire à l'option 1.

Le modèle commun est de configurer Jenkins de sorte que lorsque vous poussez pour maîtriser un dépôt de bibliothèque, il fasse une construction python et le télécharge automatiquement sur le dépôt PyPi. Une fois que vous avez écrit ce script de construction, vous n'aurez plus jamais à vous soucier de l'empaquetage des bibliothèques et de leur téléchargement manuel sur PyPi. Et avec cette option, toutes les mises à jour de la bibliothèque seront instantanément disponibles pour être éventuellement mises à niveau vers d'autres microservices.

La configuration de votre propre serveur PyPi est très simple. J'aime ce guide

— Tommy
source

1

Je suis d'accord que l'option 2 est la meilleure, mais l'option 3 avec les sous-modules a beaucoup plus en commun avec l'option 2 que l'option 1.

— 8bittree

@ 8bittree: oui, l'option 3 est similaire à l'option 2, mais avoir le serveur git (la télécommande "centrale") comme mécanisme de distribution des paquets. D'une part, il utilise git pour quelque chose qui ne l'est pas (gestion des dépendances), d'autre part, il réduit le nombre de composants (pas besoin de PyPi privé)

— dangonfast

2

Pas un gars Python mais le serveur PyPi semble la meilleure option. Une recherche rapide sur Google donne l'impression que c'est analogue à un repo Nexus pour les pots Java de l'équipe.

Vraiment tant qu'il est déployé dans une sorte de référentiel central (au bureau / équipe) avec lequel votre outil de gestion des dépendances de choix peut fonctionner (lire et déployer), alors c'est une bonne option.

L'option 1 est vraiment la pire, vous ne devriez jamais avoir à gérer manuellement les dépendances. C'est une douleur. À l'université avant de connaître Maven et quand je pensais que Git était trop compliqué, nous avons tout fait manuellement, de la fusion du code de tout le monde à la configuration des chemins de classe, en passant par les dépendances. Ce fut une douleur, je ne voudrais vraiment pas que quiconque traverse une fraction de ce problème, surtout dans un environnement de travail où l'efficacité est importante.

L'option 3 fonctionnerait probablement bien, mais elle n'a pas de réels avantages par rapport à un PyPi local (en plus d'être peut-être plus facile à configurer, mais les avantages d'un véritable système de gestion des dépendances sont tellement meilleurs).

— Captain Man
source

1

Tout d'abord, la division d'un monolithe en microservices sera toujours difficile. Voir Gestion décentralisée des données - encapsulation de bases de données dans des microservices pour une idée de pourquoi.

Cela dit, il existe plusieurs recettes pour le faire de manière relativement saine. L'un d'eux est http://12factor.net/ . Celui-ci dirait que vous devez gérer chaque bibliothèque et application indépendamment, puis gérer les dépendances de manière explicite. Si vous suivez cette voie, je vous recommanderai FORTEMENT d'avoir une commande simple qui met à jour toutes les dépendances avec ce qui est en cours, et vous l'exécutez régulièrement pour chaque micro-service. Il est important d'avoir un processus de publication sain où vous verrouillez les versions des bibliothèques en production. Cependant, vous ne voulez vraiment, vraiment , vraiment pas être dans une position où les dépendances deviennent périmées et vous ne savez pas ce qui existe.

Concentrez-vous également sur le renforcement et la concentration de vos bibliothèques de supports. Il y aura toujours une attraction naturelle pour commencer à ajouter des éléments aux bibliothèques principales pour un partage facile. Faites cela, et vous tirerez rapidement toute la boule de spaghettis existants dans les bibliothèques partagées et reviendrez efficacement au désordre que vous avez maintenant. Il est donc préférable de sur-corriger dans l'autre sens.

— btilly
source

0

Vous devriez pouvoir aller sans serveur en pointant directement à partir d'un fichier de dépendance de package Python vers le dépôt GitHub privé contenant les bibliothèques. Pipenv et Poet soutiennent tous les deux cela, je crois.

— Dogweather
source