Salutare tuturor! Aceasta este a doua postare din seria noastră despre Quarkus - astăzi vom vorbi despre compilarea nativă.
este o stivă Java adaptată pentru . Deși cu siguranță mai sunt multe de făcut aici, am făcut o mulțime de lucruri bune pe multe aspecte, inclusiv optimizarea JVM-ului și a unui număr de cadre. Una dintre caracteristicile Quarkus care a atras un interes sporit din partea dezvoltatorilor este abordarea sa cuprinzătoare, fără întreruperi, de a transforma codul Java în fișiere executabile pentru un anumit sistem de operare (așa-numita „compilare nativă”), similar cu C și C++, unde o astfel de compilare apare de obicei la sfârșitul unui ciclu de construire, testare și implementare.
Și deși compilarea nativă este importantă, așa cum vom arăta mai jos, trebuie remarcat că Quarkus rulează foarte bine pe cea mai comună mașină Java, OpenJDK Hotspot, datorită îmbunătățirilor de performanță pe care le-am implementat în întreaga stivă. Prin urmare, compilarea nativă ar trebui să fie considerată un bonus suplimentar care poate fi folosit după cum doriți sau necesar. De fapt, Quarkus se bazează foarte mult pe OpenJDK când vine vorba de imagini native. Iar modul dev, acceptat cu căldură de dezvoltatori, asigură testarea aproape instantanee a modificărilor datorită capabilităților avansate de execuție dinamică a codului implementate în Hotspot. În plus, atunci când se creează imagini GraalVM native, sunt utilizate biblioteca de clase OpenJDK și capabilitățile HotSpot.
Deci, de ce aveți nevoie de compilare nativă dacă totul este deja perfect optimizat? Vom încerca să răspundem la această întrebare mai jos.
Să începem cu ceea ce este evident: Red Hat are o experiență vastă în optimizarea JVM-urilor, stivelor și cadrelor în timpul dezvoltării proiectelor , inclusiv:
- Primul server de aplicații care funcționează în cloud pe platformă .
- Primul server de aplicații care rulează pe computere .
- Primul server de aplicații pe care rulează .
- O gamă largă de proiecte care rulează pe dispozitive .
Ne confruntăm cu provocările rulării aplicațiilor Java în cloud și pe dispozitive cu resurse limitate (a se citi: IoT) de mulți ani și am învățat să profităm la maximum de JVM în ceea ce privește performanța și optimizarea memoriei. La fel ca mulți alții, lucrăm de mult timp cu compilarea nativă a aplicațiilor Java , , și chiar și suntem bine conștienți de avantajele și dezavantajele acestei abordări (de exemplu, dilema de a alege între universalitatea „build once – run-anywhere” și faptul că aplicațiile compilate sunt mai mici și rulează mai repede).
De ce este important să luăm în considerare aceste avantaje și dezavantaje? Pentru că în unele situații raportul lor devine decisiv:
- De exemplu, în medii fără server/controlate de evenimente unde în timp real (hard sau soft) pentru a avea timp să răspundă la evenimente. Spre deosebire de serviciile persistente de lungă durată, aici durata unei porniri la rece crește în mod critic timpul de răspuns la o solicitare. JVM-ul necesită încă o perioadă semnificativă de timp pentru a porni și, deși acest lucru poate fi redus în unele cazuri prin metode hardware pur, diferența dintre o secundă și 5 milisecunde poate fi diferența dintre viață și moarte. Da, aici vă puteți juca cu crearea unei rezerve fierbinți de mașini Java (ceea ce, de exemplu, am făcut cu ), dar acest lucru în sine nu garantează că vor exista suficiente JVM-uri pentru a procesa cererile pe măsură ce sarcina crește. Și din punct de vedere economic, aceasta nu este probabil cea mai corectă opțiune.
- Apoi, există problema frecvent ridicată a multi-tenancy. Chiar dacă JVM-urile au devenit mult mai apropiate de sistemele de operare în ceea ce privește capacitățile lor, acestea încă nu sunt capabile să facă lucruri cu care suntem atât de obișnuiți în același mod. Linux„e – pentru a izola procesele. Prin urmare, o eroare a unui singur fir de execuție poate duce la întreruperea întregii mașini Java. Mulți încearcă să rezolve acest lucru dedicând o JVM separată fiecărei aplicații a utilizatorului pentru a minimiza impactul unei erori. Acest lucru este destul de logic, dar nu se scalează bine.
- În plus, pentru aplicațiile orientate spre cloud, un indicator important este densitatea serviciilor pe gazdă. Trecerea la metodologie , microservicii și Kubernetes crește numărul de mașini Java per aplicație. Adică, pe de o parte, toate acestea oferă elasticitate și fiabilitate, dar în același timp crește și consumul de memorie de bază din punct de vedere al serviciului, iar unele dintre aceste cheltuieli nu sunt întotdeauna strict necesare. Fișierele executabile compilate static beneficiază aici datorită diferitelor tehnici de optimizare, cum ar fi eliminarea codului mort la nivel scăzut, când imaginea finală include doar acele părți ale cadrelor (inclusiv JDK-ul însuși) pe care serviciul le folosește de fapt. Prin urmare, compilarea nativă Quarkus ajută la plasarea densă a instanțelor de serviciu pe gazdă, fără a compromite securitatea.
De fapt, argumentele de mai sus sunt deja suficiente pentru a înțelege justificarea compilării native din punctul de vedere al participanților la proiectul Quarkus. Cu toate acestea, există un alt motiv, non-tehnic, dar și important: în ultimii ani, mulți programatori și companii de dezvoltare au abandonat Java în favoarea noilor limbaje de programare, crezând că Java, împreună cu JVM-urile, stivele și cadrele sale, a devenit prea mult. flămând de memorie, prea lent etc.
Cu toate acestea, obiceiul de a folosi același instrument pentru a rezolva orice problemă este . Uneori este mai bine să faci un pas înapoi și să cauți altceva. Și dacă Quarkus îi face pe oameni să se oprească și să se gândească, atunci asta este bine pentru întregul ecosistem Java. Quarkus reprezintă o viziune inovatoare a modului de a construi aplicații mai eficiente, făcând Java mai relevant pentru noile arhitecturi de aplicații, cum ar fi serverless. În plus, datorită extensibilității sale, Quarkus va avea, sperăm, un întreg ecosistem de extensii Java, crescând semnificativ numărul de cadre care vor suporta compilarea nativă în aplicații din nou.
Sursa: www.habr.com
