Εγγενής συλλογή στο Quarkus - γιατί είναι σημαντική

Γεια σε όλους! Αυτή είναι η δεύτερη ανάρτηση στη σειρά μας στο Quarkus - σήμερα θα μιλήσουμε για την εγγενή συλλογή.

Εγγενής συλλογή στο Quarkus - γιατί είναι σημαντική

Κουάρκος είναι μια στοίβα Java προσαρμοσμένη για Kubernetes. Αν και υπάρχουν σίγουρα πολλά περισσότερα να κάνουμε εδώ, έχουμε κάνει πολύ καλή δουλειά σε πολλές πτυχές, συμπεριλαμβανομένης της βελτιστοποίησης του JVM και ορισμένων πλαισίων. Ένα από τα χαρακτηριστικά του Quarkus που έχει προσελκύσει αυξημένο ενδιαφέρον από προγραμματιστές είναι η ολοκληρωμένη, απρόσκοπτη προσέγγισή του στη μετατροπή του κώδικα Java σε εκτελέσιμα αρχεία για ένα συγκεκριμένο λειτουργικό σύστημα (το λεγόμενο "native compilation"), παρόμοιο με το C και το C++, όπου τέτοια μεταγλώττιση συνήθως συμβαίνει στο τέλος ενός κύκλου κατασκευής, δοκιμής και ανάπτυξης.

Και ενώ η εγγενής μεταγλώττιση είναι σημαντική, όπως θα δείξουμε παρακάτω, θα πρέπει να σημειωθεί ότι το Quarkus τρέχει πολύ καλά στον πιο συνηθισμένο μηχάνημα Java, το OpenJDK Hotspot, χάρη στις βελτιώσεις απόδοσης που έχουμε εφαρμόσει σε όλη τη στοίβα. Επομένως, η εγγενής συλλογή θα πρέπει να θεωρείται ως ένα πρόσθετο μπόνους που μπορεί να χρησιμοποιηθεί όπως επιθυμείτε ή είναι απαραίτητο. Στην πραγματικότητα, το Quarkus βασίζεται σε μεγάλο βαθμό στο OpenJDK όταν πρόκειται για εγγενείς εικόνες. Και η λειτουργία dev, που έγινε θερμά αποδεκτή από τους προγραμματιστές, εξασφαλίζει σχεδόν στιγμιαία δοκιμή των αλλαγών λόγω των προηγμένων δυνατοτήτων δυναμικής εκτέλεσης κώδικα που εφαρμόζεται στο Hotspot. Επιπλέον, κατά τη δημιουργία εγγενών εικόνων GraalVM, χρησιμοποιούνται η βιβλιοθήκη κλάσης OpenJDK και οι δυνατότητες HotSpot.

Γιατί λοιπόν χρειάζεστε εγγενή μεταγλώττιση εάν όλα είναι ήδη τέλεια βελτιστοποιημένα; Θα προσπαθήσουμε να απαντήσουμε σε αυτό το ερώτημα παρακάτω.

Ας ξεκινήσουμε με το προφανές: Η Red Hat έχει μεγάλη εμπειρία στη βελτιστοποίηση JVM, στοίβων και πλαισίων κατά την ανάπτυξη έργου JBoss, συμπεριλαμβανομένου:

  • Ο πρώτος διακομιστής εφαρμογών που λειτουργεί στο cloud στην πλατφόρμα Red Hat OpenShift.
  • Ο πρώτος διακομιστής εφαρμογών για εκτέλεση σε υπολογιστές Συνδέστε τον υπολογιστή.
  • Ο πρώτος διακομιστής εφαρμογών στον οποίο εκτελείται Raspberry Pi.
  • Μια σειρά από έργα που εκτελούνται σε συσκευές Android.

Αντιμετωπίζουμε τις προκλήσεις της εκτέλεσης εφαρμογών Java στο cloud και σε συσκευές με περιορισμένους πόρους (διαβάστε: IoT) εδώ και πολλά χρόνια και έχουμε μάθει να αξιοποιούμε στο έπακρο το JVM όσον αφορά την απόδοση και τη βελτιστοποίηση μνήμης. Όπως πολλοί άλλοι, εργαζόμαστε με εγγενή μεταγλώττιση εφαρμογών Java εδώ και πολύ καιρό G.C.J., Πουλιά, Excelsior JET και ακόμη Dalvik και γνωρίζουμε καλά τα πλεονεκτήματα και τα μειονεκτήματα αυτής της προσέγγισης (για παράδειγμα, το δίλημμα της επιλογής μεταξύ της καθολικότητας του «build Once – run-anywhere» και του γεγονότος ότι οι μεταγλωττισμένες εφαρμογές είναι μικρότερες και εκτελούνται πιο γρήγορα).

