Salut à tutti ! Questu hè u sicondu postu in a nostra serie nantu à Quarkus - oghje parlemu di compilazione nativa.
hè una pila Java adattata per . Mentre chì ci hè certamente assai più da fà quì, avemu fattu un bellu travagliu bè nantu à assai aspetti, cumpresa l'ottimisazione di a JVM è una quantità di frameworks. Una di e caratteristiche di Quarkus chì hà attiratu un interessu crescente da i sviluppatori hè u so approcciu cumpletu è senza saldatura per trasfurmà u codice Java in fugliali eseguibili per un sistema operatore specificu (cusì chjamatu "compilazione nativa"), simili à C è C ++, induve tale compilazione. generalmente accade à a fine di un ciclu di custruzzione, prova è implementazione.
E mentri a compilazione nativa hè impurtante, cum'è noi mustraremu quì sottu, deve esse nutatu chì Quarkus funziona veramente bè nantu à a macchina Java più cumuna, OpenJDK Hotspot, grazia à e migliure di rendiment chì avemu implementatu in tutta a pila. Dunque, a compilazione nativa deve esse cunsiderata cum'è un bonus addiziale chì pò esse usatu cum'è desideratu o necessariu. In fattu, Quarkus si basa assai nantu à OpenJDK quandu si tratta di l'imaghjini nativi. È u modu dev, accettatu cun calore da i sviluppatori, assicura una prova quasi istantanea di cambiamenti per via di e capacità avanzate di esecuzione di codice dinamica implementata in Hotspot. Inoltre, quandu creanu l'imaghjini GraalVM nativi, a biblioteca di classi OpenJDK è e capacità HotSpot sò aduprate.
Allora perchè avete bisognu di compilazione nativa se tuttu hè digià perfettamente ottimizatu? Avemu da pruvà à risponde à sta quistione sottu.
Cuminciamu cù l'ovvi: Red Hat hà una vasta sperienza in ottimisazione di JVM, stack è frameworks durante u sviluppu di prughjettu , cumpresi:
- U primu servitore di l'applicazioni à travaglià in u nuvulu nantu à a piattaforma .
- U primu servitore di l'applicazioni per eseguisce nantu à l'urdinatori .
- U primu servitore di l'applicazioni à eseguisce .
- Una gamma di prughjetti in esecuzione nantu à i dispositi .
Avemu trattatu cù i sfidi di eseguisce l'applicazioni Java in u nuvulu è nantu à i dispositi limitati di risorse (leghjite: IoT) per parechji anni è avemu amparatu à ottene u più da a JVM in quantu à u rendiment è l'optimizazione di memoria. Cum'è parechji altri, avemu travagliatu cù compilazione nativa di applicazioni Java per un bellu pezzu , , è ancu è sapemu bè i vantaghji è i contra di stu approcciu (per esempiu, u dilema di sceglie trà l'universalità di "custruisce una volta - run-anywhere" è u fattu chì l'applicazioni compilate sò più chjuche è eseguite più veloce).
Perchè hè impurtante di cunsiderà questi pros è cuns? Perchè in certi casi a so ratio diventa decisiva:
- Per esempiu, in ambienti serverless / event-driven induve in (duru o dolce) tempu reale per avè u tempu di risponde à l'eventi. A cuntrariu di i servizii persistenti di longa vita, quì a durata di un iniziu friddu aumenta criticamente u tempu di risposta à una dumanda. A JVM piglia sempre una quantità significativa di tempu per inizià, è mentre chì questu pò esse ridutta in certi casi da i metudi di hardware puri, a diferenza trà una seconda è 5 millisecondi pò esse a diffarenza trà a vita è a morte. Iè, quì pudete ghjucà cù a creazione di una riserva calda di macchine Java (chì, per esempiu, avemu fattu cù ), ma questu in sè stessu ùn guarantisci micca chì ci saranu abbastanza JVM per processà e richieste cum'è a scala di carica. È da un puntu di vista ecunomicu, questu hè probabilmente micca l'opzione più curretta.
- In più, ci hè un altru aspettu chì spessu spunta: multitenancy. Malgradu u fattu chì i JVM sò assai vicinu à i sistemi operativi in e so capacità, ùn sò ancu capaci di fà ciò chì simu abituati in Linux - prucessi isolanti. Dunque, u fallimentu di un filu pò caccià tutta a macchina Java. Parechje persone cercanu di aggirari stu inconveniente dedicà una JVM separata per l'applicazione di ogni utilizatore per minimizzà e cunsequenze di un fallimentu. Questu hè abbastanza logicu, ma ùn hè micca bè cù a scala.
- Inoltre, per l'applicazioni orientate à nuvola, un indicatore impurtante hè a densità di servizii nantu à l'ospite. Transizione à a metodulugia , microservices è Kubernetes aumenta u numeru di macchine Java per applicazione. Questu hè, da una banda, tuttu questu furnisce elasticità è affidabilità, ma à u stessu tempu u cunsumu di memoria di basa in termini di serviziu aumenta ancu, è certi di sti spesi ùn sò micca sempre strettamente necessarii. I fugliali eseguibili compilati staticamente beneficianu quì per via di diverse tecniche d'ottimisazione, cum'è l'eliminazione di codice mortu à livellu bassu, quandu l'imaghjini finali includenu solu quelli parti di i frameworks (cumpresu u JDK stessu) chì u serviziu in realtà usa. Dunque, a compilazione nativa di Quarkus aiuta à pusà densamente l'istanze di serviziu nantu à l'ospite senza compromette a sicurità.
In verità, l'argumenti sopra sò digià abbastanza per capiscenu a ghjustificazione di a compilazione nativa da u puntu di vista di i participanti di u prughjettu Quarkus. Tuttavia, ci hè un altru mutivu, micca tecnicu, ma ancu impurtante: in l'ultimi anni, assai programatori è cumpagnie di sviluppu anu abbandunatu Java in favore di novi linguaggi di prugrammazione, credendu chì Java, cù i so JVM, stacks è frameworks, hè diventatu troppu. fame di memoria, troppu lento, etc.
Tuttavia, l'abitudine di utilizà u stessu strumentu per risolve ogni prublema hè . Calchì volta hè megliu fà un passu in daretu è cercà qualcosa altru. È se Quarkus face a ghjente in pausa è pensa, allora hè bonu per tuttu l'ecosistema Java. Quarkus rapprisenta una visione innovativa di cumu custruisce applicazioni più efficaci, facendu Java più pertinente à e novi architetture di applicazioni cum'è serverless. Inoltre, per via di a so estensibilità, Quarkus sperendu avè un ecosistema sanu di estensioni Java, aumentendu significativamente u numeru di frameworks chì susteneranu a compilazione nativa in applicazioni fora di a scatula.
Source: www.habr.com