Üdvözlök mindenkit! Itt a második bejegyzésünk a Quarkusról – ma a natív fordításról beszélünk.
– ez egy Java-alapú teknős, amely a . És bár sok minden még hátravan, alaposan kidolgoztunk számos szempontot, beleértve a JVM optimalizálását és számos keretrendszert. A Quarkus egyik jellemzője, amely különös érdeklődést keltett a fejlesztők körében, a zökkenőmentes megközelítés a Java-kód végrehajtható fájlokká való átalakítására a konkrét operációs rendszerhez (úgynevezett „natív fordítás”), hasonlóan a C és C++ nyelvekhez, ahol az ilyen fordítás általában a gyártás, tesztelés és telepítés ciklusának végén történik.
És bár a natív fordítás, amint azt alább bemutatjuk, fontos, fontos megjegyezni, hogy a Quarkus valójában nagyon jól működik a standard OpenJDK Hotspot Java gépen is, a teljes veremben megvalósított teljesítményjavításoknak köszönhetően. Ezért a natív fordítást érdemes plusz bónuszként kezelni, amely igény szerint vagy szükség esetén felhasználható. Valójában a natív képek tekintetében a Quarkus nagymértékben támaszkodik az OpenJDK-ra. Az általunk jól fogadott fejlesztői üzemmód pedig szinte azonnali változások tesztelését biztosít a Hotspot implementált fejlett dinamikus kódvégrehajtási lehetőségeinek köszönhetően. Ezen kívül a natív képek létrehozásakor a GraalVM az OpenJDK osztálykönyvtárát és a HotSpot képességeit használja.
Tehát miért van szükség natív fordításra, ha minden amúgy remekül optimalizált? Erre a kérdésre próbáljuk meg válaszolni alább.
Kezdjük a nyilvánvalóval: A Red Hat jelentős tapasztalattal rendelkezik a JVM, verem és keretrendszerek optimalizálásában a projekt fejlesztése során. , beleértve:
- Az első felhőalapú alkalmazás-szerver a .
- Az első alkalmazás-szerver asztali számítógépeken .
- Az első alkalmazás-szerver a .
- Számos projekt, amelyek korlátozott erőforrású eszközökön futnak .
Már évek óta foglalkozunk a Java-alkalmazások felhőben és korlátozott erőforrású eszközökön (értsd: IoT) történő futtatásával, és megtanultuk kihozni a legtöbbet a JVM-ből teljesítmény és memóriaoptimalizálás szempontjából. Mint sok más, hosszú ideje dolgozunk a Java-alkalmazások natív fordításán keresztül. , , Kapcsolja össze saját domainjét Tökéletesen tudatában vagyunk ennek a megközelítésnek az előnyeinek és hátrányainak (például a „build once – run-anywhere” univerzalitás és a kisebb méretű, gyorsabban induló kompájnált alkalmazások közötti dilemmának).
Miért fontos figyelembe venni ezeket az előnyöket és hátrányokat? Mert bizonyos helyzetekben a köztük lévő arány döntő jelentőségű lehet:
- Például serverless/irányított események környezetében, ahol valós időben (szigorú vagy lágy) ahhoz, hogy képesek legyenek reagálni az eseményekre. Ellentétben a hosszú élettartamú állandó szolgáltatásokkal, itt a hideg indítás hosszú ideje kritikus módon növeli a válaszadási időt. A JVM indítása még mindig jelentős időt igényel, és bár bizonyos esetekben ezt hardveres módszerekkel lehet rövidíteni, a különbség a másodperc és az 5 milliszekundum között élet és halál kérdése lehet. Igen, lehet játszani a Java gépek meleg tartalékának létrehozásával (ahogyan ezt például mi is tettük a ), de önmagában ez nem garantálja a kérdések kezelésére elegendő JVM számot a terhelés skálázásakor. Gazdasági szempontból valószínűleg nem a legjobb megoldás.
- Ezen kívül van még egy gyakran felmerülő aspektus, mint a multitenanciáság. Annak ellenére, hogy a JVM képességei jelentősen megközelítették az operációs rendszereket, továbbra sem képesek olyan izolálásra, mint amit a Linuxnál megszoktunk – izolálni a folyamatokat. Ezért egy szál meghibásodása az egész Java gépet tönkreteheti. Sokan megpróbálják ezt a hátrányt úgy megkerülni, hogy minden felhasználónak külön JVM-t rendelnek az alkalmazásokhoz, minimalizálva a meghibásodás következményeit. Ez logikus, de nem jól illeszkedik a skálázáshoz.
- Továbbá, a felhőorientált alkalmazásoknál fontos egy mutató, mint a szolgáltatások sűrűsége a gazdán. Az áttérés a , a mikroszolgáltatások és a Kubernetes növeli a Java gépek számát egy alkalmazás esetében. Vagyis egyrészt mindez rugalmasságot és megbízhatóságot nyújt, de ugyanakkor nő az alap memóriafogyasztás a szolgáltatásra vetítve, ráadásul ezeknek a költségeknek egy része nem mindig szigorúan szükséges. A statikusan lefordított végrehajtható fájlok különböző optimalizációs technikák révén, mint például az alacsony szintű dead-code eltávolítás, itt előnyre tesznek szert, amikor a végső képre csak azok a keretrendszerek (beleértve magát a JDK-t) kerülnek be, amelyeket a szolgáltatás valójában használ. Ezért a Quarkus natív fordítása segít a szolgáltatás példányait sűrűbben elhelyezni a gazdagépen anélkül, hogy a biztonságot veszélyeztetné.
Az eddig felsorolt érvek már elegendőek ahhoz, hogy megértsük a natív fordítás indokoltságát a Quarkus projekt résztvevői szempontjából. Azonban van egy másik, nem technikai, de szintén fontos ok: az utóbbi években sok programozó és fejlesztőcég elhagyta a Java-t új programozási nyelvek javára, mivel úgy vélték, hogy a Java a JVM-jével, a stackjeivel és keretrendszereivel túlságosan memóriát igényel, túl lassú, és így tovább.
A megszokás, hogy ugyanazt az eszközt használjuk minden feladat megoldására – . Néha jobb egy lépést hátralépni és valami mást keresni. És ha a Quarkus arra ösztönzi az embereket, hogy tartsanak szünetet és elgondolkodjanak, az jót tesz a Java ökoszisztémának. A Quarkus a hatékonyabb alkalmazások létrehozásának innovatív megközelítését képviseli, relevánsabbá téve a Java-t az új alkalmazásarchitektúrák, mint például a serverless számára. Továbbá, a bővíthetősége révén a Quarkus reményeink szerint egy teljes Java bővítmény-ökoszisztémát fog kifejleszteni, jelentősen növelve a natív fordítást natív módon támogató keretrendszerek számát.
Forrás: habr.com
