Une architecture micro-service en Java et Spring Boot

Nous l’avons vu dans le précédent article, Java n’est pas mort, loin s’en faut. Voyons maintenant comment utiliser Java de manière efficace dans une architecture micro-service.

Spring Boot

Spring est avant tout connu dans le monde Java pour les injections de dépendance avec notamment avec le container IoC (Inversion of Control, l’autre nom de la Dependency Injection).

Le framework Spring comprend de nombreuses composantes, pour la plupart facultatives telles que:

  • Spring Web MVC: un Framework Model View Controller
  • Spring Data: des abstractions pour accéder aux datas dans des bases de données
  • Spring AOP: pour l’Aspect Orienting Programming
  • Spring Test
  • Et Spring Core qui gère les Beans et les configurations
  • Spring Integration: l’application de l’excellent livre Enterprise Integration Patterns
  • Spring Security: pour gérer la sécurité de sa web app
  • etc.

Ces composantes sont robustes mais peuvent un peu effrayer le néophyte et nécessitent par défaut de configurer son app avant d’avoir quelque chose qui tourne. C’est la raison pour laquelle Spring a développé Spring Boot, qui permet d’avoir une app qui tourne par défaut et qui suit le pattern « Convention over Configuration » propre à Rails. Libre à vous ensuite d’activer les modules qui vous semblent utiles.

EMBEDDED WEB-SERVER

Traditionnellement, pour faire tourner son application web en production, il faut utiliser un Web Server qui implémente notamment les interfaces Servlet. Le plus connus est Tomcat, mais il en existe une multitude d’autres comme Jetty, Glassfish ou JBoss.

Anciennement, l’on instanciait une machine, par exemple avec une distribution Linux telle que Ubuntu ou Debian, puis l’on installait Apache Tomcat dessus. Le déploiement de son application web consistait ensuite à uploader un fichier JAR ou WAR (s’il y a du HTML et des autres assets tels que JavaScript et CSS) dans un sous-dossier du serveur. Tout ceci est un peu fastidieux car il faut désormais maintenir une version de son web-server indépendamment de son application. Ensuite, cela complique le workflow de test (local) la maintenance si l’on fait tourner une flotte d’applications de type micro-service et cela n’est pas vraiment compatible avec la philosophie container de type Docker comme nous le verrons plus loin.

Tomcat et Jetty offrent par exemple une alternative intéressante. Le Web-Server peut être ’embedded’ c’est à dire directement inscrit dans les dépendances de son application au même titre que Guava ou JUnit. Les avantages sont multiples:

  • Le serveur utilisé localement et en production est le même. Par conséquent vous n’aurez pas de surprise entre vos tests locaux, vos tests dans votre environnement de build tel que Jenkins et votre application en production
  • Vous pouvez changer de serveur en une ligne de code. Par exemple, je suis passé de Tomcat à Jetty de manière très aisée (en changeant une ligne dans mon build.gradle, puis fixant 2-3 effets de bords détectés rapidement en local).
  • Vous n’avez plus qu’à deployer un seul JAR et vous pouvez lancer votre app avec un classique java -jar <file.jar> et spécifier alors les options de la JVM de manière différenciée pour chaque app.

GRADLE

En cours d’écriture.

DOCKER

En cours d’écriture.

Une architecture micro-service en Java et Spring Boot

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *