أهلاً بكم! هذه هي المقالة الثانية في سلسلتنا عن Quarkus - سنتحدث اليوم عن التجميع الأصلي.
عبارة عن مكدس Java مصمم خصيصًا لـ . على الرغم من أن هناك بالتأكيد الكثير مما يجب القيام به هنا، فقد قمنا بالكثير من العمل الجيد في العديد من الجوانب، بما في ذلك تحسين JVM وعدد من أطر العمل. إحدى ميزات Quarkus التي جذبت اهتمامًا متزايدًا من المطورين هي منهجها الشامل والسلس لتحويل كود Java إلى ملفات قابلة للتنفيذ لنظام تشغيل معين (ما يسمى "التجميع الأصلي")، على غرار C وC++، حيث يتم مثل هذا التجميع يحدث عادةً في نهاية دورة الإنشاء والاختبار والنشر.
وعلى الرغم من أهمية التجميع الأصلي، كما سنوضح أدناه، تجدر الإشارة إلى أن Quarkus يعمل بشكل جيد على جهاز Java الأكثر شيوعًا، OpenJDK Hotspot، وذلك بفضل تحسينات الأداء التي قمنا بتنفيذها في جميع أنحاء المكدس. ولذلك، ينبغي اعتبار التجميع الأصلي بمثابة مكافأة إضافية يمكن استخدامها حسب الرغبة أو الضرورة. في الواقع، يعتمد Quarkus بشكل كبير على OpenJDK عندما يتعلق الأمر بالصور الأصلية. ويضمن وضع التطوير، الذي يحظى بقبول كبير من قبل المطورين، اختبارًا فوريًا تقريبًا للتغييرات نظرًا للإمكانيات المتقدمة لتنفيذ التعليمات البرمجية الديناميكية المطبقة في Hotspot. بالإضافة إلى ذلك، عند إنشاء صور GraalVM الأصلية، يتم استخدام مكتبة فئة OpenJDK وقدرات HotSpot.
فلماذا تحتاج إلى تجميع أصلي إذا كان كل شيء مُحسّنًا بالفعل؟ سنحاول الإجابة على هذا السؤال أدناه.
لنبدأ بما هو واضح: تتمتع Red Hat بخبرة واسعة في تحسين JVMs والمكدسات وأطر العمل أثناء تطوير المشروع ، включая:
- أول خادم تطبيقات يعمل في السحابة على المنصة .
- أول خادم تطبيقات يعمل على أجهزة الكمبيوتر .
- أول خادم تطبيق يعمل عليه .
- مجموعة من المشاريع التي تعمل على الأجهزة .
لقد تعاملنا مع تحديات تشغيل تطبيقات Java في السحابة وعلى الأجهزة المحدودة الموارد (اقرأ: إنترنت الأشياء) لسنوات عديدة وتعلمنا كيفية تحقيق أقصى استفادة من JVM من حيث الأداء وتحسين الذاكرة. مثل كثيرين آخرين، كنا نعمل مع التجميع الأصلي لتطبيقات Java لفترة طويلة , , وحتى ونحن ندرك جيدًا إيجابيات وسلبيات هذا النهج (على سبيل المثال، معضلة الاختيار بين عالمية "البناء مرة واحدة - التشغيل في أي مكان" وحقيقة أن التطبيقات المجمعة أصغر حجمًا وتعمل بشكل أسرع).
لماذا من المهم النظر في هذه الإيجابيات والسلبيات؟ لأنه في بعض المواقف تصبح نسبتهم حاسمة:
- على سبيل المثال، في البيئات التي لا تعتمد على خادم/التي تعتمد على الأحداث حيث في الوقت الحقيقي (الصعب أو الناعم) من أجل الحصول على الوقت للرد على الأحداث. على عكس الخدمات المستمرة طويلة الأمد، فإن مدة البداية الباردة هنا تزيد بشكل كبير من وقت الاستجابة للطلب. لا يزال JVM يستغرق وقتًا طويلاً لبدء التشغيل، وبينما يمكن تقليل هذا الوقت في بعض الحالات عن طريق طرق الأجهزة البحتة، فإن الفرق بين ثانية واحدة و5 مللي ثانية يمكن أن يكون الفرق بين الحياة والموت. نعم، يمكنك هنا تجربة إنشاء احتياطي ساخن من أجهزة Java (وهو ما فعلناه، على سبيل المثال، باستخدام )، ولكن هذا في حد ذاته لا يضمن أنه سيكون هناك ما يكفي من أجهزة JVM لمعالجة الطلبات كمقاييس تحميل. ومن وجهة نظر اقتصادية، ربما لا يكون هذا هو الخيار الصحيح.
- علاوة على ذلك، هناك جانب آخر يظهر غالبًا: تعدد الإيجارات. على الرغم من حقيقة أن JVMs قد اقتربت جدًا من أنظمة التشغيل من حيث قدراتها، إلا أنها لا تزال غير قادرة على القيام بما اعتدنا عليه في Linux - عمليات العزل. لذلك، يمكن أن يؤدي فشل مؤشر ترابط واحد إلى تعطيل جهاز Java بأكمله. يحاول العديد من الأشخاص التغلب على هذا العيب من خلال تخصيص JVM منفصل لتطبيقات كل مستخدم من أجل تقليل عواقب الفشل. هذا أمر منطقي تمامًا، لكنه لا يتناسب بشكل جيد مع القياس.
- بالإضافة إلى ذلك، بالنسبة للتطبيقات السحابية، فإن المؤشر المهم هو كثافة الخدمات على المضيف. الانتقال إلى المنهجية تعمل الخدمات الصغيرة وKubernetes على زيادة عدد أجهزة Java لكل تطبيق. وهذا يعني، من ناحية، أن كل هذا يوفر المرونة والموثوقية، ولكن في نفس الوقت يزداد أيضًا استهلاك الذاكرة الأساسية من حيث الخدمة، وبعض هذه النفقات ليست دائمًا ضرورية تمامًا. تستفيد الملفات القابلة للتنفيذ المجمعة بشكل ثابت هنا بسبب تقنيات التحسين المختلفة، مثل إزالة التعليمات البرمجية الميتة ذات المستوى المنخفض، عندما تتضمن الصورة النهائية فقط تلك الأجزاء من الإطارات (بما في ذلك JDK نفسها) التي تستخدمها الخدمة بالفعل. لذلك، يساعد تجميع Quarkus الأصلي على وضع مثيلات الخدمة بكثافة على المضيف دون المساس بالأمان.
في الواقع، الحجج المذكورة أعلاه كافية بالفعل لفهم مبررات التجميع الأصلي من وجهة نظر المشاركين في مشروع Quarkus. ومع ذلك، هناك سبب آخر غير تقني ولكنه مهم أيضًا: في السنوات الأخيرة، تخلى العديد من المبرمجين وشركات التطوير عن Java لصالح لغات برمجة جديدة، معتقدين أن Java، جنبًا إلى جنب مع JVMs والمكدسات والأطر، أصبحت أكثر من اللازم متعطش للذاكرة، بطيء جدًا، وما إلى ذلك.
ومع ذلك، فإن عادة استخدام نفس الأداة لحل أي مشكلة هي . في بعض الأحيان يكون من الأفضل التراجع والبحث عن شيء آخر. وإذا كان Quarkus يجعل الناس يتوقفون ويفكرون، فهذا أمر جيد لنظام Java البيئي بأكمله. يمثل Quarkus رؤية مبتكرة لكيفية إنشاء تطبيقات أكثر كفاءة، مما يجعل Java أكثر صلة ببنيات التطبيقات الجديدة مثل التطبيقات بدون خادم. بالإضافة إلى ذلك، نظرًا لقابلية التوسعة، نأمل أن يكون لدى Quarkus نظام بيئي كامل من امتدادات Java، مما يزيد بشكل كبير من عدد الأطر التي ستدعم التجميع الأصلي في التطبيقات خارج الصندوق.
المصدر: www.habr.com