Ciao a tutti! Questo è il secondo post della nostra serie su Quarkus – oggi parleremo della compilazione nativa.
– è uno stack Java ottimizzato per . E anche se ci sono ancora molte cose da fare, abbiamo lavorato bene su numerosi aspetti, inclusa l'ottimizzazione della JVM e di vari framework. Una delle caratteristiche di Quarkus che ha suscitato un grande interesse tra gli sviluppatori è l'approccio integrato e fluido per trasformare il codice Java in file eseguibili per un sistema operativo specifico (la cosiddetta "compilazione nativa"), analogamente a C e C++, dove questa compilazione avviene solitamente alla fine di un ciclo di costruzione, test e distribuzione.
E anche se, come mostreremo di seguito, la compilazione nativa è importante, è doveroso sottolineare che Quarkus funziona davvero bene anche su una normale macchina Java OpenJDK Hotspot grazie ai miglioramenti delle prestazioni che abbiamo implementato in tutto lo stack. Pertanto, la compilazione nativa può essere considerata un bonus aggiuntivo, da utilizzare a piacere o necessità. In effetti, per quanto riguarda le immagini native, Quarkus si basa in larga misura su OpenJDK. Inoltre, la modalità dev mode, ben accolta dagli sviluppatori, offre quasi un test immediato delle modifiche grazie alle avanzate capacità di esecuzione dinamica del codice implementate in Hotspot. Inoltre, nella creazione di immagini native, viene utilizzata la biblioteca di classi di OpenJDK e le funzionalità di HotSpot.
Allora, perché è necessaria la compilazione nativa se tutto è già così ben ottimizzato? Proveremo a rispondere a questa domanda qui di seguito.
Iniziamo con l'ovvio: Red Hat ha una grande esperienza nell'ottimizzazione di JVM, stack e framework durante l'evoluzione del progetto , che include:
- Il primo server di applicazioni per il cloud sulla piattaforma .
- Il primo server di applicazioni per funzionare su computer .
- Il primo server di applicazioni per funzionare su .
- Una serie di progetti funzionanti su dispositivi .
Da molti anni ci occupiamo di eseguire applicazioni Java nel cloud e su dispositivi con risorse limitate (leggi, IoT) e abbiamo imparato a ottenere il massimo dalla JVM in termini di prestazioni e ottimizzazione della memoria. Come molti altri, abbiamo già lavorato a lungo con la compilazione nativa delle applicazioni Java tramite , , e persino e comprendiamo bene i pro e i contro di questo approccio (ad esempio, il dilemma tra la versatilità "build once – run-anywhere" e il fatto che le applicazioni compilate hanno dimensioni minori e si avviano più rapidamente).
Perché è così importante considerare questi pro e contro? Perché in alcune situazioni il loro rapporto diventa decisivo:
- Ad esempio, in ambienti serverless/gestiti dagli eventi, dove in modalità (rigida o morbida) real-time, per poter rispondere agli eventi. A differenza dei servizi persistenti a lungo termine, qui la durata dell'avvio a freddo aumenta criticamente il tempo di risposta alle richieste. L'avvio della JVM richiede ancora un notevole tempo e, sebbene in alcuni casi possa essere ridotto mediante metodi puramente hardware, la differenza tra un secondo e 5 millisecondi può essere una questione di vita o di morte. Sì, qui si può giocare con la creazione di riserve calde di macchine Java (cosa che abbiamo fatto, ad esempio, durante ), ma di per sé questo non garantisce un numero sufficiente di JVM per gestire le richieste man mano che il carico aumenta. E sotto il profilo economico, sicuramente non è l'opzione più giusta.
- Inoltre, c'è un altro aspetto frequentemente sollevato, come la multitenancy. Anche se le JVM hanno avvicinato molto le loro capacità a quelle dei sistemi operativi, non sono ancora in grado di fare ciò a cui siamo così abituati su Linux – isolare i processi. Pertanto, il guasto di un thread può compromettere l'intera macchina Java. Molti cercano di aggirare questo difetto dedicando a ciascun utente una JVM separata per le applicazioni, al fine di ridurre al minimo le conseguenze del guasto. Questo ha una logica, ma si sposa male con la scalabilità.
- Inoltre, per le applicazioni orientate al cloud, è importante un indicatore come la densità dei servizi sull'host. La transizione verso la metodologia , i microservizi e Kubernetes aumentano il numero di macchine Java per un'applicazione. Da un lato, tutto ciò offre elasticità e affidabilità, ma allo stesso tempo cresce anche il consumo di memoria di base per servizio, e parte di queste spese non è sempre strettamente necessaria. I file eseguibili compilati staticamente vincono qui grazie a varie tecniche di ottimizzazione, come l'eliminazione del codice morto a basso livello, quando nell'immagine finale vengono incluse solo le parti dei framework (incluso lo stesso JDK) che il servizio utilizza effettivamente. Pertanto, la compilazione nativa di Quarkus aiuta a collocare più densamente le istanze dei servizi sull'host senza compromettere la sicurezza.
In effetti, le argomentazioni sopra menzionate sono già sufficienti per comprendere la giustificazione della compilazione nativa dal punto di vista dei partecipanti al progetto Quarkus. Tuttavia, c'è un'altra ragione, non tecnica, ma altrettanto importante: negli ultimi anni molti programmatori e aziende di sviluppo hanno abbandonato Java a favore di nuovi linguaggi di programmazione, ritenendo che Java con le sue JVM, stack e framework sia diventata troppo esigente in termini di memoria, troppo lenta, ecc.
Tuttavia, l'abitudine di utilizzare lo stesso strumento per risolvere qualsiasi problema – . A volte è meglio fare un passo indietro e cercare qualcosa di diverso. E se Quarkus costringe le persone a fare una pausa e riflettere, è positivo per l'intero ecosistema Java. Quarkus rappresenta una visione innovativa su come creare applicazioni più efficienti, rendendo Java più rilevante per nuove architetture di applicazione, come quelle serverless. Inoltre, grazie alla sua estensibilità, Quarkus, speriamo, svilupperà un'intera ecosistema di estensioni Java, aumentando notevolmente il numero di framework che supporteranno nativamente la compilazione come parte delle applicazioni.
Fonte: habr.com
