په Quarkus کې اصلي تالیف - ولې دا مهم دی

سلام و ټولو ته! دا زموږ د کوارکس په لړۍ کې دوهم پوسټ دی - نن به موږ د اصلي تالیف په اړه وغږیږو.

کوارکوس د جاوا سټیک لپاره مناسب دی کوبنیټس. پداسې حال کې چې دلته واقعیا د کولو لپاره ډیر څه شتون لري ، موږ په ډیری اړخونو کې ډیر ښه کار کړی دی ، پشمول د JVM او یو شمیر چوکاټونو اصلاح کول. د Quarkus یو له ځانګړتیاوو څخه چې د پراختیا کونکو څخه یې ډیر لیوالتیا راجلب کړې ده د یو ځانګړي عملیاتي سیسټم لپاره د جاوا کوډ د اجرا وړ فایلونو ته د بدلولو لپاره د هغې جامع، بې سیمه طریقه ده (د "اصلي تالیف" په نامه یادېږي)، د C او C++ په څیر، چیرته چې دا ډول تالیف معمولا د جوړونې، ازموینې، او پلي کولو د دورې په پای کې واقع کیږي.

او پداسې حال کې چې اصلي تالیف مهم دی، لکه څنګه چې موږ به لاندې وښیو، دا باید په یاد ولرئ چې کوارکوس په خورا عام جاوا ماشین، OpenJDK Hotspot کې واقعیا ښه چلوي، د فعالیت ښه کولو څخه مننه چې موږ یې په ټول سټیک کې پلي کړي. نو ځکه، اصلي تالیف باید د اضافي بونس په توګه وګڼل شي چې د مطلوب یا اړتیا په توګه کارول کیدی شي. په حقیقت کې، Quarkus په پراخه کچه په OpenJDK باندې تکیه کوي کله چې د اصلي انځورونو خبره راځي. او د dev حالت، د پراختیا کونکو لخوا په تودوخې سره منل شوی، په هټ سپاټ کې پلي شوي د متحرک کوډ اجرا کولو پرمختللي وړتیاو له امله د بدلونونو نږدې سمدستي ازموینه تضمینوي. سربیره پردې ، کله چې اصلي GraalVM عکسونه رامینځته کوي ، د OpenJDK ټولګي کتابتون او د HotSpot وړتیاوې کارول کیږي.

نو ولې تاسو اصلي تالیف ته اړتیا لرئ که هرڅه دمخه په بشپړ ډول اصلاح شوي وي؟ موږ به هڅه وکړو چې لاندې دې پوښتنې ته ځواب ووایو.

راځئ چې د واضح سره پیل وکړو: Red Hat د پروژې پراختیا په جریان کې د JVMs، سټیکونو او چوکاټونو اصلاح کولو پراخه تجربه لري JBossپه شمول:

• په پلیټ فارم کې په بادل کې د کار کولو لپاره لومړی غوښتنلیک سرور د Red Hat OpenShift.
• په کمپیوټر کې د چلولو لپاره لومړی غوښتنلیک سرور پی سی ولګوه.
• د لومړي غوښتنلیک سرور چې چلول کیږي راسبری پییر.
• یو لړ پروژې چې په وسایلو چلیږي Android.

موږ د ډیرو کلونو راهیسې په بادل کې د جاوا غوښتنلیکونو چلولو ننګونو سره معامله کوو او د سرچینو محدود وسیلو (لوستل: IoT) کې او د فعالیت او حافظې اصلاح کولو شرایطو کې د JVM څخه خورا ډیر ترلاسه کول زده کړل. د ډیری نورو په څیر، موږ د اوږدې مودې لپاره د جاوا غوښتنلیکونو اصلي تالیف سره کار کوو G.C.J., ایوین, Excelsior JET او حتي دلیک او موږ د دې تګلارې له ګټو او زیانونو څخه ښه خبر یو (د مثال په توګه، د "یوځل جوړ کړئ - هرچیرې چل کړئ" د نړیوالتوب تر مینځ د انتخاب کولو ستونزه او دا حقیقت چې تالیف شوي غوښتنلیکونه کوچني دي او ګړندي چلیږي).

ولې دا مهمه ده چې دا ګټې او زیانونه په پام کې ونیول شي؟ ځکه چې په ځینو حاالتو کې د دوی تناسب پریکړه کونکی کیږي:

