13 frameworks Java pour des microservices à toute épreuve

Cela a été un long voyage pour Java, une langue qui a commencé comme la lingua franca de la boîte au-dessus du téléviseur à l'époque où les téléviseurs n'étaient pas équipés de Roku ou Chromecast intégré. Ensuite, Java allait devenir propriétaire du World Wide Web en animant le navigateur avant que JavaScript n'arrive et ne le supprime.

Java a fini par trouver une niche dans les fermes de serveurs où il y avait autrefois suffisamment d'architectures de puces et de systèmes d'exploitation différents pour rendre la promesse «d'écrire une fois exécuté n'importe où» convaincante. Et dans ces fermes de serveurs, Java a survécu, un favori des magasins informatiques d'entreprise accros à la fiabilité et des développeurs qui aiment la frappe forte.

Entre-temps, JavaScript en général et Node.js en particulier ont défié Java sur le serveur, en utilisant leur haut débit et leur vitesse sans thread pour prendre en charge une énorme partie du trafic sur le Web. Node a capturé l'imagination des plus récents programmeurs côté serveur en offrant non seulement la vitesse et l'efficacité des ressources, mais également la simplicité du code qui s'exécute à la fois sur le client et le serveur.

Pourtant, malgré la montée de la concurrence, Java continue non seulement de survivre mais aussi d'exceller. De nombreuses équipes chargées de développer des architectures de microservices continuent d'utiliser Java. Une raison majeure doit être parce que la technologie est testée au combat depuis des années sur le front de l'analyse des requêtes HTTP. Sun a créé une machine virtuelle à toute épreuve, et Oracle continue de la nourrir et de la prendre en charge.

Une autre raison doit être l'évolution continue de la langue. Java 8 offre un support solide pour les langages fonctionnels tels que Scala et Kotlin. La JVM est désormais la base de nombreuses des meilleures expériences de développement de langage informatique. Des dizaines de nouveaux langages peuvent être compilés en octets Java et se lier les uns aux autres pour faire fonctionner des projets complexes ensemble. La plupart des piles fonctionnant correctement sur une JVM peuvent être construites par un mélange de Java et d'un certain nombre d'autres langages.

La principale raison, cependant, doit être la pure inertie. Au moment où j'écris, 371 emplois pour les programmeurs COBOL sont répertoriés sur Dice. Il y a beaucoup, beaucoup plus d'emplois avec le mot Java en eux. Est-il surprenant que les équipes intelligentes examinent leurs énormes piles de code Java vieillissant et pensent que la solution la plus simple consiste simplement à ajouter une porte latérale qui crache les données sous forme de structures de données JSON? Voilà. L'ancien code continue de fonctionner, mais il agit comme un microservice moderne à ces portes latérales.

Toutes ces options et d'autres garantissent que Java continue de jouer un rôle important et vital dans la révolution des microservices. Et il n'est pas surprenant que la communauté open source Java ait suivi, créant de nombreuses nouvelles options pour les programmeurs Java qui doivent apprendre à leur code Java à parler comme un microservice.

Voici une liste de 13 options open source que les développeurs Java utilisent pour créer des solutions qui forment la base des architectures de microservices partout.

Botte de printemps

Le monde Java construit des applications Spring depuis longtemps. Spring Boot est une version particulière de Spring qui rend le processus beaucoup plus facile en gérant de nombreux détails de configuration pour vous. Spring Boot a été créé pour automatiser le démarrage des projets Spring de tout type, pas seulement des microservices. Pour rendre les choses encore plus simples, une fois que vous avez terminé avec l'application, Spring Boot se mélange dans un serveur Web et crache un seul fichier JAR qui est à peu près tout ce dont vous avez besoin, à l'exception de la JVM. Considérez-le comme le conteneur Docker d'origine.

Toute cette intelligence est appréciée par de nombreuses personnes chargées de créer des microservices, car toute la configuration devient ennuyeuse lorsque vous devez le refaire encore et encore pour chacun des dizaines de microservices. Si Spring Boot peut l'automatiser, il est beaucoup plus facile de créer plusieurs dizaines de microservices.

Les microservices développés avec Spring suivent la même philosophie MVC que les applications web macro que nous construisons depuis des années. Le framework bénéficie de toutes les connexions profondes construites au fil des années de développement Java, y compris l'intégration avec tous les magasins de données majeurs et mineurs, les serveurs LDAP et les outils de messagerie comme Apache Kafka. Il existe également des dizaines de fonctionnalités petites et pas si petites pour maintenir une collection de serveurs en cours d'exécution, des fonctionnalités telles que Spring Vault, un outil permettant de conserver les secrets, les mots de passe et les informations d'identification nécessaires aux serveurs en production. Tous ces avantages montrent pourquoi les programmeurs Java ont rejoint le train en marche depuis de nombreuses années.

