اس سال ہم کنٹینر تھیمز کو سنجیدگی سے تیار کرنے کا ارادہ رکھتے ہیں، и . ان عنوانات کا منطقی تسلسل Quarkus کے فریم ورک کے بارے میں ایک کہانی ہو گی، پہلے ہی Habré پر. آج کا مضمون "subatomic superfast Java" کے ڈیزائن کے بارے میں کم اور اس وعدے کے بارے میں زیادہ ہے جو Quarkus انٹرپرائز کے لیے لاتا ہے۔
جاوا اور جے وی ایم اب بھی انتہائی مقبول ہیں، لیکن جب سرور لیس ٹیکنالوجیز اور کلاؤڈ مقامی مائیکرو سروسز کے ساتھ کام کرتے ہیں، تو جاوا اور دیگر جے وی ایم زبانیں کم اور کم استعمال ہوتی ہیں کیونکہ وہ بہت زیادہ میموری کی جگہ لیتی ہیں اور لوڈ کرنے میں بہت سست ہوتی ہیں، قلیل المدت کنٹینرز کے ساتھ استعمال کے لیے ناقص موزوں۔ خوش قسمتی سے، یہ صورتحال اب Quarkus کی بدولت بدلنا شروع ہو رہی ہے۔
سپر فاسٹ ذیلی ایٹمی جاوا ایک نئی سطح پر پہنچ گیا ہے!
42 ریلیز، 8 ماہ کا کمیونٹی ورک اور 177 حیرت انگیز ڈویلپرز - ان سب کا نتیجہ نومبر 2019 میں ریلیز ہوا ، ایک ریلیز جو پروجیکٹ کی ترقی میں ایک اہم سنگ میل کی نشاندہی کرتی ہے اور بہت ساری عمدہ خصوصیات اور صلاحیتیں پیش کرتی ہے (آپ ان کے بارے میں مزید پڑھ سکتے ہیں ).
آج ہم آپ کو دکھائیں گے کہ کس طرح Quarkus لازمی اور رد عمل والے پروگرامنگ ماڈلز کو ایک واحد ری ایکٹو کور میں جوڑتا ہے۔ ہم ایک مختصر تاریخ کے ساتھ شروع کریں گے اور پھر اس کے بارے میں تفصیل سے جائیں گے کہ Quarkus کا ری ایکٹو کور ڈوئلزم کیا ہے اور کیسے -ڈیولپرز ان فوائد سے فائدہ اٹھا سکتے ہیں۔
, и -فنکشنز - یہ سب کچھ ہے، جیسا کہ وہ کہتے ہیں، آج عروج پر ہے۔ حال ہی میں، کلاؤڈ سینٹرک آرکیٹیکچرز کی تخلیق بہت آسان اور زیادہ قابل رسائی ہو گئی ہے، لیکن مسائل باقی ہیں - خاص طور پر جاوا ڈویلپرز کے لیے۔ مثال کے طور پر، سرور لیس فنکشنز اور مائیکرو سروسز کی صورت میں، آغاز کے وقت کو کم کرنے، یادداشت کی کھپت کو کم کرنے، اور پھر بھی ان کی نشوونما کو زیادہ آسان اور پرلطف بنانے کی اشد ضرورت ہے۔ جاوا نے حالیہ برسوں میں کئی اصلاحات کی ہیں، جیسے کنٹینرز کے لیے بہتر ergonomics فعالیت وغیرہ۔ تاہم، جاوا کو کنٹینر میں صحیح طریقے سے کام کرنا اب بھی مشکل ہے۔ لہذا ہم جاوا کی کچھ موروثی پیچیدگیوں کو دیکھ کر شروع کریں گے، جو کنٹینر پر مبنی جاوا ایپلی کیشنز تیار کرتے وقت خاص طور پر شدید ہوتی ہیں۔
پہلے تاریخ پر نظر ڈالتے ہیں۔
نہریں اور کنٹینرز
ورژن 8u131 سے شروع کرتے ہوئے، جاوا نے ergonomics کی فعالیت میں بہتری کی وجہ سے کم و بیش کنٹینرز کو سپورٹ کرنا شروع کیا۔ خاص طور پر، JVM اب جانتا ہے کہ اس پر کتنے پروسیسر کور چل رہے ہیں اور اس کے مطابق تھریڈ پولز کو کنفیگر کر سکتے ہیں — عام طور پر فورک/جوائن پولز —۔ یقینا، یہ بہت اچھا ہے، لیکن ہم کہتے ہیں کہ ہمارے پاس ایک روایتی ویب ایپلی کیشن ہے جو HTTP سرولیٹس کا استعمال کرتی ہے اور Tomcat، Jetty وغیرہ میں چلتی ہے۔ نتیجے کے طور پر، یہ ایپلیکیشن ہر درخواست کو ایک الگ تھریڈ دے گی اور I/O آپریشنز کا انتظار کرتے ہوئے اس تھریڈ کو بلاک کرنے کی اجازت دے گی، مثال کے طور پر، ڈیٹا بیس، فائلز یا دیگر سروسز تک رسائی کے وقت۔ یعنی، اس طرح کی درخواست کا سائز دستیاب کور کی تعداد پر منحصر نہیں ہے، بلکہ بیک وقت درخواستوں کی تعداد پر منحصر ہے۔ اس کے علاوہ، اس کا مطلب یہ ہے کہ کور کی تعداد پر کوبرنیٹس میں کوٹہ یا حدیں یہاں زیادہ مددگار نہیں ہوں گی، اور معاملہ بالآخر گلا گھونٹنے پر ختم ہو جائے گا۔
یادداشت کی تھکن
دھاگے یاداشت ہیں۔ اور انٹرا کنٹینر میموری کی حدود کسی بھی طرح سے علاج نہیں ہیں۔ بس ایپلی کیشنز اور تھریڈز کی تعداد بڑھانا شروع کر دیں، اور جلد یا بدیر آپ کو سوئچنگ فریکوئنسی میں شدید اضافے کا سامنا کرنا پڑے گا اور اس کے نتیجے میں، کارکردگی میں کمی آئے گی۔ اس کے علاوہ، اگر آپ کی ایپلیکیشن روایتی مائیکرو سروس فریم ورک استعمال کرتی ہے، یا ڈیٹا بیس سے منسلک ہوتی ہے، یا کیچنگ کا استعمال کرتی ہے، یا بصورت دیگر میموری استعمال کرتی ہے، تو آپ کو ظاہر ہے کہ آپ کو ایک ایسے ٹول کی ضرورت ہے جو آپ کو JVM کے اندر دیکھنے کی اجازت دے اور یہ دیکھ سکے کہ یہ میموری کو مارے بغیر کیسے منظم کرتا ہے۔ خود JVM (مثال کے طور پر، XX:+UseCGroupMemoryLimitForHeap)۔ اور اگرچہ، Java 9 کے بعد سے، JVM نے cgroups کو قبول کرنا اور اس کے مطابق ڈھالنا سیکھ لیا ہے، میموری کو محفوظ کرنا اور ان کا انتظام کرنا ایک پیچیدہ معاملہ ہے۔
کوٹہ اور حدود
جاوا 11 نے سی پی یو کوٹہ کے لیے سپورٹ متعارف کرایا (جیسے PreferContainerQuotaForCPUCount)۔ Kubernetes حدود اور کوٹے کے لیے بھی تعاون پیش کرتا ہے۔ ہاں، یہ سب سمجھ میں آتا ہے، لیکن اگر ایپلیکیشن دوبارہ مختص کردہ کوٹہ سے تجاوز کر جاتی ہے، تو ہم دوبارہ سائز کے ساتھ ختم ہو جاتے ہیں - جیسا کہ روایتی جاوا ایپلیکیشنز کا معاملہ ہے - جس کا تعین کور کی تعداد اور ہر ایک کے لیے علیحدہ دھاگے کے مختص کے ساتھ ہوتا ہے۔ درخواست کریں، پھر اس سب میں کوئی معنی نہیں ہے۔
اس کے علاوہ، اگر آپ Kubernetes کے تحت پلیٹ فارم کے کوٹہ اور حدود یا اسکیل آؤٹ فنکشنز استعمال کرتے ہیں، تو مسئلہ بھی خود حل نہیں ہوتا ہے۔ ہم صرف اصل مسئلہ کو حل کرنے پر زیادہ وسائل صرف کرتے ہیں یا زیادہ خرچ کرتے ہیں۔ اور اگر یہ عوامی عوامی کلاؤڈ میں زیادہ بوجھ والا نظام ہے، تو ہم یقینی طور پر اپنی ضرورت سے زیادہ وسائل استعمال کرتے ہیں۔
اور اس سب کا کیا کریں؟
سیدھے الفاظ میں، غیر مطابقت پذیر اور غیر مسدود I/O لائبریریوں اور نیٹی جیسے فریم ورک کا استعمال کریں۔ یا اکا. وہ اپنی رد عمل کی نوعیت کی وجہ سے کنٹینرز میں کام کرنے کے لیے زیادہ موزوں ہیں۔ I/O کو بلاک نہ کرنے کی بدولت، ایک ہی تھریڈ بیک وقت متعدد درخواستوں پر کارروائی کر سکتا ہے۔ جب کہ ایک درخواست I/O کے نتائج کا انتظار کر رہی ہے، دھاگے پر کارروائی جاری ہے اور دوسری درخواست کے ذریعے اسے سنبھال لیا جاتا ہے۔ اور جب آخر کار I/O کے نتائج آتے ہیں، پہلی درخواست پر کارروائی جاری رہتی ہے۔ ایک ہی تھریڈ میں درخواستوں کی انٹرلیویڈ پروسیسنگ کے ذریعے، آپ تھریڈز کی کل تعداد کو کم کر سکتے ہیں اور درخواستوں پر کارروائی کے لیے وسائل کی کھپت کو کم کر سکتے ہیں۔
غیر مسدود I/O کے ساتھ، کور کی تعداد ایک کلیدی پیرامیٹر بن جاتی ہے کیونکہ یہ I/O تھریڈز کی تعداد کا تعین کرتا ہے جو متوازی طور پر چلائے جا سکتے ہیں۔ صحیح طریقے سے استعمال ہونے پر، یہ آپ کو کور کے درمیان بوجھ کو مؤثر طریقے سے تقسیم کرنے اور کم وسائل کے ساتھ زیادہ کام کے بوجھ کو سنبھالنے کی اجازت دیتا ہے۔
یہ سب کیسے؟
نہیں، کچھ اور ہے۔ ری ایکٹیو پروگرامنگ وسائل کے بہتر استعمال میں مدد کرتی ہے، بلکہ قیمت پر بھی آتی ہے۔ خاص طور پر، کوڈ کو نان بلاکنگ کے اصولوں کے مطابق دوبارہ لکھنا ہوگا اور I/O تھریڈز کو بلاک کرنے سے گریز کرنا ہوگا۔ اور یہ ترقی اور عمل درآمد کا بالکل مختلف ماڈل ہے۔ اور اگرچہ یہاں بہت ساری مفید لائبریریاں ہیں، لیکن یہ اب بھی سوچنے کے معمول کے انداز میں ایک بنیادی تبدیلی ہے۔
سب سے پہلے، آپ کو کوڈ لکھنے کا طریقہ سیکھنے کی ضرورت ہے جو متضاد طور پر چلتا ہے۔ ایک بار جب آپ نان بلاکنگ I/O استعمال کرنا شروع کر دیتے ہیں، تو آپ کو واضح طور پر یہ بتانا ہوگا کہ جب کسی درخواست کا جواب موصول ہوتا ہے تو کیا ہونا چاہیے۔ بس مسدود کرنا اور انتظار کرنا اب کام نہیں کرے گا۔ اس کے بجائے، آپ کال بیکس پاس کر سکتے ہیں، ری ایکٹو پروگرامنگ یا تسلسل استعمال کر سکتے ہیں۔ لیکن یہ سب کچھ نہیں ہے: نان بلاکنگ I/O استعمال کرنے کے لیے، آپ کو نان بلاکنگ سرورز اور کلائنٹس دونوں کی ضرورت ہے، ترجیحا ہر جگہ۔ HTTP کے معاملے میں، سب کچھ آسان ہے، لیکن ڈیٹا بیس، فائل سسٹم، اور بہت کچھ بھی ہیں.
اور اگرچہ مکمل اختتام سے آخر تک رد عمل کارکردگی کو زیادہ سے زیادہ کرتا ہے، لیکن اس طرح کی تبدیلی عملی طور پر پیٹ کے لیے مشکل ہو سکتی ہے۔ لہذا، رد عمل اور لازمی کوڈ کو یکجا کرنے کی صلاحیت ایک شرط بن جاتی ہے تاکہ:
- سافٹ ویئر سسٹم کے سب سے زیادہ بھرے ہوئے علاقوں میں وسائل کو مؤثر طریقے سے استعمال کریں۔
- اس کے باقی حصوں میں آسان اسٹائل کوڈ استعمال کریں۔
کوارکس کا تعارف
دراصل، یہ Quarkus کا جوہر ہے - ایک ہی رن ٹائم ماحول میں رد عمل اور لازمی ماڈلز کو یکجا کرنا۔
Quarkus Vert.x اور Netty پر مبنی ہے، جس میں ڈیولپر کی مدد کے لیے سب سے اوپر ری ایکٹو فریم ورک اور ایکسٹینشنز ہیں۔ Quarkus کو نہ صرف HTTP مائیکرو سروسز بنانے کے لیے ڈیزائن کیا گیا ہے بلکہ ایونٹ سے چلنے والے فن تعمیرات بھی۔ اس کی رد عمل کی وجہ سے، یہ پیغام رسانی کے نظام (Apache Kafka، AMQP، وغیرہ) کے ساتھ بہت مؤثر طریقے سے کام کرتا ہے۔
چال یہ ہے کہ ایک ہی ری ایکٹیو انجن کو لازمی اور ری ایکٹیو کوڈ دونوں کے لیے کیسے استعمال کیا جائے۔
Quarkus یہ شاندار طریقے سے کرتا ہے۔ لازمی اور رد عمل کے درمیان انتخاب واضح ہے - دونوں کے لیے ایک رد عمل کا دانا استعمال کریں۔ جس چیز سے یہ واقعی مدد کرتا ہے وہ ہے تیز، نان بلاکنگ کوڈ جو ایونٹ لوپ تھریڈ عرف IO تھریڈ سے گزرنے والی تقریباً ہر چیز کو ہینڈل کرتا ہے۔ لیکن اگر آپ کے پاس کلاسک REST یا کلائنٹ سائیڈ ایپلی کیشنز ہیں، تو Quarkus کے پاس ایک لازمی پروگرامنگ ماڈل تیار ہے۔ مثال کے طور پر، کوارکس میں ایچ ٹی ٹی پی سپورٹ ایک نان بلاکنگ اور ری ایکٹیو انجن کے استعمال پر مبنی ہے (Eclipse Vert.x اور Netty)۔ آپ کی درخواست کے ذریعے موصول ہونے والی تمام HTTP درخواستیں پہلے ایونٹ لوپ (IO تھریڈ) سے گزرتی ہیں اور پھر کوڈ کے اس حصے میں بھیجی جاتی ہیں جو درخواستوں کا انتظام کرتا ہے۔ منزل پر منحصر ہے، درخواست کے انتظامی کوڈ کو ایک الگ تھریڈ (نام نہاد ورکر تھریڈ، سرولیٹس اور جیکس-RS کے معاملے میں استعمال کیا جاتا ہے) کے اندر کال کیا جا سکتا ہے یا سورس I/O تھریڈ (رد عمل کا راستہ) استعمال کیا جا سکتا ہے۔
پیغام رسانی کے نظام کے کنیکٹر Vert.x انجن کے اوپر چلنے والے نان بلاکنگ کلائنٹس کا استعمال کرتے ہیں۔ لہذا، آپ میسجنگ مڈل ویئر سسٹمز سے مؤثر طریقے سے پیغامات بھیج سکتے ہیں، وصول کر سکتے ہیں اور اس پر کارروائی کر سکتے ہیں۔
سائٹ Quarkus کے ساتھ شروع کرنے میں آپ کی مدد کے لیے یہاں کچھ اچھے سبق ہیں:
ہم نے آپ کو صرف ایک براؤزر میں رد عمل والے پروگرامنگ کے مختلف پہلوؤں کو سکھانے کے لیے آن لائن ہینڈ آن ٹیوٹوریلز بھی بنائے ہیں، کسی IDE کی ضرورت نہیں ہے اور نہ ہی کمپیوٹر کی ضرورت ہے۔ آپ یہ اسباق تلاش کر سکتے ہیں۔ .
کارآمد وسائل
- کوارکس پروجیکٹ کی ویب سائٹ -
- GitHub پر Quarkus پروجیکٹ -
- کوارکس پروجیکٹ ٹویٹر -
- کوارکس پروجیکٹ چیٹ -
- کوارکس پروجیکٹ فورمز - !forum/quarkus-dev
موضوع سے واقفیت حاصل کرنے کے لیے Quarkus پر 10 ویڈیو اسباق
جیسا کہ وہ ویب سائٹ پر کہتے ہیں۔ , ہے - -اورینٹڈ جاوا اسٹیک، جو GraalVM اور OpenJDK HotSpot کے لیے تیار کیا گیا ہے اور بہترین جاوا لائبریریوں اور معیارات سے اسمبل کیا گیا ہے۔
موضوع کو سمجھنے میں آپ کی مدد کے لیے، ہم نے 10 ویڈیو ٹیوٹوریلز کا انتخاب کیا ہے جو Quarkus کے مختلف پہلوؤں اور اس کے استعمال کی مثالوں کا احاطہ کرتے ہیں:
1. Quarkus کا تعارف: Kubernetes کے لیے اگلی نسل کا جاوا فریم ورک
تھامس کیوورنسٹروم اور جیسن گرین کے ذریعہ
Quarkus پروجیکٹ کا ہدف Kubernetes اور سرور لیس ماحول کے لیے جاوا پلیٹ فارم بنانا ہے، اور ایک ہی رن ٹائم ماحول میں رد عمل اور لازمی پروگرامنگ ماڈلز کو یکجا کرنا ہے تاکہ تقسیم شدہ ایپلیکیشن آرکیٹیکچرز کی ایک وسیع رینج کے ساتھ کام کرتے وقت ڈیولپرز لچکدار طریقے سے اپنے نقطہ نظر کو تبدیل کر سکیں۔ ذیل میں تعارفی لیکچر میں مزید معلومات حاصل کریں۔
2. کوارکس: سپر فاسٹ سباٹومک جاوا
بذریعہ: برر سٹر
DevNation Live کا یہ ویڈیو ٹیوٹوریل یہ بتاتا ہے کہ Quarkus کو انٹرپرائز جاوا ایپلیکیشنز، APIs، مائیکرو سروسز، اور سرور لیس فنکشنز کو Kubernetes/OpenShift ماحول میں بہتر بنانے کے لیے کس طرح استعمال کیا جاتا ہے، جس سے وہ بہت چھوٹا، تیز اور زیادہ قابل توسیع بنتا ہے۔
3. Quarkus اور GraalVM: ہائیبرنیٹ کو تیز رفتار سے تیز کرنا اور اسے ذیلی ایٹمی سائز تک سکڑنا
مصنف: Sanne Grinovero
پریزنٹیشن سے آپ سیکھیں گے کہ Quarkus کیسے وجود میں آیا، یہ کیسے کام کرتا ہے، اور یہ آپ کو پیچیدہ لائبریریاں بنانے کی اجازت دیتا ہے، جیسے Hibernate ORM، مقامی GraalVM تصاویر کے ساتھ ہم آہنگ۔
4. بغیر سرور ایپلی کیشنز تیار کرنا سیکھیں۔
مصنف: مارٹن لوتھر
نیچے دی گئی ویڈیو میں دکھایا گیا ہے کہ Quarkus کا استعمال کرتے ہوئے ایک سادہ جاوا ایپلی کیشن کیسے بنایا جائے اور اسے Knative پر سرور لیس ایپلی کیشن کے طور پر تعینات کیا جائے۔
5. Quarkus: کوڈنگ کا مزہ لیں۔
مصنف: ایڈسن یاناگا
اپنا پہلا Quarkus پروجیکٹ بنانے کے لیے ایک ویڈیو گائیڈ، جو آپ کو یہ سمجھنے کی اجازت دیتا ہے کہ Quarkus ڈویلپرز کا دل کیوں جیت رہا ہے۔
6. جاوا اور کنٹینرز - ان کا مستقبل ایک ساتھ کیا ہوگا۔
مارک لٹل کے ذریعہ پوسٹ کیا گیا۔
یہ پیشکش جاوا کی تاریخ کو متعارف کراتی ہے اور بتاتی ہے کہ کوارکس جاوا کا مستقبل کیوں ہے۔
7. کوارکس: سپر فاسٹ سباٹومک جاوا
مصنف: Dimitris Andreadis
Quarkus کے ان فوائد کا ایک جائزہ جنہیں ڈویلپرز کی جانب سے تسلیم کیا گیا ہے: سادگی، انتہائی تیز رفتار، بہترین لائبریریاں اور معیارات۔
8. کوارکس اور ذیلی ایٹمی راکٹ سسٹم
مصنف: کلیمنٹ ایسکوفیر
GraalVM کے ساتھ انضمام کے ذریعے، Quarkus انتہائی تیز رفتار ترقی کا تجربہ اور ذیلی ایٹمی رن ٹائم ماحول فراہم کرتا ہے۔ مصنف Quarkus کے رد عمل والے پہلو کے بارے میں بات کرتا ہے اور اسے رد عمل اور اسٹریمنگ ایپلی کیشنز بنانے کے لیے کیسے استعمال کیا جائے۔
9. ایکلیپس مائیکرو پروفائل میں کوارکس اور تیز رفتار ایپلی کیشن ڈویلپمنٹ
مصنف: جان کلنگن
Eclipse MicroProfile اور Quarkus کو ملا کر، ڈویلپر مکمل خصوصیات والی کنٹینرائزڈ مائیکرو پروفائل ایپلی کیشنز بنا سکتے ہیں جو دسیوں ملی سیکنڈ میں لانچ ہوتی ہیں۔ ویڈیو میں تفصیل سے بتایا گیا ہے کہ Kubernetes پلیٹ فارم پر تعیناتی کے لیے کنٹینرائزڈ مائیکرو پروفائل ایپلیکیشن کو کوڈ کرنے کا طریقہ۔
10. جاوا، "ٹربو" ورژن
مصنف: مارکس بیئل
مصنف یہ بتاتا ہے کہ Quarkus کو انتہائی چھوٹے، تیز رفتار جاوا کنٹینرز بنانے کے لیے کیسے استعمال کیا جائے جو حقیقی کامیابیوں کو قابل بناتا ہے، خاص طور پر بغیر سرور کے ماحول میں۔
ماخذ: www.habr.com
