Sziasztok! Ez a második bejegyzés a Quarkusról szóló sorozatunkban – ma a natív összeállításról fogunk beszélni.
egy Java verem erre szabva . És bár természetesen sok a tennivaló itt, sok szempontból jól dolgoztunk, beleértve a JVM és számos keretrendszer optimalizálását. A Quarkus egyik jellemzője, amely fokozott érdeklődést váltott ki a fejlesztők részéről, az átfogó, zökkenőmentes megközelítése a Java kód futtatható fájlokká alakítására egy adott operációs rendszer számára (úgynevezett „natív fordítás”), hasonlóan a C-hez és C++-hoz, ahol ilyen fordítást végeznek. általában a felépítési, tesztelési és telepítési ciklus végén történik.
És bár a natív fordítás fontos, ahogy az alábbiakban bemutatjuk, meg kell jegyezni, hogy a Quarkus nagyon jól fut a legelterjedtebb Java gépen, az OpenJDK Hotspoton, köszönhetően a veremben végrehajtott teljesítményjavításoknak. Ezért a natív fordítást további bónusznak kell tekinteni, amelyet tetszés szerint vagy szükség szerint lehet használni. Valójában a Quarkus nagymértékben támaszkodik az OpenJDK-ra, amikor natív képekről van szó. A fejlesztők által melegen elfogadott fejlesztői mód pedig szinte azonnali változások tesztelését biztosítja a Hotspotban megvalósított dinamikus kódvégrehajtás fejlett képességeinek köszönhetően. Ezenkívül a natív GraalVM-képek létrehozásakor az OpenJDK osztálykönyvtárat és a HotSpot-képességeket használják.
Akkor miért van szükség natív fordításra, ha már minden tökéletesen optimalizált? Az alábbiakban erre a kérdésre próbálunk választ adni.
Kezdjük a nyilvánvalóval: a Red Hat nagy tapasztalattal rendelkezik a JVM-ek, veremek és keretrendszerek optimalizálása terén a projektfejlesztés során , beleértve:
- Az első alkalmazásszerver, amely felhőben működik a platformon .
- Az első számítógépeken futó alkalmazáskiszolgáló .
- Az első alkalmazáskiszolgáló, amelyen fut .
- Az eszközökön futó projektek sora .
Évek óta küzdünk a Java alkalmazások felhőben és erőforrás-korlátozott eszközökön (értsd: IoT) való futtatásának kihívásaival, és megtanultuk, hogy a legtöbbet hozzuk ki a JVM-ből a teljesítmény és a memória optimalizálás terén. Sok máshoz hasonlóan mi is hosszú ideje dolgozunk a Java alkalmazások natív fordításával , , és még és jól ismerjük ennek a megközelítésnek az előnyeit és hátrányait (például a választás dilemmáját az „egyszer építeni – futni-bárhol” univerzalitása és az a tény, hogy a lefordított alkalmazások kisebbek és gyorsabban futnak) között.
Miért fontos ezeket az előnyöket és hátrányokat mérlegelni? Mert bizonyos helyzetekben ezek aránya döntő:
- Például kiszolgáló nélküli/eseményvezérelt környezetekben, ahol (kemény vagy lágy) valós időben, hogy legyen ideje reagálni az eseményekre. A hosszú élettartamú, tartós szolgáltatásokkal ellentétben itt a hidegindítás időtartama kritikusan megnöveli a kérésre adott válaszidőt. A JVM még mindig jelentős időt vesz igénybe, hogy elinduljon, és bár ez bizonyos esetekben tisztán hardveres módszerekkel csökkenthető, az egy másodperc és az 5 ezredmásodperc közötti különbség lehet az élet és a halál közötti különbség. Igen, itt eljátszhatod a Java gépek forró tartalékának létrehozását (amit például mi megtettünk ), de ez önmagában nem garantálja, hogy elegendő JVM lesz a kérések feldolgozásához terhelési mérlegként. És gazdasági szempontból valószínűleg nem ez a leghelyesebb megoldás.
- Ezután van egy másik szempont, amely gyakran felbukkan: többbérlet. Annak ellenére, hogy a JVM-ek képességeikben nagyon közel kerültek az operációs rendszerekhez, még mindig nem képesek arra, amit a Linuxban megszoktunk – a folyamatok elkülönítésére. Ezért egy szál meghibásodása az egész Java gépet lerombolhatja. Sokan úgy próbálják megkerülni ezt a hátrányt, hogy minden egyes felhasználói alkalmazáshoz külön JVM-et rendelnek, hogy minimalizálják a meghibásodás következményeit. Ez teljesen logikus, de nem illik jól a méretezéshez.
- Ezenkívül a felhő-orientált alkalmazásoknál fontos mutató a szolgáltatások sűrűsége a gazdagépen. Áttérés a módszertanra , mikroszolgáltatások és a Kubernetes növeli az alkalmazásonkénti Java gépek számát. Azaz egyrészt mindez rugalmasságot és megbízhatóságot biztosít, ugyanakkor az alapmemória fogyasztása a szolgáltatás szempontjából is megnő, és ezen kiadások egy része nem mindig feltétlenül szükséges. A statikusan lefordított futtatható fájlok itt előnyösek a különféle optimalizálási technikák miatt, mint például az alacsony szintű holtkód kiküszöbölése, amikor a végső kép a keretrendszernek csak azokat a részeit tartalmazza (beleértve magát a JDK-t is), amelyeket a szolgáltatás ténylegesen használ. Ezért a Quarkus natív fordítása segít a szolgáltatáspéldányok sűrű elhelyezésében a gazdagépen a biztonság veszélyeztetése nélkül.
Valójában a fenti érvek már elegendőek ahhoz, hogy megértsük a natív fordítás indokoltságát a Quarkus projekt résztvevőinek szemszögéből. Van azonban egy másik, nem technikai, de szintén fontos ok: az elmúlt években sok programozó és fejlesztő cég elhagyta a Java-t és új programozási nyelveket választott ki, mert úgy gondolja, hogy a Java a JVM-ekkel, veremekkel és keretrendszerekkel együtt túlságosan is túlnyomórészt memóriaéhes, túl lassú stb.
Azonban az a szokás, hogy ugyanazt az eszközt használjuk bármilyen probléma megoldására . Néha jobb egy lépést hátralépni, és valami más után nézni. És ha a Quarkus megállásra készteti az embereket és elgondolkodtat, az jót tesz az egész Java ökoszisztémának. A Quarkus egy innovatív nézetet képvisel arra vonatkozóan, hogyan lehet hatékonyabb alkalmazásokat készíteni, így a Java relevánsabbá válik az olyan új alkalmazásarchitektúrák számára, mint a szerver nélküli. Ráadásul a Quarkus a bővíthetősége miatt remélhetőleg a Java-bővítmények teljes ökoszisztémájával fog rendelkezni, jelentősen megnövelve azoknak a keretrendszereknek a számát, amelyek már a dobozból is támogatják a natív fordítást az alkalmazásokban.
Forrás: will.com