{"id":74795,"date":"2020-03-20T20:42:21","date_gmt":"2020-03-20T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie"},"modified":"2020-03-20T20:42:21","modified_gmt":"2020-03-20T17:42:21","slug":"kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Comment Quarkus combine la programmation imp\u00e9rative et r\u00e9active","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cette ann\u00e9e, nous pr\u00e9voyons de d\u00e9velopper s\u00e9rieusement les th\u00e8mes des conteneurs, Java Cloud-Native<\/a><\/noindex> et Kubernetes<\/a><\/noindex>. Une suite logique de ces th\u00e8mes sera le r\u00e9cit du framework Quarkus, d\u00e9j\u00e0 examin\u00e9<\/a><\/noindex> sur Habr\u00e9. L'article d'aujourd'hui n'est pas tant consacr\u00e9 \u00e0 la structure de la \u00ab Java subatomique ultra-rapide \u00bb, mais plut\u00f4t aux perspectives que Quarkus apporte \u00e0 l'Enterprise.<\/p>\n

\"Comment
\n
\nJava et la JVM restent extr\u00eamement populaires, mais lors de l'utilisation de technologies sans serveur et de microservices ax\u00e9s sur le cloud, Java et d'autres langages pour la JVM sont de moins en moins utilis\u00e9s, car ils prennent trop de m\u00e9moire et se chargent trop lentement, ce qui les rend inadapt\u00e9s \u00e0 l'utilisation avec des conteneurs \u00e0 courte dur\u00e9e de vie. Heureusement, cette situation commence \u00e0 changer gr\u00e2ce \u00e0 Quarkus.
\n<\/a><\/noindex><\/p>\n

Java subatomique ultra-rapide a atteint un nouveau niveau !<\/h3>\n

