Moien alleguer! Dëst ass den zweete Post an eiser Serie iwwer Quarkus - haut schwätze mir iwwer gebierteg Kompiléierung.
ass e Java Stack ugepasst fir . Och wann et sécherlech vill méi hei ze maachen ass, hu mir vill gutt Aarbecht op villen Aspekter gemaach, dorënner d'Optimiséierung vum JVM an eng Rei vu Kaderen. Ee vun de Feature vu Quarkus, déi erhéicht Interessi vun den Entwéckler ugezunn huet, ass seng ëmfaassend, nahtlos Approche fir Java Code an ausführbar Dateie fir e spezifesche Betribssystem ze maachen (sougenannte "native Compilation"), ähnlech wéi C an C++, wou esou Kompilatioun geschitt normalerweis um Enn vun engem Zyklus vum Bau, Test an Deployment.
A wärend native Compilatioun wichteg ass, wéi mir hei ënnen weisen, sollt et bemierkt ginn datt Quarkus wierklech gutt op der üblecher Java Maschinn leeft, OpenJDK Hotspot, dank de Performanceverbesserungen déi mir am ganze Stack implementéiert hunn. Dofir, gebierteg Zesummesetzung soll als zousätzlech Bonus considéréiert ginn, datt wéi gewënschte oder néideg benotzt ginn. Tatsächlech hänkt Quarkus staark op OpenJDK wann et ëm gebierteg Biller kënnt. An den Dev Modus, häerzlech vun den Entwéckler akzeptéiert, garantéiert bal direkt Testen vun Ännerungen wéinst de fortgeschratt Fäegkeeten vun dynamescher Code Ausféierung implementéiert am Hotspot. Zousätzlech, wann Dir gebierteg GraalVM Biller erstellt, ginn d'OpenJDK Klassebibliothéik an HotSpot Fäegkeeten benotzt.
Also firwat braucht Dir gebierteg Kompilatioun wann alles scho perfekt optimiséiert ass? Mir probéieren dës Fro hei ënnen ze beäntweren.
Loosst eis mat dem offensichtlechen ufänken: Red Hat huet extensiv Erfahrung mat der Optimisatioun vun JVMs, Stacks a Frameworks wärend der Entwécklung vum Projet , dorënner:
- Den éischten Applikatiounsserver fir an der Wollek op der Plattform ze schaffen .
- Den éischten Applikatiounsserver fir op Computeren ze lafen .
- Den éischten Applikatiounsserver fir op ze lafen .
- Eng Rei vu Projete lafen op Apparater .
Mir hunn eis mat den Erausfuerderunge beschäftegt fir Java Uwendungen an der Wollek an op Ressource-beschränkten Apparater (liesen: IoT) fir vill Joren ze beschäftegen an hu geléiert dat Bescht aus dem JVM a punkto Leeschtung an Erënnerungsoptimiséierung ze kréien. Wéi vill anerer, hu mir laang mat der gebierteg Compilatioun vun Java Uwendungen geschafft , , an esouguer a mir si gutt bewosst iwwer d'Virdeeler an Nodeeler vun dëser Approche (zum Beispill d'Dilemma vun der Wiel tëscht der Universalitéit vun "eemol bauen - iwwerall lafen" an der Tatsaach datt kompiléiert Uwendungen méi kleng sinn a méi séier lafen).
Firwat ass et wichteg dës Virdeeler an Nodeeler ze berücksichtegen? Well an e puer Situatiounen ass hire Verhältnis entscheedend:
- Zum Beispill, an serverless / Event-Undriff Ëmfeld wou an (haard oder mëll) Echtzäit fir Zäit ze hunn op Eventer ze reagéieren. Am Géigesaz zu laangjärege bestänneg Servicer, erhéicht d'Dauer vun engem Kale Start kritesch d'Äntwertzäit op eng Ufro. De JVM hëlt nach ëmmer e wesentleche Betrag un Zäit fir opzemaachen, a wärend dëst an e puer Fäll duerch reng Hardwaremethoden reduzéiert ka ginn, kann den Ënnerscheed tëscht enger Sekonn a 5 Millisekonnen den Ënnerscheed tëscht Liewen an Doud sinn. Jo, hei kënnt Dir mat der Schafung vun enger waarmer Reserve vu Java Maschinnen spillen (wat mir zum Beispill gemaach hunn ), awer dëst u sech garantéiert net datt et genuch JVMs gëtt fir Ufroen ze veraarbechten wéi d'Laaschtskala. An aus wirtschaftlecher Siicht ass dëst wahrscheinlech net déi richteg Optioun.
- Weider gëtt et en aneren Aspekt deen dacks opdaucht: Multitenancy. Trotz der Tatsaach, datt JVMs ganz no bei Betribssystemer an hire Fäegkeeten komm sinn, si se nach ëmmer net fäeg ze maachen wat mir sou gewinnt sinn am Linux - Prozesser isoléieren. Dofir kann de Feeler vun engem Fuedem déi ganz Java Maschinn erofbréngen. Vill Leit probéieren dësen Nodeel ëmzegoen andeems se e separaten JVM fir d'Applikatioun vun all Benotzer widmen fir d'Konsequenze vun engem Feeler ze minimiséieren. Dëst ass ganz logesch, awer passt net gutt mat Skalen.
- Zousätzlech, fir Cloud-orientéiert Uwendungen, ass e wichtege Indikator d'Dicht vu Servicer um Host. Iwwergank zu Methodik , Mikroservicer a Kubernetes erhéicht d'Zuel vun Java Maschinnen pro Applikatioun. Dat ass, engersäits, all dat gëtt Elastizitéit an Zouverlässegkeet, mä an der selwechter Zäit de Konsum vun Basis Erënnerung am Sënn vun Service och erop, an e puer vun dësen Ausgaben sinn net ëmmer strikt néideg. Statesch kompiléiert ausführbar Dateie profitéieren hei wéinst verschiddenen Optimisatiounstechniken, sou wéi d'Eliminatioun vu Low-Level Dead-Code, wann dat lescht Bild nëmmen déi Deeler vun de Kaderen enthält (inklusiv der JDK selwer) déi de Service tatsächlech benotzt. Dofir hëlleft Quarkus gebierteg Kompiléierung fir Serviceinstanzen dicht op den Host ze placéieren ouni d'Sécherheet ze kompromittéieren.
Eigentlech sinn déi uewe genannte Argumenter scho genuch fir d'Begrënnung vun der gebierteg Zesummesetzung aus der Siicht vun de Quarkus Projet Participanten ze verstoen. Wéi och ëmmer, et gëtt en aneren, net-techneschen, awer och wichtege Grond: an de leschte Joeren hunn vill Programméierer an Entwécklungsfirmen Java zugonschte vun neie Programméierungssproochen opginn, a gleewen datt Java, zesumme mat sengen JVMs, Stacks a Kaderen, ze ginn ass. Erënnerung-hongereg, ze lues, etc.
Wéi och ëmmer, d'Gewunnecht datselwecht Tool ze benotzen fir all Problem ze léisen ass . Heiansdo ass et besser e Schrëtt zeréck ze huelen an eppes anescht ze sichen. A wann Quarkus d'Leit mécht Paus an nodenken, dann ass dat gutt fir de ganze Java-Ökosystem. Quarkus stellt eng innovativ Vue duer fir méi effizient Uwendungen ze bauen, wat Java méi relevant mécht fir nei Applikatiounsarchitekturen wéi Serverlos. Zousätzlech, wéinst senger Erweiterbarkeet, wäert Quarkus hoffentlech e ganzen Ökosystem vu Java Extensiounen hunn, wat d'Zuel vu Frameworks wesentlech erhéijen déi gebierteg Kompilatioun an Uwendungen aus der Këscht ënnerstëtzen.
Source: will.com