MicroProfile Eclipse

En 2016, certains des fans de la communauté Java Enterprise ont regardé autour d'eux et ont décidé de nettoyer toutes les impuretés de Java Enterprise Edition afin que les gens puissent créer des microservices simples avec les parties classiques. Ils ont jeté un nombre surprenant de bibliothèques, mais ont conservé le code pour traiter les requêtes REST, analyser JSON et gérer l'injection de dépendances. Ce qu'ils ont obtenu, baptisé Eclipse MicroProfile, était simple et rapide.

Depuis lors, la communauté MicroProfile a conclu un pacte pour publier de nouvelles versions aussi souvent que tous les trimestres tout en ajoutant un nouveau code pour que les microservices fonctionnent correctement et en toute sécurité. Le processus de développement et la structure du code seront très familiers à quiconque a vécu dans le monde Java EE, mais les tracas de configuration sans fin ont été réglés. C'est la preuve que vous pouvez apprendre de nouveaux trucs aux vieux chiens.

Dropwizard

Lorsque Dropwizard est apparu en 2011, cela a ouvert les yeux des développeurs Java Enterprise sur le peu de code nécessaire. Le framework Dropwizard a fourni un modèle de développement très simple avec de nombreuses décisions importantes prises pour vous, et il a continué à suivre cette voie. Vous ajoutez une logique métier, puis à peu près tout le reste est configuré pour vous selon la convention. Le résultat est des fichiers JAR minces que les utilisateurs louent pour un démarrage rapide.

La plus grande limitation peut être le manque d'injection de dépendances. Si vous souhaitez utiliser l'injection de dépendances pour garder votre code propre et faiblement couplé, vous devrez ajouter les bibliothèques vous-même. Il n'y a pas de moyen Dropwizard de le faire, contrairement au monde Spring. La plupart des autres articles de luxe, cependant, sont désormais pris en charge, y compris la journalisation, les vérifications de l'état et le code fournissant la résilience. Vous n'aurez pas besoin de faire trop de sacrifices.

Queue d'épine WildFly

Les gens de Red Hat ont construit leur propre version de MicroProfile avec un outil de configuration astucieux. Le framework s'appelait à l'origine WildFly Swarm, mais il a ensuite été renommé Thorntail. Le site Web Thorntail vous aide à créer votre propre fichier de construction Maven simplement en spécifiant les fonctionnalités dont vous avez besoin. Maven s'occupe ensuite de tout assembler.

Thorntail détectera également les principaux composants dont vous aurez besoin en scannant votre code, mais vous pouvez le remplacer avec un fichier de nomenclature (nomenclature). Quand tout est en cours d'exécution, Thorntail supprimera les parties de Java Enterprise Edition qui ne seront pas utilisées et créera un fichier JAR petit et prêt à être déployé avec une seule commande - une fonctionnalité astucieuse qui permet au projet Thorntail de l'appeler Uber -POT. C'est une autre approche pour suivre la tradition de Java Enterprise Edition sans garder tous les bagages lourds.

Hélidon

Helidon n'est sorti que depuis quelques mois depuis les communiqués de presse et le premier engagement dans le référentiel GitHub, mais le framework attire déjà le genre d'attention que le support d'Oracle garantit. Bien que l'univers Java soit énorme, une grande partie tourne toujours autour d'Oracle. 

Les architectes d'Hélidon ont suivi plusieurs des mêmes thèmes qui sont répétés dans les autres projets ici. Arrachez la cruft Java Enterprise Edition et conservez le noyau léger basé sur des servlets qui a gagné la confiance du monde entier. Dans le cas d'Helidon, les développeurs ont commencé avec Netty et ont ajouté juste assez de code pour effectuer le routage et la gestion des erreurs. Pour rendre les choses intéressantes, ils ont adopté deux modèles de base pour le code, les versions dites SE et MP.

Helidon SE semblera très familier aux programmeurs de Node.js avec les longues chaînes d'appels de fonctions reliées par des points. Helidon MP semblera plus familier aux programmeurs Java qui utilisent JAX-RS. Il existe également des outils utiles et appréciés pour vérifier la santé des serveurs ou suivre le flux de données à travers une forêt de microservices. Ce sont des raisons impérieuses d'explorer le potentiel, même sans le soutien d'Oracle.  

Criquet

Encore un autre cadre pour le développement rapide d'API est Cricket. Cricket est petit malgré l'inclusion de plusieurs extras comme un magasin de données clé-valeur pour vous éviter de connecter une base de données et un planificateur pour contrôler le traitement répétitif en arrière-plan. Il n'y a pas d'autres dépendances qui ajoutent des complications ou un verrouillage, il est donc assez facile d'ajouter votre code à Cricket et de démarrer un microservice indépendant.

Jersey

