{"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 combina programmazione imperativa e reattiva","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Quest'anno abbiamo in programma di sviluppare seriamente i temi dei container, Cloud-Native Java<\/a><\/noindex> e Kubernetes<\/a><\/noindex>. Un naturale proseguimento di questi temi sar\u00e0 il racconto del framework Quarkus, gi\u00e0 trattato<\/a><\/noindex> su Habr. L'articolo di oggi \u00e8 dedicato non tanto alla struttura della \u00abJava subatomica ultraveloce\u00bb, quanto alle prospettive che Quarkus porta nel mondo Enterprise.<\/p>\n

\"Come
\n
\nJava e JVM rimangono estremamente popolari, ma nell'uso di tecnologie serverless e microservizi orientati al cloud, Java e altri linguaggi per la JVM vengono applicati sempre meno, poich\u00e9 occupano troppo spazio in memoria e si caricano troppo lentamente, rendendoli poco adatti all'uso con container a vita breve. Fortunatamente, questa situazione sta iniziando a cambiare grazie a Quarkus.
\n<\/a><\/noindex><\/p>\n

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

\n42 versioni, 8 mesi di lavoro della comunit\u00e0 e 177 sviluppatori straordinari \u2013 il risultato di tutto ci\u00f2 \u00e8 stato il rilascio nel novembre 2019 di Quarkus 1.0<\/a><\/noindex>, una versione che segna un'importante pietra miliare nello sviluppo del progetto e offre un sacco di fantastiche funzionalit\u00e0 e possibilit\u00e0 (puoi leggere di pi\u00f9 su di esse in un annuncio<\/a><\/noindex>).<\/p>\n

Oggi parleremo di come Quarkus unisce i modelli di programmazione imperativa e reattiva basati su un unico nucleo reattivo. Inizieremo con una breve escursione nella storia e poi analizzeremo in dettaglio in cosa consiste il dualismo del nucleo reattivo di Quarkus e come Java<\/a><\/noindex>-i programmatori possono trarre vantaggio da questi benefici.<\/p>\n

Microservizi<\/a><\/noindex>, architetture guidate dagli eventi<\/a><\/noindex> e serverless<\/a><\/noindex>-funzioni \u2013 tutto ci\u00f2 oggi \u00e8 in forte crescita. Recentemente, la creazione di architetture orientate al cloud \u00e8 diventata molto pi\u00f9 semplice e accessibile, ma i problemi rimangono \u2013 specialmente per gli sviluppatori Java. Ad esempio, nel caso delle funzioni serverless e dei microservizi c'\u00e8 un'esigenza urgente di ridurre i tempi di avvio, diminuire il consumo di memoria e rendere la loro sviluppo pi\u00f9 comodo e piacevole. Negli ultimi anni, Java ha apportato alcuni miglioramenti, come funzionalit\u00e0 ergonomiche ottimizzate per i container e altro. Tuttavia, ottenere un funzionamento efficace di Java in un container continua a essere una sfida. Pertanto, iniziamo esaminando alcune delle complessit\u00e0 interne di Java che si manifestano in modo particolarmente accentuato durante lo sviluppo di applicazioni Java orientate ai container.<\/p>\n

Iniziamo con la storia.<\/p>\n

\"Come<\/p>\n

Flussi e container<\/h3>\n

\nA partire dalla versione 8u131, Java ha iniziato a supportare in modo pi\u00f9 efficace i container grazie a miglioramenti nella funzionalit\u00e0 ergonomics. In particolare, ora la JVM sa su quanti core del processore viene eseguita e pu\u00f2 configurare i pool di thread di conseguenza, generalmente usando pool fork\/join. Certamente, questo \u00e8 positivo, ma supponiamo di avere un'applicazione web tradizionale che utilizza servlet HTTP e gira su Tomcat, Jetty e simili. Di conseguenza, questa applicazione assegner\u00e0 un thread separato per ogni richiesta, permettendole di bloccare quel thread durante l'attesa delle operazioni di input-output, ad esempio durante l'accesso a database, file o altri servizi. Questo significa che le dimensioni di tale applicazione non dipendono dal numero di core disponibili, ma dal numero di richieste simultanee. Inoltre, ci\u00f2 implica che le quote o i limiti in Kubernetes relativi al numero di core non saranno di grande aiuto, e alla fine si finir\u00e0 per affrontare il throttling.<\/p>\n

Esaurimento della memoria<\/h3>\n

\nI flussi sono memoria. E le limitazioni interne ai container sulla memoria non sono affatto una panacea. Iniziate semplicemente ad aumentare il numero di applicazioni e flussi, e prima o poi vi troverete di fronte a un aumento critico della frequenza dei cambiamenti e, di conseguenza, a una degradazione delle prestazioni. Inoltre, se un'applicazione utilizza tradizionali framework microservizi, si connette a un database, o utilizza una cache, o in qualche modo consuma memoria in modo aggiuntivo, \u00e8 evidente che avrete bisogno di uno strumento che permetta di guardare dentro la JVM e vedere come gestisce la memoria, senza compromettere la JVM stessa (ad esempio, XX:+UseCGroupMemoryLimitForHeap). Anche se, a partire da Java 9, la JVM ha imparato a riconoscere i cgroups e ad adattarsi di conseguenza, la prenotazione e la gestione della memoria restano affari piuttosto complessi.<\/p>\n

Quote e limiti<\/h3>\n

\nIn Java 11, support for CPU quotas (such as PreferContainerQuotaForCPUCount) was introduced. Kubernetes also provides support for limits and quotas. Yes, all of this makes sense, but if the application exceeds its allocated quota again, we return to the situation where size \u2014 as in traditional Java applications \u2014 is determined by the number of cores, with a separate thread allocated for each request. This means that the benefits are minimal.
\nMoreover, using quotas and limits or the scale-out functions of the Kubernetes underlying platform does not solve the problem by itself. We simply end up consuming more resources to address the original issue or eventually lead to resource overconsumption. If this is a high-load system in a public cloud, we almost certainly start using more resources than necessary.<\/p>\n

What should we do about all this?<\/h3>\n

\nTo put it simply, use asynchronous and non-blocking input-output libraries and frameworks like Netty, Vert.x<\/a><\/noindex> o Akka. Sono molto pi\u00f9 adatti per lavorare nei contenitori grazie alla loro natura reattiva. Grazie all'I\/O non bloccante, lo stesso thread pu\u00f2 gestire pi\u00f9 richieste simultaneamente. Mentre una richiesta attende risultati di I\/O, il thread che la gestisce \u00e8 liberato e pu\u00f2 occuparsi di un'altra richiesta. Quando i risultati di I\/O finalmente arrivano, la lavorazione della prima richiesta riprende. Alternando la lavorazione delle richieste all'interno dello stesso thread, \u00e8 possibile ridurre il numero totale di thread e diminuire i consumi di risorse nella gestione delle richieste.<\/p>\n

Con l'I\/O non bloccante, il numero di core diventa un parametro fondamentale, poich\u00e9 determina il numero di thread di I\/O che possono essere eseguiti in parallelo. Se utilizzato correttamente, questo permette di distribuire in modo efficace il carico tra i core e gestire carichi pi\u00f9 elevati con minori risorse.<\/p>\n

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

\nNo, c'\u00e8 dell'altro. La programmazione reattiva aiuta a utilizzare meglio le risorse, ma ha anche un prezzo. In particolare, sar\u00e0 necessario riscrivere il codice secondo i principi di non blocco e evitare il blocco dei flussi di input-output. Questo richiede un approccio completamente diverso nello sviluppo e nell'esecuzione. Anche se ci sono molte librerie utili, si tratta comunque di un cambiamento radicale nel modo di pensare.<\/p>\n

Innanzitutto, \u00e8 necessario imparare a scrivere codice che venga eseguito in modo asincrono. Non appena si inizia a utilizzare l'input-output non bloccante, \u00e8 necessario specificare esplicitamente cosa dovrebbe accadere quando si riceve una risposta a una richiesta. Non \u00e8 pi\u00f9 possibile semplicemente bloccare e aspettare. In cambio, \u00e8 possibile utilizzare callback, programmazione reattiva o continuation. Ma non \u00e8 tutto: per utilizzare l'input-output non bloccante, sono necessari anche server e client non bloccanti, e sarebbe preferibile in ogni caso. Per quanto riguarda HTTP, \u00e8 semplice, ma ci sono anche database, file system e molto altro.<\/p>\n

Anche se la reattivit\u00e0 totale consente di ottenere il massimo dell'efficienza, questo spostamento pu\u00f2 essere difficile da digerire nella pratica. Perci\u00f2, la possibilit\u00e0 di combinare codice reattivo e imperativo diventa una condizione necessaria per:<\/p>\n

    \n
  1. Usare in modo efficace le risorse nelle aree pi\u00f9 cariche del sistema software;<\/li>\n
  2. Utilizzare un codice pi\u00f9 semplice nel suo resto.<\/li>\n<\/ol>\n

    <\/p>\n

    Presentiamo Quarkus<\/h3>\n

    \nEcco il cuore di Quarkus: unire i modelli reattivi e imperativi all'interno di un'unica runtime.<\/p>\n

    Alla base di Quarkus ci sono Vert.x e Netty, su cui viene costruita una serie di framework e estensioni reattive pensate per assistere gli sviluppatori. Quarkus \u00e8 progettato per la creazione non solo di microservizi HTTP, ma anche di architetture a eventi. Grazie alla sua natura reattiva, lavora in modo molto efficace con sistemi di messaggistica (Apache Kafka, AMQP, ecc.).<\/p>\n

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

    \"Come<\/p>\n

    Quarkus gestisce questo in modo brillante. La scelta tra imperativo e reattivo \u00e8 chiara: utilizzare un nucleo reattivo per entrambi. Ci\u00f2 che supporta notevolmente \u00e8 il codice non bloccante e veloce, che gestisce quasi tutto ci\u00f2 che attraversa il ciclo degli eventi (event-loop thread, ovvero IO thread). Tuttavia, se hai applicazioni REST classiche o applicazioni lato client, Quarkus ha pronta una model di programmazione imperativa. Ad esempio, il supporto HTTP in Quarkus \u00e8 costruito utilizzando un motore non bloccante e reattivo (Eclipse Vert.x e Netty). Tutte le richieste HTTP ricevute dalla tua applicazione passano inizialmente attraverso il ciclo degli eventi (IO Thread), e poi vengono inviate a quella parte del codice che gestisce le richieste. A seconda della destinazione, il codice di gestione delle richieste pu\u00f2 essere attivato all'interno di un thread separato (il cosiddetto worker thread, utilizzato nel caso di servlet e Jax-RS) o utilizzare il thread di input\/output originale (reactive route).<\/p>\n

    \"Come<\/p>\n

    I connettori dei sistemi di trasmissione dei messaggi utilizzano client non bloccanti, che operano sopra il motore Vert.x. Questo consente di inviare, ricevere e elaborare efficacemente i messaggi dai sistemi di tipo messaging middleware.<\/p>\n

    Sul sito Quarkus.io<\/a><\/noindex> sono stati raccolti diversi buoni tutorial che aiutano a iniziare a lavorare con Quarkus:<\/p>\n