Saluton al ĉiuj! Ĉi tiu estas la dua afiŝo en nia serio pri Quarkus - hodiaŭ ni parolos pri indiĝena kompilo.
estas Java stako adaptita por . Kvankam certe estas multe pli por fari ĉi tie, ni faris multan bonan laboron pri multaj aspektoj, inkluzive de optimumigado de la JVM kaj kelkaj kadroj. Unu el la trajtoj de Quarkus, kiu altiris pliigitan intereson de programistoj, estas ĝia ampleksa, senjunta aliro por igi Java-kodon en ruleblajn dosierojn por specifa operaciumo (tiel nomata "denaska kompilo"), simila al C kaj C++, kie tia kompilo. kutime okazas ĉe la fino de ciklo de konstruo, testo kaj deplojo.
Kaj kvankam denaska kompilo estas grava, kiel ni montros malsupre, oni devas rimarki, ke Quarkus funkcias tre bone sur la plej ofta Java-maŝino, OpenJDK Hotspot, danke al la agado-plibonigoj, kiujn ni efektivigis tra la stako. Tial, denaska kompilo devus esti konsiderata kiel aldona gratifiko, kiu povas esti uzata kiel dezirate aŭ necese. Fakte, Quarkus multe dependas de OpenJDK kiam temas pri denaskaj bildoj. Kaj la dev-reĝimo, varme akceptita de programistoj, certigas preskaŭ tujan testadon de ŝanĝoj pro la altnivelaj kapabloj de dinamika koda ekzekuto efektivigita en Hotspot. Krome, dum kreado de indiĝenaj GraalVM-bildoj, la OpenJDK-klasa biblioteko kaj HotSpot-kapabloj estas uzataj.
Do kial vi bezonas denaskan kompilon se ĉio jam estas perfekte optimumigita? Ni provos respondi ĉi tiun demandon sube.
Ni komencu per la evidenta: Red Hat havas vastan sperton optimumigante JVM-ojn, stakojn kaj kadrojn dum projekt-disvolviĝo , inkluzive de:
- La unua aplikaĵoservilo laboranta en la nubo sur la platformo .
- La unua aplikaĵoservilo por funkciado en komputiloj .
- La unua aplika servilo por funkcii .
- Gamo da projektoj kurantaj sur aparatoj .
Ni traktas la defiojn pri rulado de Java-aplikoj en la nubo kaj sur resurs-limigitaj aparatoj (legu: IoT) dum multaj jaroj kaj lernis eltiri la plej multajn el la JVM laŭ rendimento kaj memor-optimumigo. Kiel multaj aliaj, ni jam delonge laboras kun denaska kompilo de Java-aplikoj , , kaj eĉ kaj ni bone konscias pri la avantaĝoj kaj malavantaĝoj de ĉi tiu aliro (ekzemple, la dilemo elekti inter la universaleco de "konstrui unufoje - ruliĝi ie ajn" kaj la fakto ke kompilitaj aplikoj estas pli malgrandaj kaj funkcias pli rapide).
Kial gravas konsideri ĉi tiujn avantaĝojn kaj malavantaĝojn? Ĉar en iuj situacioj ilia proporcio fariĝas decida:
- Ekzemple, en senservilaj/okazaĵaj medioj kie en (malmola aŭ mola) reala tempo por havi tempon respondi al eventoj. Male al longdaŭraj persistaj servoj, ĉi tie la daŭro de malvarma starto kritike pliigas la respondtempon al peto. La JVM ankoraŭ bezonas signifan tempon por komenci, kaj dum ĉi tio povas esti reduktita en iuj kazoj per puraj aparataj metodoj, la diferenco inter unu sekundo kaj 5 milisekundoj povas esti la diferenco inter vivo kaj morto. Jes, ĉi tie vi povas ludi per kreado de varma rezervo de Java maŝinoj (kion ni faris ekzemple per ), sed ĉi tio en si mem ne garantias, ke estos sufiĉe da JVM-oj por procesi petojn dum la ŝarĝo skalas. Kaj el ekonomia vidpunkto, ĉi tio verŝajne ne estas la plej ĝusta eblo.
- Plue, estas alia aspekto, kiu ofte aperas: plurtenado. Malgraŭ la fakto, ke JVM-oj tre proksimiĝis al operaciumoj en siaj kapabloj, ili ankoraŭ ne kapablas fari tion, al kio ni tiom kutimas en Linukso - izolaj procezoj. Tial, la malsukceso de unu fadeno povas faligi la tutan Java-maŝinon. Multaj homoj provas ĉirkaŭiri ĉi tiun malavantaĝon dediĉante apartan JVM por la aplikoj de ĉiu uzanto por minimumigi la sekvojn de malsukceso. Ĉi tio estas sufiĉe logika, sed ne bone kongruas kun skalo.
- Krome, por nubo-orientitaj aplikoj, grava indikilo estas la denseco de servoj sur la gastiganto. Transiro al metodiko , mikroservoj kaj Kubernetes pliigas la nombron da Java-maŝinoj per aplikaĵo. Tio estas, unuflanke, ĉio ĉi provizas elastecon kaj fidindecon, sed samtempe ankaŭ pliiĝas la konsumo de baza memoro laŭ servo, kaj iuj el ĉi tiuj elspezoj ne ĉiam estas strikte necesaj. Statike kompilitaj ruleblaj dosieroj profitas ĉi tie pro diversaj optimumigaj teknikoj, kiel malaltnivela malviva kodo-elimino, kiam la fina bildo inkluzivas nur tiujn partojn de la kadroj (inkluzive de la JDK mem), kiujn la servo efektive uzas. Sekve, Quarkus-indiĝena kompilo helpas dense meti servajn petskribojn sur la gastiganto sen endanĝerigi sekurecon.
Fakte, la supraj argumentoj jam sufiĉas por kompreni la pravigon de indiĝena kompilo el la vidpunkto de la partoprenantoj de la projekto Quarkus. Tamen ekzistas alia, ne-teknika, sed ankaŭ grava kialo: en la lastaj jaroj, multaj programistoj kaj evolukompanioj forlasis Javan favore al novaj programlingvoj, opiniante ke Java, kune kun siaj JVM-oj, stakoj kaj kadroj, fariĝis tro. memormalsata, tro malrapida, ktp.
Tamen, la kutimo uzi la saman ilon por solvi ajnan problemon estas . Kelkfoje estas pli bone fari paŝon malantaŭen kaj serĉi ion alian. Kaj se Quarkus igas homojn paŭzi kaj pensi, tiam tio estas bona por la tuta Java ekosistemo. Quarkus reprezentas novigan vidon pri kiel konstrui pli efikajn aplikojn, igante Javan pli grava al novaj aplikaĵarkitekturoj kiel senservila. Krome, pro ĝia etendebleco, Quarkus espereble havos tutan ekosistemon de Java-etendaĵoj, signife pliigante la nombron da kadroj, kiuj subtenos denaskan kompiladon en aplikoj el la skatolo.
fonto: www.habr.com