L'une des approches standard du développement d'un service Web est l'API Java pour les services Web RESTful (alias JAX-RS), une spécification générale qui a été implémentée dans le framework Jersey. L'approche dépend fortement de l'utilisation des annotations pour spécifier le mappage de chemin et les détails de retour. Tout le reste, de l'analyse des paramètres et de l'emballage du JSON, est géré par Jersey.

Le principal avantage de Jersey est qu'il implémente la norme JAX-RS, une fonctionnalité suffisamment souhaitable pour que certains développeurs combinent Jersey avec Spring Boot pour profiter des deux ensemble. 

Jouer

L'un des meilleurs moyens de profiter de la puissance multilingue de la JVM est d'utiliser le framework Play, une pile de code Scala qui se connecte à Java ou à l'un des autres langages JVM. La fondation est très moderne, avec un modèle asynchrone et sans état qui ne surcharge pas le serveur avec des threads sans fin essayant de garder une trace des utilisateurs et de leurs données de session. Il existe également un certain nombre de fonctionnalités supplémentaires qui peuvent être utilisées pour étoffer un site Web comme OpenID, la validation et la prise en charge du téléchargement de fichiers.

La base de code Play évolue depuis plus d'une décennie, vous trouverez donc également des échos de temps oubliés depuis longtemps, comme la prise en charge de XML. Le jeu est à la fois mature et souple, une combinaison qui peut être rare dans la nature.

Swagger

Construire une API peut sembler aussi simple que d'écrire du code qui écoute sur un port et fournit des réponses, mais les développeurs de Swagger ne sont pas d'accord. Ils ont créé un langage de spécification d'API complet appelé OpenAPI que vous pouvez utiliser pour expliquer ce que votre API va faire. Cela peut sembler une étape supplémentaire, mais l'équipe Swagger a également fourni un code qui transforme cette spécification en tests automatisés, en documentation, etc.

La description simple et presque spartiate d'une API dans le fichier de configuration Swagger est transformée en code Java pour implémenter l'interface, documenter son comportement et fournir un ensemble d'outils pour tester le code construit en dessous. Il existe même un mécanisme de gouvernance des API afin que vous puissiez travailler avec les masses non lavées qui vont bientôt frapper à la porte de votre API et attendre des réponses.

Swagger est un écosystème d'API et ne se limite pas à Java. Si votre équipe passe à Node.js ou à l'une des dizaines d'autres langues, un module Swagger Codegen attend de convertir votre spécification OpenAPI en une implémentation dans cette langue.

Restlet

L'une des plus grandes différences entre les différents frameworks est le nombre de connexions à d'autres services et bibliothèques. Le projet Restlet offre l'une des plus grandes collections de fonctionnalités et de connexions. Il est déjà intégré à des bibliothèques comme JavaMail, au cas où votre microservice aurait besoin de parler POP, IMAP ou SMTP à un serveur de messagerie, et Lucene / Solr, au cas où vous voudriez créer des index de recherche de gros morceaux de texte et les métadonnées enveloppées il.

Les possibilités de Restlet continuent car cette pile prend généralement en charge plusieurs options différentes pour chaque pièce. Vous n'avez pas besoin d'utiliser JSON, par exemple, car le code gérera XML, CSV, YAML et quelques autres formats de fichiers. Vous obtenez également plusieurs options différentes pour les modèles pour structurer votre réponse. L'une des fonctionnalités supplémentaires les plus intéressantes est le client Restlet, qui vous permet de tester vos API à partir du navigateur Chrome.

Écraser

Le débogage des microservices est souvent un véritable défi car les pièces sont si faiblement couplées et il est difficile de suivre le flux de données à travers toutes les couches du système. Squash vous permet de configurer des points d'arrêt dans votre code s'exécutant sur un cluster Kubernetes, puis de recevoir toutes les données dans votre IDE comme s'il s'agissait de code s'exécutant localement. Squash s'intègre également aux environnements d'exécution Node.js et Python au cas où votre collection de microservices ne serait pas uniquement Java.

Téléprésence

Une autre option de débogage consiste à utiliser la téléprésence pour créer un proxy local pour un microservice sur un cluster Kubernetes distant. Vos appels pour ce service seront détournés vers la version locale où vous pouvez configurer des points d'arrêt ou faire tout ce que vous pouvez imaginer sur votre machine locale.

Zipkin

Zipkin est un mécanisme permettant de consigner les événements sur divers microservices, puis de corréler les événements afin que les problèmes puissent être isolés et étudiés au fur et à mesure qu'ils se propagent dans l'ensemble des machines. Il existe une implémentation Zipkin pour Java ainsi qu'au moins six autres langages afin que les systèmes multilingues puissent être abordés. Certains des frameworks les plus sophistiqués comme Spring intègrent déjà Zipkin sous une forme ou une autre.