Dag Allemaal! Dit is het tweede bericht in onze serie over Quarkus - vandaag zullen we het hebben over native compilatie.
is een Java-stack op maat gemaakt voor . Hoewel er hier zeker nog veel meer te doen is, hebben we veel goed werk verricht op veel aspecten, waaronder het optimaliseren van de JVM en een aantal raamwerken. Een van de kenmerken van Quarkus die steeds meer belangstelling van ontwikkelaars heeft getrokken, is de alomvattende, naadloze aanpak om Java-code om te zetten in uitvoerbare bestanden voor een specifiek besturingssysteem (zogenaamde “native compilatie”), vergelijkbaar met C en C++, waarbij een dergelijke compilatie vindt meestal plaats aan het einde van een cyclus van bouwen, testen en implementeren.
En hoewel native compilatie belangrijk is, zoals we hieronder zullen laten zien, moet worden opgemerkt dat Quarkus heel goed draait op de meest voorkomende Java-machine, OpenJDK Hotspot, dankzij de prestatieverbeteringen die we in de hele stack hebben geïmplementeerd. Daarom moet native compilatie worden beschouwd als een extra bonus die naar wens of noodzakelijk kan worden gebruikt. Quarkus vertrouwt zelfs sterk op OpenJDK als het gaat om native afbeeldingen. En de dev-modus, die warm wordt geaccepteerd door ontwikkelaars, zorgt ervoor dat wijzigingen vrijwel onmiddellijk kunnen worden getest dankzij de geavanceerde mogelijkheden voor dynamische code-uitvoering die in Hotspot zijn geïmplementeerd. Bij het maken van native GraalVM-images worden bovendien de OpenJDK-klassenbibliotheek en HotSpot-mogelijkheden gebruikt.
Dus waarom heb je native compilatie nodig als alles al perfect geoptimaliseerd is? Deze vraag zullen wij hieronder proberen te beantwoorden.
Laten we beginnen met het voor de hand liggende: Red Hat heeft uitgebreide ervaring met het optimaliseren van JVM's, stacks en frameworks tijdens projectontwikkeling , inbegrepen:
- De eerste applicatieserver die in de cloud op het platform werkt .
- De eerste applicatieserver voor gebruik op computers .
- De eerste applicatieserver waarop draait .
- Een reeks projecten die op apparaten draaien .
We hebben al vele jaren te maken met de uitdagingen van het uitvoeren van Java-applicaties in de cloud en op apparaten met beperkte middelen (lees: IoT) en hebben geleerd het maximale uit de JVM te halen op het gebied van prestaties en geheugenoptimalisatie. Net als vele anderen werken wij al geruime tijd met native compilatie van Java-applicaties , , en zelfs en we zijn ons terdege bewust van de voor- en nadelen van deze aanpak (bijvoorbeeld het dilemma van het kiezen tussen de universaliteit van “eenmalig bouwen – overal draaien” en het feit dat gecompileerde applicaties kleiner zijn en sneller werken).
Waarom is het belangrijk om deze voor- en nadelen tegen elkaar af te wegen? Omdat in sommige situaties hun verhouding doorslaggevend wordt:
- Bijvoorbeeld in serverloze/gebeurtenisgestuurde omgevingen waar in (harde of zachte) realtime om tijd te hebben om op gebeurtenissen te reageren. In tegenstelling tot persistente services met een lange levensduur, verhoogt de duur van een koude start hier de responstijd op een verzoek op kritische wijze. Het opstarten van de JVM duurt nog steeds aanzienlijk, en hoewel dit in sommige gevallen kan worden verminderd door pure hardwaremethoden, kan het verschil tussen één seconde en vijf milliseconden het verschil zijn tussen leven en dood. Ja, hier kun je spelen met het maken van een hot reserve van Java-machines (wat we bijvoorbeeld hebben gedaan met ), maar dit op zichzelf garandeert niet dat er voldoende JVM's zullen zijn om verzoeken te verwerken naarmate de belasting toeneemt. En vanuit economisch oogpunt is dit waarschijnlijk niet de meest correcte optie.
- Verder is er nog een ander aspect dat vaak naar voren komt: multitenancy. Ondanks het feit dat JVM's qua mogelijkheden heel dicht bij besturingssystemen komen, zijn ze nog steeds niet in staat om te doen waar we zo aan gewend zijn in Linux: processen isoleren. Daarom kan het falen van één thread de hele Java-machine platleggen. Veel mensen proberen dit nadeel te omzeilen door een aparte JVM toe te wijzen aan de applicatie van elke gebruiker, om zo de gevolgen van een storing te minimaliseren. Dit is heel logisch, maar past niet goed bij schaalvergroting.
- Voor cloudgerichte applicaties is bovendien een belangrijke indicator de dichtheid van services op de host. Overgang naar methodologie , microservices en Kubernetes vergroten het aantal Java-machines per applicatie. Dat wil zeggen dat dit enerzijds elasticiteit en betrouwbaarheid biedt, maar tegelijkertijd neemt ook het verbruik van basisgeheugen in termen van service toe, en sommige van deze kosten zijn niet altijd strikt noodzakelijk. Statisch gecompileerde uitvoerbare bestanden profiteren hier van verschillende optimalisatietechnieken, zoals het elimineren van dode code op laag niveau, wanneer het uiteindelijke beeld alleen die delen van de raamwerken bevat (inclusief de JDK zelf) die de service daadwerkelijk gebruikt. Daarom helpt de native compilatie van Quarkus om service-instances dicht op de host te plaatsen zonder de veiligheid in gevaar te brengen.
Eigenlijk zijn de bovenstaande argumenten al voldoende om de rechtvaardiging van native compilatie te begrijpen vanuit het standpunt van de deelnemers aan het Quarkus-project. Er is echter nog een andere, niet-technische, maar ook belangrijke reden: de afgelopen jaren hebben veel programmeurs en ontwikkelingsbedrijven Java verlaten ten gunste van nieuwe programmeertalen, in de overtuiging dat Java, samen met zijn JVM's, stacks en frameworks, te veel is geworden. geheugenhongerig, te langzaam, enz.
De gewoonte om elk probleem op te lossen is echter hetzelfde hulpmiddel . Soms is het beter om een stapje terug te doen en iets anders te zoeken. En als Quarkus mensen aan het denken zet, dan is dat goed voor het hele Java-ecosysteem. Quarkus vertegenwoordigt een innovatieve kijk op het bouwen van efficiëntere applicaties, waardoor Java relevanter wordt voor nieuwe applicatie-architecturen zoals serverless. Bovendien zal Quarkus, vanwege de uitbreidbaarheid, hopelijk over een heel ecosysteem van Java-extensies beschikken, waardoor het aantal raamwerken dat native compilatie in kant-en-klare applicaties zal ondersteunen aanzienlijk zal toenemen.
Bron: www.habr.com