\n42 versions, 8 mois de travail communautaire et 177 d\u00e9veloppeurs incroyables \u2013 tout cela a abouti \u00e0 la sortie en novembre 2019 de Quarkus 1.0<\/a><\/noindex>, une version qui marque une \u00e9tape importante dans le d\u00e9veloppement du projet et propose de nombreuses fonctionnalit\u00e9s int\u00e9ressantes (vous pouvez en lire plus \u00e0 propos de cela dans l'annonce<\/a><\/noindex>).<\/p>\n

Aujourd'hui, nous allons expliquer comment Quarkus unit les mod\u00e8les de programmation imp\u00e9ratifs et r\u00e9actifs sur la base d'un noyau r\u00e9actif unique. Nous commencerons par un bref aper\u00e7u historique, puis nous examinerons en d\u00e9tail en quoi consiste le dualisme du noyau r\u00e9actif de Quarkus et comment Java<\/a><\/noindex>-les d\u00e9veloppeurs peuvent tirer parti de ces avantages.<\/p>\n

Les microservices<\/a><\/noindex>, des architectures orient\u00e9es \u00e9v\u00e9nements<\/a><\/noindex> et serverless<\/a><\/noindex>-les fonctions sont aujourd'hui, ce qu'on appelle, en plein essor. R\u00e9cemment, la cr\u00e9ation d'architectures orient\u00e9es vers le cloud est devenue beaucoup plus simple et accessible, mais des d\u00e9fis subsistent \u2013 surtout pour les d\u00e9veloppeurs Java. Par exemple, dans le cas des fonctions serverless et des microservices, il y a un besoin urgent de r\u00e9duire le temps de d\u00e9marrage, de diminuer l'utilisation de la m\u00e9moire et de rendre leur d\u00e9veloppement plus pratique et agr\u00e9able. Java a fait quelques am\u00e9liorations ces derni\u00e8res ann\u00e9es, 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\u00e9s internes de Java, qui se manifestent particuli\u00e8rement lors du d\u00e9veloppement d'applications Java orient\u00e9es conteneurs.<\/p>\n

Commen\u00e7ons par l'histoire.<\/p>\n

\"Comment<\/p>\n

Flux et conteneurs<\/h3>\n

\nDepuis la version 8u131, Java a commenc\u00e9 \u00e0 supporter les conteneurs gr\u00e2ce \u00e0 des am\u00e9liorations fonctionnalit\u00e9 ergonomique. En particulier, la JVM sait d\u00e9sormais sur combien de c\u0153urs de processeur elle s'ex\u00e9cute et peut configurer les pools de threads en cons\u00e9quence - g\u00e9n\u00e9ralement des pools fork\/join. C'est formidable, mais supposons que nous ayons une application Web traditionnelle utilisant des servlets HTTP et s'ex\u00e9cutant sous Tomcat, Jetty, etc. En cons\u00e9quence, cette application attribuera un thread distinct \u00e0 chaque requ\u00eate et lui permettra de bloquer ce thread en attendant des op\u00e9rations d'entr\u00e9e-sortie, comme lors de l'acc\u00e8s \u00e0 une base de donn\u00e9es, \u00e0 des fichiers ou \u00e0 d'autres services. Cela signifie que la taille de cette application ne d\u00e9pend pas du nombre de c\u0153urs disponibles, mais du nombre de requ\u00eates simultan\u00e9es. De plus, cela signifie que les quotas ou limites dans Kubernetes concernant le nombre de c\u0153urs ne seront pas vraiment utiles ici, et que le r\u00e9sultat final sera un throttling.<\/p>\n

\u00c9puisement de la m\u00e9moire<\/h3>\n

\nLes threads sont de la m\u00e9moire. Et les limitations de m\u00e9moire \u00e0 l'int\u00e9rieur des conteneurs ne sont pas une panac\u00e9e. Commencez simplement \u00e0 augmenter le nombre d'applications et de threads, et t\u00f4t ou tard vous rencontrerez une augmentation critique de la fr\u00e9quence des commutations et, par cons\u00e9quent, une d\u00e9gradation des performances. De plus, si l'application utilise des frameworks de microservices traditionnels ou se connecte \u00e0 une base de donn\u00e9es, ou utilise le cache, ou consomme de la m\u00e9moire d'une autre mani\u00e8re, vous avez absolument besoin d'un outil qui vous permet de voir \u00e0 l'int\u00e9rieur de la JVM et de comprendre comment elle g\u00e8re la m\u00e9moire, sans pour autant tuer la JVM elle-m\u00eame (par exemple, XX:+UseCGroupMemoryLimitForHeap). Et m\u00eame si, depuis Java 9, la JVM a appris \u00e0 reconna\u00eetre les cgroups et \u00e0 s'adapter en cons\u00e9quence, la r\u00e9servation et la gestion de la m\u00e9moire restent des t\u00e2ches assez complexes.<\/p>\n

Quotas et limites<\/h3>\n

\nJava 11 a introduit le support des quotas CPU (comme PreferContainerQuotaForCPUCount). Kubernetes propose \u00e9galement un support pour les limites et quotas. Oui, tout cela a du sens, mais si l'application sort \u00e0 nouveau des limites allou\u00e9es, nous revenons \u00e0 la situation o\u00f9 la taille - comme avec les applications Java traditionnelles - est d\u00e9termin\u00e9e par le nombre de c\u0153urs avec un thread s\u00e9par\u00e9 allou\u00e9 \u00e0 chaque requ\u00eate, donc tout cela n'est pas d'une grande utilit\u00e9.
\nDe plus, si l'on utilise des quotas et des limites ou des fonctions de mise \u00e0 l'\u00e9chelle horizontale (scale-out) de la plateforme sous-jacente de Kubernetes, le probl\u00e8me ne se r\u00e9sout pas de lui-m\u00eame. Nous d\u00e9pensons simplement plus de ressources pour r\u00e9soudre le probl\u00e8me initial ou finissons par un surconsommation des ressources. Et si c'est un syst\u00e8me tr\u00e8s charg\u00e9 dans un cloud public accessible au public, nous commen\u00e7ons presque certainement \u00e0 utiliser plus de ressources que n\u00e9cessaire.<\/p>\n

Et que faire avec tout cela ?<\/h3>\n

\nPour faire simple, il faut utiliser des biblioth\u00e8ques et des frameworks d'entr\u00e9e-sortie asynchrones et non bloquants, comme Netty, Vert.x<\/a><\/noindex> ou Akka. Ils conviennent beaucoup mieux au travail dans des conteneurs en raison de leur nature r\u00e9active. Gr\u00e2ce \u00e0 l'entr\u00e9e-sortie non bloquante, un m\u00eame thread peut traiter plusieurs requ\u00eates simultan\u00e9ment. Pendant qu'une requ\u00eate attend des r\u00e9sultats d'entr\u00e9e-sortie, le thread qui la traite est lib\u00e9r\u00e9 et s'occupe d'une autre requ\u00eate. Et lorsque les r\u00e9sultats d'entr\u00e9e-sortie arrivent enfin, le traitement de la premi\u00e8re requ\u00eate se poursuit. En alternant le traitement des requ\u00eates dans un m\u00eame thread, on peut r\u00e9duire le nombre total de threads et diminuer la consommation de ressources li\u00e9e au traitement des requ\u00eates.<\/p>\n

Avec l'entr\u00e9e-sortie non bloquante, le nombre de c\u0153urs devient un param\u00e8tre cl\u00e9, car c'est ce qui d\u00e9termine le nombre de threads d'entr\u00e9e-sortie qui peuvent s'ex\u00e9cuter en parall\u00e8le. Lorsque cela est utilis\u00e9 correctement, cela permet de r\u00e9partir efficacement la charge entre les c\u0153urs et de g\u00e9rer des charges plus \u00e9lev\u00e9es avec moins de ressources.<\/p>\n

Comment, c'est tout ?<\/h3>\n

\nNon, il y a encore autre chose. La programmation r\u00e9active aide \u00e0 mieux utiliser les ressources, mais cela a aussi un co\u00fbt. En particulier, le code devra \u00eatre r\u00e9\u00e9crit selon les principes de non-bloquage, et il faudra \u00e9viter le blocage des threads d'entr\u00e9e-sortie. C'est un tout autre mod\u00e8le de d\u00e9veloppement et d'ex\u00e9cution. Et bien qu'il existe un grand nombre de biblioth\u00e8ques utiles, cela repr\u00e9sente tout de m\u00eame un changement radical de la fa\u00e7on de penser habituelle.<\/p>\n

Tout d'abord, vous devez apprendre \u00e0 \u00e9crire du code qui s'ex\u00e9cute de mani\u00e8re asynchrone. D\u00e8s que vous commencez \u00e0 utiliser des entr\u00e9es-sorties non bloquantes, vous devez sp\u00e9cifier clairement ce qui doit se passer lors de la r\u00e9ception d'une r\u00e9ponse \u00e0 la demande. Il n'est plus possible de bloquer et d'attendre. En revanche, vous pouvez passer des rappels, utiliser la programmation r\u00e9active ou des continuations. Mais ce n'est pas tout : pour utiliser des entr\u00e9es-sorties non bloquantes, vous avez besoin de serveurs et de clients non bloquants, de pr\u00e9f\u00e9rence partout. Dans le cas de HTTP, c'est simple, mais il y a aussi des bases de donn\u00e9es, des syst\u00e8mes de fichiers et bien d'autres choses.<\/p>\n

Et bien que la r\u00e9activit\u00e9 totale et int\u00e9grale offre un maximum d'efficacit\u00e9, ce changement peut \u00eatre difficile \u00e0 dig\u00e9rer en pratique. C'est pourquoi la possibilit\u00e9 de combiner code r\u00e9actif et imp\u00e9ratif devient une condition n\u00e9cessaire pour :<\/p>\n

    \n
  1. Utiliser efficacement les ressources dans les domaines les plus sollicit\u00e9s du syst\u00e8me logiciel ;<\/li>\n
  2. Utiliser un code au style plus simple dans ses autres parties.<\/li>\n<\/ol>\n

    <\/p>\n

    D\u00e9couvrez Quarkus<\/h3>\n

    \nEn r\u00e9alit\u00e9, c'est l\u00e0 toute la philosophie de Quarkus \u2013 unir les mod\u00e8les r\u00e9actif et imp\u00e9ratif dans le cadre d'un m\u00eame environnement d'ex\u00e9cution.<\/p>\n

    Au c\u0153ur de Quarkus se trouvent Vert.x et Netty, sur lesquels repose une s\u00e9rie de frameworks et d'extensions r\u00e9actifs con\u00e7us pour aider le d\u00e9veloppeur. Quarkus est destin\u00e9 \u00e0 la construction non seulement de microservices HTTP, mais aussi d'architectures pilot\u00e9es par des \u00e9v\u00e9nements. Gr\u00e2ce \u00e0 sa nature r\u00e9active, il fonctionne tr\u00e8s efficacement avec des syst\u00e8mes de messagerie (Apache Kafka, AMQP, etc.).<\/p>\n

    Tout le secret r\u00e9side dans la mani\u00e8re d'utiliser le m\u00eame moteur r\u00e9actif pour le code imp\u00e9ratif et le code r\u00e9actif.<\/p>\n

    \"Comment<\/p>\n

    Quarkus s'en occupe brillamment. Le choix entre une approche imp\u00e9rative et r\u00e9active est \u00e9vident : utiliser un noyau r\u00e9actif pour les deux. Et ce sur quoi il aide beaucoup, c\u2019est le code non bloquant rapide qui traite presque tout ce qui passe par le thread de la boucle d'\u00e9v\u00e9nements (event-loop thread, aussi appel\u00e9 IO thread). Mais si vous avez des applications REST classiques ou des applications c\u00f4t\u00e9 client, Quarkus est pr\u00eat avec un mod\u00e8le de programmation imp\u00e9ratif. Par exemple, le support HTTP dans Quarkus est construit sur l'utilisation d'un moteur non bloquant et r\u00e9actif (Eclipse Vert.x et Netty). Toutes les requ\u00eates HTTP re\u00e7ues par votre application passent d'abord par la boucle d'\u00e9v\u00e9nements (IO Thread), puis sont envoy\u00e9es \u00e0 la partie du code qui g\u00e8re les requ\u00eates. Selon la destination, le code de gestion des requ\u00eates peut \u00eatre appel\u00e9 dans un thread s\u00e9par\u00e9 (le soi-disant worker thread, utilis\u00e9 dans le cas des servlets et Jax-RS) ou utiliser le thread d'entr\u00e9e-sortie d'origine (le chemin r\u00e9actif).<\/p>\n

    \"Comment<\/p>\n

    Pour les connecteurs des syst\u00e8mes de transmission de messages, des clients non bloquants sont utilis\u00e9s, fonctionnant sur le moteur Vert.x. Vous pouvez donc envoyer, recevoir et traiter efficacement des messages depuis des syst\u00e8mes de type middleware de messaging.<\/p>\n

    Sur le site Quarkus.io<\/a><\/noindex> plusieurs bons guides ont \u00e9t\u00e9 rassembl\u00e9s pour vous aider \u00e0 d\u00e9marrer avec Quarkus :<\/p>\n