{"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\/it\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Come Quarkus unisce programmazione imperativa e reattiva","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Quest'anno prevediamo di sviluppare seriamente i temi dei container, Java Cloud-Native<\/a><\/noindex> e Kubernetes<\/a><\/noindex>. Un seguito logico a questi temi sar\u00e0 la discussione sul framework Quarkus, gi\u00e0 esaminato<\/a><\/noindex> su Habr. L'articolo di oggi non si concentra tanto sull'architettura della \u00abJava subatomica superveloce\u00bb, quanto sulle prospettive che Quarkus porta nel mondo Enterprise.<\/p>\n

\"Come
\n
\nJava e la JVM sono ancora eccezionalmente popolari, ma quando si tratta di tecnologie serverless e microservizi orientati al cloud, Java e altri linguaggi per la JVM vengono utilizzati sempre meno, in quanto occupano troppo spazio in memoria e si caricano troppo lentamente, risultando quindi poco adatti per essere utilizzati con container a breve durata. Fortunatamente, questa situazione sta iniziando a cambiare grazie a Quarkus.
\n<\/a><\/noindex><\/p>\n

La Java subatomica superveloce ha raggiunto un nuovo livello!<\/h3>\n

\n42 release, 8 mesi di lavoro della comunit\u00e0 e 177 straordinari sviluppatori \u2013 il risultato di tutto ci\u00f2 \u00e8 stata la pubblicazione nel novembre 2019 di Quarkus 1.0<\/a><\/noindex>, una release che segna una tappa importante nello sviluppo del progetto e offre molte funzionalit\u00e0 e possibilit\u00e0 interessanti (puoi leggerne di pi\u00f9 in comunicato<\/a><\/noindex>).<\/p>\n

Oggi parleremo di come Quarkus unisca i modelli di programmazione imperativa e reattiva su una base di un unico nucleo reattivo. Inizieremo con una breve escursione nella storia, per poi analizzare nei dettagli in cosa consiste il dualismo del nucleo reattivo di Quarkus e come Java<\/a><\/noindex>-gli sviluppatori possono sfruttare questi vantaggi.<\/p>\n

Microservizi<\/a><\/noindex>, architetture basate su eventi<\/a><\/noindex> e serverless<\/a><\/noindex>-le funzioni \u2013 tutto questo oggi, per cos\u00ec dire, \u00e8 in crescita. Recentemente, la creazione di architetture orientate al cloud \u00e8 diventata molto pi\u00f9 semplice e accessibile, ma i problemi rimangono, soprattutto per gli sviluppatori Java. Ad esempio, nel caso delle funzioni serverless e dei microservizi, c'\u00e8 una forte necessit\u00e0 di ridurre il tempo di avvio, diminuire il consumo di memoria e rendere lo sviluppo pi\u00f9 comodo e piacevole. Negli ultimi anni, Java ha introdotto diversi miglioramenti, come funzionalit\u00e0 ergonomiche ottimizzate per i container e altro. Tuttavia, ottenere un funzionamento normale di Java in un container \u00e8 ancora complicato. Pertanto, inizieremo esaminando alcune delle complessit\u00e0 interne di Java, che si manifestano in modo particolarmente acuto durante lo sviluppo di applicazioni Java orientate ai container.<\/p>\n

Per cominciare, diamo un'occhiata alla storia.<\/p>\n

\"Come<\/p>\n

Thread e container<\/h3>\n

\nA partire dalla versione 8u131, Java ha iniziato a supportare pi\u00f9 o meno i container grazie a miglioramenti nelle funzionalit\u00e0 ergonomiche. In particolare, ora la JVM sa su quanti core di elaborazione sta girando e pu\u00f2 configurare correttamente i pool di thread \u2013 di solito, pool fork\/join. Certamente, \u00e8 ottimo, ma supponiamo di avere un'applicazione web tradizionale che utilizza servlet HTTP e che gira su Tomcat, Jetty e simili. In tal caso, questa applicazione fornisce a ogni richiesta un thread separato e consente di bloccare quel thread in attesa di operazioni di input\/output, ad esempio quando si accede a un database, a file o ad altri servizi. Questo significa che la dimensione di tale applicazione non dipende dal numero di core disponibili, ma dal numero di richieste simultanee. Inoltre, ci\u00f2 implica che le quote o i limiti in Kubernetes per il numero di core non aiutano molto, e la situazione alla fine si risolver\u00e0 con il throttling.<\/p>\n

Esaurimento della memoria<\/h3>\n

\nI flussi sono memoria. Le limitazioni interne ai contenitori non sono affatto una panacea. Iniziate semplicemente ad aumentare il numero di applicazioni e flussi, e prima o poi vi troverete a fronteggiare una crescita critica della frequenza di switching e, di conseguenza, una degradazione delle prestazioni. Inoltre, se l'applicazione utilizza framework microservizi tradizionali o si connette a un database, o utilizza la memorizzazione nella cache, o in qualche altro modo consuma memoria, \u00e8 chiaro che avete bisogno di uno strumento che consenta di guardare dentro la JVM e vedere come gestisce la memoria, senza uccidere la JVM stessa (ad esempio, XX:+UseCGroupMemoryLimitForHeap). E anche se a partire da Java 9 la JVM ha imparato a capire i cgroups e ad adattarsi di conseguenza, la riservazione e la gestione della memoria rimangono un compito piuttosto complesso.<\/p>\n

Quote e limiti<\/h3>\n

\nCon Java 11 \u00e8 stata introdotta la supporto per le quote di CPU (come PreferContainerQuotaForCPUCount). Kubernetes offre anche supporto per limiti e quote. S\u00ec, tutto questo ha senso, ma se l'applicazione supera di nuovo la quota assegnata, torniamo al punto in cui la dimensione - come nel caso delle applicazioni Java tradizionali - \u00e8 definita dal numero di core e dall'assegnazione di un thread separato per ogni richiesta, quindi ne deriva poco.
\nInoltre, se si utilizzano quote e limiti o le funzionalit\u00e0 di scalabilit\u00e0 orizzontale (scale-out) della piattaforma alla base di Kubernetes, il problema non si risolve da solo. Stiamo semplicemente spendendo pi\u00f9 risorse per risolvere il problema originale o finiamo per sprecare risorse. E se si tratta di un sistema ad alta disponibilit\u00e0 nel cloud pubblico, \u00e8 quasi certo che cominciamo a utilizzare pi\u00f9 risorse di quelle realmente necessarie.<\/p>\n

E cosa fare con tutto questo?<\/h3>\n

\nIn parole semplici, si devono utilizzare librerie e framework di I\/O asincroni e non bloccanti come Netty, Vert.x<\/a><\/noindex> o Akka. Sono decisamente pi\u00f9 adatti per lavorare in contenitori grazie alla loro natura reattiva. Grazie all'input\/output non bloccante, lo stesso thread pu\u00f2 gestire simultaneamente pi\u00f9 richieste. Mentre una richiesta aspetta i risultati dell'input\/output, il thread che la gestisce viene liberato e si occupa di un'altra richiesta. Quando i risultati dell'input\/output arrivano infine, la elaborazione della prima richiesta continua. Alternando la gestione delle richieste all'interno dello stesso thread, \u00e8 possibile ridurre il numero totale di thread e diminuire il consumo di risorse nella gestione delle richieste.<\/p>\n

Con l'input\/output non bloccante, il numero di core diventa un parametro chiave, poich\u00e9 determina il numero di thread di input\/output che possono essere eseguiti in parallelo. Se usato correttamente, consente di distribuire efficacemente il carico tra i core e gestire carichi pi\u00f9 elevati con risorse inferiori.<\/p>\n

Come, e questo \u00e8 tutto?<\/h3>\n

\nNo, c'\u00e8 ancora qualcos'altro. La programmazione reattiva aiuta a sfruttare meglio le risorse, ma ha anche un costo. In particolare, sar\u00e0 necessario riscrivere il codice secondo i principi della non bloccabilit\u00e0 ed evitare di bloccare i thread di input\/output. E questo \u00e8 un modello di sviluppo e di esecuzione completamente diverso. Anche se ci sono molte librerie utili, si tratta comunque di un cambiamento radicale nel modo di pensare.<\/p>\n

Prima di tutto, \u00e8 necessario imparare a scrivere codice che si esegue in modo asincrono. Una volta iniziato a utilizzare l'input\/output non bloccante, \u00e8 necessario specificare esplicitamente cosa deve accadere quando si riceve una risposta alla richiesta. Non \u00e8 pi\u00f9 possibile semplicemente bloccare e aspettare. In cambio, \u00e8 possibile passare callback, utilizzare la programmazione reattiva o continuazioni. E non \u00e8 tutto: per utilizzare l'input\/output non bloccante, servono anche server e client non bloccanti, e idealmente ovunque. Nel caso dell'HTTP \u00e8 semplice, ma ci sono anche database, sistemi di file e molto altro.<\/p>\n

E sebbene la reattivit\u00e0 totale offra la massima efficienza, un tale cambiamento pu\u00f2 essere difficile da digerire nella pratica. Pertanto, la possibilit\u00e0 di combinare codice reattivo e imperativo diventa una condizione necessaria per:<\/p>\n

    \n
  1. Utilizzare in modo efficace le risorse nelle aree pi\u00f9 cariche del sistema software;<\/li>\n
  2. Utilizzare un codice pi\u00f9 semplice nello stile nelle altre parti.<\/li>\n<\/ol>\n

    <\/p>\n

    Presentiamo Quarkus<\/h3>\n

    \nIn effetti, questo \u00e8 il punto di Quarkus: unire i modelli reattivi e imperativi all'interno di un unico ambiente di esecuzione.<\/p>\n

    Alla base di Quarkus ci sono Vert.x e Netty, sopra i quali viene utilizzata una serie di framework e estensioni reattive, progettate per aiutare lo sviluppatore. Quarkus \u00e8 destinato alla creazione non solo di microservizi HTTP, ma anche di architetture basate su eventi. Grazie alla sua natura reattiva, lavora molto efficacemente con i sistemi di messaggistica (Apache Kafka, AMQP, ecc.).<\/p>\n

    La vera astuzia sta nel come utilizzare lo stesso motore reattivo sia per il codice imperativo che per quello reattivo.<\/p>\n

    \"Come<\/p>\n

    Quarkus riesce a farlo splendidamente. La scelta tra imperativo e reattivo \u00e8 chiara: utilizzare il nucleo reattivo per entrambi. E ci\u00f2 che aiuta molto \u00e8 il codice non bloccante e veloce, che elabora quasi tutto ci\u00f2 che passa attraverso il thread del ciclo degli eventi (thread dell'event-loop, noto anche come thread IO). Ma se hai applicazioni REST classiche o applicazioni lato client, Quarkus ha a disposizione un modello di programmazione imperativa. Ad esempio, il supporto HTTP in Quarkus si basa sull'utilizzo di un motore non bloccante e reattivo (Eclipse Vert.x e Netty). Tutte le richieste HTTP ricevute dall'applicazione passano inizialmente attraverso il ciclo degli eventi (IO Thread) e poi vengono inviate alla parte di codice che gestisce le richieste. A seconda della destinazione, il codice di gestione delle richieste pu\u00f2 essere eseguito in un thread separato (il cosiddetto worker thread, utilizzato nel caso di servlet e Jax-RS) o pu\u00f2 utilizzare il thread di input-output originale (rotta reattiva).<\/p>\n

    \"Come<\/p>\n

    Per i connettori dei sistemi di messaggistica vengono utilizzati client non bloccanti che lavorano sopra il motore Vert.x. Pertanto, puoi inviare, ricevere e elaborare messaggi dai sistemi di messaggistica in modo efficace.<\/p>\n

    Sul sito Quarkus.io<\/a><\/noindex> \u00e8 raccolto un certo numero di ottimi tutorial che aiutano a iniziare a lavorare con Quarkus:<\/p>\n