Hej alla! HĂ€r Ă€r det andra inlĂ€gget i vĂ„r serie om Quarkus â idag pratar vi om native kompilering.
â Ă€r ett Java-stack som Ă€r inriktat pĂ„ . Och Ă€ven om det fortfarande finns mycket kvar att göra hĂ€r, har vi noggrant arbetat med mĂ„nga aspekter, inklusive JVM-optimering och en rad ramverk. En av Quarkus sĂ€rskilda egenskaper, som har vĂ€ckt stort intresse hos utvecklare, Ă€r den sömlösa och omfattande ansatsen att omvandla Java-kod till körbara filer för specifika operativsystem (den sĂ„ kallade "native kompileringen") pĂ„ liknande sĂ€tt som C och C++, dĂ€r sĂ„dan kompilering vanligtvis sker i slutet av en cykel som omfattar byggande, testning och distribution.
Och Àven om native kompilering, som vi kommer att visa nedan, Àr viktigt, mÄste det pÄpekas att Quarkus faktiskt fungerar mycket bra Àven pÄ en vanlig Java-maskin OpenJDK Hotspot tack vare de prestandaförbÀttringar vi har fÄtt till stÄnd i hela stacken. DÀrför bör native kompilering betraktas som en extra bonus som kan anvÀndas vid behov. NÀr det kommer till native bilder förlitar sig Quarkus i stor utstrÀckning pÄ OpenJDK. Den vÀl mottagna utvecklingslÀget (dev mode) möjliggör nÀstan omedelbar testning av förÀndringar tack vare de avancerade funktionerna för dynamisk kodkörning som implementeras i Hotspot. Dessutom anvÀnds OpenJDK:s klassbibliotek och HotSpot-funktioner vid skapandet av native bilder med GraalVM.
SÄ varför behövs dÄ native kompilering om allt redan Àr sÄ bra optimerat? Den frÄgan ska vi försöka besvara nedan.
Vi börjar med det uppenbara: Red Hat har stor erfarenhet av att optimera JVM, stackar och ramverk under projektets utveckling , inklusive:
- Den första applikationsservern för att arbeta i molnet pÄ plattformen .
- Den första applikationsservern för att arbeta pÄ datorer .
- Den första applikationsservern för att arbeta pÄ .
- Ett antal projekt som arbetar pÄ enheter .
Vi har under mĂ„nga Ă„r arbetat med att köra Java-applikationer i molnet och pĂ„ enheter med begrĂ€nsade resurser (lĂ€s, IoT) och har lĂ€rt oss att fĂ„ ut det mesta av JVM i frĂ„ga om prestanda och minnesoptimering. Precis som mĂ„nga andra har vi lĂ€nge arbetat med native kompilering av Java-applikationer genom , , och Ă€ven och vi Ă€r fullt medvetna om fördelarna och nackdelarna med denna metod (till exempel dilemmat mellan mĂ„ngsidigheten i "build once â run-anywhere" och det faktum att kompilering av applikationer ger mindre storlek och snabbare uppstart).
Varför Àr det sÄ viktigt att ta hÀnsyn till dessa fördelar och nackdelar? För att i vissa situationer kan deras förhÄllande bli avgörande:
- Till exempel i serverless-/eventdrivna miljöer dÀr i (hÄrd eller mjuk) realtid för att kunna reagera pÄ hÀndelser. Till skillnad frÄn lÄnglivade persistenta tjÀnster innebÀr hÀr lÀngden pÄ kallstarten en kritisk ökning av svarstiden pÄ begÀran. Att starta JVM tar fortfarande en betydande tid, och Àven om den i vissa fall kan förkortas med hjÀlp av rena hÄrdvarumetoder, kan skillnaden mellan en sekund och 5 millisekunder vara en frÄga om liv och död. Ja, hÀr kan man experimentera med att skapa en varm reserv av Java-maskiner (vilket vi till exempel gjorde vid ), men detta garanterar i sig inte tillrÀckligt med JVM för att hantera begÀrningar nÀr belastningen ökar. Och ur ett ekonomiskt perspektiv Àr det förmodligen inte den mest optimala lösningen.
- Dessutom finns det en annan aspekt som ofta dyker upp, nĂ€mligen multitenancy. Ăven om JVM har kommit nĂ€ra operativsystemens kapabiliteter, Ă€r de fortfarande inte kapabla att göra det som vi Ă€r sĂ„ vana vid i Linux - att isolera processer. DĂ€rför kan ett fel i en trĂ„d stĂ€nga ner hela Java-maskinen. MĂ„nga försöker kringgĂ„ denna brist genom att tilldela varje anvĂ€ndares applikation en separat JVM för att minimera konsekvenserna av ett fel. Detta Ă€r helt logiskt, men passar dĂ„ligt med skalning.
- Dessutom Ă€r en viktig faktor för molnbaserade applikationer densiteten av tjĂ€nster pĂ„ vĂ€rden. ĂvergĂ„ngen till metodologin , mikrotjĂ€nster och Kubernetes ökar antalet Java-maskiner för en applikation. Det innebĂ€r att Ă„ ena sidan ger allt detta flexibilitet och pĂ„litlighet, men samtidigt ökar ocksĂ„ den basminnesförbrukningen per tjĂ€nst, dĂ€r vissa av dessa kostnader lĂ„ngt ifrĂ„n alltid Ă€r absolut nödvĂ€ndiga. Statiskt kompilerade körfiler vinner hĂ€r genom olika optimeringstekniker, som lĂ„g-nivĂ„ dead-code elimination, dĂ€r endast de delar av ramverken (inklusive sjĂ€lva JDK) som tjĂ€nsten faktiskt anvĂ€nder inkluderas i den slutliga bilden. DĂ€rför hjĂ€lper den inbyggda kompileringen av Quarkus att mer effektivt placera tjĂ€nstinstanser pĂ„ vĂ€rden utan att det pĂ„verkar sĂ€kerheten.
De ovan nÀmnda argumenten Àr redan tillrÀckliga för att förstÄ rÀttfÀrdigheten av inbyggd kompilering ur perspektivet för deltagarna i Quarkus-projektet. Men det finns en annan, inte-teknisk, men ocksÄ viktig anledning: under de senaste Ären har mÄnga programmerare och utvecklingsföretag övergett Java till förmÄn för nya programmeringssprÄk, ansett att Java med sina JVM:er, stackar och ramverk har blivit för minneskrÀvande, för lÄngsam, osv.
Men vanan att anvĂ€nda samma verktyg för att lösa alla uppgifter â . Ibland Ă€r det bĂ€ttre att ta ett steg tillbaka och leta efter nĂ„got annat. Och om Quarkus fĂ„r mĂ€nniskor att pausa och tĂ€nka efter, sĂ„ Ă€r det bra för hela Java-ekosystemet. Quarkus representerar en innovativ syn pĂ„ hur man skapar effektivare applikationer och gör Java mer relevant för nya applikationsarkitekturer, som serverlös. Dessutom, tack vare sin utbyggbarhet, hoppas vi att Quarkus kommer att fĂ„ ett helt ekosystem av Java-tillĂ€gg, vilket avsevĂ€rt ökar antalet ramverk som kommer att stödja inbyggd kompilering som en del av applikationerna.
KĂ€lla: habr.com
