Comment Quarkus combine la programmation impérative et réactive

Cette année, nous prévoyons de développer sérieusement les thèmes des conteneurs, Java Cloud-Native et Kubernetes. Une suite logique de ces thèmes sera le récit du framework Quarkus, déjà examiné sur Habré. L'article d'aujourd'hui n'est pas tant consacré à la structure de la « Java subatomique ultra-rapide », mais plutôt aux perspectives que Quarkus apporte à l'Enterprise.

Java et la JVM restent extrêmement populaires, mais lors de l'utilisation de technologies sans serveur et de microservices axés sur le cloud, Java et d'autres langages pour la JVM sont de moins en moins utilisés, car ils prennent trop de mémoire et se chargent trop lentement, ce qui les rend inadaptés à l'utilisation avec des conteneurs à courte durée de vie. Heureusement, cette situation commence à changer grâce à Quarkus.

Java subatomique ultra-rapide a atteint un nouveau niveau !

42 versions, 8 mois de travail communautaire et 177 développeurs incroyables – tout cela a abouti à la sortie en novembre 2019 de Quarkus 1.0, une version qui marque une étape importante dans le développement du projet et propose de nombreuses fonctionnalités intéressantes (vous pouvez en lire plus à propos de cela dans l'annonce).

Aujourd'hui, nous allons expliquer comment Quarkus unit les modèles de programmation impératifs et réactifs sur la base d'un noyau réactif unique. Nous commencerons par un bref aperçu historique, puis nous examinerons en détail en quoi consiste le dualisme du noyau réactif de Quarkus et comment Java-les développeurs peuvent tirer parti de ces avantages.

Les microservices, des architectures orientées événements et serverless-les fonctions sont aujourd'hui, ce qu'on appelle, en plein essor. Récemment, la création d'architectures orientées vers le cloud est devenue beaucoup plus simple et accessible, mais des défis subsistent – surtout pour les développeurs Java. Par exemple, dans le cas des fonctions serverless et des microservices, il y a un besoin urgent de réduire le temps de démarrage, de diminuer l'utilisation de la mémoire et de rendre leur développement plus pratique et agréable. Java a fait quelques améliorations ces dernières années, comme l'optimisation du fonctionnement pour les conteneurs et autres. Cependant, faire fonctionner Java correctement dans un conteneur reste difficile. C'est pourquoi nous commencerons par examiner certaines des complexités internes de Java, qui se manifestent particulièrement lors du développement d'applications Java orientées conteneurs.

Commençons par l'histoire.

Flux et conteneurs

Depuis la version 8u131, Java a commencé à supporter les conteneurs grâce à des améliorations fonctionnalité ergonomique. En particulier, la JVM sait désormais sur combien de cœurs de processeur elle s'exécute et peut configurer les pools de threads en conséquence - généralement des pools fork/join. C'est formidable, mais supposons que nous ayons une application Web traditionnelle utilisant des servlets HTTP et s'exécutant sous Tomcat, Jetty, etc. En conséquence, cette application attribuera un thread distinct à chaque requête et lui permettra de bloquer ce thread en attendant des opérations d'entrée-sortie, comme lors de l'accès à une base de données, à des fichiers ou à d'autres services. Cela signifie que la taille de cette application ne dépend pas du nombre de cœurs disponibles, mais du nombre de requêtes simultanées. De plus, cela signifie que les quotas ou limites dans Kubernetes concernant le nombre de cœurs ne seront pas vraiment utiles ici, et que le résultat final sera un throttling.

Épuisement de la mémoire

Les threads sont de la mémoire. Et les limitations de mémoire à l'intérieur des conteneurs ne sont pas une panacée. Commencez simplement à augmenter le nombre d'applications et de threads, et tôt ou tard vous rencontrerez une augmentation critique de la fréquence des commutations et, par conséquent, une dégradation des performances. De plus, si l'application utilise des frameworks de microservices traditionnels ou se connecte à une base de données, ou utilise le cache, ou consomme de la mémoire d'une autre manière, vous avez absolument besoin d'un outil qui vous permet de voir à l'intérieur de la JVM et de comprendre comment elle gère la mémoire, sans pour autant tuer la JVM elle-même (par exemple, XX:+UseCGroupMemoryLimitForHeap). Et même si, depuis Java 9, la JVM a appris à reconnaître les cgroups et à s'adapter en conséquence, la réservation et la gestion de la mémoire restent des tâches assez complexes.

Quotas et limites

Java 11 a introduit le support des quotas CPU (comme PreferContainerQuotaForCPUCount). Kubernetes propose également un support pour les limites et quotas. Oui, tout cela a du sens, mais si l'application sort à nouveau des limites allouées, nous revenons à la situation où la taille - comme avec les applications Java traditionnelles - est déterminée par le nombre de cœurs avec un thread séparé alloué à chaque requête, donc tout cela n'est pas d'une grande utilité.
De plus, si l'on utilise des quotas et des limites ou des fonctions de mise à l'échelle horizontale (scale-out) de la plateforme sous-jacente de Kubernetes, le problème ne se résout pas de lui-même. Nous dépensons simplement plus de ressources pour résoudre le problème initial ou finissons par un surconsommation des ressources. Et si c'est un système très chargé dans un cloud public accessible au public, nous commençons presque certainement à utiliser plus de ressources que nécessaire.

Et que faire avec tout cela ?

Pour faire simple, il faut utiliser des bibliothèques et des frameworks d'entrée-sortie asynchrones et non bloquants, comme Netty, Vert.x ou Akka. Ils conviennent beaucoup mieux au travail dans des conteneurs en raison de leur nature réactive. Grâce à l'entrée-sortie non bloquante, un même thread peut traiter plusieurs requêtes simultanément. Pendant qu'une requête attend des résultats d'entrée-sortie, le thread qui la traite est libéré et s'occupe d'une autre requête. Et lorsque les résultats d'entrée-sortie arrivent enfin, le traitement de la première requête se poursuit. En alternant le traitement des requêtes dans un même thread, on peut réduire le nombre total de threads et diminuer la consommation de ressources liée au traitement des requêtes.

Avec l'entrée-sortie non bloquante, le nombre de cœurs devient un paramètre clé, car c'est ce qui détermine le nombre de threads d'entrée-sortie qui peuvent s'exécuter en parallèle. Lorsque cela est utilisé correctement, cela permet de répartir efficacement la charge entre les cœurs et de gérer des charges plus élevées avec moins de ressources.

Comment, c'est tout ?

Non, il y a encore autre chose. La programmation réactive aide à mieux utiliser les ressources, mais cela a aussi un coût. En particulier, le code devra être réécrit selon les principes de non-bloquage, et il faudra éviter le blocage des threads d'entrée-sortie. C'est un tout autre modèle de développement et d'exécution. Et bien qu'il existe un grand nombre de bibliothèques utiles, cela représente tout de même un changement radical de la façon de penser habituelle.

Tout d'abord, vous devez apprendre à écrire du code qui s'exécute de manière asynchrone. Dès que vous commencez à utiliser des entrées-sorties non bloquantes, vous devez spécifier clairement ce qui doit se passer lors de la réception d'une réponse à la demande. Il n'est plus possible de bloquer et d'attendre. En revanche, vous pouvez passer des rappels, utiliser la programmation réactive ou des continuations. Mais ce n'est pas tout : pour utiliser des entrées-sorties non bloquantes, vous avez besoin de serveurs et de clients non bloquants, de préférence partout. Dans le cas de HTTP, c'est simple, mais il y a aussi des bases de données, des systèmes de fichiers et bien d'autres choses.

Et bien que la réactivité totale et intégrale offre un maximum d'efficacité, ce changement peut être difficile à digérer en pratique. C'est pourquoi la possibilité de combiner code réactif et impératif devient une condition nécessaire pour :

1. Utiliser efficacement les ressources dans les domaines les plus sollicités du système logiciel ;
2. Utiliser un code au style plus simple dans ses autres parties.

Découvrez Quarkus

En réalité, c'est là toute la philosophie de Quarkus – unir les modèles réactif et impératif dans le cadre d'un même environnement d'exécution.

Au cœur de Quarkus se trouvent Vert.x et Netty, sur lesquels repose une série de frameworks et d'extensions réactifs conçus pour aider le développeur. Quarkus est destiné à la construction non seulement de microservices HTTP, mais aussi d'architectures pilotées par des événements. Grâce à sa nature réactive, il fonctionne très efficacement avec des systèmes de messagerie (Apache Kafka, AMQP, etc.).

Tout le secret réside dans la manière d'utiliser le même moteur réactif pour le code impératif et le code réactif.

Quarkus s'en occupe brillamment. Le choix entre une approche impérative et réactive est évident : utiliser un noyau réactif pour les deux. Et ce sur quoi il aide beaucoup, c’est le code non bloquant rapide qui traite presque tout ce qui passe par le thread de la boucle d'événements (event-loop thread, aussi appelé IO thread). Mais si vous avez des applications REST classiques ou des applications côté client, Quarkus est prêt avec un modèle de programmation impératif. Par exemple, le support HTTP dans Quarkus est construit sur l'utilisation d'un moteur non bloquant et réactif (Eclipse Vert.x et Netty). Toutes les requêtes HTTP reçues par votre application passent d'abord par la boucle d'événements (IO Thread), puis sont envoyées à la partie du code qui gère les requêtes. Selon la destination, le code de gestion des requêtes peut être appelé dans un thread séparé (le soi-disant worker thread, utilisé dans le cas des servlets et Jax-RS) ou utiliser le thread d'entrée-sortie d'origine (le chemin réactif).

Pour les connecteurs des systèmes de transmission de messages, des clients non bloquants sont utilisés, fonctionnant sur le moteur Vert.x. Vous pouvez donc envoyer, recevoir et traiter efficacement des messages depuis des systèmes de type middleware de messaging.

Sur le site Quarkus.io plusieurs bons guides ont été rassemblés pour vous aider à démarrer avec Quarkus :

• Utiliser des routes réactives
• Clients SQL réactifs
• Utiliser Apache Kafka avec la messagerie réactive
• Utiliser l'AMQP avec la messagerie réactive
• Utiliser l'API Vertx

De plus, nous avons préparé des cours pratiques en ligne pour découvrir divers aspects de la programmation réactive, et pour les suivre, il suffit d'un navigateur, aucune IDE n'est nécessaire, et même un ordinateur n'est pas obligatoire. Vous pouvez trouver ces cours ici.

Ressources utiles

• 4 raisons d'essayer Quarkus
• Le site du projet Quarkus – quarkus.io
• Le projet Quarkus sur GitHub – github.com/quarkusio/quarkus
• Le Twitter du projet Quarkus – twitter.com/QuarkusIO
• Le chat du projet Quarkus – quarkusio.zulipchat.com
• Les forums du projet Quarkus – groups.google.com/forum/#!forum/quarkus-dev

10 tutoriels vidéo sur Quarkus pour se familiariser avec le sujet

Comme indiqué sur le site Quarkus.io, Quarkus – c'est Kubernetes- une pile Java orientée, optimisée pour GraalVM et OpenJDK HotSpot, assemblée à partir des meilleures bibliothèques et standards Java.

Pour vous aider à comprendre le sujet, nous avons sélectionné 10 tutoriels vidéo qui couvrent divers aspects de Quarkus et des exemples d'utilisation :

1. Présentation de Quarkus : framework Java de nouvelle génération pour Kubernetes

Auteurs : Thomas Qvarnstrom et Jason Greene
L'objectif du projet Quarkus est de créer une plateforme Java pour Kubernetes et les environnements serverless, tout en combinant les modèles de programmation réactifs et impératifs dans un seul environnement d'exécution, permettant aux développeurs de varier flexiblement leur approche dans un large éventail d'architectures d'applications distribuées. En savoir plus dans la conférence d'introduction ci-dessous.

2. Quarkus : java subatomique ultra-rapide

Auteur : Burr Sutter
Le tutoriel vidéo du séminaire en ligne DevNation Live montre comment utiliser Quarkus pour optimiser les applications Java d'entreprise, APIs, microservices et fonctions serverless dans un environnement Kubernetes/OpenShift, les rendant beaucoup plus petites, plus rapides et évolutives.

3. Quarkus et GraalVM : propulsons Hibernate à des vitesses extrêmes et réduisons-le à des tailles subatomiques

Auteur : Sanne Grinovero
Dans cette présentation, vous découvrirez comment Quarkus a été développé, comment il fonctionne et comment il rend compatibles des bibliothèques complexes comme Hibernate ORM avec les images natives de GraalVM.

4. Apprenons à développer des applications serverless

Auteur : Marthen Luther
La vidéo ci-dessous montre comment créer une simple application Java avec Quarkus et la déployer en tant qu'application serverless sur Knative.

5. Quarkus : codez avec plaisir

Auteur : Edson Yanaga
Un guide vidéo pour créer votre premier projet Quarkus, permettant de comprendre pourquoi Quarkus séduit les développeurs.

6. Java et conteneurs – quel sera leur avenir commun ?

Auteur : Mark Little
Cette présentation présente l'histoire de Java et explique pourquoi Quarkus est l'avenir de Java.

7. Quarkus : java subatomique ultra-rapide

Auteur : Dimitris Andreadis
Aperçu des avantages de Quarkus qui ont été reconnus par les développeurs : simplicité, vitesses ultra-rapides, meilleures bibliothèques et normes.

8. Quarkus et systèmes réactifs subatomiques

Auteur : Clement Escoffier
Grâce à l'intégration avec GraalVM, Quarkus offre une expérience de développement ultra-rapide et un environnement d'exécution subatomique. L'auteur parle de l'aspect réactif de Quarkus et de la façon de l'utiliser pour créer des applications réactives et des applications de streaming.

9. Quarkus et développement rapide d'applications dans Eclipse MicroProfile

Auteur : John Clingan
En combinant Eclipse MicroProfile et Quarkus, les développeurs peuvent créer des applications conteneurisées MicroProfile entièrement fonctionnelles, qui se lancent en quelques dizaines de millisecondes. La vidéo explique en détail comment coder une application conteneurisée MicroProfile pour un déploiement sur la plateforme Kubernetes.

10. Java, version « Turbo »

Auteur : Marcus Biel
L'auteur montre comment utiliser Quarkus pour créer des conteneurs Java super petits et super rapides, permettant de réaliser une véritable percée, notamment dans les environnements sans serveur.

Source : habr.com