Tere kõigile! See on meie Quarkuse seeria teine postitus – täna räägime omakeelsest kompileerimisest.
on Java pinu, mis on kohandatud . Kuigi siin on kindlasti veel palju teha, oleme teinud palju head tööd paljude aspektidega, sealhulgas JVM-i ja mitmete raamistike optimeerimisega. Üks Quarkuse omadusi, mis on pälvinud arendajate suuremat huvi, on selle terviklik ja sujuv lähenemine Java-koodi muutmisel konkreetse operatsioonisüsteemi jaoks käivitatavateks failideks (nn native kompilatsioon), mis on sarnane C- ja C++-ga, kus selline kompileerimine. toimub tavaliselt ehitamise, testimise ja juurutamise tsükli lõpus.
Ja kuigi natiivne kompileerimine on oluline, nagu me allpool näitame, tuleb märkida, et Quarkus töötab väga hästi kõige tavalisemas Java masinas OpenJDK Hotspotis tänu jõudluse täiustustele, mida oleme kogu virnas rakendanud. Seetõttu tuleks natiivset koostamist pidada lisaboonuseks, mida saab soovi või vajaduse järgi kasutada. Tegelikult toetub Quarkus oma piltide osas suuresti OpenJDK-le. Ja arendajate poolt soojalt vastu võetud arendusrežiim tagab muudatuste peaaegu kohese testimise tänu Hotspotis rakendatud dünaamilise koodi täitmise täiustatud võimalustele. Lisaks kasutatakse natiivsete GraalVM-piltide loomisel OpenJDK klassi teeki ja HotSpoti võimalusi.
Miks on siis vaja natiivset kompileerimist, kui kõik on juba täiuslikult optimeeritud? Püüame sellele küsimusele allpool vastata.
Alustame ilmselgest: Red Hatil on laialdased kogemused JVM-ide, virnade ja raamistike optimeerimisel projekti arendamise ajal , kaasa arvatud:
- Esimene rakendusserver, mis töötab platvormil pilves .
- Esimene rakendusserver arvutites töötamiseks .
- Esimene rakendusserver, millel töötab .
- Seadmetes töötavate projektide valik .
Oleme juba aastaid tegelenud väljakutsetega, mis on seotud Java rakenduste pilves ja piiratud ressurssidega seadmetes (loe: IoT) käivitamisega ning oleme õppinud JVM-ist jõudluse ja mälu optimeerimise osas maksimumi võtma. Nagu paljud teised, oleme ka meie Java-rakenduste natiivse kompileerimisega töötanud juba pikka aega , , ja isegi ja me teame hästi selle lähenemise plusse ja miinuseid (näiteks dilemma valida universaalsuse "build one – run-anywhere" ja selle vahel, et kompileeritud rakendused on väiksemad ja töötavad kiiremini).
Miks on oluline neid plusse ja miinuseid kaaluda? Kuna mõnes olukorras saab nende suhe määravaks:
- Näiteks serverita/sündmuspõhistes keskkondades, kus (kõvas või pehmes) reaalajas, et oleks aega sündmustele reageerida. Erinevalt pikaealistest püsivatest teenustest pikendab külmkäivituse kestus kriitiliselt päringule reageerimise aega. JVM-i käivitamine võtab ikka veel palju aega ja kuigi seda saab mõnel juhul puhtalt riistvaraliste meetoditega vähendada, võib ühe sekundi ja 5 millisekundi vahe olla elu ja surma vahe. Jah, siin saate mängida Java-masinate kuuma reservi loomisega (mida me näiteks tegime ), kuid see iseenesest ei garanteeri, et taotluste töötlemiseks koormusskaalana on piisavalt JVM-e. Ja majanduslikust seisukohast pole see ilmselt kõige õigem variant.
- Lisaks on sageli esile kerkinud veel üks aspekt: mitu üürilepingut. Vaatamata sellele, et JVM-id on oma võimekuses jõudnud operatsioonisüsteemidele väga lähedale, ei suuda nad siiski teha seda, millega me Linuxis nii harjunud oleme – protsesside isoleerimiseks. Seetõttu võib ühe lõime rike kogu Java masina alla laadida. Paljud inimesed püüavad sellest puudusest mööda saada, pühendades iga kasutaja rakenduse jaoks eraldi JVM-i, et minimeerida tõrke tagajärgi. See on üsna loogiline, kuid ei sobi skaleerimisega hästi.
- Lisaks on pilvele orienteeritud rakenduste puhul oluline näitaja hosti teenuste tihedus. Üleminek metoodikale , mikroteenused ja Kubernetes suurendab Java-masinate arvu rakenduse kohta. See tähendab, et ühest küljest annab see kõik elastsuse ja töökindluse, kuid samal ajal suureneb ka baasmälu tarbimine teeninduse mõttes ja osa neist kuludest pole alati tingimata vajalik. Staatiliselt kompileeritud käivitatavad failid saavad siin kasu erinevate optimeerimistehnikate, näiteks madala taseme surnud koodi kõrvaldamise tõttu, kui lõplik pilt sisaldab ainult neid raamistiku osi (sh JDK-d), mida teenus tegelikult kasutab. Seetõttu aitab Quarkuse natiivne kompileerimine teenusejuhte tihedalt hosti paigutada, ilma et see kahjustaks turvalisust.
Tegelikult on ülaltoodud argumendid juba piisavad, et mõista kohaliku kompileerimise õigustatust Quarkuse projektis osalejate vaatevinklist. Siiski on veel üks, mittetehniline, kuid samuti oluline põhjus: viimastel aastatel on paljud programmeerijad ja arendusettevõtted loobunud Javast uute programmeerimiskeelte kasuks, arvates, et Java koos JVM-ide, virnade ja raamistikega on muutunud liiga palju. mälunäljas, liiga aeglane jne.
Siiski on harjumus kasutada mis tahes probleemi lahendamiseks sama tööriista . Mõnikord on parem astuda samm tagasi ja otsida midagi muud. Ja kui Quarkus paneb inimesed peatuma ja mõtlema, siis on see hea kogu Java ökosüsteemile. Quarkus esindab uuenduslikku vaadet tõhusamate rakenduste loomisele, muutes Java asjakohasemaks uute rakendusarhitektuuride jaoks, nagu serverita. Lisaks on Quarkusel tänu oma laiendatavusele loodetavasti terve Java laienduste ökosüsteem, mis suurendab oluliselt raamistike arvu, mis toetavad natiivset kompileerimist rakendustes.
Allikas: www.habr.com