Salaam wote! Hili ni chapisho la pili katika safu yetu ya Quarkus - leo tutazungumza juu ya mkusanyiko wa asili.
ni mrundikano wa Java iliyoundwa kwa ajili ya . Ingawa hakika kuna mengi zaidi ya kufanya hapa, tumefanya kazi nyingi nzuri kwa vipengele vingi, ikiwa ni pamoja na kuboresha JVM na idadi ya mifumo. Mojawapo ya sifa za Quarkus ambazo zimevutia kuongezeka kwa shauku kutoka kwa watengenezaji ni mbinu yake ya kina, isiyo na mshono ya kugeuza nambari ya Java kuwa faili zinazoweza kutekelezwa kwa mfumo maalum wa kufanya kazi (unaoitwa "mkusanyiko wa asili"), sawa na C na C++, ambapo mkusanyiko kama huo. kawaida hutokea mwishoni mwa mzunguko wa kujenga, mtihani, na kupelekwa.
Na ingawa mkusanyo wa asili ni muhimu, kama tutakavyoonyesha hapa chini, ikumbukwe kwamba Quarkus hufanya kazi vizuri kwenye mashine ya kawaida ya Java, OpenJDK Hotspot, shukrani kwa maboresho ya utendakazi ambayo tumetekeleza katika safu nzima. Kwa hivyo, mkusanyiko asilia unapaswa kuzingatiwa kama bonasi ya ziada ambayo inaweza kutumika kama inavyotakiwa au muhimu. Kwa kweli, Quarkus hutegemea sana OpenJDK linapokuja suala la picha asili. Na hali ya usanidi, inayokubaliwa kwa uchangamfu na wasanidi programu, huhakikisha majaribio ya karibu papo hapo ya mabadiliko kutokana na uwezo wa juu wa utekelezaji wa msimbo unaotekelezwa katika Hotspot. Kwa kuongeza, wakati wa kuunda picha za asili za GraalVM, maktaba ya darasa la OpenJDK na uwezo wa HotSpot hutumiwa.
Kwa hivyo kwa nini unahitaji mkusanyiko wa asili ikiwa kila kitu tayari kimeboreshwa kikamilifu? Tutajaribu kujibu swali hili hapa chini.
Wacha tuanze na dhahiri: Red Hat ina uzoefu mkubwa wa kuboresha JVM, safu na mifumo wakati wa ukuzaji wa mradi. , ikiwa ni pamoja na:
- Seva ya kwanza ya programu kufanya kazi katika wingu kwenye jukwaa .
- Seva ya kwanza ya programu inayotumika kwenye kompyuta .
- Seva ya kwanza ya programu kuendeshwa .
- Miradi mbalimbali inayoendeshwa kwenye vifaa .
Tumekuwa tukishughulika na changamoto za kuendesha programu za Java katika wingu na kwenye vifaa vinavyobanwa na rasilimali (soma: IoT) kwa miaka mingi na tumejifunza kufaidika zaidi na JVM katika suala la utendakazi na uboreshaji wa kumbukumbu. Kama wengine wengi, tumekuwa tukifanya kazi na mkusanyiko asilia wa programu za Java kwa muda mrefu kupitia , , na hata na tunafahamu vyema faida na hasara za mbinu hii (kwa mfano, mtanziko wa kuchagua kati ya ulimwengu wote wa "build once - run-popote" na ukweli kwamba maombi yaliyokusanywa ni ndogo na yanaendeshwa kwa kasi).
Kwa nini ni muhimu kuzingatia faida na hasara hizi? Kwa sababu katika hali zingine uwiano wao unakuwa wa kuamua:
- Kwa mfano, katika mazingira yasiyo na seva/tukio yanayoendeshwa ambapo katika (ngumu au laini) wakati halisi ili kuwa na wakati wa kujibu matukio. Tofauti na huduma za kudumu kwa muda mrefu, hapa muda wa kuanza kwa baridi huongeza sana wakati wa kukabiliana na ombi. JVM bado inachukua muda mwingi kuanza, na ingawa hii inaweza kupunguzwa katika baadhi ya matukio kwa mbinu safi za maunzi, tofauti kati ya sekunde moja na milisekunde 5 inaweza kuwa tofauti kati ya maisha na kifo. Ndio, hapa unaweza kucheza na kuunda hifadhi ya moto ya mashine za Java (ambayo, kwa mfano, tulifanya nayo. ), lakini hii yenyewe haihakikishi kuwa kutakuwa na JVM za kutosha kushughulikia maombi kama mizani ya mzigo. Na kutoka kwa mtazamo wa kiuchumi, hii labda sio chaguo sahihi zaidi.
- Zaidi ya hayo, kuna kipengele kingine ambacho mara nyingi hujitokeza: multitenancy. Licha ya ukweli kwamba JVM wamekaribia sana mifumo ya uendeshaji katika uwezo wao, bado hawana uwezo wa kufanya kile ambacho tumezoea katika Linux - michakato ya kutenganisha. Kwa hiyo, kushindwa kwa thread moja kunaweza kuleta mashine nzima ya Java. Watu wengi hujaribu kuzunguka kasoro hii kwa kuweka JVM tofauti kwa programu tumizi ya kila mtumiaji ili kupunguza matokeo ya kutofaulu. Hii ni mantiki kabisa, lakini haifai vizuri na kuongeza.
- Kwa kuongeza, kwa programu zinazoelekezwa kwa wingu, kiashiria muhimu ni wiani wa huduma kwenye mwenyeji. Mpito kwa mbinu , huduma ndogo na Kubernetes huongeza idadi ya mashine za Java kwa kila programu. Hiyo ni, kwa upande mmoja, yote haya hutoa elasticity na kuegemea, lakini wakati huo huo matumizi ya kumbukumbu ya msingi katika suala la huduma pia huongezeka, na baadhi ya gharama hizi sio lazima kila wakati. Faili zinazoweza kutekelezeka zilizokusanywa kwa uthabiti hunufaika hapa kutokana na mbinu mbalimbali za uboreshaji, kama vile uondoaji wa msimbo uliokufa wa kiwango cha chini, wakati picha ya mwisho inajumuisha tu sehemu hizo za mifumo (pamoja na JDK yenyewe) ambayo huduma hutumia. Kwa hivyo, mkusanyiko asili wa Quarkus husaidia kuweka matukio ya huduma kwa msongamano bila kuathiri usalama.
Kwa kweli, hoja zilizo hapo juu tayari zinatosha kuelewa uhalali wa mkusanyiko wa asili kutoka kwa mtazamo wa washiriki wa mradi wa Quarkus. Walakini, kuna sababu nyingine, isiyo ya kiufundi, lakini pia muhimu: katika miaka ya hivi karibuni, watengenezaji programu na kampuni nyingi za maendeleo wameacha Java kwa niaba ya lugha mpya za programu, wakiamini kuwa Java, pamoja na JVMs, safu na mifumo, imekuwa pia. kumbukumbu-njaa, polepole mno, nk.
Hata hivyo, tabia ya kutumia chombo sawa kutatua tatizo lolote ni . Wakati mwingine ni bora kuchukua hatua nyuma na kutafuta kitu kingine. Na ikiwa Quarkus huwafanya watu watume na kufikiria, basi hiyo ni nzuri kwa mfumo mzima wa ikolojia wa Java. Quarkus inawakilisha mtazamo wa kiubunifu wa jinsi ya kuunda programu bora zaidi, na kuifanya Java kuwa muhimu zaidi kwa usanifu mpya wa programu kama vile isiyo na seva. Kwa kuongeza, kwa sababu ya upanuzi wake, Quarkus itakuwa na matumaini ya kuwa na mfumo mzima wa ikolojia wa viendelezi vya Java, na kuongeza kwa kiasi kikubwa idadi ya mifumo ambayo itasaidia ujumuishaji wa asili katika programu nje ya boksi.
Chanzo: mapenzi.com