ProHoster > Blog > Administrimi > Kompilimi natyror nĂ« Quarkus – pse Ă«shtĂ« i rĂ«ndĂ«sishĂ«m

Kompilimi natyror nĂ« Quarkus – pse Ă«shtĂ« i rĂ«ndĂ«sishĂ«m

PĂ«rshĂ«ndetje tĂ« gjithĂ«ve! Ky Ă«shtĂ« postimi i dytĂ« nga seria jonĂ« mbi Quarkus – sot do tĂ« flasim pĂ«r kompilimin natyror.

Kompilimi natyror nĂ« Quarkus – pse Ă«shtĂ« i rĂ«ndĂ«sishĂ«m

Quarkus – Ă«shtĂ« njĂ« stak Java i projektuar pĂ«r Kubernetes. Dhe ndonĂ«se ka ende shumĂ« pĂ«r tĂ« bĂ«rĂ«, ne kemi punuar mirĂ« mbi shumĂ« aspekte, duke pĂ«rfshirĂ« optimizimin e JVM dhe njĂ« sĂ«rĂ« strukturash. NjĂ« nga karakteristikat e Quarkus qĂ« ka shkaktuar interes tĂ« madh nga zhvilluesit Ă«shtĂ« qasja e tij gjithĂ«pĂ«rfshirĂ«se dhe pa ndĂ«rprerje pĂ«r shndĂ«rrimin e kodit Java nĂ« skedarĂ« ekzekutivĂ« pĂ«r njĂ« sistem operativ specifik (e njohur si "kompilimi natyror") nĂ« mĂ«nyrĂ« tĂ« ngjashme me C dhe C++, ku njĂ« kompilim i tillĂ« zakonisht ndodh nĂ« fund tĂ« ciklit, i cili pĂ«rfshin ndĂ«rtimin, testimin dhe shpĂ«rndarjen.

Edhe pse kompilimi natyror, siç do të tregojmë më poshtë, është i rëndësishëm, duhet theksuar se Quarkus funksionon mjaft mirë edhe në makinën standarde Java OpenJDK Hotspot falë përmirësimeve të performancës që kemi zbatuar në të gjithë grumbullin. Prandaj, kompilimi natyror duhet të konsiderohet si një bonus shtesë që mund të përdoret në varësi të dëshirës ose nevojës. Në të vërtetë, sa i përket imazheve natyrore, Quarkus mbështetet në masë të madhe në OpenJDK. Mënyra dev mode, e cila është mirëpritur nga zhvilluesit, siguron testim praktikisht të menjëhershëm të ndryshimeve falë mundësive të zhvilluara për ekzekutimin dinamik të kodit, të realizuara në Hotspot. Për më tepër, kur krijohen imazhe natyrore, GraalVM përdor bibliotekën e klasave të OpenJDK dhe mundësitë e HotSpot.

Por pse na nevojitet kompilimi natyror, nëse gjithçka është tashmë e optimizuar aq mirë? Për këtë pyetje do të përpiqemi të përgjigjemi më poshtë.

Le të fillojmë me të dukshmen: Red Hat ka përvojë të madhe në optimizimin e JVM, grumbujve dhe kornizave gjatë zhvillimit të projektit JBoss, duke përfshirë:

  • Serveri i parĂ« i aplikacioneve pĂ«r tĂ« punuar nĂ« cloud nĂ« platformĂ«n Red Hat OpenShift.
  • Serveri i parĂ« i aplikacioneve pĂ«r tĂ« punuar nĂ« kompjuterĂ« Plug PC.
  • Serveri i parĂ« i aplikacioneve pĂ«r tĂ« punuar nĂ« Raspberry Pi.
  • NjĂ« gamĂ« e gjerĂ« projektesh qĂ« funksionojnĂ« nĂ« pajisje Fare OS.

Kemi kaluar shumë vite duke u marrë me problemet e insatimit të aplikacioneve Java në re dhe në pajisje me burime të kufizuara (domethënë, IoT) dhe kemi mësuar të shfrytëzojmë maksimalin nga JVM në lidhje me performancën dhe optimizimin e memories. Si shumë të tjerë, ne kemi punuar prej kohësh me kompilimin natyror të aplikacioneve Java përmes GCJ, Avian, Excelsior JET dhe madje Dalvik dhe jemi plotësisht të vetëdijshëm për përparësitë dhe disavantazhet e këtij qasje (për shembull, dilemën e zgjedhjes midis universialitetit "kompliko një herë - funksionon kudo" dhe faktit që aplikacionet e komatuara janë më të vogla dhe startojnë më shpejt).

