Hamıya salam! Bu, Quarkus seriyasındakı ikinci yazıdır - bu gün biz yerli kompilyasiya haqqında danışacağıq.
üçün hazırlanmış Java yığınıdır . Burada əlbəttə ki, görüləsi daha çox iş olsa da, biz JVM və bir sıra çərçivələrin optimallaşdırılması da daxil olmaqla bir çox aspektlər üzrə çox yaxşı iş görmüşük. Tərtibatçıların artan marağına səbəb olan Quarkus-un xüsusiyyətlərindən biri də Java kodunu C və C++ kimi xüsusi əməliyyat sistemi üçün icra edilə bilən fayllara (“doğma tərtib” adlanır) çevirmək üçün hərtərəfli, qüsursuz yanaşmasıdır. adətən qurma, sınaq və yerləşdirmə dövrünün sonunda baş verir.
Doğma kompilyasiya vacib olsa da, aşağıda göstərəcəyimiz kimi, qeyd etmək lazımdır ki, Quarkus bütün yığın boyunca tətbiq etdiyimiz performans təkmilləşdirmələri sayəsində ən çox yayılmış Java maşını olan OpenJDK Hotspot-da həqiqətən yaxşı işləyir. Buna görə də, doğma kompilyasiya istənilən və ya lazım olduqda istifadə edilə bilən əlavə bir bonus kimi qəbul edilməlidir. Əslində, Quarkus yerli şəkillərə gəldikdə OpenJDK-ya çox güvənir. Tərtibatçılar tərəfindən hərarətlə qəbul edilən dev rejimi Hotspot-da həyata keçirilən dinamik kod icrasının qabaqcıl imkanları sayəsində dəyişikliklərin demək olar ki, ani sınaqdan keçirilməsini təmin edir. Bundan əlavə, yerli GraalVM şəkilləri yaratarkən OpenJDK sinif kitabxanası və HotSpot imkanlarından istifadə olunur.
Beləliklə, hər şey artıq mükəmməl şəkildə optimallaşdırılıbsa, niyə yerli tərtibə ehtiyacınız var? Bu suala aşağıda cavab verməyə çalışacağıq.
Gəlin aydın olandan başlayaq: Red Hat layihənin inkişafı zamanı JVM-ləri, yığınları və çərçivələri optimallaşdırmaqda geniş təcrübəyə malikdir. , o cümlədən:
- Platformada buludda işləyən ilk proqram serveri .
- Kompüterlərdə işləmək üçün ilk proqram serveri .
- Çalışan ilk proqram serveri .
- Cihazlarda işləyən bir sıra layihələr .
Biz uzun illərdir ki, Java proqramlarını buludda və məhdud resurslu cihazlarda (oxu: IoT) işləmək problemləri ilə məşğul oluruq və performans və yaddaşın optimallaşdırılması baxımından JVM-dən maksimum yararlanmağı öyrənmişik. Bir çox başqaları kimi, biz də uzun müddətdir ki, Java proqramlarının yerli kompilyasiyası ilə işləyirik , , hətta və biz bu yanaşmanın müsbət və mənfi tərəflərini yaxşı bilirik (məsələn, “bir dəfə qurun – hər yerdə işləyin” universallığı ilə tərtib edilmiş proqramların daha kiçik olması və daha sürətli işləməsi arasında seçim dilemması).
Bu müsbət və mənfi cəhətləri nəzərə almaq nə üçün vacibdir? Çünki bəzi hallarda onların nisbəti həlledici olur:
- Məsələn, serversiz/hadisə idarə edən mühitlərdə hadisələrə cavab vermək üçün vaxt tapmaq üçün (sərt və ya yumşaq) real vaxtda. Uzun ömürlü davamlı xidmətlərdən fərqli olaraq, burada soyuq başlanğıcın müddəti sorğuya cavab müddətini kritik dərəcədə artırır. JVM-nin işə salınması hələ də xeyli vaxt tələb edir və bu, bəzi hallarda təmiz aparat üsulları ilə azaldıla bilsə də, bir saniyə ilə 5 millisaniyə arasındakı fərq həyat və ölüm arasındakı fərq ola bilər. Bəli, burada siz Java maşınlarının isti ehtiyatını yaratmaqla oynaya bilərsiniz (məsələn, biz bunu etdik. ), lakin bu, yük miqyası kimi sorğuları emal etmək üçün kifayət qədər JVM-lərin olacağına zəmanət vermir. Və iqtisadi baxımdan bu, yəqin ki, ən düzgün variant deyil.
- Bundan əlavə, tez-tez ortaya çıxan başqa bir aspekt var: çox kirayəlik. JVM-lərin öz imkanlarına görə əməliyyat sistemlərinə çox yaxınlaşmasına baxmayaraq, onlar hələ də Linux-da bizim öyrəşdiyimiz işi - izolyasiya proseslərini həyata keçirə bilmirlər. Buna görə də, bir mövzunun uğursuzluğu bütün Java maşınını sıradan çıxara bilər. Bir çox insanlar uğursuzluğun nəticələrini minimuma endirmək üçün hər bir istifadəçinin tətbiqi üçün ayrıca JVM ayıraraq bu çatışmazlığı aradan qaldırmağa çalışırlar. Bu olduqca məntiqlidir, lakin miqyasla yaxşı uyğun gəlmir.
- Bundan əlavə, bulud yönümlü tətbiqlər üçün mühüm göstərici hostda xidmətlərin sıxlığıdır. Metodologiyaya keçid , mikroservislər və Kubernetes hər tətbiq üçün Java maşınlarının sayını artırır. Yəni, bir tərəfdən, bütün bunlar elastiklik və etibarlılığı təmin edir, lakin eyni zamanda xidmət baxımından əsas yaddaşın istehlakı da artır və bu xərclərin bəziləri həmişə ciddi şəkildə lazım deyil. Statik şəkildə tərtib edilmiş icra edilə bilən fayllar, son görüntü yalnız xidmətin həqiqətən istifadə etdiyi çərçivələrin hissələrini (JDK-nın özü də daxil olmaqla) ehtiva etdikdə, aşağı səviyyəli ölü kodların aradan qaldırılması kimi müxtəlif optimallaşdırma üsulları sayəsində burada faydalanır. Buna görə də, Quarkus yerli kompilyasiyası təhlükəsizliyə xələl gətirmədən xidmət nümunələrini hostda sıx şəkildə yerləşdirməyə kömək edir.
Əslində, yuxarıdakı arqumentlər Quarkus layihəsinin iştirakçılarının nöqteyi-nəzərindən yerli tərtibatın əsaslandırılmasını başa düşmək üçün artıq kifayətdir. Bununla belə, başqa, qeyri-texniki, həm də vacib bir səbəb var: son illərdə bir çox proqramçı və inkişaf şirkətləri Java-dan imtina edərək yeni proqramlaşdırma dillərinin xeyrinə hesab edirlər ki, Java-nın JVM-ləri, yığınları və çərçivələri ilə birlikdə çox böyük hala çevrilib. yaddaş aclığı, çox yavaş və s.
Ancaq hər hansı bir problemi həll etmək üçün eyni vasitədən istifadə etmək vərdişi var . Bəzən bir addım geri çəkilib başqa bir şey axtarmaq daha yaxşıdır. Quarkus insanları dayandırıb düşünməyə vadar edirsə, bu, bütün Java ekosistemi üçün yaxşıdır. Quarkus, Java-nı serversiz kimi yeni proqram arxitekturaları üçün daha uyğun hala gətirərək, daha səmərəli proqramların necə qurulacağına dair innovativ baxışı təmsil edir. Bundan əlavə, genişlənmə qabiliyyətinə görə Quarkus inşallah Java genişləndirmələrinin bütün ekosisteminə sahib olacaq və qutudan kənar tətbiqlərdə yerli kompilyasiyanı dəstəkləyəcək çərçivələrin sayını əhəmiyyətli dərəcədə artıracaqdır.
Mənbə: www.habr.com