Përshëndetje të gjithëve! Ky është postimi i dytë nga seria jonë mbi Quarkus – sot do të flasim për kompilimin natyror.
– është një stak Java i projektuar për . 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 , duke përfshirë:
- Serveri i parë i aplikacioneve për të punuar në cloud në platformën .
- Serveri i parë i aplikacioneve për të punuar në kompjuterë .
- Serveri i parë i aplikacioneve për të punuar në .
- Një gamë e gjerë projektesh që funksionojnë në pajisje .
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 , , и даже 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 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 ), 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ë , 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 - . 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
