Hæ allir! Þetta er önnur færslan í röðinni okkar um Quarkus - í dag munum við tala um innfædda samantekt.
er Java stafla sniðinn fyrir . Þó að það sé vissulega miklu meira að gera hér, höfum við unnið mikið og gott starf á mörgum þáttum, þar á meðal að fínstilla JVM og fjölda ramma. Einn af eiginleikum Quarkus sem hefur vakið aukinn áhuga þróunaraðila er alhliða, hnökralaus nálgun þess að breyta Java kóða í keyranlegar skrár fyrir tiltekið stýrikerfi (svokallað „native compilation“), svipað og C og C++, þar sem slík samantekt. gerist venjulega í lok hringrásar byggingar, prófunar og uppsetningar.
Og þó að innbyggð samantekt sé mikilvæg, eins og við munum sýna hér að neðan, skal tekið fram að Quarkus keyrir mjög vel á algengustu Java vélinni, OpenJDK Hotspot, þökk sé frammistöðubótunum sem við höfum innleitt í gegnum staflann. Þess vegna ætti að líta á innfædda samantekt sem viðbótarbónus sem hægt er að nota eftir þörfum eða þörf. Reyndar treystir Quarkus mjög á OpenJDK þegar kemur að innfæddum myndum. Og þróunarstillingin, sem hönnuðir hafa tekið hjartanlega vel við, tryggir næstum tafarlaus prófun á breytingum vegna háþróaðrar getu kraftmikillar kóðaframkvæmd sem innleidd er í Hotspot. Að auki, þegar búið er til innfæddar GraalVM myndir, er OpenJDK bekkjarsafnið og HotSpot hæfileikar notaðir.
Svo hvers vegna þarftu innfædda samantekt ef allt er þegar fullkomlega fínstillt? Við munum reyna að svara þessari spurningu hér að neðan.
Byrjum á því augljósa: Red Hat hefur víðtæka reynslu af því að fínstilla JVM, stafla og ramma við þróun verkefna , þar á meðal:
- Fyrsti forritaþjónninn sem vinnur í skýinu á pallinum .
- Fyrsti forritaþjónninn til að keyra á tölvum .
- Fyrsti forritaþjónninn til að keyra á .
- Fjölbreytt verkefni í gangi á tækjum .
Við höfum verið að takast á við þær áskoranir sem fylgja því að keyra Java forrit í skýinu og á tækjum með takmarkaða auðlind (lesist: IoT) í mörg ár og höfum lært að fá sem mest út úr JVM hvað varðar afköst og minni fínstillingu. Eins og margir aðrir höfum við unnið með innbyggða samantekt Java forrita í langan tíma , , og jafnvel og við erum vel meðvituð um kosti og galla þessarar aðferðar (td vandamálið við að velja á milli algildis „byggja einu sinni – keyra hvar sem er“ og þeirrar staðreyndar að samansett forrit eru smærri og keyra hraðar).
Hvers vegna er mikilvægt að íhuga þessa kosti og galla? Vegna þess að í sumum tilfellum verður hlutfall þeirra afgerandi:
- Til dæmis, í netþjónalausu/viðburðadrifnu umhverfi þar sem í (hörðum eða mjúkum) rauntíma til að hafa tíma til að bregðast við atburðum. Ólíkt langvarandi viðvarandi þjónustu, hér eykur tímalengd kaldræsingar viðbragðstímann við beiðni. JVM tekur enn töluverðan tíma að ræsa sig og þó að hægt sé að draga úr þessu í sumum tilfellum með hreinum vélbúnaðaraðferðum, getur munurinn á milli einni sekúndu og 5 millisekúndna verið munurinn á lífi og dauða. Já, hér geturðu leikið þér að því að búa til heitan varasjóð af Java vélum (sem við til dæmis gerðum með ), en þetta í sjálfu sér tryggir ekki að það verði nóg af JVM til að vinna úr beiðnum eftir því sem hleðslan mælist. Og frá efnahagslegu sjónarmiði er þetta líklega ekki réttasti kosturinn.
- Ennfremur er annar þáttur sem oft kemur upp: fjöleign. Þrátt fyrir þá staðreynd að JVMs hafi komist mjög nálægt stýrikerfum í getu sinni, þá eru þeir samt ekki færir um að gera það sem við erum svo vön í Linux - að einangra ferla. Þess vegna getur bilun á einum þræði fellt alla Java vélina. Margir reyna að komast hjá þessum galla með því að tileinka sérstakt JVM fyrir forrit hvers notanda til að lágmarka afleiðingar bilunar. Þetta er alveg rökrétt, en passar ekki vel við skala.
- Að auki, fyrir skýjamiðuð forrit, er mikilvægur vísir þéttleiki þjónustu á hýsingaraðilanum. Umskipti yfir í aðferðafræði , örþjónustur og Kubernetes fjölgar Java vélum í hverju forriti. Það er, annars vegar, allt þetta veitir teygjanleika og áreiðanleika, en á sama tíma eykst neysla grunnminni hvað varðar þjónustu, og sum þessara útgjalda eru ekki alltaf nauðsynleg. Statískt samsettar keyranlegar skrár njóta góðs af því vegna ýmissa hagræðingaraðferða, svo sem útrýmingar á lágu stigi dauðakóða, þegar lokamyndin inniheldur aðeins þá hluta ramma (þar á meðal JDK sjálft) sem þjónustan notar í raun. Þess vegna hjálpar Quarkus innfæddur samansafn við að setja þjónustutilvik þétt á hýsilinn án þess að skerða öryggi.
Reyndar nægja ofangreind rök nú þegar til að skilja réttlætingu innfæddrar samantektar frá sjónarhóli þátttakenda Quarkus verkefnisins. Hins vegar er önnur, ótæknileg, en einnig mikilvæg ástæða: á undanförnum árum hafa margir forritarar og þróunarfyrirtæki yfirgefið Java í þágu nýrra forritunarmála, í þeirri trú að Java, ásamt JVM, stafla og ramma, hafi orðið of minnisþrunginn, of hægur o.s.frv.
Hins vegar er vaninn að nota sama tólið til að leysa öll vandamál . Stundum er betra að stíga skref til baka og leita að einhverju öðru. Og ef Quarkus fær fólk til að staldra við og hugsa, þá er það gott fyrir allt Java vistkerfið. Quarkus táknar nýstárlega sýn á hvernig á að byggja upp skilvirkari forrit, sem gerir Java meira viðeigandi fyrir nýja forritaarkitektúr eins og netþjónalaus. Þar að auki, vegna stækkanleika þess, mun Quarkus vonandi hafa heilt vistkerfi af Java viðbótum, sem mun auka verulega fjölda ramma sem munu styðja innbyggða samantekt í forritum úr kassanum.
Heimild: www.habr.com