• د مثال په توګه، د سرور پرته / پیښې پرمخ وړونکي چاپیریال کې چیرته خدمتونه باید په ساده ډول پیل شي په ریښتیني وخت کې (سخت یا نرم) پیښو ته د ځواب ویلو لپاره وخت ولرئ. د اوږدمهاله دوامداره خدماتو برعکس، دلته د سړې پیل موده په جدي توګه د غوښتنې لپاره د غبرګون وخت زیاتوي. JVM لاهم د پیل کولو لپاره د پام وړ وخت نیسي ، او پداسې حال کې چې دا په ځینو مواردو کې د خالص هارډویر میتودونو لخوا کم کیدی شي ، د یوې ثانیې او 5 ملی ثانیو ترمینځ توپیر د ژوند او مرګ ترمینځ توپیر کیدی شي. هو ، دلته تاسو کولی شئ د جاوا ماشینونو د ګرمې زیرمې رامینځته کولو سره شاوخوا لوبه وکړئ (کوم چې ، د مثال په توګه ، موږ ورسره وکړل Knative ته OpenWhisk پورټ کول)، مګر دا پخپله تضمین نه کوي چې د بار اندازې په توګه د غوښتنو پروسس کولو لپاره به کافي JVMs شتون ولري. او د اقتصادي نظر څخه، دا شاید ترټولو سم انتخاب نه وي.
• برسېره پردې، یو بل اړخ شتون لري چې ډیری وختونه راڅرګندیږي: څو اړخیزه. د دې حقیقت سره سره چې JVMs په خپلو وړتیاو کې عملیاتي سیسټمونو ته خورا نږدې شوي ، دوی لاهم د دې وړتیا نلري چې هغه څه وکړي چې موږ یې په لینکس کې خورا عادی یو - جلا کولو پروسې. له همدې امله ، د یوې تار ناکامي کولی شي ټول جاوا ماشین لاندې راولي. ډیری خلک هڅه کوي چې د هر کارونکي غوښتنلیک لپاره جلا JVM وقف کولو سره د دې نیمګړتیا شاوخوا ترلاسه کړي ترڅو د ناکامۍ پایلې کمې کړي. دا خورا منطقي دی، مګر د پیمانه کولو سره سم نه دی.
• برسېره پردې، د بادل پر بنسټ غوښتنلیکونو لپاره، یو مهم شاخص په کوربه کې د خدماتو کثافت دی. میتودولوژي ته لیږد د غوښتنلیک 12 عوامل, microservices او Kubernetes په هر غوښتنلیک کې د جاوا ماشینونو شمیر زیاتوي. دا، له یوې خوا، دا ټول لچک او اعتبار چمتو کوي، مګر په ورته وخت کې د خدماتو په شرایطو کې د بیس حافظې مصرف هم زیاتیږي، او ځینې دا لګښتونه تل په کلکه اړین ندي. په ثابت ډول ترتیب شوي اجرایوي فایلونه دلته د مختلف اصلاح کولو تخنیکونو له امله ګټه پورته کوي ، لکه د ټیټ کچې مړ کوډ له مینځه وړل ، کله چې وروستی عکس یوازې د چوکاټ هغه برخې شاملې وي (په شمول پخپله د JDK په شمول) چې خدمت واقعیا کاروي. له همدې امله، د Quarkus اصلي تالیف د امنیت سره موافقت پرته په کوربه کې د خدماتو مثالونه په کثافاتو کې ځای په ځای کولو کې مرسته کوي.

په حقیقت کې، پورتني دلیلونه د کوارکس پروژې د ګډونوالو له نظره د اصلي تالیف د توجیه کولو لپاره لا دمخه کافي دي. په هرصورت، یو بل، غیر تخنیکي، مګر مهم دلیل هم شتون لري: په وروستیو کلونو کې، ډیری پروګرامرانو او پراختیایی شرکتونو د نوي پروګرامینګ ژبو په ګټه جاوا پریښوده، په دې باور چې جاوا، د دې JVMs، سټیکونو او چوکاټونو سره ډیر شوی دی. حافظه - لوږه، ډیر ورو، او داسې نور

په هرصورت، د هرې ستونزې د حل لپاره د ورته وسیلې کارولو عادت دی دا تل سم نه وي. ځینې ​​​​وختونه دا غوره ده چې یو ګام بیرته واخلئ او د بل څه په لټه کې شئ. او که Quarkus خلک ودروي او فکر وکړي، نو دا د ټول جاوا ایکوسیستم لپاره ښه دی. Quarkus د یو نوښتګر لید استازیتوب کوي چې څنګه د ډیرو اغیزمنو غوښتنلیکونو رامینځته کولو لپاره، جاوا د نوي غوښتنلیک جوړښتونو لکه سرور بې برخې کولو سره ډیر اړونده کوي. برسېره پردې، د دې پراخوالي له امله، Quarkus به هیله مند وي چې د جاوا توسیع ټول اکوسیستم ولري، د پام وړ د چوکاټونو شمیر زیات کړي چې د بکس څخه بهر غوښتنلیکونو کې د اصلي تالیف ملاتړ کوي.

سرچینه: www.habr.com