Нативна компилация в Quarkus – защо това е важно

Здравейте! Това е вторият пост от нашата серия за Quarkus – днес ще говорим за родната компилация.

Quarkus – това е Java стек, оптимизиран за Kubernetes. И макар че тук все още има много работа, която трябва да се свърши, ние добре проучихме много аспекти, включително оптимизацията на JVM и различни фреймворкове. Една от характеристиките на Quarkus, която предизвика повишен интерес сред разработчиците, е комплексният безшевен подход за преобразуване на Java код в изпълними файлове за конкретни операционни системи (така наречената „родна компилация“) подобно на C и C++, където такава компилация обикновено се извършва в края на цикъла, състоящ се от сборка, тестване и внедряване.

И макар че родната компилация, както ще покажем по-долу, е важна, трябва да отбележим, че Quarkus всъщност работи много добре и на обикновена Java машина OpenJDK Hotspot благодарение на подобренията в производителността, които реализирахме в целия стек. Следователно, родната компилация следва да се разглежда като допълнителен бонус, който можете да използвате по желание или при необходимост. Всъщност, що се отнася до родните изображения, Quarkus силно разчита на OpenJDK. Освен това, широко приетият режим dev mode осигурява почти мигновено тестване на промените благодарение на развитите възможности за динамично изпълнение на кода, реализирани в Hotspot. Освен това, при създаването на родни изображения, GraalVM използва библиотеката с класове на OpenJDK и възможностите на HotSpot.

Така че защо е нужна родната компилация, ако всичко е толкова добре оптимизирано? На този въпрос ще се опитаме да отговорим по-долу.

Да започнем с очевидното: Red Hat разполага с голям опит в оптимизирането на JVM, стекове и фреймворкове през развитието на проекта JBoss, включително:

• Първият сървър за приложения за работа в облака на платформата Red Hat OpenShift.
• Първият сървър за приложения за работа на компютри Plug PC.
• Първият сървър за приложения за работа на Raspberry Pi.
• Цял ред проекти, работещи на устройства Android.

Ние се занимаваме с разработването на Java приложения в облака и на устройства с ограничени ресурси (чети, IoT) от много години и научихме как да извлечем максимума от JVM в отношение производителност и оптимизация на паметта. Както и много други, ние работим с родната компилация на Java приложения отдавна чрез GCJ, Avian, Excelsior JET и дори Dalvik и отлично осъзнаваме плюсовете и минусите на този подход (например, дилемата за избор между универсалността „създаване веднъж – стартиране навсякъде“ и факта, че скомпилираните приложения имат по-малък размер и се стартират по-бързо).

Защо е толкова важно да се вземат предвид тези плюсове и минуси? Защото в някои ситуации съотношението им става решаващо:

• Например, в serverless/управлявани от събития среди, където услугите просто трябва да се стартират в режим (строг или нестрог) реално време, за да могат да реагират на събитията. В отличие от дългоживеещите персистентни услуги, тук продължителността на студеното стартиране критично увеличава времето за отговор на заявките. Все още е необходима значителна време за стартиране на JVM, и макар в някои случаи да може да се съкрати чисто чрез хардуерни методи, разликата между една секунда и 5 милисекунди може да бъде въпрос на живот и смърт. Да, тук може да се експериментира с изграждането на горещ резерв на Java машини (както направихме, например, при портироването на OpenWhisk на Knative), но само по себе си това не гарантира достатъчно количество JVM за обработка на заявките при увеличаване на натоварването. И от икономическа гледна точка, това със сигурност не е най-разумният вариант.
• Освен това, съществува и такъв често срещан аспект, като мултитенантност. Въпреки че JVM значително се доближават до операционните системи по своите възможности, те все пак не са способни да правят това, на което сме свикнали в Linux – да изолират процесите. Следователно, провалът на един поток може да изведе от строя цялата Java машина. Много опитват да заобиколят този недостатък, като отделят за приложенията на всеки потребител отделна JVM, за да минимизират последствията от провала. Това е напълно логично, но не съвпада добре с мащабирането.
• Освен това, за облачно-ориентираните приложения е важен показателят за плътност на услугите на хоста. Преминаването към методология 12 фактора на приложението, микросервизите и Kubernetes увеличават броя на Java инстанции за едно приложение. Тоест, от една страна, всичко това предоставя гъвкавост и надеждност, но същевременно нараства и потреблението на основна памет на сервис, като част от тези разходи не винаги е строго необходима. Статично компилираните изпълними файлове печелят тук благодарение на различни техники за оптимизация, като нискоуровнево премахване на ненужния код, когато в крайния образ се включват само онези части от фреймворците (включително и самото JDK), които сервизът реално използва. Затова, нативната компилация на Quarkus помага за по-плътно разположение на инстанции на сервиза на хост без компромис с безопасността.

Всъщност, представените по-горе доводи вече са достатъчни, за да разбере оправдаността на нативната компилация от гледна точка на участниците в проекта Quarkus. Но има още една, не техническа, но все пак важна причина: през последните години много програмисти и компании-разработчици се оттеглиха от Java в полза на нови програмни езици, считайки, че Java заедно със своите JVM, стекове и фреймворци стана твърде ненаситна по отношение на памет, прекалено бавна и т.н.

Но навикът да се използва един и същи инструмент за решаване на всякакви задачи – не винаги е правилен. Понякога е по-добре да се направи крачка назад и да се потърси нещо друго. И ако Quarkus принуждава хората да си вземат пауза и да помислят, то това е добро за цялата екосистема на Java. Quarkus олицетворява иновационен поглед към начина, по който да се създават по-ефективни приложения, правейки Java по-релевантна на новите архитектури на приложения, като serverless. Освен това, благодарение на своята разширяемост, Quarkus, надяваме се, ще се сдобие с цяла екосистема от Java разширения, значително увеличаваща броя на фреймворците, които по подразбиране ще поддържат нативна компилация в състава на приложения.

Източник: habr.com