Bună ziua! Acesta este al doilea post din seria noastră despre Quarkus – astăzi vom discuta despre compilarea nativă.
– este un stack Java conceput pentru . Și deși mai sunt multe de făcut, am lucrat bine la o serie de aspecte, inclusiv optimizarea JVM și a diverselor framework-uri. Una dintre caracteristicile Quarkus care a suscitat un interes crescut din partea dezvoltatorilor este abordarea sa cuprinzătoare și seamless de transformare a codului Java în fișiere executabile pentru un sistem de operare specific (așa-numita „compilare nativă”) în mod similar cu C și C++, unde această compilare are loc de obicei la sfârșitul ciclului de construcție, testare și implementare.
Și deși compilarea nativă, după cum vom arăta mai jos, este importantă, trebuie menționat că Quarkus funcționează foarte bine și pe o mașină Java obișnuită OpenJDK Hotspot, datorită îmbunătățirilor de performanță pe care le-am implementat pe întreaga structură. De aceea, compilarea nativă ar trebui privită ca un bonus suplimentar pe care îl poți folosi la nevoie. În realitate, în ceea ce privește imaginile native, Quarkus depinde semnificativ de OpenJDK. În plus, modul dev, bine primit de dezvoltatori, asigură testarea aproape instantanee a modificărilor, datorită capacităților avansate de execuție dinamică a codului implementate în Hotspot. Împreună cu asta, la crearea imaginilor native, GraalVM utilizează biblioteca de clase OpenJDK și capacitățile HotSpot.
Atunci, de ce avem nevoie de compilarea nativă, dacă totul este deja optimizat exceptional? La această întrebare vom încerca să răspundem mai jos.
Să începem cu evidentul: Red Hat are multă experiență în optimizarea JVM, stack-urilor și framework-urilor în timpul dezvoltării proiectului , inclusiv:
- Primul server de aplicații pentru lucrul în cloud pe platforma .
- Primul server de aplicații pentru lucrul pe computere .
- Primul server de aplicații pentru lucrul pe .
- O întreagă serie de proiecte care funcționează pe dispozitive .
Ne ocupăm de mulți ani de problemele de lansare a aplicațiilor Java în cloud și pe dispozitive cu resurse limitate (citiți, IoT) și am învățat să extragem maximum din JVM în ceea ce privește performanța și optimizarea memoriei. La fel ca alții, lucrăm deja de mult timp cu compilarea nativă a aplicațiilor Java prin , , și chiar și suntem perfect conștienți de avantajele și dezavantajele unei astfel de abordări (de exemplu, dilema alegerii între versatilitatea "build once – run-anywhere" și faptul că aplicațiile compilate au o dimensiune mai mică și se lansează mai repede).
De ce este atât de important să luăm în considerare aceste avantaje și dezavantaje? Pentru că, în anumite situații, proporția lor devine decisivă:
- De exemplu, în medii serverless/gestionate de evenimente, unde în mod (rigid sau flexibil) în timp real, pentru a reacționa la evenimente. Spre deosebire de serviciile persistente cu durată lungă de viață, aici durata de lansare la rece crește critic timpul de răspuns la cerere. Lansarea JVM necesită încă un timp semnificativ, și, deși în unele cazuri poate fi redusă prin metode hardware, diferența dintre o secundă și 5 milisecunde poate fi o problemă de viață și de moarte. Da, aici se poate experimenta cu crearea de rezerve calde de mașini Java (așa cum am făcut, de exemplu, în cazul ), dar acest lucru în sine nu garantează un număr suficient de JVM-uri pentru a gestiona cererile pe măsură ce se escaladează sarcina. Nici din punct de vedere economic, cu siguranță, aceasta nu este cea mai bună opțiune.
- În plus, există un alt aspect care apare frecvent, și anume multitenanța. Deși JVM-urile au avansat semnificativ în capacitățile lor, ele nu sunt încă capabile să facă ceea ce am învățat să expectăm în Linux – să izoleze procesele. Prin urmare, o defecțiune a unui fir poate duce la prăbușirea întregii mașini Java. Mulți încearcă să ocolească această deficiență alocând câte o JVM separată pentru aplicațiile fiecărui utilizator, pentru a minimiza consecințele defecțiunii. Aceasta este o abordare logică, dar se potrivește prost cu scalarea.
- În plus, pentru aplicațiile orientate spre cloud, un parametru important este densitatea serviciilor pe gazdă. Trecerea la metodologia , microserviciile și Kubernetes cresc numărul de mașini Java pentru o aplicație. Cu alte cuvinte, pe de o parte, toate acestea oferă elasticitate și fiabilitate, dar pe de altă parte, crește și consumul de memorie de bază raportat la serviciu, iar o parte din aceste cheltuieli nu sunt întotdeauna strict necesare. Fișierele executabile compilate static câștigă aici prin diverse tehnici de optimizare, cum ar fi eliminarea codului mort la nivel de bază, când în imaginea finală sunt incluse doar acele părți ale framework-urilor (inclusiv JDK-ul însuși) pe care serviciul le folosește efectiv. Prin urmare, compilarea nativă Quarkus ajută la plasarea mai densă a instanțelor serviciilor pe gazdă fără a compromite securitatea.
Practic, argumentele prezentate mai sus sunt deja suficiente pentru a înțelege justificarea compilării native din perspectiva participanților proiectului Quarkus. Cu toate acestea, există și un alt motiv, non-tehnic, dar la fel de important: în ultimii ani, mulți programatori și companii de dezvoltare au abandonat Java în favoarea unor noi limbaje de programare, considerând că Java, împreună cu JVM-urile, stivele și framework-urile sale, a devenit prea „foame” în ceea ce privește memoria, prea lentă etc.
Cu toate acestea, obișnuința de a folosi același instrument pentru a rezolva orice problemă – . Uneori, este mai bine să faci un pas înapoi și să cauți altceva. Și dacă Quarkus îi determină pe oameni să facă o pauză și să reflecteze, atunci acest lucru este benefic pentru întreaga ecologie Java. Quarkus înfățișează o viziune inovatoare despre cum să creezi aplicații mai eficiente, făcând Java mai relevantă pentru noile arhitecturi de aplicații, precum serverless. În plus, datorită extensibilității sale, Quarkus, așa cum sperăm, va avea o întreagă ecologie de extensii Java, crescând semnificativ numărul de framework-uri care vor susține nativ compilarea în cadrul aplicațiilor.
Sursa: habr.com
