Hoi allegearre! Dit is de twadde post yn ús searje oer Quarkus - hjoed sille wy prate oer native kompilaasje.
is in Java stack maatwurk foar . Hoewol d'r hjir grif folle mear te dwaan is, hawwe wy in protte goed wurk dien oan in protte aspekten, ynklusyf it optimalisearjen fan de JVM en in oantal kaders. Ien fan 'e skaaimerken fan Quarkus dy't tanommen belangstelling hat lutsen fan ûntwikkelders is har wiidweidige, naadleaze oanpak foar it omsette fan Java-koade yn útfierbere bestannen foar in spesifyk bestjoeringssysteem (saneamde "native compilation"), fergelykber mei C en C++, wêr't sa'n kompilaasje bart meastentiids oan 'e ein fan in syklus fan bouwen, testen en ynset.
En hoewol native kompilaasje wichtich is, lykas wy hjirûnder sille sjen litte, moat opmurken wurde dat Quarkus echt goed rint op 'e meast foarkommende Java-masine, OpenJDK Hotspot, tanksij de prestaasjesferbetteringen dy't wy yn 'e heule stapel hawwe ymplementearre. Dêrom moat native kompilaasje wurde beskôge as in ekstra bonus dy't kin brûkt wurde as winske of nedich. Yn feite, Quarkus fertrout swier op OpenJDK as it giet om native bylden. En de dev-modus, waarm akseptearre troch ûntwikkelders, soarget foar hast fuortendaliks testen fan feroaringen fanwege de avansearre mooglikheden fan dynamyske koade-útfiering ymplementearre yn Hotspot. Derneist, by it meitsjen fan native GraalVM-ôfbyldings, wurde de OpenJDK-klassebibleteek en HotSpot-mooglikheden brûkt.
Dus wêrom hawwe jo native kompilaasje nedich as alles al perfekt optimalisearre is? Wy sille besykje dizze fraach hjirûnder te beantwurdzjen.
Litte wy begjinne mei it fanselssprekkende: Red Hat hat wiidweidige ûnderfining mei it optimalisearjen fan JVM's, stapels en kaders tidens projektûntwikkeling , ynklusyf:
- De earste applikaasje-tsjinner dy't wurket yn 'e wolk op it platfoarm .
- De earste applikaasje-tsjinner foar it útfieren op kompjûters .
- De earste applikaasje-tsjinner om op te rinnen .
- In ferskaat oan projekten dy't rinne op apparaten .
Wy hawwe in protte jierren te krijen mei de útdagings fan it útfieren fan Java-applikaasjes yn 'e wolk en op boarne-beheinde apparaten (lês: IoT) en hawwe leard om it measte út' e JVM te krijen yn termen fan prestaasjes en ûnthâldoptimalisaasje. Lykas in protte oaren hawwe wy in lange tiid wurke mei native kompilaasje fan Java-applikaasjes , , en sels en wy binne ús goed bewust fan 'e foar- en neidielen fan dizze oanpak (bygelyks it dilemma om te kiezen tusken de universaliteit fan "bou ienris - run-oeral" en it feit dat kompilearre applikaasjes lytser binne en flugger rinne).
Wêrom is it wichtich om dizze foar- en neidielen te beskôgjen? Om't yn guon situaasjes har ferhâlding beslissend wurdt:
- Bygelyks, yn serverless / evenemint-oandreaune omjouwings wêr yn (hurde of sêfte) echte tiid om tiid te hawwen om te reagearjen op eveneminten. Oars as langlibbene oanhâldende tsjinsten, fergruttet hjir de doer fan in kâlde start de reaksjetiid op in fersyk kritysk. De JVM nimt noch in signifikante tiid om op te starten, en hoewol dit yn guon gefallen kin wurde fermindere troch suvere hardwaremetoaden, kin it ferskil tusken ien sekonde en 5 millisekonden it ferskil wêze tusken libben en dea. Ja, hjir kinne jo boartsje mei it meitsjen fan in hot reserve fan Java-masines (wat wy bygelyks diene mei ), mar dit op himsels garandearret net dat d'r genôch JVM's sille wêze om oanfragen te ferwurkjen as de loadskalen. En út in ekonomysk eachpunt is dit wierskynlik net de meast korrekte opsje.
- Fierder is der in oar aspekt dat faak opdûkt: multitenancy. Nettsjinsteande it feit dat JVM's heul ticht by bestjoeringssystemen binne kommen yn har mooglikheden, binne se noch altyd net yn steat om te dwaan wat wy sa wend binne yn Linux - prosessen isolearje. Dêrom kin it mislearjen fan ien tried de hiele Java-masine delbringe. In protte minsken besykje om dit nadeel te kommen troch in aparte JVM te wijen foar elke applikaasje fan elke brûker om de gefolgen fan in mislearring te minimalisearjen. Dit is frij logysk, mar past net goed by skaalfergrutting.
- Derneist, foar wolk-rjochte applikaasjes, is in wichtige yndikator de tichtens fan tsjinsten op 'e host. Oergong nei metodyk , microservices en Kubernetes fergruttet it oantal Java masines per applikaasje. Dat is, oan 'e iene kant, dit alles soarget foar elastisiteit en betrouberens, mar tagelyk nimt it konsumpsje fan basisûnthâld yn termen fan tsjinst ek ta, en guon fan dizze útjeften binne net altyd strikt nedich. Statysk gearstalde útfierbere bestannen profitearje hjir troch ferskate optimisaasjetechniken, lykas eliminaasje fan deade-koade op leech nivo, as de definitive ôfbylding allinich de dielen fan 'e kaders omfettet (ynklusyf de JDK sels) dy't de tsjinst eins brûkt. Dêrom helpt Quarkus native kompilaasje om tsjinstynstânsjes ticht op 'e host te pleatsen sûnder feiligens te kompromittearjen.
Eins binne de boppesteande arguminten al genôch om de rjochtfeardiging fan native kompilaasje te begripen út it eachpunt fan 'e Quarkus-projektdielnimmers. D'r is lykwols in oare, net-technyske, mar ek wichtige reden: de lêste jierren hawwe in protte programmeurs en ûntwikkelingsbedriuwen Java ferlitten yn it foardiel fan nije programmeartalen, yn 't leauwe dat Java, tegearre mei har JVM's, stacks en frameworks, ek wurden is ûnthâld-hongerich, te stadich, etc.
De gewoante om itselde ark te brûken om elk probleem op te lossen is lykwols . Soms is it better om in stap werom te dwaan en wat oars te sykjen. En as Quarkus minsken stopet en tinkt, dan is dat goed foar it hiele Java-ekosysteem. Quarkus fertsjintwurdiget in ynnovative werjefte fan hoe't jo effisjintere applikaasjes bouwe kinne, wêrtroch Java relevanter is foar nije applikaasje-arsjitektueren lykas serverless. Dêrnjonken sil Quarkus troch syn útwreidzjen hooplik in folslein ekosysteem hawwe fan Java-útwreidings, wêrtroch it oantal kaders signifikant tanimme dy't native kompilaasje sille stypje yn applikaasjes bûten it fak.
Boarne: www.habr.com