ProHoster > Blogs > Administrācija > Vietējā kompilācija Quarkus - kāpēc tas ir svarīgi

Vietējā kompilācija Quarkus - kāpēc tas ir svarīgi

Sveiki visiem! Å Ä« ir otrā ziņa mÅ«su sērijā par Quarkus ā€” Å”odien mēs runāsim par vietējo kompilāciju.

Vietējā kompilācija Quarkus - kāpēc tas ir svarīgi

Kvarkuss ir Java kaudze, kas pielāgota Kubernetes. Lai gan Å”eit noteikti ir daudz darāmā, mēs esam paveikuÅ”i daudz laba darba pie daudziem aspektiem, tostarp optimizējot JVM un vairākas ietvaras. Viena no Quarkus funkcijām, kas ir izraisÄ«jusi pastiprinātu izstrādātāju interesi, ir tā visaptveroŔā, vienlaidus pieeja Java koda pārvērÅ”anai izpildāmos failos noteiktai operētājsistēmai (tā sauktā ā€œnative kompilācijaā€), lÄ«dzÄ«gi kā C un C++, kur Ŕāda kompilācija parasti notiek izveides, testÄ“Å”anas un izvietoÅ”anas cikla beigās.

Un, lai gan vietējā kompilācija ir svarÄ«ga, kā mēs parādÄ«sim tālāk, jāatzÄ«mē, ka Quarkus patieŔām labi darbojas visizplatÄ«tākajā Java maŔīnā OpenJDK Hotspot, pateicoties veiktspējas uzlabojumiem, ko esam ieviesuÅ”i visā kaudzē. Tāpēc vietējā kompilācija jāuzskata par papildu bonusu, ko var izmantot pēc vēlÄ“Å”anās vai nepiecieÅ”amÄ«bas. Faktiski Quarkus ļoti paļaujas uz OpenJDK, kad runa ir par vietējiem attēliem. Un izstrādātāju režīms, ko ļoti atzinÄ«gi novērtējuÅ”i izstrādātāji, nodroÅ”ina gandrÄ«z tÅ«lÄ«tēju izmaiņu pārbaudi, pateicoties Hotspot ieviestajām uzlabotajām dinamiskā koda izpildes iespējām. Turklāt, veidojot vietējos GraalVM attēlus, tiek izmantota OpenJDK klases bibliotēka un HotSpot iespējas.

Tātad, kāpēc jums ir nepiecieÅ”ama vietējā kompilācija, ja viss jau ir perfekti optimizēts? Tālāk mēs centÄ«simies atbildēt uz Å”o jautājumu.

Sāksim ar acÄ«mredzamo: Red Hat ir liela pieredze JVM, steku un ietvaru optimizÄ“Å”anā projekta izstrādes laikā. JBoss, tostarp:

  • Pirmais lietojumprogrammu serveris, kas platformā strādā mākonÄ« Red Hat OpenShift.
  • Pirmais lietojumprogrammu serveris, kas darbojas datoros Pievienojiet datoru.
  • Pirmais lietojumprogrammu serveris, kurā darbojas Raspberry Pi.
  • Virkne projektu, kas darbojas ierÄ«cēs android.

Mēs jau daudzus gadus esam risinājuÅ”i problēmas, kas saistÄ«tas ar Java lietojumprogrammu darbināŔanu mākonÄ« un ierÄ«cēs ar ierobežotiem resursiem (lasÄ«t: IoT), un esam iemācÄ«juÅ”ies maksimāli izmantot JVM veiktspējas un atmiņas optimizācijas ziņā. Tāpat kā daudzi citi, mēs jau ilgu laiku esam strādājuÅ”i ar Java lietojumprogrammu vietējo kompilāciju G.C.J., Putni, Excelsior JET un pat Dalvik un mēs labi apzināmies Ŕīs pieejas plusus un mÄ«nusus (piemēram, dilemma izvēlēties starp universālumu ā€œbÅ«vēt vienreiz ā€“ palaist jebkurā€ un to, ka apkopotās lietojumprogrammas ir mazākas un darbojas ātrāk).

