Pozdravljeni vsi skupaj! To je druga objava v naši seriji o Quarkusu - danes bomo govorili o izvorni kompilaciji.
je sklad Java, prilagojen za . Čeprav je tu vsekakor treba še veliko narediti, smo opravili veliko dobrega dela na številnih vidikih, vključno z optimizacijo JVM in številnih ogrodij. Ena od značilnosti Quarkusa, ki je pritegnila povečano zanimanje razvijalcev, je njegov celovit, brezhiben pristop k pretvarjanju javanske kode v izvršljive datoteke za določen operacijski sistem (tako imenovano »domače prevajanje«), podobno kot C in C++, kjer je takšno prevajanje se običajno pojavi na koncu cikla gradnje, testiranja in uvajanja.
In čeprav je izvorno prevajanje pomembno, kot bomo pokazali spodaj, je treba opozoriti, da Quarkus res dobro deluje na najpogostejšem stroju Java, OpenJDK Hotspot, zahvaljujoč izboljšavam zmogljivosti, ki smo jih implementirali v celotnem skladu. Zato je treba izvorno kompilacijo obravnavati kot dodaten bonus, ki ga je mogoče uporabiti po želji ali potrebi. Pravzaprav se Quarkus močno opira na OpenJDK, ko gre za izvorne slike. Način za razvijalce, ki so ga razvijalci toplo sprejeli, zagotavlja skoraj takojšnje testiranje sprememb zaradi naprednih zmožnosti izvajanja dinamične kode, implementirane v Hotspot. Poleg tega se pri ustvarjanju izvornih slik GraalVM uporabljajo knjižnica razredov OpenJDK in zmogljivosti HotSpot.
Zakaj torej potrebujete domačo kompilacijo, če je že vse popolnoma optimizirano? Na to vprašanje bomo poskušali odgovoriti spodaj.
Začnimo z očitnim: Red Hat ima bogate izkušnje z optimizacijo JVM-jev, skladov in ogrodij med razvojem projektov vključno z:
- Prvi aplikacijski strežnik, ki deluje v oblaku na platformi .
- Prvi aplikacijski strežnik za delovanje na računalnikih .
- Prvi aplikacijski strežnik, na katerem se izvaja .
- Vrsta projektov, ki se izvajajo na napravah .
Že vrsto let se ukvarjamo z izzivi izvajanja aplikacij Java v oblaku in na napravah z omejenimi viri (beri: IoT) in smo se naučili kar najbolje izkoristiti JVM v smislu zmogljivosti in optimizacije pomnilnika. Tako kot mnogi drugi, tudi mi že dolgo delamo z izvorno kompilacijo aplikacij Java , , in celo dobro se zavedamo prednosti in slabosti tega pristopa (na primer dileme izbire med univerzalnostjo »sestavi enkrat – zaženi kjer koli« in dejstvom, da so prevedene aplikacije manjše in delujejo hitreje).
Zakaj je pomembno upoštevati te prednosti in slabosti? Ker v nekaterih situacijah postane njihovo razmerje odločilno:
- Na primer v okoljih brez strežnika/dogodkov, kjer v (trdem ali mehkem) realnem času, da bi imeli čas za odziv na dogodke. Za razliko od dolgotrajnih vztrajnih storitev tukaj trajanje hladnega zagona kritično poveča odzivni čas na zahtevo. JVM še vedno potrebuje veliko časa, da se zažene, in čeprav je to v nekaterih primerih mogoče zmanjšati s čistimi strojnimi metodami, je lahko razlika med eno sekundo in 5 milisekundami razlika med življenjem in smrtjo. Da, tukaj se lahko igrate z ustvarjanjem vroče rezerve strojev Java (kar smo na primer storili s ), vendar to samo po sebi ne zagotavlja, da bo na voljo dovolj JVM-jev za obdelavo zahtev glede na obremenitev. In z ekonomskega vidika to verjetno ni najbolj pravilna možnost.
- Poleg tega obstaja še en vidik, ki se pogosto pojavlja: večnajemništvo. Kljub temu, da so se JVM-ji po svojih zmogljivostih zelo približali operacijskim sistemom, še vedno ne zmorejo tega, česar smo v Linuxu tako vajeni - izolacije procesov. Zato lahko okvara ene niti uniči celoten stroj Java. Veliko ljudi se poskuša izogniti tej pomanjkljivosti tako, da za vsako uporabniško aplikacijo namenijo ločen JVM, da bi zmanjšali posledice okvare. To je precej logično, vendar se ne ujema dobro s skaliranjem.
- Poleg tega je za aplikacije, ki so usmerjene v oblak, pomemben pokazatelj gostota storitev na gostitelju. Prehod na metodologijo , mikrostoritve in Kubernetes poveča število strojev Java na aplikacijo. To pomeni, da po eni strani vse to zagotavlja elastičnost in zanesljivost, hkrati pa se poveča tudi poraba osnovnega pomnilnika v smislu storitev, nekateri od teh stroškov pa niso vedno nujno potrebni. Statično prevedene izvedljive datoteke imajo tukaj koristi zaradi različnih optimizacijskih tehnik, kot je nizkonivojsko odstranjevanje mrtve kode, ko končna slika vključuje samo tiste dele ogrodij (vključno s samim JDK), ki jih storitev dejansko uporablja. Zato izvorno prevajanje Quarkus pomaga gosto postaviti primerke storitev na gostitelja brez ogrožanja varnosti.
Pravzaprav so zgornji argumenti že dovolj, da razumemo upravičenost izvornega prevajanja z vidika udeležencev projekta Quarkus. Vendar pa obstaja še en, netehnični, a prav tako pomemben razlog: v zadnjih letih so številni programerji in razvojna podjetja opustili Javo v korist novih programskih jezikov, saj menijo, da je Java skupaj s svojimi JVM-ji, nizi in ogrodji postala preveč lačen spomina, prepočasen itd.
Vendar pa je navada uporabe istega orodja za reševanje katere koli težave . Včasih je bolje narediti korak nazaj in poiskati nekaj drugega. In če zaradi Quarkusa ljudje postanejo in razmišljajo, potem je to dobro za celoten javanski ekosistem. Quarkus predstavlja inovativen pogled na to, kako zgraditi učinkovitejše aplikacije, zaradi česar je Java bolj pomembna za nove arhitekture aplikacij, kot je brezstrežniška. Poleg tega bo Quarkus zaradi svoje razširljivosti upajmo, da bo imel celoten ekosistem razširitev Java, kar bo znatno povečalo število ogrodij, ki bodo podpirala izvorno prevajanje v aplikacijah takoj po namestitvi.
Vir: www.habr.com