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

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

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

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

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

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

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

Справяме се с предизвикателствата на изпълнението на Java приложения в облака и на устройства с ограничени ресурси (да се чете: IoT) в продължение на много години и се научихме да извличаме максимума от JVM по отношение на производителността и оптимизацията на паметта. Подобно на много други, ние работим с естествена компилация на Java приложения от дълго време G.C.J., Птичият, Excelsior JET и дори Dalvik и ние сме добре запознати с предимствата и недостатъците на този подход (например дилемата при избора между универсалността на „изграждане веднъж – стартиране навсякъде“ и факта, че компилираните приложения са по-малки и работят по-бързо).

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

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

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

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

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