Pse është kaq e rëndësishme të merret parasysh këto përparësi dhe disavantazhe? Sepse në disa situata raporti i tyre bëhet vendimtar:

  • PĂ«r shembull, nĂ« mjediset serverless / tĂ« menaxhuara nga ngjarjet, ku shĂ«rbimet thjesht duhet tĂ« nisin nĂ« mĂ«nyrĂ« (tĂ« rreptĂ« ose tĂ« butĂ«) nĂ« kohĂ« reale, pĂ«r tĂ« qenĂ« nĂ« gjendje tĂ« reagoni ndaj ngjarjeve. Ndryshe nga shĂ«rbimet e qĂ«ndrueshme me jetĂ« tĂ« gjatĂ«, kĂ«tu kohĂ«zgjatja e nisjes sĂ« ftohtĂ« rrit ndjeshĂ«m kohĂ«n e pĂ«rgjigjes ndaj kĂ«rkesĂ«s. Ende kĂ«rkohet shumĂ« kohĂ« pĂ«r tĂ« nisur JVM, dhe ndonĂ«se nĂ« disa raste kjo mund tĂ« reduktohet pĂ«rmes metodave ekskluzivisht harduerike, ndryshimi midis njĂ« sekonde dhe 5 milisekondave mund tĂ« jetĂ« njĂ« çështje jete a vdekje. Po, kĂ«tu mund tĂ« eksperimentoni me krijimin e njĂ« rezervĂ« tĂ« nxehtĂ« tĂ« Java-makinerive (çka ne e bĂ«mĂ«, pĂ«r shembull, me portimin e OpenWhisk nĂ« Knative), por kjo vetĂ« nuk garanton numrin e mjaftueshĂ«m tĂ« JVM-ve pĂ«r pĂ«rpunimin e kĂ«rkesave ndĂ«rsa ngarkesa zmadhohet. NjĂ«kohĂ«sisht, nga pikĂ«pamja ekonomike, ndoshta nuk Ă«shtĂ« zgjidhja mĂ« e duhur.
  • MĂ« pas, ka njĂ« aspekt tjetĂ«r qĂ« shpesh shfaqet, siç Ă«shtĂ« multitenantizmi. MegjithĂ«se JVM ka arritur nĂ« mundĂ«si tĂ« ngjashme me ato tĂ« sistemeve operative, ato ende nuk janĂ« nĂ« gjendje tĂ« bĂ«jnĂ« atĂ« qĂ« ne jemi mĂ«suar tĂ« shohim nĂ« Linux – tĂ« izolojnĂ« proceset. Prandaj, njĂ« dĂ«shtim i njĂ« thread-i mund tĂ« shkaktojĂ« dĂ«shtimin e gjithĂ« Java-makinĂ«s. ShumĂ« pĂ«rpiqen tĂ« kalojnĂ« kĂ«tĂ« mangĂ«si duke ndarĂ« njĂ« JVM tĂ« veçantĂ« pĂ«r aplikacionet e çdo pĂ«rdoruesi, pĂ«r tĂ« minimizuar pasojat e dĂ«shtimit. Kjo Ă«shtĂ« krejtĂ«sisht logjike, por keq kuptohet me shkallĂ«zimin.
  • PĂ«r mĂ« tepĂ«r, pĂ«r aplikacionet e orientuara nĂ« cloud, njĂ« tregues i tillĂ« si dendĂ«sia e shĂ«rbimeve nĂ« host Ă«shtĂ« i rĂ«ndĂ«sishĂ«m. Kalimi nĂ« metodologjinĂ« 12 faktorĂ«t e aplikacionit, mikroserviset dhe Kubernetes rrisin numrin e makinave Java pĂ«r njĂ« aplikacion. Kjo do tĂ« thotĂ« se, nga njĂ«ra anĂ«, tĂ« gjitha kĂ«to ofrojnĂ« elastikĂ« dhe besueshmĂ«ri, por njĂ«kohĂ«sisht rritet edhe shpenzimi i memories bazĂ« pĂ«r shĂ«rbim, dhe njĂ« pjesĂ« e kĂ«tyre shpenzimeve nuk Ă«shtĂ« gjithmonĂ« e nevojshme. SkedarĂ«t ekzekutivĂ« tĂ« kompiluar statikisht fitojnĂ« nĂ« kĂ«tĂ« rast pĂ«rmes teknikave tĂ« ndryshme optimizimi, si eliminimi i kodit tĂ« vdekur nĂ« nivel tĂ« ulĂ«t, kur nĂ« imazhin pĂ«rfundimtar pĂ«rfshihen vetĂ«m ato pjesĂ« tĂ« relevante tĂ« framework-Ă«ve (duke pĂ«rfshirĂ« edhe vetĂ« JDK), qĂ« shĂ«rbimi nĂ« tĂ« vĂ«rtetĂ« i pĂ«rdor. Prandaj, kompaktimi natyror i Quarkus ndihmon nĂ« vendosjen mĂ« tĂ« ngjeshur tĂ« instancave tĂ« shĂ«rbimeve nĂ« host pa kompromise pĂ«r sigurinĂ«.

Të gjitha argumentet e sipërpërmendura janë tashmë të mjaftueshme për të kuptuar arsyen e justifikimit të kompilimit natyror nga këndvështrimi i pjesëmarrësve në projektin Quarkus. Megjithatë, ka një arsye tjetër, jo teknike, por po aq e rëndësishme: vitet e fundit, shumë programues dhe kompani zhvillues kanë hequr dorë nga Java në favor të gjuhëve të reja të programimit, duke menduar se Java, së bashku me JVM-të, steket dhe kornizat e saj, është bërë tepër e etur për memorie, jashtëzakonisht e ngadaltë, etj.

Megjithatë, zakoni për të përdorur të njëjtin mjet për zgjidhjen e çdo problemi - nuk është gjithmonë i saktë. Ndonjëherë është më mirë të heqësh një hap prapa dhe të kërkosh diçka tjetër. Nëse Quarkus i bën njerëzit të ndalojnë dhe të mendojnë, atëherë kjo është e mirë për tërë ekosistemin e Java-s. Quarkus përfaqëson një perspektivë novatore mbi mënyrën se si të krijohen aplikacione më efektive, duke e bërë Java më relevante për arkitekturat e reja të aplikacioneve, si serverless. Për më tepër, falë zgjerueshmërisë së saj, shpresojmë që Quarkus të ketë një ekosistem të tërë zgjerimesh Java, duke rritur ndjeshëm numrin e framework-eve që do të mbështesin compilimin natyror në aplikacione nga kutia.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster