Bonjour à tous ! Voici le deuxième article de notre série sur Quarkus – aujourd'hui, nous allons parler de la compilation native.
– est une pile Java conçue pour . Et bien qu'il reste encore beaucoup à faire ici, nous avons bien travaillé sur de nombreux aspects, y compris l'optimisation de la JVM et de plusieurs frameworks. L'une des caractéristiques de Quarkus qui a suscité un vif intérêt parmi les développeurs est son approche intégrée et transparente pour transformer le code Java en fichiers exécutables pour un système d'exploitation spécifique (ce que l'on appelle la « compilation native ») par analogie avec C et C++, où cette compilation a généralement lieu à la fin d'un cycle de construction, de test et de déploiement.
Et bien que la compilation native, comme nous allons le montrer ci-dessous, soit importante, il est bon de noter que Quarkus fonctionne effectivement très bien même sur une machine Java classique avec OpenJDK Hotspot grâce aux améliorations de performance que nous avons réalisées dans toute la pile. Par conséquent, la compilation native doit être envisagée comme un bonus supplémentaire que l'on peut utiliser par préférence ou nécessité. En fait, en ce qui concerne les images natives, Quarkus s'appuie dans une large mesure sur OpenJDK. De plus, le mode dev, très bien accueilli par les développeurs, permet de tester presque instantanément les changements grâce à des capacités avancées d'exécution dynamique du code mises en œuvre dans Hotspot. En outre, lors de la création d'images natives, GraalVM utilise la bibliothèque de classes d'OpenJDK et les capacités de HotSpot.
Alors, pourquoi la compilation native est-elle nécessaire, si tout est déjà si bien optimisé ? C'est la question à laquelle nous allons tenter de répondre ci-dessous.
Commençons par l'évidence : Red Hat possède une vaste expérience dans l'optimisation de la JVM, des piles et des frameworks au cours du développement du projet , y compris :
- Le premier serveur d'applications pour le cloud sur la plateforme .
- Le premier serveur d'applications pour les ordinateurs .
- Le premier serveur d'applications pour fonctionner sur .
- Une série de projets fonctionnant sur des appareils .
Nous travaillons depuis de nombreuses années sur les problèmes de démarrage d'applications Java dans le cloud et sur des appareils à ressources limitées (lire, IoT) et nous avons appris à tirer le meilleur parti de la JVM en termes de performance 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 Nous sommes bien conscients des avantages et inconvénients de cette approche (par exemple, le dilemme entre l'universalité du « build once – run-anywhere » et le fait que les applications compilées occupent moins d'espace et démarrent plus rapidement).
Pourquoi est-il si important de prendre en compte ces avantages et inconvénients ? Parce que dans certaines situations, leur rapport devient déterminant :
- Par exemple, dans les environnements sans serveur / basés sur des événements, où en temps réel (dur ou doux) pour pouvoir réagir aux événements. Contrairement aux services persistants de longue durée, ici, la durée du démarrage à froid augmente de manière critique le temps de réponse à une demande. Le démarrage de la JVM prend encore un temps considérable, et bien que dans certains cas, il soit possible de le réduire par des méthodes matérielles, la différence entre une seconde et 5 millisecondes peut être une question de vie ou de mort. Oui, il est possible de jouer avec la création de réserves chaudes de machines Java (ce que nous avons fait par exemple lors de ), mais cela ne garantit pas à lui seul un nombre adéquat de JVM pour traiter les demandes à mesure que la charge augmente. Et d'un point de vue économique, ce n'est certainement pas la meilleure option.
- Ensuite, il y a cet aspect souvent mentionné, à savoir la multi-tenance. Bien que la JVM ait beaucoup évolué pour se rapprocher des systèmes d'exploitation, elle n'est toujours pas capable de faire ce à quoi nous sommes si habitués sous Linux – isoler les processus. Par conséquent, une défaillance d'un thread peut paralyser toute la machine Java. Beaucoup essaient de contourner cet inconvénient en allouant une JVM distincte pour chaque utilisateur, afin de minimiser les conséquences d'un échec. Cela a du sens, mais cela ne s'accorde pas bien avec l'évolutivité.
- De plus, pour les applications orientées cloud, un indicateur important est la densité des services sur l'hôte. Le passage à la méthodologie , les microservices et Kubernetes augmentent le nombre de machines Java par application. Cela signifie que, d'une part, cela offre de l'élasticité et de la fiabilité, mais en même temps, la consommation de mémoire de base augmente par service, bien qu'une partie de ces coûts ne soit pas toujours strictement nécessaire. Les fichiers exécutables compilés statiquement en profitent grâce à diverses techniques d'optimisation, comme l'élimination du code mort de bas niveau, où seules les parties des frameworks (y compris le JDK lui-même) réellement utilisées par le service sont incluses dans l'image finale. C'est pourquoi la compilation native de Quarkus aide à placer plus densément les instances de services sur l'hôte sans compromettre la sécurité.
En réalité, 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 tout aussi importante : ces dernières années, de nombreux programmeurs et entreprises de développement ont abandonné Java au profit de nouveaux langages de programmation, estimant que Java, avec ses JVM, ses stacks et ses frameworks, était devenue trop gourmande en mémoire, trop lente, etc.
Cependant, l'habitude d'utiliser le même outil pour résoudre tous les problèmes – . Parfois, il est préférable de prendre du recul et de chercher autre chose. Et si Quarkus pousse les gens à faire une pause et à réfléchir, c'est bon pour tout l'écosystème Java. Quarkus incarne une approche novatrice de la création d'applications plus efficaces, rendant Java plus pertinent pour les nouvelles architectures d'applications, telles que serverless. De plus, grâce à sa modularité, nous espérons que Quarkus bénéficiera d'un véritable écosystème d'extensions Java, augmentant considérablement le nombre de frameworks qui prendront en charge la compilation native dans les applications dès le départ.
Source : habr.com
