Hammaga salom! Bu Quarkus haqidagi seriyamizdagi ikkinchi post - bugun biz mahalliy kompilyatsiya haqida gaplashamiz.
uchun moslashtirilgan Java stekidir . Albatta, bu yerda qilinadigan ishlar ko‘p bo‘lsa-da, biz ko‘p jihatlar, jumladan JVM va qator ramkalarni optimallashtirish bo‘yicha ko‘plab yaxshi ishlarni amalga oshirdik. Quarkus-ning ishlab chiquvchilarning qiziqishini oshirgan xususiyatlaridan biri bu Java kodini C va C++ ga o'xshash ma'lum bir operatsion tizim uchun bajariladigan fayllarga ("mahalliy kompilyatsiya" deb ataladi) aylantirishga keng qamrovli, muammosiz yondashuvidir. odatda qurish, sinovdan o'tkazish va joylashtirish tsiklining oxirida sodir bo'ladi.
Mahalliy kompilyatsiya muhim bo'lsa-da, quyida ko'rsatamiz, shuni ta'kidlash kerakki, Quarkus biz stek bo'ylab amalga oshirgan ish faoliyatini yaxshilash tufayli eng keng tarqalgan Java mashinasi OpenJDK Hotspotda juda yaxshi ishlaydi. Shuning uchun, mahalliy kompilyatsiya istalgan yoki kerak bo'lganda ishlatilishi mumkin bo'lgan qo'shimcha bonus sifatida ko'rib chiqilishi kerak. Aslida, Quarkus mahalliy tasvirlar haqida gap ketganda OpenJDK ga tayanadi. Ishlab chiquvchilar tomonidan iliq qabul qilingan dev rejimi Hotspot-da joriy qilingan dinamik kodni bajarishning ilg'or imkoniyatlari tufayli o'zgarishlarni deyarli bir zumda sinab ko'rishni ta'minlaydi. Bundan tashqari, mahalliy GraalVM tasvirlarini yaratishda OpenJDK sinf kutubxonasi va HotSpot imkoniyatlaridan foydalaniladi.
Xo'sh, agar hamma narsa allaqachon mukammal optimallashtirilgan bo'lsa, nega sizga mahalliy kompilyatsiya kerak? Bu savolga quyida javob berishga harakat qilamiz.
Aniq narsadan boshlaylik: Red Hat loyihani ishlab chiqish jarayonida JVM, stek va ramkalarni optimallashtirish bo'yicha katta tajribaga ega. , shu jumladan:
- Platformada bulutda ishlaydigan birinchi dastur serveri .
- Kompyuterlarda ishlash uchun birinchi dastur serveri .
- Ishlaydigan birinchi dastur serveri .
- Qurilmalarda ishlaydigan bir qator loyihalar .
Biz ko‘p yillar davomida bulutda va cheklangan resurslarga ega qurilmalarda (o‘qing: IoT) Java ilovalarini ishga tushirish bilan bog‘liq muammolar bilan shug‘ullanib keldik va unumdorlik va xotirani optimallashtirish nuqtai nazaridan JVM’dan maksimal darajada foydalanishni o‘rgandik. Boshqa ko'pchilik singari, biz ham uzoq vaqt davomida Java ilovalarining mahalliy kompilyatsiyasi bilan ishlamoqdamiz , , va hatto va biz bu yondashuvning ijobiy va salbiy tomonlarini yaxshi bilamiz (masalan, “bir marta qurish – hamma joyda ishga tushirish” universalligi va kompilyatsiya qilingan ilovalarning kichikroq va tezroq ishlashi o‘rtasida tanlov dilemmasi).
Nima uchun bu ijobiy va salbiy tomonlarini hisobga olish muhim? Chunki ba'zi hollarda ularning nisbati hal qiluvchi bo'ladi:
- Masalan, serversiz/hodisaga asoslangan muhitlarda voqealarga javob berishga vaqt topish uchun (qattiq yoki yumshoq) real vaqtda. Uzoq muddatli doimiy xizmatlardan farqli o'laroq, bu erda sovuq boshlashning davomiyligi so'rovga javob berish vaqtini keskin oshiradi. JVMni ishga tushirish uchun hali ham katta vaqt talab etiladi va bu ba'zi hollarda sof apparat usullari bilan qisqartirilishi mumkin bo'lsa-da, bir soniya va 5 millisekundlar orasidagi farq hayot va o'lim o'rtasidagi farq bo'lishi mumkin. Ha, bu erda siz Java mashinalarining issiq zaxirasini yaratish bilan o'ynashingiz mumkin (masalan, biz buni qildik. ), lekin bu o'z-o'zidan yuk shkalasi sifatida so'rovlarni qayta ishlash uchun etarli JVM bo'lishini kafolatlamaydi. Va iqtisodiy nuqtai nazardan, bu, ehtimol, eng to'g'ri variant emas.
- Keyin ko'p ijaraga olish masalasi tez-tez ko'tariladi. JVMlar o'z imkoniyatlari bo'yicha operatsion tizimlarga ancha yaqinlashgan bo'lsa-da, ular hali ham biz o'rganib qolgan narsalarni xuddi shunday qila olmaydi. Linux'e – jarayonlarni ajratish uchun. Shuning uchun, bitta thread nosozligi butun Java mashinasining ishdan chiqishiga olib kelishi mumkin. Ko'pchilik nosozlik ta'sirini minimallashtirish uchun har bir foydalanuvchi dasturiga alohida JVM ajratish orqali buni chetlab o'tishga harakat qiladi. Bu juda mantiqiy, lekin u yaxshi miqyoslanmaydi.
- Bundan tashqari, bulutga yo'naltirilgan ilovalar uchun muhim ko'rsatkich xostdagi xizmatlarning zichligi hisoblanadi. Metodologiyaga o'tish , mikroservislar va Kubernetes har bir dastur uchun Java mashinalari sonini oshiradi. Ya'ni, bir tomondan, bularning barchasi elastiklik va ishonchlilikni ta'minlaydi, lekin ayni paytda xizmat ko'rsatish nuqtai nazaridan asosiy xotiraning iste'moli ham oshadi va bu xarajatlarning bir qismi har doim ham qat'iy zarur emas. Statik kompilyatsiya qilingan bajariladigan fayllar bu erda turli xil optimallashtirish usullari tufayli foyda keltiradi, masalan, past darajadagi o'lik kodni yo'q qilish, agar oxirgi tasvir faqat xizmat haqiqatda foydalanadigan ramka qismlarini (jumladan, JDK ning o'zini) o'z ichiga oladi. Shu sababli, Quarkus mahalliy kompilyatsiyasi xavfsizlikni buzmasdan xostga xizmat ko'rsatish namunalarini zich joylashtirishga yordam beradi.
Aslida, yuqoridagi dalillar Quarkus loyihasi ishtirokchilari nuqtai nazaridan mahalliy kompilyatsiya asoslanishini tushunish uchun etarli. Biroq, yana bir texnik bo'lmagan, ammo muhim sabab ham bor: so'nggi yillarda ko'plab dasturchilar va ishlab chiquvchilar Java-dan voz kechib, yangi dasturlash tillari foydasiga Java-ni JVM-lar, steklar va ramkalar bilan bir qatorda juda ko'p narsaga aylangan deb hisoblashdi. xotira och, juda sekin va h.k.
Biroq, har qanday muammoni hal qilish uchun bir xil vositadan foydalanish odati . Ba'zan orqaga bir qadam tashlab, boshqa narsani izlash yaxshiroqdir. Va agar Quarkus odamlarni to'xtatib, o'ylashga majbur qilsa, bu butun Java ekotizimiga foydali bo'ladi. Quarkus Java-ni serversiz kabi yangi ilovalar arxitekturalariga ko'proq moslashtirib, samaraliroq ilovalar yaratishning innovatsion ko'rinishini ifodalaydi. Bundan tashqari, kengayishi tufayli Quarkus Java kengaytmalarining butun ekotizimiga ega bo'ladi, bu esa ilovalarda mahalliy kompilyatsiyani qo'llab-quvvatlaydigan ramkalar sonini sezilarli darajada oshiradi.
Manba: www.habr.com
