TL; DR;
Regardez mon exposé sur la migration du traitement de données vers les microservices trouvés ici: https://www.youtube.com/watch?v=COzkPkHZMG8. Si après cela, vous pensez toujours que c'est une mauvaise chose, passez au fond où je propose une approche alternative (non recommandée).
Pourquoi est-ce une bonne chose
Laissez-moi prendre une minute pour marcher à travers pourquoi nous chose que c'est une meilleure solution pour l'avenir et pourquoi je vous déconseille de prendre une approche monolithique. Après tout cela, je proposerai une alternative que je ne recommande pas, mais qui devrait fonctionner.
Briser le monolithe
Si vous pensez au sujet du processus la plupart des entreprises ont pour fournir la fonctionnalité de traitement par lots de l'ordinateur portable d'un développeur à la production, il est généralement un processus lent avec les versions rares. Le processus est lent, il peut y avoir plusieurs groupes que le code doit traverser (développement, certains de QA externe, éventuellement une forme de processus de contrôle des changements, puis finalement un certain type d'équipe d'opérations pour réellement déployer le code). Généralement, plus le code qui doit passer par ce processus est petit, plus il est facile de passer à travers ce processus.
Dans cet exemple, pour un système qui contient 50 tâches par lots, pour en changer un, vous devez passer par ce processus avec tous les travaux. Rompre cela en fait simplifie la maintenance en ce sens que vous pouvez changer et déployer des travaux indépendamment. Un développeur n'a besoin que de se concentrer sur le travail par lots.
Migration vers des pots über
Un autre avantage de passer d'un seul fichier WAR avec tous vos emplois emballés dans c'est la flexibilité. Vous pouvez exécuter ces tâches comme vous le souhaitez, quelle que soit l'infrastructure souhaitée. Voulez-vous l'exécuter localement ou sur du métal nu via la commande java -jar foo.jar? Fonce. Voulez-vous l'exécuter sur CloudFoundry via un cf push? Tu paries. Vous voulez dockeriser l'application et l'exécuter sur Kubernetes? Vous pouvez! Alors que vous pouvez faire la même chose sans aller à une approche über jar, c'est plus nuancé puisque l'infrastructure peut changer d'environnement en environnement. Dans le cas d'un über jar, tout ce que vous devez garantir est la version java.
La pièce de gestion d'artefacts est également un problème bien résolu. Pousser des über jars vers un dépôt Maven est un processus simple et bien étudié dans le paysage java. Comment gérer les fichiers WAR n'est pas vraiment.Vous pouvez les pousser vers un dépôt Maven, mais ce n'est pas idéal. En passant à über jars, votre processus de publication devient très standardisé pour tous les travaux (et toutes vos applications en général).
Enfin, passer à un pot über ne devrait pas être si difficile. Ce devrait être juste un exercice d'emballage en supposant que vos emplois sont bien définis. Si ce n'est pas le cas, il s'agit d'une bonne occasion de procéder à une restructuration saine afin d'être plus modulaire (bonnes pratiques d'ingénierie).
L'approche alternative
Je veux commencer ici en disant que je ne ai pas recommande cette approche. Cependant, cela devrait fonctionner. Au lieu de créer un seul grand pot pour chaque travail, créez un grand pot avec les 50 tâches qu'il contient. Vous devez créer votre propre CommandLineRunner qui examine une variable d'environnement pour déterminer le travail à exécuter lors du lancement et désactiver la fonctionnalité Spring Start pour exécuter automatiquement vos tâches au démarrage. À partir de là, vous configurerez vos 50 tâches via 50 définitions de tâches dans Spring Cloud Data Flow. Chacun passant la variable d'environnement indiquant le travail à exécuter. De là, vous serez en mesure d'exécuter indépendamment/monitor/etc chacun des 50 travaux et toujours obtenir votre artefact monolithique.
Merci pour la réponse, l'approche microservices est géniale. Mais encore, peut-être la flexibilité devrait être là pour emballer plusieurs travaux dans le même pot et ils peuvent être lancés séparément de Cloud Dashboard? Il peut y avoir des cas d'utilisation, par exemple les travaux sont petits et les pots séparés peuvent être des frais généraux. Notre cas d'utilisation est, en migrant de DB2 vers Cassandra, environ 50 tables sont là. Le plan consiste à écrire 1 travail pour 1 table, donc au total 50 emplois. Une fois la migration effectuée, nous n'utilisons pas 90% de ces emplois. Donc, notre pensée est de générer ces nombreux pots est au-dessus et permet de paquet de manière monolithique habituelle. – praveen
Si vous cherchez à faire une table par travail, pourquoi ne pas écrire un travail qui est assez intelligent pour gérer chaque table via la configuration? Cela ressemble plus à un problème de conception qu'à un problème de déploiement. –
Salut Michael, Avec l'administration par lots, nous voulions avoir un travail pour chaque table (avec les mêmes lecteurs/rédacteurs, scoped travail/étape), de sorte qu'il est facile de tracer/lancer les travaux et la migration de table à partir de l'interface utilisateur. Maintenant, en reconsidérant l'approche comme vous l'avez suggéré, un travail intelligent qui peut gérer plusieurs migrations de table via la configuration. Et il est prévu d'ajouter une définition de tâche pour chaque table, nous allons donc différencier la migration au niveau de la définition de tâche. Merci beaucoup pour votre soutien :) – praveen