Γιατί είναι σημαντικό να λάβουμε υπόψη αυτά τα πλεονεκτήματα και τα μειονεκτήματα; Επειδή σε ορισμένες περιπτώσεις η αναλογία τους γίνεται καθοριστική:

  • Για παράδειγμα, σε περιβάλλοντα χωρίς διακομιστή/συμβάντα όπου οι υπηρεσίες απλά πρέπει να ξεκινήσουν σε (σκληρό ή μαλακό) πραγματικό χρόνο για να έχετε χρόνο να απαντήσετε στα γεγονότα. Σε αντίθεση με τις μακροχρόνιες επίμονες υπηρεσίες, εδώ η διάρκεια μιας ψυχρής εκκίνησης αυξάνει σημαντικά τον χρόνο απόκρισης σε ένα αίτημα. Το JVM χρειάζεται ακόμα σημαντικό χρονικό διάστημα για να ξεκινήσει, και ενώ αυτό μπορεί να μειωθεί σε ορισμένες περιπτώσεις με μεθόδους καθαρού υλικού, η διαφορά μεταξύ ενός δευτερολέπτου και 5 χιλιοστών του δευτερολέπτου μπορεί να είναι η διαφορά μεταξύ ζωής και θανάτου. Ναι, εδώ μπορείτε να παίξετε με τη δημιουργία ενός ζεστού αποθέματος μηχανών Java (το οποίο, για παράδειγμα, κάναμε με μεταφορά του OpenWhisk στο Knative), αλλά αυτό από μόνο του δεν εγγυάται ότι θα υπάρχουν αρκετά JVM για την επεξεργασία αιτημάτων καθώς κλιμακώνεται το φορτίο. Και από οικονομικής άποψης, αυτή μάλλον δεν είναι η πιο σωστή επιλογή.
  • Επιπλέον, υπάρχει μια άλλη πτυχή που εμφανίζεται συχνά: η πολυμίσθωση. Παρά το γεγονός ότι τα JVM έχουν φτάσει πολύ κοντά στα λειτουργικά συστήματα στις δυνατότητές τους, εξακολουθούν να μην είναι σε θέση να κάνουν αυτό που έχουμε συνηθίσει στο Linux - διαδικασίες απομόνωσης. Επομένως, η αποτυχία ενός νήματος μπορεί να καταστρέψει ολόκληρο το μηχάνημα Java. Πολλοί άνθρωποι προσπαθούν να ξεπεράσουν αυτό το μειονέκτημα αφιερώνοντας ένα ξεχωριστό JVM για τις εφαρμογές κάθε χρήστη, προκειμένου να ελαχιστοποιήσουν τις συνέπειες μιας αποτυχίας. Αυτό είναι αρκετά λογικό, αλλά δεν ταιριάζει καλά με την κλιμάκωση.
  • Επιπλέον, για εφαρμογές προσανατολισμένες στο cloud, ένας σημαντικός δείκτης είναι η πυκνότητα των υπηρεσιών στον κεντρικό υπολογιστή. Μετάβαση στη μεθοδολογία 12 παράγοντες εφαρμογής, microservices και Kubernetes αυξάνει τον αριθμό των μηχανών Java ανά εφαρμογή. Δηλαδή, αφενός, όλα αυτά παρέχουν ελαστικότητα και αξιοπιστία, αλλά ταυτόχρονα αυξάνεται και η κατανάλωση της βασικής μνήμης όσον αφορά την εξυπηρέτηση και ορισμένα από αυτά τα έξοδα δεν είναι πάντα απολύτως απαραίτητα. Τα στατικά μεταγλωττισμένα εκτελέσιμα αρχεία ωφελούνται εδώ λόγω διαφόρων τεχνικών βελτιστοποίησης, όπως η εξάλειψη νεκρού κώδικα χαμηλού επιπέδου, όταν η τελική εικόνα περιλαμβάνει μόνο εκείνα τα μέρη των πλαισίων (συμπεριλαμβανομένου του ίδιου του JDK) που χρησιμοποιεί στην πραγματικότητα η υπηρεσία. Επομένως, η εγγενής μεταγλώττιση του Quarkus βοηθά στην πυκνή τοποθέτηση παρουσιών υπηρεσίας στον κεντρικό υπολογιστή χωρίς να διακυβεύεται η ασφάλεια.

Στην πραγματικότητα, τα παραπάνω επιχειρήματα είναι ήδη αρκετά για να κατανοήσουμε την αιτιολόγηση της εγγενούς συλλογής από τη σκοπιά των συμμετεχόντων στο έργο Quarkus. Ωστόσο, υπάρχει ένας άλλος, μη τεχνικός, αλλά και σημαντικός λόγος: τα τελευταία χρόνια, πολλοί προγραμματιστές και εταιρείες ανάπτυξης έχουν εγκαταλείψει την Java υπέρ νέων γλωσσών προγραμματισμού, πιστεύοντας ότι η Java, μαζί με τα JVM, τις στοίβες και τα πλαίσια της, έχει γίνει πάρα πολύ πεινασμένος για μνήμη, πολύ αργός κ.λπ.

Ωστόσο, η συνήθεια να χρησιμοποιείτε το ίδιο εργαλείο για να λύσετε οποιοδήποτε πρόβλημα είναι δεν είναι πάντα σωστό. Μερικές φορές είναι καλύτερο να κάνετε ένα βήμα πίσω και να αναζητήσετε κάτι άλλο. Και αν το Quarkus κάνει τους ανθρώπους να σταματήσουν και να σκεφτούν, τότε αυτό είναι καλό για ολόκληρο το οικοσύστημα της Java. Το Quarkus αντιπροσωπεύει μια καινοτόμο άποψη του τρόπου δημιουργίας πιο αποτελεσματικών εφαρμογών, καθιστώντας την Java πιο σχετική με νέες αρχιτεκτονικές εφαρμογών, όπως χωρίς διακομιστή. Επιπλέον, λόγω της επεκτασιμότητας του, το Quarkus ελπίζουμε ότι θα έχει ένα ολόκληρο οικοσύστημα επεκτάσεων Java, αυξάνοντας σημαντικά τον αριθμό των πλαισίων που θα υποστηρίζουν εγγενή μεταγλώττιση σε εφαρμογές εκτός συσκευασίας.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο