Нативна компилация в 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 и отлично осъзнаваме плюсовете и минусите на този подход (например дилемата за избор между универсалността на "build once – run-anywhere" и това, че компилираните приложения имат по-малък размер и се стартират по-бързо).

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

• Например, в 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