Бәріңе сәлем! Бұл Quarkus сериясындағы екінші жазба - бүгін біз жергілікті компиляция туралы сөйлесетін боламыз.
үшін бейімделген Java стегі болып табылады . Әрине, бұл жерде көп нәрсе істеу керек болса да, біз JVM және бірқатар фреймворктарды оңтайландыруды қоса алғанда, көптеген аспектілер бойынша көп жақсы жұмыс жасадық. Әзірлеушілердің қызығушылығын арттырған Quarkus ерекшеліктерінің бірі оның Java кодын белгілі бір операциялық жүйе үшін орындалатын файлдарға («жергілікті компиляция» деп аталатын) айналдырудың кешенді, біркелкі тәсілі болып табылады, мұнда мұндай компиляция жасалатын C және C++ сияқты. әдетте құрастыру, сынау және орналастыру циклінің соңында орын алады.
Жергілікті компиляция маңызды болғанымен, төменде көрсетеміз, Quarkus біз стекке енгізген өнімділікті жақсартудың арқасында ең көп таралған Java құрылғысы OpenJDK Hotspot-та өте жақсы жұмыс істейтінін атап өткен жөн. Сондықтан жергілікті компиляцияны қалауыңыз бойынша немесе қажет болғанда пайдалануға болатын қосымша бонус ретінде қарастырған жөн. Шындығында, Quarkus жергілікті кескіндерге қатысты OpenJDK-ге қатты сүйенеді. Әзірлеушілер жылы қабылдаған әзірлеу режимі Hotspot жүйесінде енгізілген динамикалық кодты орындаудың кеңейтілген мүмкіндіктерінің арқасында өзгерістерді дерлік лезде тексеруді қамтамасыз етеді. Сонымен қатар, жергілікті GraalVM кескіндерін жасау кезінде OpenJDK класс кітапханасы және HotSpot мүмкіндіктері пайдаланылады.
Егер бәрі қазірдің өзінде оңтайландырылған болса, неге сізге жергілікті компиляция қажет? Бұл сұраққа төменде жауап беруге тырысамыз.
Ашық нәрседен бастайық: Red Hat жобаны әзірлеу кезінде JVM, стектерді және фреймворктерді оңтайландыруда үлкен тәжірибесі бар. , оның ішінде:
- Платформадағы бұлтта жұмыс істейтін бірінші қолданба сервері .
- Компьютерлерде жұмыс істеуге арналған бірінші қолданбалы сервер .
- Бірінші іске қосылатын қолданба сервері .
- Құрылғыларда жұмыс істейтін жобалар ауқымы .
Біз көптеген жылдар бойы бұлтта және ресурстары шектеулі құрылғыларда (оқыңыз: IoT) Java қолданбаларын іске қосу қиындықтарымен айналысып келеміз және JVM өнімділігі мен жадты оңтайландыру тұрғысынан барынша тиімді пайдалануды үйрендік. Көптеген басқалар сияқты, біз Java қолданбаларының жергілікті компиляциясымен ұзақ уақыт бойы жұмыс істеп келеміз , , және тіпті және біз бұл тәсілдің оң және теріс жақтарын жақсы білеміз (мысалы, «бір рет құрастыру – кез келген жерде іске қосу» әмбебаптығы мен құрастырылған қосымшалардың кішірек және жылдамырақ жұмыс істеуі арасындағы таңдау дилеммасы).
Неліктен бұл артықшылықтар мен кемшіліктерді ескеру маңызды? Өйткені кейбір жағдайларда олардың арақатынасы шешуші болады:
- Мысалы, серверсіз/оқиғаға негізделген орталарда оқиғаларға жауап беруге уақыт табу үшін (қатты немесе жұмсақ) нақты уақытта. Ұзақ өмір сүретін тұрақты қызметтерден айырмашылығы, мұнда суық старттың ұзақтығы сұрауға жауап беру уақытын сыни арттырады. JVM іске қосу үшін әлі де көп уақыт қажет және оны кейбір жағдайларда таза аппараттық әдістермен азайтуға болатынымен, бір секунд пен 5 миллисекунд арасындағы айырмашылық өмір мен өлім арасындағы айырмашылық болуы мүмкін. Иә, мұнда сіз Java машиналарының ыстық резервін жасаумен ойнай аласыз (мысалы, біз онымен істедік. ), бірақ мұның өзі жүктеме масштабы ретінде сұрауларды өңдеу үшін жеткілікті JVM болатынына кепілдік бермейді. Ал экономикалық тұрғыдан алғанда бұл ең дұрыс нұсқа емес шығар.
- Сонымен қатар, жиі пайда болатын тағы бір аспект бар: көп жалдау. JVM-лер өздерінің мүмкіндіктері бойынша операциялық жүйелерге өте жақын болғанына қарамастан, олар әлі де Linux-те біз үйренген нәрсені - оқшаулау процестерін жасай алмайды. Сондықтан бір ағынның сәтсіздігі бүкіл Java машинасын бұзуы мүмкін. Көптеген адамдар сәтсіздіктің салдарын азайту үшін әрбір пайдаланушы қолданбасы үшін жеке JVM арнау арқылы осы кемшілікті жеңуге тырысады. Бұл өте қисынды, бірақ масштабтауға жақсы сәйкес келмейді.
- Сонымен қатар, бұлтқа бағытталған қолданбалар үшін хосттағы қызметтердің тығыздығы маңызды көрсеткіш болып табылады. Әдістемеге көшу , микросервистері және Kubernetes бір қолданбаға Java машиналарының санын көбейтеді. Яғни, бір жағынан, мұның бәрі икемділік пен сенімділікті қамтамасыз етеді, бірақ сонымен бірге қызмет көрсету тұрғысынан базалық жадты тұтыну да артады және бұл шығындардың кейбірі әрқашан қатаң қажет емес. Статикалық түрде құрастырылған орындалатын файлдар мұнда түпкілікті кескін қызмет шын мәнінде қолданатын фреймворктердің (соның ішінде JDK өзі) бөліктерін ғана қамтитын төмен деңгейлі өлі кодты жою сияқты әртүрлі оңтайландыру әдістерінің арқасында пайда көреді. Сондықтан, Quarkus түпнұсқа компиляциясы қауіпсіздікті бұзбай хостқа қызмет даналарын тығыз орналастыруға көмектеседі.
Шын мәнінде, жоғарыда келтірілген дәлелдер Quarkus жобасына қатысушылардың көзқарасы бойынша жергілікті компиляцияның негіздемесін түсіну үшін жеткілікті. Дегенмен, тағы бір, техникалық емес, сонымен қатар маңызды себеп бар: соңғы жылдары көптеген бағдарламашылар мен әзірлеушілер Java-дан бас тартып, жаңа бағдарламалау тілдерінің пайдасына Java-ны JVM-мен, стектермен және фреймворктармен бірге тым айналды деп санайды. есте сақтау қабілеті нашар, тым баяу және т.б.
Дегенмен, кез келген мәселені шешу үшін бір құралды пайдалану әдеті . Кейде артқа шегініп, басқа нәрсені іздеген дұрыс. Ал егер Quarkus адамдарды кідіртуге және ойлануға мәжбүр етсе, бұл бүкіл Java экожүйесі үшін жақсы. Quarkus Java-ны серверсіз сияқты жаңа қолданба архитектураларына көбірек сәйкестендіріп, тиімдірек қосымшаларды құрудың инновациялық көрінісін білдіреді. Сонымен қатар, оның кеңеюіне байланысты, Quarkus Java кеңейтімдерінің бүкіл экожүйесіне ие болады деп үміттенеміз, бұл қораптан тыс қолданбаларда жергілікті компиляцияны қолдайтын фреймворктардың санын айтарлықтай арттырады.
Ақпарат көзі: www.habr.com