Kāpēc ir svarÄ«gi apsvērt Å”os plusus un mÄ«nusus? Tā kā dažās situācijās to attiecÄ«ba kļūst noteicoŔā:

  • Piemēram, bezserveru/notikumu vadÄ«tās vidēs, kur pakalpojumi vienkārÅ”i jāsāk (cietajā vai mÄ«kstajā) reāllaikā, lai bÅ«tu laiks reaģēt uz notikumiem. AtŔķirÄ«bā no ilgstoÅ”iem pastāvÄ«giem pakalpojumiem, Å”eit aukstās palaiÅ”anas ilgums kritiski palielina atbildes laiku uz pieprasÄ«jumu. JVM palaiÅ”ana joprojām prasa ievērojamu laiku, un, lai gan dažos gadÄ«jumos to var samazināt, izmantojot tikai aparatÅ«ras metodes, atŔķirÄ«ba starp vienu sekundi un 5 milisekundēm var bÅ«t atŔķirÄ«ba starp dzÄ«vÄ«bu un nāvi. Jā, Å”eit jÅ«s varat paspēlēties ar Java maŔīnu karstās rezerves izveidi (ko, piemēram, mēs darÄ«jām ar OpenWhisk pārneÅ”ana uz Knative), taču tas pats par sevi negarantē, ka bÅ«s pietiekami daudz JVM, lai apstrādātu pieprasÄ«jumus kā slodzes skalas. Un no ekonomiskā viedokļa tas, iespējams, nav pareizākais variants.
  • Turklāt bieži parādās vēl viens aspekts: vairāku Ä«re. Neskatoties uz to, ka JVM savās iespējās ir pietuvojuÅ”ies ļoti tuvu operētājsistēmām, tie joprojām nav spējÄ«gi darÄ«t to, pie kā esam tik ļoti pieraduÅ”i Linux ā€“ izolēt procesus. Tāpēc viena pavediena kļūme var nojaukt visu Java maŔīnu. Daudzi cilvēki cenÅ”as apiet Å”o trÅ«kumu, katrai lietotāja lietojumprogrammai pieŔķirot atseviŔķu JVM, lai samazinātu kļūmes sekas. Tas ir diezgan loÄ£iski, taču tas labi nesaskan ar mērogoÅ”anu.
  • Turklāt uz mākoņiem orientētām lietojumprogrammām svarÄ«gs rādÄ«tājs ir pakalpojumu blÄ«vums resursdatorā. Pāreja uz metodiku 12 pielietojuma faktori, mikropakalpojumi un Kubernetes palielina Java maŔīnu skaitu vienā lietojumprogrammā. Tas ir, no vienas puses, tas viss nodroÅ”ina elastÄ«bu un uzticamÄ«bu, bet tajā paŔā laikā palielinās arÄ« bāzes atmiņas patēriņŔ apkalpoÅ”anas ziņā, un daži no Å”iem izdevumiem ne vienmēr ir obligāti nepiecieÅ”ami. Statiski kompilēti izpildāmie faili Å”eit ir noderÄ«gi dažādu optimizācijas paņēmienu dēļ, piemēram, zema lÄ«meņa miruŔā koda likvidÄ“Å”ana, kad galÄ«gajā attēlā ir iekļautas tikai tās ietvaru daļas (tostarp pats JDK), kuras pakalpojums faktiski izmanto. Tāpēc Quarkus vietējā kompilācija palÄ«dz blÄ«vi izvietot pakalpojumu gadÄ«jumus resursdatorā, neapdraudot droŔību.

Faktiski ar iepriekÅ”minētajiem argumentiem jau ir pietiekami, lai saprastu vietējās kompilācijas pamatojumu no Quarkus projekta dalÄ«bnieku viedokļa. Tomēr ir vēl viens, netehnisks, bet arÄ« svarÄ«gs iemesls: pēdējos gados daudzi programmētāji un izstrādes uzņēmumi ir atteikuÅ”ies no Java par labu jaunām programmÄ“Å”anas valodām, uzskatot, ka Java kopā ar tās JVM, skursteņiem un ietvariem ir kļuvusi pārāk liela. atmiņas izsalkuÅ”i, pārāk lēni utt.

Tomēr ieradums izmantot vienu un to paÅ”u rÄ«ku jebkuras problēmas risināŔanai ir tas ne vienmēr ir pareizi. Dažreiz labāk ir atkāpties un meklēt kaut ko citu. Un, ja Quarkus liek cilvēkiem apstāties un padomāt, tad tas nāk par labu visai Java ekosistēmai. Quarkus ir novatorisks skatÄ«jums uz to, kā veidot efektÄ«vākas lietojumprogrammas, padarot Java atbilstoŔāku jaunām lietojumprogrammu arhitektÅ«rām, piemēram, bez servera. Turklāt, pateicoties tā paplaÅ”ināmÄ«bai, Quarkus, cerams, bÅ«s visa Java paplaÅ”inājumu ekosistēma, ievērojami palielinot to ietvaru skaitu, kas atbalstÄ«s sākotnējo kompilāciju lietojumprogrammās.

Avots: www.habr.com

Pievieno komentāru