هيلو سڀ! هيءَ ٻي پوسٽ آهي اسان جي سيريز جي Quarkus تي - اڄ اسين ڳالهائينداسين ڏيهي تاليف بابت.
هڪ جاوا اسٽيڪ لاء ٺهيل آهي . جڏهن ته هتي ضرور ڪرڻ لاءِ گهڻو ڪجهه آهي، اسان ڪيترن ئي حصن تي تمام سٺو ڪم ڪيو آهي، بشمول JVM کي بهتر ڪرڻ ۽ ڪيترن ئي فريم ورڪن تي. Quarkus جي خاصيتن مان هڪ آهي جنهن ڊولپرز جي دلچسپي وڌي آهي، جاوا ڪوڊ کي هڪ مخصوص آپريٽنگ سسٽم لاءِ ايگزيڪيوٽيبل فائلن ۾ تبديل ڪرڻ لاءِ ان جو جامع ۽ بيحد طريقو آهي (جنهن کي ”مقامي تاليف“ سڏيو وڃي ٿو) سي ۽ سي++ سان ملندڙ جلندڙ آهي، جتي اهڙي تاليف عام طور تي تعمير، ٽيسٽ، ۽ ترتيب ڏيڻ جي چڪر جي آخر ۾ ٿيندي آهي.
۽ جڏهن ته مقامي تاليف ضروري آهي، جيئن اسان هيٺ ڏيکارينداسين، اهو ياد رکڻ گهرجي ته Quarkus تمام عام جاوا مشين، OpenJDK Hotspot تي واقعي چڱي ريت هلندو آهي، ڪارڪردگي بهتر ڪرڻ جي مهرباني جنهن کي اسان سڄي اسٽيڪ ۾ لاڳو ڪيو آهي. تنهن ڪري، مقامي تاليف کي هڪ اضافي بونس طور سمجهيو وڃي ٿو جيڪو گهربل يا ضروري طور استعمال ڪري سگهجي ٿو. حقيقت ۾، ڪوارڪس گهڻو ڪري OpenJDK تي ڀاڙي ٿو جڏهن اهو اچي ٿو ڏيهي تصويرون. ۽ ديو موڊ، ڊولپرز پاران گرمجوشي سان قبول ڪيو ويو، هاٽ اسپاٽ ۾ لاڳو ڪيل متحرڪ ڪوڊ جي عمل جي جديد صلاحيتن جي ڪري تبديلين جي تقريبن فوري جانچ کي يقيني بڻائي ٿي. اضافي طور تي، جڏهن اصلي GraalVM تصويرون ٺاهي رهيا آهن، OpenJDK ڪلاس لائبريري ۽ HotSpot صلاحيتون استعمال ڪيون وينديون آهن.
تنهن ڪري توهان کي مقامي تاليف جي ضرورت ڇو آهي جيڪڏهن هر شي اڳ ۾ ئي مڪمل طور تي بهتر آهي؟ اسان هيٺ هن سوال جو جواب ڏيڻ جي ڪوشش ڪنداسين.
اچو ته واضح سان شروع ڪريون: ريڊ هيٽ وٽ وسيع تجربو آهي JVMs، اسٽيڪ ۽ فريم ورڪ کي بهتر ڪرڻ جو پروجيڪٽ ڊولپمينٽ دوران شامل آهن:
- پليٽ فارم تي ڪلائوڊ ۾ ڪم ڪرڻ لاءِ پهريون ايپليڪيشن سرور .
- ڪمپيوٽرن تي هلائڻ لاءِ پهريون ايپليڪيشن سرور .
- هلائڻ لاءِ پهريون ايپليڪيشن سرور .
- ڊوائيسز تي هلندڙ منصوبن جو هڪ سلسلو .
اسان ڪيترن ئي سالن کان ڪلائوڊ ۾ جاوا ايپليڪيشنن کي هلائڻ ۽ وسيلن جي محدود ڊوائيسز تي (پڙهو: IoT) جي چيلنجز کي منهن ڏئي رهيا آهيون ۽ ڪارڪردگي ۽ ميموري جي اصلاح جي لحاظ کان JVM مان تمام گهڻو حاصل ڪرڻ سکيو آهي. ٻين ڪيترن ئي وانگر، اسان جاوا ايپليڪيشنن جي مقامي تاليف سان گڏ ڪم ڪري رهيا آهيون هڪ ڊگهي وقت تائين , , ۽ اڃا به ۽ اسان هن طريقي جي فائدن ۽ نقصانن کان چڱي ريت واقف آهيون (مثال طور، "هڪ ڀيرو تعمير ڪريو - ڪٿي به هلايو" جي عالمگيريت جي وچ ۾ چونڊڻ جو شڪ ۽ حقيقت اها آهي ته مرتب ٿيل ايپليڪيشنون ننڍا آهن ۽ تيز هلن ٿيون).
انهن فائدن ۽ نقصانن تي غور ڪرڻ ڇو ضروري آهي؟ ڇاڪاڻ ته ڪجهه حالتن ۾ انهن جو تناسب فيصلو ڪندڙ هوندو آهي:
- مثال طور، بي سرور/واقعي تي هلندڙ ماحول ۾ جتي واقعن جو جواب ڏيڻ لاءِ وقت حاصل ڪرڻ لاءِ (سخت يا نرم) حقيقي وقت ۾. ڊگھي زندگي جي مسلسل خدمتن جي برعڪس، هتي سرد شروع جي مدت هڪ درخواست جي جوابي وقت کي تنقيدي طور تي وڌائي ٿو. JVM اڃا تائين شروع ٿيڻ ۾ ڪافي وقت وٺندو آهي، ۽ جڏهن ته اهو ڪجهه ڪيسن ۾ خالص هارڊويئر طريقن سان گهٽجي سگهي ٿو، هڪ سيڪنڊ ۽ 5 ملي سيڪنڊن جي وچ ۾ فرق زندگي ۽ موت جي وچ ۾ فرق ٿي سگهي ٿو. ها، هتي توهان جاوا مشينن جي گرم رزرو ٺاهڻ سان گڏ راند ڪري سگهو ٿا (جيڪو، مثال طور، اسان سان ڪيو. )، پر اهو پاڻ ۾ اها ضمانت نه ٿو ڏئي ته اتي ڪافي JVMs هونديون جيڪي درخواستن تي عمل ڪرڻ لاءِ لوڊ اسڪيل جي طور تي. ۽ اقتصادي نقطي نظر کان، اهو شايد سڀ کان وڌيڪ صحيح اختيار نه آهي.
- وڌيڪ، هڪ ٻيو پاسو آهي جيڪو اڪثر پاپ اپ ٿئي ٿو: گھڻائي. ان حقيقت جي باوجود ته JVMs انهن جي صلاحيتن ۾ آپريٽنگ سسٽم جي تمام ويجهو اچي چڪا آهن، اهي اڃا تائين ڪرڻ جي قابل نه آهن جيڪي اسان لينڪس ۾ ايترو عادی آهيون - الڳ ڪرڻ وارا عمل. ان ڪري، ھڪڙي سلسلي جي ناڪامي سڄي جاوا مشين کي ھيٺ آڻي سگھي ٿي. ڪيترائي ماڻهو ڪوشش ڪندا آهن ته هن خرابيءَ کي ختم ڪرڻ لاءِ هڪ الڳ JVM وقف ڪري هر صارف جي ايپليڪيشن لاءِ ته جيئن ناڪامي جا نتيجا گهٽجي وڃن. اهو ڪافي منطقي آهي، پر اسڪيلنگ سان چڱي طرح ٺهڪي نٿو اچي.
- اضافي طور تي، بادل تي مبني ايپليڪيشنن لاء، هڪ اهم اشارو ميزبان تي خدمتن جي کثافت آهي. طريقيڪار ڏانهن منتقلي , microservices ۽ Kubernetes هر ايپليڪيشن جاوا مشينن جو تعداد وڌائي ٿو. اهو آهي، هڪ طرف، اهو سڀ ڪجهه لچڪدار ۽ قابل اعتماد فراهم ڪري ٿو، پر ساڳئي وقت خدمت جي لحاظ کان بنيادي ياداشت جو استعمال پڻ وڌائي ٿو، ۽ انهن مان ڪجهه خرچ هميشه سختي سان ضروري ناهي. جامد طور تي مرتب ڪيل ايگزيڪيوٽو فائلون هتي مختلف اصلاحي طريقن جي ڪري فائدو وٺن ٿيون، جهڙوڪ گهٽ-سطح ڊيڊ ڪوڊ ختم ڪرڻ، جڏهن حتمي تصوير ۾ صرف فريم ورڪ جا اهي حصا شامل آهن (بشمول خود JDK) جيڪا خدمت اصل ۾ استعمال ڪري ٿي. تنهن ڪري، Quarkus جي مقامي تاليف سيڪيورٽي کي سمجھوتو ڪرڻ کان سواء ميزبان تي خدمت جي مثالن کي گھڻائي سان رکڻ ۾ مدد ڪري ٿي.
دراصل، مٿيون دليل اڳي ئي ڪافي آهن ته جيئن ڪوارڪس پروجيڪٽ جي شرڪت ڪندڙن جي نقطه نظر کان اصلي تاليف جي جواز کي سمجهڻ لاء. بهرحال، اتي هڪ ٻيو، غير ٽيڪنيڪل، پر پڻ اهم سبب آهي: تازن سالن ۾، ڪيترن ئي پروگرامر ۽ ترقياتي ڪمپنين جاوا کي نئين پروگرامنگ ٻولين جي حق ۾ ڇڏي ڏنو آهي، يقين رکون ٿا ته جاوا، ان جي JVMs، اسٽيڪ ۽ فريم ورڪ سان گڏ، پڻ ٿي چڪو آهي. ياداشت- بکيو، تمام سست، وغيره.
بهرحال، ڪنهن به مسئلي کي حل ڪرڻ لاء ساڳيو اوزار استعمال ڪرڻ جي عادت آهي . ڪڏهن ڪڏهن اهو بهتر آهي ته هڪ قدم پوئتي وٺو ۽ ٻيو ڪجهه ڳوليو. ۽ جيڪڏهن ڪوارڪس ماڻهن کي رڪجي ۽ سوچڻ تي مجبور ڪري، ته پوءِ اهو سڄي جاوا ماحولياتي نظام لاءِ سٺو آهي. Quarkus هڪ جديد نظارو پيش ڪري ٿو ته ڪيئن وڌيڪ ڪارائتو ايپليڪيشنون ٺاهيون وڃن، جاوا کي نئين ايپليڪيشن آرڪيٽيڪچرز جهڙوڪ سرور کان سواءِ وڌيڪ لاڳاپيل بڻائي ٿي. ان کان علاوه، ان جي توسيع جي ڪري، Quarkus کي اميد آهي ته جاوا ايڪسٽينشن جو هڪ مڪمل ايڪو سسٽم هوندو، خاص طور تي فريم ورڪ جي تعداد ۾ اضافو ٿيندو جيڪو باڪس کان ٻاهر ايپليڪيشنن ۾ مقامي تاليف کي سپورٽ ڪندو.
جو ذريعو: www.habr.com