אוסף מקורי ב-Quarkus - למה זה חשוב

שלום לכולם! זהו הפוסט השני בסדרת Quarkus שלנו - היום נדבר על אוסף מקורי.

קוורקוס הוא ערימת Java המותאמת עבור קוברנט. למרות שאין ספק שיש עוד הרבה מה לעשות כאן, עשינו הרבה עבודה טובה בהרבה היבטים, כולל אופטימיזציה של ה-JVM ומספר מסגרות. אחת התכונות של Quarkus שמשכה התעניינות מוגברת מצד מפתחים היא הגישה המקיפה והחלקה שלה להפיכת קוד Java לקבצי הפעלה עבור מערכת הפעלה ספציפית (מה שנקרא "קומפילציה מקורית"), בדומה ל-C ו-C++, שבהן קומפילציה כזו מתרחש בדרך כלל בסוף מחזור של בנייה, בדיקה ופריסה.

ולמרות שהקומפילציה מקורית חשובה, כפי שנראה להלן, יש לציין ש-Quarkus פועל ממש טוב על מכונת ה-Java הנפוצה ביותר, OpenJDK Hotspot, הודות לשיפורי הביצועים שהטמענו בכל הערימה. לכן, יש להתייחס לקומפילציה מקורית כבונוס נוסף שניתן להשתמש בו לפי הצורך או הדרוש. למעשה, Quarkus מסתמך במידה רבה על OpenJDK בכל הנוגע לתמונות מקוריות. ומצב הפיתוח, שהתקבל בחום על ידי מפתחים, מבטיח בדיקה כמעט מיידית של שינויים בשל היכולות המתקדמות של ביצוע קוד דינמי המיושם ב-Hotspot. בנוסף, בעת יצירת תמונות GraalVM מקוריות, נעשה שימוש בספריית מחלקות OpenJDK וביכולות HotSpot.

אז למה אתה צריך קומפילציה מקורית אם הכל כבר מותאם בצורה מושלמת? ננסה לענות על שאלה זו להלן.

נתחיל עם המובן מאליו: ל-Red Hat יש ניסיון רב באופטימיזציה של JVMs, ערימות ומסגרות במהלך פיתוח הפרויקט JBoss, כולל:

• שרת האפליקציות הראשון שעובד בענן בפלטפורמה רד האט.
• שרת היישומים הראשון להפעלה על מחשבים חבר את המחשב.
• שרת היישומים הראשון לרוץ עליו פטל Pi.
• מגוון פרויקטים הפועלים במכשירים אנדרואיד.

אנחנו מתמודדים עם האתגרים של הפעלת יישומי Java בענן ובמכשירים מוגבלי משאבים (קראו: IoT) כבר שנים רבות ולמדנו להפיק את המרב מה-JVM מבחינת ביצועים ואופטימיזציה של זיכרון. כמו רבים אחרים, אנו עובדים עם קומפילציה מקורית של יישומי Java במשך זמן רב G.C.J., אביאן, אקסלסיור JET ואפילו Dalvik ואנחנו מודעים היטב ליתרונות ולחסרונות של גישה זו (לדוגמה, הדילמה של בחירה בין האוניברסליות של "בנה פעם אחת - הפעלה בכל מקום" לבין העובדה שיישומים מהודרים קטנים יותר ורצים מהר יותר).

מדוע חשוב לקחת בחשבון את היתרונות והחסרונות הללו? מכיוון שבמצבים מסוימים היחס שלהם הופך להיות מכריע:

• לדוגמה, בסביבות ללא שרתים/אירועים שבהם השירותים פשוט צריכים להתחיל בזמן אמת (קשה או רך) על מנת להספיק להגיב לאירועים. בניגוד לשירותים מתמשכים ארוכים, כאן משך ההתחלה הקרה מגדיל באופן קריטי את זמן התגובה לבקשה. ה-JVM עדיין לוקח זמן משמעותי להתנעול, ולמרות שבמקרים מסוימים ניתן להפחית זאת בשיטות חומרה טהורות, ההבדל בין שנייה אחת ל-5 אלפיות השנייה יכול להיות ההבדל בין חיים למוות. כן, כאן אתה יכול לשחק עם יצירת רזרבה חמה של מכונות Java (מה, למשל, עשינו איתם העברה של OpenWhisk ל-Knative), אך זה כשלעצמו אינו מבטיח שיהיו מספיק JVMs לעבד בקשות כקנה המידה של העומס. ומבחינה כלכלית זו כנראה לא האופציה הנכונה ביותר.
• יתר על כן, יש היבט נוסף שצץ לעתים קרובות: ריבוי דירות. למרות העובדה שמכשירי JVM התקרבו מאוד למערכות הפעלה ביכולות שלהם, הם עדיין לא מסוגלים לעשות את מה שאנחנו כל כך רגילים אליו בלינוקס – בידוד תהליכים. לכן, כשל של שרשור אחד יכול להפיל את כל מכונת ה-Java. אנשים רבים מנסים לעקוף את החיסרון הזה על ידי הקדשת JVM נפרד עבור כל אפליקציה של משתמש על מנת למזער את ההשלכות של כשל. זה די הגיוני, אבל לא מתאים לשינוי קנה מידה.
• בנוסף, עבור יישומים מוכווני ענן, אינדיקטור חשוב הוא צפיפות השירותים על המארח. מעבר למתודולוגיה 12 גורמי יישום, microservices ו-Kubernetes מגדילים את מספר מכונות Java לכל אפליקציה. כלומר, מצד אחד כל זה מספק גמישות ואמינות, אך במקביל גם צריכת הזיכרון הבסיסי מבחינת שירות עולה, וחלק מההוצאות הללו לא תמיד נחוצות בהחלט. קבצי הפעלה בעלי קומפילציה סטטית מרוויחים כאן בשל טכניקות אופטימיזציה שונות, כמו חיסול קוד מת ברמה נמוכה, כאשר התמונה הסופית כוללת רק את אותם חלקים של ה-frameworks (כולל ה-JDK עצמו) שהשירות משתמש בהם בפועל. לכן, קומפילציה מקורית של Quarkus עוזרת למקם בצפיפות מופעי שירות על המארח מבלי לפגוע באבטחה.

למעשה, הטיעונים שלעיל כבר מספיקים כדי להבין את ההצדקה של קומפילציה מקומית מנקודת המבט של משתתפי פרויקט Quarkus. עם זאת, יש סיבה נוספת, לא טכנית, אך גם חשובה: בשנים האחרונות, הרבה מתכנתים וחברות פיתוח נטשו את ג'אווה לטובת שפות תכנות חדשות, מתוך אמונה ש-Java, יחד עם ה-JVMs, הערימות וה-frameworks שלה, הפכו גם רעב לזיכרון, איטי מדי וכו'.

עם זאת, ההרגל להשתמש באותו כלי כדי לפתור כל בעיה הוא זה לא תמיד נכון. לפעמים עדיף לקחת צעד אחורה ולחפש משהו אחר. ואם Quarkus גורם לאנשים לעצור ולחשוב, אז זה טוב לכל המערכת האקולוגית של Java. Quarkus מייצג השקפה חדשנית כיצד לבנות יישומים יעילים יותר, מה שהופך את Java לרלוונטי יותר לארכיטקטורות יישומים חדשות כמו ללא שרת. בנוסף, בשל יכולת ההרחבה שלה, לקוורקוס תהיה בתקווה מערכת אקולוגית שלמה של הרחבות Java, מה שיגדיל משמעותית את מספר ה-frameworks שיתמכו בהידור מקורי ביישומים מחוץ לקופסה.

מקור: www.habr.com