მშობლიური კრებული Quarkus-ში - რატომ არის ეს მნიშვნელოვანი

Სალამი ყველას! ეს არის ჩვენი სერიის მეორე პოსტი Quarkus-ზე - დღეს ჩვენ ვისაუბრებთ მშობლიურ კომპილაციაზე.

კვარკუსი არის ჯავის დასტა, რომელიც მორგებულია კუბერნეტები. მიუხედავად იმისა, რომ აქ, რა თქმა უნდა, კიდევ ბევრი რამ არის გასაკეთებელი, ჩვენ ბევრი კარგი სამუშაო გავაკეთეთ ბევრ ასპექტზე, მათ შორის 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 და კიდევ დალვიკი და ჩვენ კარგად ვიცით ამ მიდგომის დადებითი და უარყოფითი მხარეები (მაგალითად, არჩევანის დილემა უნივერსალურობას „აშენე ერთხელ – გაუშვა-არსად“ და იმ ფაქტს, რომ კომპილირებული აპლიკაციები უფრო მცირეა და უფრო სწრაფად მუშაობს).

რატომ არის მნიშვნელოვანი ამ დადებითი და უარყოფითი მხარეების გათვალისწინება? რადგან ზოგიერთ სიტუაციაში მათი თანაფარდობა გადამწყვეტი ხდება:

• მაგალითად, სერვერის გარეშე/მოვლენებზე ორიენტირებულ გარემოში, სადაც სერვისები უბრალოდ უნდა დაიწყოს (მყარ ან რბილ) რეალურ დროში, რათა გქონდეთ დრო მოვლენებზე რეაგირებისთვის. გრძელვადიანი მუდმივი სერვისებისგან განსხვავებით, აქ ცივი დაწყების ხანგრძლივობა კრიტიკულად ზრდის მოთხოვნაზე რეაგირების დროს. JVM-ს ჯერ კიდევ დიდი დრო სჭირდება გაშვებას და მიუხედავად იმისა, რომ ზოგიერთ შემთხვევაში ეს შეიძლება შემცირდეს სუფთა აპარატურის მეთოდებით, განსხვავება ერთ წამსა და 5 მილიწამს შორის შეიძლება იყოს განსხვავება სიცოცხლესა და სიკვდილს შორის. დიახ, აქ შეგიძლიათ ითამაშოთ ჯავის მანქანების ცხელი რეზერვის შექმნაზე (რაც, მაგალითად, ჩვენ გავაკეთეთ OpenWhisk-ის პორტირება Knative-ზე), მაგრამ ეს თავისთავად არ იძლევა გარანტიას, რომ იქნება საკმარისი JVM მოთხოვნები დატვირთვის მასშტაბის მიხედვით. და ეკონომიკური თვალსაზრისით, ეს ალბათ არ არის ყველაზე სწორი ვარიანტი.
• გარდა ამისა, არის კიდევ ერთი ასპექტი, რომელიც ხშირად ჩნდება: მრავალბინიანობა. მიუხედავად იმისა, რომ JVM-ები თავიანთი შესაძლებლობებით ძალიან მიუახლოვდნენ ოპერაციულ სისტემებს, მათ ჯერ კიდევ არ შეუძლიათ გააკეთონ ის, რასაც ჩვენ ასე მიჩვეულები ვართ Linux-ში - იზოლაციის პროცესები. აქედან გამომდინარე, ერთი თემის წარუმატებლობამ შეიძლება დაანგრიოს მთელი ჯავის მანქანა. ბევრი ადამიანი ცდილობს ამ ნაკლის თავიდან აცილებას თითოეული მომხმარებლის აპლიკაციისთვის ცალკე JVM-ის გამოყოფით, რათა მინიმუმამდე დაიყვანოს წარუმატებლობის შედეგები. ეს საკმაოდ ლოგიკურია, მაგრამ კარგად არ ჯდება სკალირებასთან.
• გარდა ამისა, ღრუბელზე ორიენტირებული აპლიკაციებისთვის მნიშვნელოვანი მაჩვენებელია სერვისების სიმკვრივე ჰოსტზე. მეთოდოლოგიაზე გადასვლა 12 განაცხადის ფაქტორი, microservices და Kubernetes ზრდის Java მანქანების რაოდენობას თითო აპლიკაციაზე. ანუ, ეს ყველაფერი, ერთის მხრივ, უზრუნველყოფს ელასტიურობას და საიმედოობას, მაგრამ ამავდროულად იზრდება ბაზის მეხსიერების მოხმარება მომსახურების კუთხით და ამ ხარჯების ნაწილი ყოველთვის არ არის მკაცრად საჭირო. სტატიკურად შედგენილი შესრულებადი ფაილები აქ სარგებლობს ოპტიმიზაციის სხვადასხვა ტექნიკის გამო, როგორიცაა დაბალი დონის მკვდარი კოდის აღმოფხვრა, როდესაც საბოლოო სურათი მოიცავს მხოლოდ იმ ფრეიმორიკების ნაწილებს (მათ შორის თავად JDK-ს), რომლებსაც სერვისი რეალურად იყენებს. ამიტომ, Quarkus-ის მშობლიური კომპილაცია ხელს უწყობს სერვისის ინსტანციების მჭიდროდ განთავსებას მასპინძელზე უსაფრთხოების დარღვევის გარეშე.

სინამდვილეში, ზემოთ მოყვანილი არგუმენტები უკვე საკმარისია იმისათვის, რომ გავიგოთ მშობლიური კომპილაციის დასაბუთება Quarkus-ის პროექტის მონაწილეთა თვალსაზრისით. თუმცა, არის კიდევ ერთი, არატექნიკური, მაგრამ ასევე მნიშვნელოვანი მიზეზი: ბოლო წლებში ბევრმა პროგრამისტმა და დეველოპერულმა კომპანიამ მიატოვა Java ახალი პროგრამირების ენების სასარგებლოდ და მიაჩნიათ, რომ ჯავა, JVM-ებთან, სტეკებთან და ჩარჩოებთან ერთად, ძალიან გახდა. მეხსიერების მშიერი, ძალიან ნელი და ა.შ.

თუმცა, ერთი და იგივე ინსტრუმენტის გამოყენების ჩვევა ნებისმიერი პრობლემის გადასაჭრელად არის ყოველთვის არ არის სწორი. ხანდახან ჯობია უკან გადადგა ნაბიჯი და სხვა რამე მოძებნო. და თუ Quarkus აიძულებს ხალხს შეაჩერონ და იფიქრონ, მაშინ ეს კარგია ჯავის მთელი ეკოსისტემისთვის. Quarkus წარმოადგენს ინოვაციურ ხედვას იმის შესახებ, თუ როგორ უნდა ავაშენოთ უფრო ეფექტური აპლიკაციები, რაც ჯავას უფრო რელევანტურს ხდის ახალ აპლიკაციების არქიტექტურას, როგორიცაა სერვერის გარეშე. გარდა ამისა, მისი გაფართოების გამო, Quarkus-ს იმედია ექნება ჯავის გაფართოებების მთელი ეკოსისტემა, რაც მნიშვნელოვნად გაზრდის ჩარჩოების რაოდენობას, რომლებიც მხარს დაუჭერენ ბუნებრივ კომპილაციას აპლიკაციებში.

წყარო: www.habr.com