Natiivne kompileerimine Quarkuses – miks see on oluline

Tere kõigile! Täna on meil teine postitus meie Quarkuse seeriast – räägime natiivkompileerimisest.

Quarkus – see on Java-tehnoloogiakomplekt, mis on loodud Kubernetes. Ja kuigi siin on veel palju teha, oleme hästi töötanud paljude aspektide, sealhulgas JVM-i ja mitmete raamistikute optimeerimise kallal. Üks Quarkuse eripära, mis on arendajate seas suurt huvi äratanud, on terviklik ja sujuv lähenemine Java-koodi muutmisele käivitatavaks failiks kindlale operatsioonisüsteemile (nn "natiivkompileerimine"), sarnaselt C ja C++-ga, kus selline kompileerimine toimub tavaliselt tsükli lõpus, mis koosneb kokkupanekust, testimisest ja juurutamisest.

Kuigi natiivkompileerimine on, nagu me allpool näitame, oluline, tasub märkida, et Quarkus töötab tõeliselt hästi ka tavalises Java-masinas OpenJDK Hotspot, tänu neile jõudluse parandustele, mida oleme kogu tehnoloogia virnas rakendanud. Seega tuleks natiivkompileerimist käsitleda kui täiendavat boonust, mida saab kasutada vastavalt soovile või vajadusele. Tegelikult toetub Quarkus natiivpiltide osas suuresti OpenJDK-le. Ja tööstuse poolt hästi vastu võetud arendajatele mõeldud dev mode tagab peaaegu kohese muudatuste testimise, toetudes Hotspoti arenenud dünaamilise koodi täitmise võimalustele. Lisaks kasutatakse natiivpiltide loomisel GraalVM-is OpenJDK klassiteeki ja HotSpot'i võimalusi.

Kuid miks on siis natiivkompileerimine vajalik, kui kõik on juba suurepäraselt optimeeritud? Sellele küsimusele püüame allpool vastata.

Alustame ilmsega: Red Hat'il on suur kogemus JVM-i, tehnoloogiakuhjade ja raamistikude optimeerimise alal projekti arengu käigus. JBoss, sealhulgas:

• Esimene rakendusserver pilve platvormil töötamiseks Red Hat OpenShift.
• Esimene rakenduste server, mis töötab arvutites Plug PC.
• Esimene rakenduste server, mis töötab Raspberry Pi.
• Mitmed projektid, mis töötavad seadmetes Android.

Oleme aastaid tegelenud Java-rakenduste käivitamise probleemidega pilves ja piiratud ressurssidega seadmetes (loe: IoT) ning õppinud JVM-i maksimumi välja pigistama nii jõudluse kui ka mälu optimeerimise osas. Nagu paljusid teisi, on meid kaua huvitanud Java rakenduste native kompileerimine läbi GCJ, Avian, Excelsior JET ja isegi Dalvik ja oleme hästi teadlikud sellise lähenemise plussidest ja miinustest (näiteks dilemma valiku vahel „kandu kord – jookse igal pool” ja selle vahel, et kompileeritud rakendustel on väiksem suurus ja nad käivituvad kiiremini).

Miks on oluline arvestada nende plusside ja miinustega? Sest teatud olukordades nende suhe muutub määravaks:

• Näiteks serverless/üritustepõhistes keskkondades, kus teenused peavad lihtsalt käivituma reaalajas (kas ranged või pehmed) režiimid, et kiiresti reageerida sündmustele. Erinevalt pikaajalistest püsimist teenustest, kriitiliselt suurendab siin külmkäivitamise kestus vastuseaja pikkust. JVM-i käivitamiseks kulub endiselt märkimisväärselt aega ja kuigi mõnel juhul on seda võimalik lüheneda puhtalt riistvaratehnikate kaudu, võib vahe ühe sekundi ja 5 millisekundi vahel olla elu ja surma küsimus. Jah, siin on võimalik katsetada Java-masinate kuumad reserveerimise loomisega (nagu me näiteks tegime OpenWhiski portimisel Knative'ile OpenWhiski Knative'ile), kuid see iseenesest ei taga piisavat JVM-ide arvu, et taluda koormuse suurendamiseks nõudeid. Ja majanduslikust vaatenurgast ei pruugi see kindlasti olla kõige õigem valik.
• Edasi, on veel üks sageli esile kerkiv aspekt, nagu multitenantsus. Kuigi JVM on oma võimaluste poolest jõudnud lähedale operatsioonisüsteemidele, ei suuda nad siiski teha seda, milleks me oleme Linuxis nii harjunud – isoleerida protsesse. Seega võib ühe tõrke ilmnemine hävitada kogu Java-masina. Paljud üritavad seda puudust ringi juhtida, eraldades iga kasutaja rakenduse jaoks eraldi JVM, et minimeerida tõrgete tagajärgi. See on üsna loogiline, kuid ei sobi hästi skaleerimisega.
• Lisaks on pilvepõhiste rakenduste jaoks oluline selline näitaja nagu teenuste tihedus hostis. Üleminek metoodikale 12 rakenduse tegurit, mikroteenused ja Kubernetes suurendavad Java-masinate arvu ühe rakenduse kohta. Ehkki see pakub paindlikkust ja usaldusväärsust, suureneb samuti baimälu kulu teenuse kohta, mille osa ei ole alati rangelt vajalik. Staatiliselt kompileeritud täitmisfailid võidavad siin madala taseme optimeerimistehnikaid, nagu dead-code elimination, kasutades ainult neid raamistiku osi (sealhulgas JDK), mida teenus tõeliselt vajab. Seetõttu aitab Quarkuse kohandatud kompileerimine teenuste eesrindelahtede tihedamat paigutamist hostile ilma ohverdamata turvalisust.

Tegurite ülaltoodud põhjused on juba piisavad, et mõista Quarkuse projekti osalejate jaoks natiivkompileerimise mõistlikkust. Siiski on veel üks, mitte tehniline, kuid samuti oluline põhjus: viimastel aastatel on paljud programmeerijad ja arendusettevõtted loobunud Javast, eelistades uusi programmeerimiskeeli, arvates, et Java koos oma JVM-ide, stekkide ja raamistikega on muutunud liiga mälurikkaks, liiga aeglaseks jne.

Kuid harjumus kasutada sama tööriista erinevate ülesannete lahendamiseks – ei ole alati õige. Mõnikord on parem astuda samm tagasi ja otsida midagi muud. Ja kui Quarkus paneb inimesi peatuma ja mõtlema, on see hea kogu Java ökosüsteemi jaoks. Quarkus esindab uuenduslikku lähenemist, kuidas luua efektiivsemaid rakendusi, muutes Java uutele rakenduste arhitektuuridele, nagu serverless, asjakohasemaks. Lisaks, tänu oma laiendatavusele, loodame, et Quarkus omandab terve Java laienduste ökosüsteemi, mis suurendab märkimisväärselt raamistike arvu, mis out-of-the-box toetavad natiivset kompileerimist rakenduste koostamisel.

Allikas: habr.com