Salut tout le monde! Ceci est le deuxième article de notre série sur Quarkus. Aujourd'hui, nous parlerons de la compilation native.
est une pile Java conçue pour . Bien qu'il y ait certainement beaucoup plus à faire ici, nous avons fait beaucoup de bon travail sur de nombreux aspects, notamment l'optimisation de la JVM et d'un certain nombre de frameworks. L'une des fonctionnalités de Quarkus qui a suscité un intérêt croissant de la part des développeurs est son approche complète et transparente consistant à transformer le code Java en fichiers exécutables pour un système d'exploitation spécifique (appelée « compilation native »), similaire au C et au C++, où une telle compilation se produit généralement à la fin d’un cycle de construction, de test et de déploiement.
Et bien que la compilation native soit importante, comme nous le montrerons ci-dessous, il convient de noter que Quarkus fonctionne très bien sur la machine Java la plus courante, OpenJDK Hotspot, grâce aux améliorations de performances que nous avons implémentées dans toute la pile. Par conséquent, la compilation native doit être considérée comme un bonus supplémentaire pouvant être utilisé selon les besoins ou les besoins. En fait, Quarkus s'appuie fortement sur OpenJDK pour les images natives. Et le mode développement, chaleureusement accepté par les développeurs, garantit un test presque instantané des modifications grâce aux capacités avancées d'exécution de code dynamique implémentées dans Hotspot. De plus, lors de la création d'images GraalVM natives, la bibliothèque de classes OpenJDK et les fonctionnalités HotSpot sont utilisées.
Alors pourquoi avez-vous besoin d’une compilation native si tout est déjà parfaitement optimisé ? Nous tenterons de répondre à cette question ci-dessous.
Commençons par l'évidence : Red Hat possède une vaste expérience dans l'optimisation des JVM, des piles et des frameworks pendant le développement de projets. , y compris:
- Le premier serveur d'applications à fonctionner dans le cloud sur la plateforme .
- Le premier serveur d'applications fonctionnant sur ordinateur .
- Le premier serveur d'applications à fonctionner sur .
- Une gamme de projets exécutés sur des appareils .
Nous sommes confrontés aux défis liés à l'exécution d'applications Java dans le cloud et sur des appareils aux ressources limitées (lire : IoT) depuis de nombreuses années et avons appris à tirer le meilleur parti de la JVM en termes de performances et d'optimisation de la mémoire. Comme beaucoup d’autres, nous travaillons depuis longtemps avec la compilation native d’applications Java via , , et même et nous sommes bien conscients des avantages et des inconvénients de cette approche (par exemple, le dilemme de choisir entre l'universalité du « construire une fois – exécuter n'importe où » et le fait que les applications compilées sont plus petites et s'exécutent plus rapidement).
Pourquoi est-il important de considérer ces avantages et inconvénients ? Car dans certaines situations leur ratio devient déterminant :
- Par exemple, dans des environnements sans serveur/pilotés par événements où en temps réel (dur ou soft) afin d'avoir le temps de réagir aux événements. Contrairement aux services persistants de longue durée, la durée d'un démarrage à froid augmente ici de manière critique le temps de réponse à une requête. La JVM prend encore beaucoup de temps à démarrer, et bien que cela puisse être réduit dans certains cas par des méthodes purement matérielles, la différence entre une seconde et 5 millisecondes peut faire la différence entre la vie et la mort. Oui, ici vous pouvez jouer en créant une réserve chaude de machines Java (ce que nous avons fait par exemple avec ), mais cela ne garantit pas en soi qu'il y aura suffisamment de JVM pour traiter les requêtes à mesure que la charge évolue. Et d’un point de vue économique, ce n’est probablement pas l’option la plus correcte.
- De plus, un autre aspect revient souvent : la multilocation. Malgré le fait que les JVM soient très proches des systèmes d'exploitation dans leurs capacités, elles ne sont toujours pas capables de faire ce à quoi nous sommes si habitués sous Linux : isoler les processus. Par conséquent, la défaillance d’un thread peut faire tomber l’ensemble de la machine Java. De nombreuses personnes tentent de contourner cet inconvénient en dédiant une JVM distincte à l'application de chaque utilisateur afin de minimiser les conséquences d'une panne. C'est tout à fait logique, mais cela ne correspond pas bien à la mise à l'échelle.
- De plus, pour les applications orientées cloud, un indicateur important est la densité des services sur l'hôte. Transition vers la méthodologie , les microservices et Kubernetes augmentent le nombre de machines Java par application. Autrement dit, d'une part, tout cela offre élasticité et fiabilité, mais en même temps, la consommation de mémoire de base en termes de service augmente également, et certaines de ces dépenses ne sont pas toujours strictement nécessaires. Les fichiers exécutables compilés statiquement bénéficient ici de diverses techniques d'optimisation, telles que l'élimination des codes morts de bas niveau, lorsque l'image finale inclut uniquement les parties des frameworks (y compris le JDK lui-même) que le service utilise réellement. Par conséquent, la compilation native de Quarkus permet de placer de manière dense les instances de service sur l'hôte sans compromettre la sécurité.
En fait, les arguments ci-dessus suffisent déjà à comprendre la justification de la compilation native du point de vue des participants au projet Quarkus. Cependant, il existe une autre raison, non technique, mais également importante : ces dernières années, de nombreux programmeurs et sociétés de développement ont abandonné Java au profit de nouveaux langages de programmation, estimant que Java, avec ses JVM, ses piles et ses frameworks, est devenu trop gourmand en mémoire, trop lent, etc.
Cependant, l’habitude d’utiliser le même outil pour résoudre n’importe quel problème est . Parfois, il vaut mieux prendre du recul et chercher autre chose. Et si Quarkus incite les gens à réfléchir et à réfléchir, alors c'est bon pour l'ensemble de l'écosystème Java. Quarkus représente une vision innovante de la manière de créer des applications plus efficaces, rendant Java plus pertinent pour les nouvelles architectures d'applications telles que le sans serveur. De plus, en raison de son extensibilité, Quarkus disposera, espérons-le, d'un écosystème complet d'extensions Java, augmentant considérablement le nombre de frameworks prenant en charge la compilation native dans les applications prêtes à l'emploi.
Source: habr.com