Pershendetje te gjitheve! Ky është postimi i dytë në serinë tonë në Quarkus - sot do të flasim për përpilimin vendas.
është një pirg Java i përshtatur për . Ndërsa sigurisht që ka shumë më tepër për të bërë këtu, ne kemi bërë shumë punë të mirë në shumë aspekte, duke përfshirë optimizimin e JVM dhe një sërë kornizash. Një nga veçoritë e Quarkus që ka tërhequr interesim të shtuar nga zhvilluesit është qasja e tij gjithëpërfshirëse dhe e qetë për ta kthyer kodin Java në skedarë të ekzekutueshëm për një sistem operativ specifik (i ashtuquajturi "përpilim vendas"), i ngjashëm me C dhe C++, ku një përpilim i tillë zakonisht ndodh në fund të një cikli ndërtimi, testimi dhe vendosjeje.
Dhe ndërsa përpilimi vendas është i rëndësishëm, siç do të tregojmë më poshtë, duhet të theksohet se Quarkus funksionon vërtet mirë në makinën më të zakonshme Java, OpenJDK Hotspot, falë përmirësimeve të performancës që kemi zbatuar në të gjithë grupin. Prandaj, përpilimi vendas duhet të konsiderohet si një bonus shtesë që mund të përdoret sipas dëshirës ose nevojës. Në fakt, Quarkus mbështetet shumë në OpenJDK kur bëhet fjalë për imazhet vendase. Dhe modaliteti i devijimit, i pranuar ngrohtësisht nga zhvilluesit, siguron testimin pothuajse të menjëhershëm të ndryshimeve për shkak të aftësive të avancuara të ekzekutimit dinamik të kodit të zbatuar në Hotspot. Përveç kësaj, kur krijohen imazhe amtare GraalVM, përdoren biblioteka e klasës OpenJDK dhe aftësitë HotSpot.
Pra, pse keni nevojë për përpilim vendas nëse gjithçka tashmë është optimizuar në mënyrë perfekte? Ne do të përpiqemi t'i përgjigjemi kësaj pyetjeje më poshtë.
Le të fillojmë me të dukshmen: Red Hat ka përvojë të gjerë në optimizimin e JVM-ve, pirgjeve dhe kornizave gjatë zhvillimit të projektit , duke përfshirë:
- Serveri i parë i aplikacionit që funksionon në cloud në platformë .
- Serveri i parë i aplikacionit që funksionon në kompjuterë .
- Serveri i parë i aplikacionit që funksionon .
- Një sërë projektesh që funksionojnë në pajisje .
Ne kemi qenë duke u marrë me sfidat e ekzekutimit të aplikacioneve Java në cloud dhe në pajisje me burime të kufizuara (lexo: IoT) për shumë vite dhe kemi mësuar të përfitojmë sa më shumë nga JVM për sa i përket performancës dhe optimizimit të kujtesës. Si shumë të tjerë, ne kemi punuar me përpilimin vendas të aplikacioneve Java për një kohë të gjatë , , dhe madje edhe dhe ne jemi të vetëdijshëm për të mirat dhe të këqijat e kësaj qasjeje (për shembull, dilema e zgjedhjes midis universalitetit të "ndërto një herë - ekzekuto-kudo" dhe faktit që aplikacionet e përpiluara janë më të vogla dhe funksionojnë më shpejt).
Pse është e rëndësishme të merren parasysh këto të mirat dhe të këqijat? Sepse në disa situata raporti i tyre bëhet vendimtar:
- Për shembull, në mjediset pa server/të drejtuar nga ngjarjet ku në kohë reale (të vështirë ose të butë) në mënyrë që të keni kohë për t'iu përgjigjur ngjarjeve. Ndryshe nga shërbimet e qëndrueshme jetëgjatë, këtu kohëzgjatja e një fillimi të ftohtë rrit në mënyrë kritike kohën e përgjigjes ndaj një kërkese. JVM kërkon ende një kohë të konsiderueshme për t'u nisur, dhe ndërsa kjo mund të reduktohet në disa raste me metoda të pastra harduerike, diferenca midis një sekonde dhe 5 milisekonda mund të jetë diferenca midis jetës dhe vdekjes. Po, këtu mund të luani me krijimin e një rezerve të nxehtë të makinave Java (të cilën, për shembull, e bëmë me ), por kjo në vetvete nuk garanton se do të ketë mjaft JVM për të përpunuar kërkesat sipas shkallës së ngarkesës. Dhe nga pikëpamja ekonomike, kjo ndoshta nuk është alternativa më e saktë.
- Më tej, ka një aspekt tjetër që shfaqet shpesh: shumë qira. Përkundër faktit se JVM-të janë afruar shumë me sistemet operative në aftësitë e tyre, ata ende nuk janë në gjendje të bëjnë atë që jemi mësuar aq shumë në Linux - proceset izoluese. Prandaj, dështimi i një filli mund të rrëzojë të gjithë makinën Java. Shumë njerëz përpiqen të kapërcejnë këtë pengesë duke dedikuar një JVM të veçantë për aplikacionin e secilit përdorues në mënyrë që të minimizojnë pasojat e një dështimi. Kjo është mjaft logjike, por nuk përshtatet mirë me shkallëzimin.
- Për më tepër, për aplikacionet e orientuara nga cloud, një tregues i rëndësishëm është dendësia e shërbimeve në host. Kalimi në metodologji , microservices dhe Kubernetes rrit numrin e makinave Java për aplikacion. Kjo do të thotë, nga njëra anë, e gjithë kjo siguron elasticitet dhe besueshmëri, por në të njëjtën kohë rritet edhe konsumi i memories bazë për sa i përket shërbimit, dhe disa nga këto shpenzime nuk janë gjithmonë rreptësisht të nevojshme. Skedarët e ekzekutueshëm të përpiluar statikisht përfitojnë këtu për shkak të teknikave të ndryshme të optimizimit, të tilla si eliminimi i kodit të vdekur të nivelit të ulët, kur imazhi përfundimtar përfshin vetëm ato pjesë të kornizave (përfshirë vetë JDK-në) që shërbimi përdor në të vërtetë. Prandaj, përpilimi vendas i Quarkus ndihmon në vendosjen e dendur të instancave të shërbimit në host pa kompromentuar sigurinë.
Në fakt, argumentet e mësipërme janë tashmë të mjaftueshme për të kuptuar justifikimin e përpilimit vendas nga këndvështrimi i pjesëmarrësve të projektit Quarkus. Megjithatë, ka një arsye tjetër, jo-teknike, por edhe të rëndësishme: vitet e fundit, shumë programues dhe kompani zhvillimi kanë braktisur Java-n në favor të gjuhëve të reja të programimit, duke besuar se Java, së bashku me JVM-të, pirgjet dhe kornizat e saj, është bërë shumë. i uritur për kujtesë, shumë i ngadalshëm, etj.
Sidoqoftë, zakoni i përdorimit të të njëjtit mjet për të zgjidhur çdo problem është . Ndonjëherë është më mirë të bëni një hap prapa dhe të kërkoni diçka tjetër. Dhe nëse Quarkus i bën njerëzit të ndalojnë dhe të mendojnë, atëherë kjo është mirë për të gjithë ekosistemin Java. Quarkus përfaqëson një pamje inovative se si të ndërtohen aplikacione më efikase, duke e bërë Java më të përshtatshme për arkitekturat e reja të aplikacioneve si pa server. Për më tepër, për shkak të shtrirjes së tij, Quarkus shpresojmë se do të ketë një ekosistem të tërë të shtesave Java, duke rritur ndjeshëm numrin e kornizave që do të mbështesin përpilimin vendas në aplikacione jashtë kutisë.
Burimi: www.habr.com