Comment encapsuler plusieurs applications Spring Boot en une seule
Je travaille en équipe, qui développe de nouvelles versions d'applications web pour nos anciennes solutions, mais il y a aussi des idées innovantes. Nous utilisons Angular à l'avant, Java à l'arrière, MongoDB pour la base de données et l'exécutons via Spring Boot).
Au stade actuel, deux applications sont terminées et d'autres sont en cours de développement. Maintenant, nous les exécutons séparément, ce sont des applications différentes qui s'exécutent dans différents ports à des fins très spécifiques, à la seule exception étant la conception car nous avons essayé un peu dur de garder une sorte de modèle d'utilisation.
Cependant, nous regardons de plus en plus vers l'avenir et nous réalisons qu'en plus de l'objectif de chaque application étant très spécifique, ils composent en fait un produit plus gros qui pourrait tout emballer à l'intérieur.
Ce que nous prévoyons pour l'instant peut être très simple à décrire, mais je veux en savoir plus à ce sujet pour nous assurer que nous sommes sur la bonne voie pour intégrer les applications. Fondamentalement, vous pouvez envisager un menu fixé en haut qui affichera toutes les applications disponibles en fonction des autorisations utilisateur enregistrées. Après cela, une fois qu'il/elle en a sélectionné un, le flux doit être le même que dans l'application sélectionnée lors de son exécution séparée (mais le menu toujours).
Quelqu'un a-t-il des recommandations ou quelque chose qui pourrait nous aider à construire cela de manière appropriée? (car il sera plus facile d'intégrer les choses maintenant que dans le futur)
Je suis à peu près sûr qu'il peut exister des raisons pour cela, mais selon les besoins de l'entreprise, la solution peut être très différente. Voici les deux options que vous pouvez considérer:
Conteneurisation de vos applications. Placez chaque application dans un conteneur Docker, puis utilisez
docker-composepour exécuter les deux sur le même serveur en même temps. Vous pouvez utiliser une passerelle API ou un proxy pour exposer les deux services via un point d'entrée unique. Le principal avantage est que vous pourrez le faire évoluer sur plusieurs serveurs, si nécessaire, et vous n'avez pas besoin de toucher le code de l'application, ce qui préserve la modularité.Architecture du plugin. Avec quelques modifications de la configuration de Spring, vous pouvez traiter les applications originales comme des plugins, en implémentant une API. Vous mettez les configurations du plugin dans un dossier classpath commun, par exemple
/META-INF/plugins/pluginN.xml, il sera donc détectable par l'application hôte. Vous écrivez l'application Host Spring Boot, qui chargera les plugins via Spring DI en recherchant les configurations dans le chemin de classe. Les plugins contribueront les mappages de demandes à la configuration WebMVC de l'application hôte, exposant leur partie des fonctionnalités. Avantages: a) vous conservez toujours la modularité. b) taille d'image plus petite et utilisation de la mémoire/CPU sur le serveur. Con: nécessite une réflexion approfondie sur la configuration de Spring et l'architecture du plugin. Non évolutif au sens de "l'architecture de microservice" (peut toujours être déployé sur plusieurs machines comme une seule application faisant tout).
Et bien non. Ils ne composent pas une "application plus importante", sauf si vous le souhaitez.
Vous vous dirigez vers Microsoft Office. Vous envisagez de faire un monolithe. Il s'agit d'une décision commerciale. Celui dont vous serez jugé. Cela n'a rien à voir avec un meilleur design.
Ce qui a à voir avec une meilleure conception, c'est l'intégration que vous avez mentionnée. Essayer très dur de présenter une expérience utilisateur uniforme est une bonne chose. Les faire travailler ensemble, c'est bien. C'est exactement ce que sont les outils de ligne de commande UNIX. Ils travaillent ensemble. Ils ont une manière uniforme d'interagir avec eux. Ce n'est pas un monolithe. Ce sont de nombreux petits outils qui fonctionnent bien ensemble. Ils sont intégrés.
Si vous voulez faire un beau monolithe. Mais ne prétendez pas que c'est le seul moyen de faire fonctionner les applications ensemble. C'est un choix indépendant.
Si vous voulez simplement indiquer comment ils sont bien intégrés dans votre marketing, donnez simplement à leurs icônes un thème cohérent.
L'encapsulation de plusieurs applications Spring Boot ne semble pas être la solution. Si vous voulez un seul conteneur, créez les applications en tant que fichiers war et déployez-les dans un seul conteneur.
Vous pouvez toujours être coincé avec le problème de rappel au conteneur pour accéder à différentes couches. Vous souhaiterez peut-être empaqueter certains modules en tant que bibliothèques et les utiliser directement. Vous aurez déjà développé un module découplé, continuez ainsi en utilisant son interface.