Hi almal! Dit is die tweede plasing in ons reeks oor Quarkus - vandag praat ons oor inheemse samestelling.
is 'n Java-stapel wat aangepas is vir . Alhoewel daar beslis baie meer hier is om te doen, het ons baie goeie werk gedoen oor baie aspekte, insluitend die optimalisering van die JVM en 'n aantal raamwerke. Een van die kenmerke van Quarkus wat toenemende belangstelling van ontwikkelaars gelok het, is sy omvattende, naatlose benadering om Java-kode te omskep in uitvoerbare lêers vir 'n spesifieke bedryfstelsel (sogenaamde "inheemse samestelling"), soortgelyk aan C en C++, waar sulke samestelling vind gewoonlik plaas aan die einde van 'n siklus van bou, toets en ontplooiing.
En hoewel inheemse samestelling belangrik is, soos ons hieronder sal wys, moet daarop gelet word dat Quarkus baie goed werk op die mees algemene Java-masjien, OpenJDK Hotspot, danksy die prestasieverbeterings wat ons regdeur die stapel geïmplementeer het. Daarom moet inheemse samestelling beskou word as 'n bykomende bonus wat gebruik kan word soos verlang of nodig is. Trouens, Quarkus maak sterk staat op OpenJDK wanneer dit kom by inheemse beelde. En die dev-modus, wat hartlik deur ontwikkelaars aanvaar word, verseker byna onmiddellike toetsing van veranderinge as gevolg van die gevorderde vermoëns van dinamiese kode-uitvoering wat in Hotspot geïmplementeer is. Daarbenewens, wanneer inheemse GraalVM-beelde geskep word, word die OpenJDK-klasbiblioteek en HotSpot-vermoëns gebruik.
So hoekom het jy inheemse samestelling nodig as alles reeds perfek geoptimaliseer is? Ons sal probeer om hierdie vraag hieronder te beantwoord.
Kom ons begin met die voor die hand liggende: Red Hat het uitgebreide ervaring met die optimalisering van JVM's, stapels en raamwerke tydens projekontwikkeling , insluitend:
- Die eerste toepassingsbediener wat in die wolk op die platform werk .
- Die eerste toepassingsbediener om op rekenaars te loop .
- Die eerste toepassingsbediener om op te loop .
- 'n Reeks projekte wat op toestelle loop .
Ons het al baie jare te doen met die uitdagings om Java-toepassings in die wolk en op hulpbronbeperkte toestelle (lees: IoT) te laat loop en het geleer om die meeste uit die JVM te haal in terme van werkverrigting en geheue-optimalisering. Soos baie ander, werk ons al lank met inheemse samestelling van Java-toepassings , , selfs en ons is deeglik bewus van die voor- en nadele van hierdie benadering (byvoorbeeld die dilemma om te kies tussen die universaliteit van “bou een keer – hardloop-enige plek” en die feit dat saamgestelde toepassings kleiner is en vinniger loop).
Hoekom is dit belangrik om hierdie voor- en nadele in ag te neem? Want in sommige situasies word hul verhouding deurslaggewend:
- Byvoorbeeld, in bedienerlose/gebeurtenisgedrewe omgewings waar in (harde of sagte) reële tyd om tyd te hê om op gebeure te reageer. In teenstelling met langdurige aanhoudende dienste, verhoog die duur van 'n koue begin hier die reaksietyd op 'n versoek krities. Die JVM neem steeds 'n aansienlike hoeveelheid tyd om te begin, en hoewel dit in sommige gevalle deur suiwer hardeware-metodes verminder kan word, kan die verskil tussen een sekonde en 5 millisekondes die verskil tussen lewe en dood wees. Ja, hier kan jy rondspeel met die skep van 'n warm reserwe van Java-masjiene (wat ons byvoorbeeld gedoen het ), maar dit op sigself waarborg nie dat daar genoeg JVM's sal wees om versoeke te verwerk soos die vragskale nie. En vanuit 'n ekonomiese oogpunt is dit waarskynlik nie die mees korrekte opsie nie.
- Verder is daar nog 'n aspek wat dikwels opduik: multitenancy. Ten spyte van die feit dat JVM's baie naby aan bedryfstelsels gekom het in hul vermoëns, is hulle steeds nie in staat om te doen waaraan ons so gewoond is in Linux nie - prosesse te isoleer. Daarom kan die mislukking van een draad die hele Java-masjien vernietig. Baie mense probeer om hierdie nadeel te omseil deur 'n aparte JVM vir elke gebruiker se toepassing toe te wy om die gevolge van 'n mislukking te minimaliseer. Dit is redelik logies, maar pas nie goed by skaal nie.
- Daarbenewens, vir wolk-georiënteerde toepassings, is 'n belangrike aanwyser die digtheid van dienste op die gasheer. Oorgang na metodologie , mikrodienste en Kubernetes verhoog die aantal Java-masjiene per toepassing. Dit wil sê, enersyds bied dit alles elastisiteit en betroubaarheid, maar terselfdertyd neem die verbruik van basisgeheue in terme van diens ook toe, en sommige van hierdie uitgawes is nie altyd streng nodig nie. Staties saamgestelde uitvoerbare lêers baat hier as gevolg van verskeie optimaliseringstegnieke, soos lae-vlak dooie-kode eliminasie, wanneer die finale prent slegs daardie dele van die raamwerke (insluitend die JDK self) insluit wat die diens werklik gebruik. Daarom help Quarkus-inheemse samestelling om diensgevalle dig op die gasheer te plaas sonder om sekuriteit in te boet.
Eintlik is bogenoemde argumente reeds genoeg om die regverdiging van inheemse samestelling vanuit die oogpunt van die Quarkus-projekdeelnemers te verstaan. Daar is egter 'n ander, nie-tegniese, maar ook belangrike rede: in onlangse jare het baie programmeerders en ontwikkelingsmaatskappye Java laat vaar ten gunste van nuwe programmeertale, en glo dat Java, saam met sy JVM's, stapels en raamwerke, ook geheuehonger, te stadig, ens.
Die gewoonte om dieselfde instrument te gebruik om enige probleem op te los, is egter . Soms is dit beter om 'n tree terug te gee en na iets anders te soek. En as Quarkus mense laat stilstaan en dink, dan is dit goed vir die hele Java-ekosisteem. Quarkus verteenwoordig 'n innoverende siening van hoe om meer doeltreffende toepassings te bou, wat Java meer relevant maak vir nuwe toepassingsargitekture soos bedienerloos. As gevolg van die uitbreidbaarheid daarvan, sal Quarkus hopelik 'n hele ekosisteem van Java-uitbreidings hê, wat die aantal raamwerke wat oorspronklike samestelling in toepassings uit die boks sal ondersteun aansienlik verhoog.
Bron: will.com