JavaRush /جاوا بلاگ /Random-UR /مائیکرو سروس فن تعمیر: فوائد اور نقصانات

مائیکرو سروس فن تعمیر: فوائد اور نقصانات

گروپ میں شائع ہوا۔
مائیکرو سروسز ایک بڑی ایپلیکیشن کو ڈھیلے جوڑے ہوئے ماڈیولز میں توڑنے کا ایک طریقہ ہے جو ایک سادہ API کے ذریعے ایک دوسرے کے ساتھ بات چیت کرتے ہیں۔
مائیکرو سروس فن تعمیر: فوائد اور نقصانات - 1
حال ہی میں، صرف گونگے لوگوں نے مائیکرو سروسز کے بارے میں بات نہیں کی ہے۔ یہ زیادہ سے زیادہ مقبول ہوتا جا رہا ہے۔ ماڈیولر آرکیٹیکچرل سٹائل خاص طور پر کلاؤڈ بیسڈ ماحول کے لیے موزوں لگتا ہے اور مقبولیت میں بڑھ رہا ہے۔ اس سے پہلے کہ ہم تفصیلات میں جائیں، آئیے ہر چیز کا برڈز آئی ویو لیتے ہیں ۔ لہذا: مائیکرو سروسز ایک بڑے پروجیکٹ کو چھوٹے، آزاد اور ڈھیلے طریقے سے جوڑے ہوئے ماڈیولز میں توڑنے کا ایک طریقہ ہے۔ آزاد ماڈیول واضح طور پر متعین اور مجرد کاموں کے لیے ذمہ دار ہیں اور ایک سادہ اور قابل رسائی API کے ذریعے ایک دوسرے کے ساتھ بات چیت کرتے ہیں۔ دوسرے لفظوں میں، مائیکرو سروسز پیچیدہ، زیادہ تر ویب ایپلیکیشنز کو ڈیزائن کرنے کے لیے محض ایک مختلف آرکیٹیکچرل اسٹائل ہیں۔ لیکن موجودہ تعمیراتی حل جیسے SOA (سروس پر مبنی فن تعمیر) کے بارے میں کیا برا ہے؟ SOA کا استعمال کرتے ہوئے لکھے گئے زیادہ تر جدید انٹرپرائز حل کافی اچھے طریقے سے کام کرتے نظر آتے ہیں۔ صنعت کو ان دنوں جن چیلنجز کا سامنا ہے ان میں سے کچھ کے بارے میں بات کرنے کا یہ بہترین وقت ہو سکتا ہے... آئیے ایک سادہ سی مثال کے ساتھ شروعات کرتے ہیں۔ ہم کہتے ہیں کہ مجھے جاوا میں لکھی ہوئی کلاسک ایپلیکیشن چلانے کی ضرورت ہے۔ پہلے میں یوزر انٹرفیس تیار کروں گا، پھر بزنس لاجک پرت، جس میں کئی اجزاء ہوں گے جو UI کے ساتھ تعامل کریں گے، اور آخر میں ڈیٹا بیس کی تہہ، جو مستقل ڈیٹا بیس تک قابل رسائی ہوگی۔ اب اس حقیقت کے مطابق کہ میں ایپلی کیشن چلانا چاہتا ہوں، میں ایک WAR/EAR/JAR بناؤں گا اور اسے سرور (جیسے JBoss، Tomcat یا WebLogic) پر ماؤنٹ کروں گا۔ چونکہ یہ سب ایک میں ہوتا ہے، مجھے ایک یک سنگی ایپلی کیشن ملتی ہے، جس کا مطلب ہے کہ تمام اجزاء ایک جگہ پر ہیں... تصویر میں مثال:
مائیکرو سروس فن تعمیر: فوائد اور نقصانات - 2
زیادہ تر امکان ہے کہ آپ اس طریقہ کار سے پہلے ہی واقف ہیں اور اسے استعمال کر چکے ہیں، لیکن خیال یہ ہے کہ اس مثال کو یہ بتانے کے لیے استعمال کیا جائے کہ اس تعمیراتی حل کو استعمال کرتے ہوئے ڈویلپرز کو کن چیلنجوں کا سامنا کرنا پڑے گا۔ یک سنگی ایپلی کیشن: چیلنجز چیلنجز
  • جیسے جیسے ایپلیکیشن بڑھتی ہے، اسی طرح لکھے گئے کوڈ کی مقدار بھی بڑھتی ہے، جو ہر بار جب آپ کو اسے کھولنے کی ضرورت ہوتی ہے تو ترقی کے ماحول کو اوورلوڈ کر سکتا ہے۔ یہ یقینی طور پر ڈویلپر کی کارکردگی کو کم کرتا ہے۔
  • چونکہ ہر چیز کو ایک جگہ پر نصب کرنا ہوتا ہے، اس لیے اس سے یہ حقیقت سامنے آتی ہے کہ کسی دوسری پروگرامنگ لینگویج کو تبدیل کرنا یا دوسری ٹیکنالوجیز کو تبدیل کرنا ایک بڑا مسئلہ ہے۔ مثال کے طور پر، آپ نے جاوا میں ایک درخواست لکھی، اور تھوڑی دیر کے بعد کوٹلن سامنے آیا اور آپ اسے دوبارہ لکھنے کے لیے بے چین تھے، کیونکہ اسے ٹھنڈا، بہتر، تیز تر قرار دیا گیا تھا۔ یک سنگی استعمال کے ساتھ، ری فیکٹرنگ کے بارے میں سوچنا بھی حقیقی درد کا باعث بنے گا، اس عمل کا ذکر نہ کرنا۔ اس وقت بہت ساری ایپلی کیشنز ہیں جو اس طرح بنائی گئی ہیں اور کوڈ کی لائنوں کی تعداد صرف ناقابل یقین ہے۔
  • اگر اجزاء میں سے کوئی بھی کسی وجہ سے کام کرنا چھوڑ دیتا ہے تو پوری ایپلیکیشن بھی کریش ہو جائے گی۔ ذرا تصور کریں کہ ایک ویب ایپلیکیشن ہے جس میں ماڈیولز ہیں جیسے اجازت، ادائیگی، تاریخ وغیرہ۔ اور کسی وجہ سے ان میں سے ایک ٹوٹ جاتا ہے۔ یہ کاروبار کے لیے اور اس کے نتیجے میں، ڈویلپرز کے لیے محض ایک جھٹکا ہے۔
  • یک سنگی ایپلیکیشن کی پیمائش صرف اسی قسم کی دوسری ایپلی کیشن کو بڑھا کر حاصل کی جا سکتی ہے۔ لیکن کیا ہوگا اگر آپ کو صرف ایک جزو کو پیمانہ کرنے کی ضرورت ہے، نہ کہ پوری درخواست کو۔ کتنے وسائل ضائع ہوں گے؟
  • اس کا ترقیاتی عمل اور ایپلیکیشن کی تنصیب کے عمل پر بڑا اثر پڑ سکتا ہے۔ ایپلی کیشن جتنی بڑی ہوگی، اتنا ہی اہم یہ ہے کہ ڈویلپرز ایپلیکیشن کو چھوٹے کام کرنے والے حصوں میں تقسیم کر سکتے ہیں۔ چونکہ یک سنگی ایپلی کیشن میں تمام ماڈیولز ایک دوسرے سے جڑے ہوتے ہیں، اس لیے ڈویلپر ان ماڈیولز کو ایک دوسرے سے آزادانہ طور پر کام/ماؤنٹ نہیں کر سکتے۔ چونکہ ڈویلپرز ایک دوسرے پر انحصار کرتے ہیں، ترقی کا وقت بڑھ جاتا ہے۔
ایک ہی وقت میں، ہم مائیکرو سروسز کے معنی پر غور کرنے اور سمجھنے کے لیے تیار ہیں، یعنی ان کا استعمال اس لچک کو بحال کرنے کے لیے کیسے کیا جا سکتا ہے جو SOA کے انداز سے کھو گیا تھا۔ بچاؤ کے لیے خدا مائیکرو سروسز کسی بھی تعمیراتی حل میں سب سے اہم خصوصیات میں سے ایک اسکیل ایبلٹی ہے۔ جب میں پہلی بار مائیکرو سروسز سیکھ رہا تھا، میں نے دیکھا کہ ہر چیز کتاب "دی آرٹ آف اسکیل ایبلٹی" کے اقتباسات سے ملتی جلتی ہے۔ یہ بحث کے لیے ایک بہترین آغاز اور جگہ ہے۔ یہ کتاب نام نہاد "اسکیل ایبلٹی کیوب" ماڈل کی وضاحت کرتی ہے، جو تین جہتی اسکیل ایبلٹی سسٹم کی وضاحت کرتی ہے:
مائیکرو سروس فن تعمیر: فوائد اور نقصانات - 3
جیسا کہ آپ دیکھ سکتے ہیں، X محور "افقی اسکیلنگ" کی وضاحت کرتا ہے (جسے ہم نے دیکھا ہے کہ یک سنگی فن تعمیر کے لیے بھی دستیاب ہے)، Y محور مختلف خدمت کے اجزاء کو الگ کرنے کے معنی میں اسکیلنگ کی نمائندگی کرتا ہے ۔ Z محور کا خیال اس وقت سمجھا جاتا ہے جب ڈیٹا کو تقسیم کیا جاتا ہے اور ایپلی کیشن درخواستیں بھیجتی ہے جہاں ڈیٹا واقع ہے۔ یعنی یہ سب ایک جگہ پر نہیں ہیں۔ Y محور کا خیال وہی ہے جس پر ہم مزید تفصیل سے توجہ مرکوز کریں گے۔ یہ محور ایک فنکشنل سڑن کی نمائندگی کرتا ہے ۔ اس حکمت عملی میں، مختلف افعال کو آزاد خدمات کے طور پر سمجھا جا سکتا ہے۔ لہذا، پوری ایپلیکیشن کو صرف اس وقت ماؤنٹ کرنے سے جب سب کچھ ہو جائے، ڈویلپر انفرادی خدمات کو ایک دوسرے سے آزادانہ طور پر ماؤنٹ کر سکتے ہیں اور دوسروں کے اپنے ماڈیولز پر کام ختم کرنے کا انتظار نہیں کر سکتے۔ یہ نہ صرف ترقی کے وقت کو بہتر بنائے گا، بلکہ ایپلی کیشن کے باقی اجزاء کے بارے میں فکر کیے بغیر تبدیلی اور دوبارہ وائر کرنے کی لچک بھی پیش کرے گا۔ آئیے اس خاکہ کا موازنہ پچھلے یک سنگی سے کرتے ہیں:
مائیکرو سروس فن تعمیر: فوائد اور نقصانات - 4
مائیکرو سروسز: فوائد مائیکرو سروسز کے فوائد انٹرپرائز ڈویلپرز جیسے Amazon، Netflix، Ebay کو اس نقطہ نظر کو استعمال کرنے کے لیے راضی کرنے کے لیے کافی ہیں۔ یک سنگی آرکیٹیکچرل ایپلی کیشنز کے برعکس، مائیکرو سروسز:
  • اجزاء کی ناکامی کی تنہائی کو بہتر بناتا ہے: بڑی ایپلی کیشنز مؤثر طریقے سے چلتی رہ سکتی ہیں چاہے ایک ماڈیول ناکام ہو جائے۔
  • ایک ٹیکنالوجی اسٹیک کے لیے ایپلیکیشن کی وابستگی کو ختم کرتا ہے: اگر آپ کسی سروس پر ایک نیا ٹیکنالوجی اسٹیک آزمانا چاہتے ہیں، تو آگے بڑھیں۔ انحصار ایک یک سنگی کے مقابلے میں بہت ہلکا ہوگا، اور ہر چیز کو پیچھے ہٹانا بھی بہت آسان ہوگا۔ ایک ایپلیکیشن میں جتنا کم کوڈ ہوگا، کام کرنا اتنا ہی آسان ہوگا۔
  • نئے ملازمین کے لیے سروس کی فعالیت کو سمجھنا بہت آسان بناتا ہے۔
مائیکرو سروسز: ماؤنٹنگ اور ورچوئلائزیشن کی خصوصیات اب ہم سمجھتے ہیں کہ مائیکرو سروسز کیا ہیں۔ اور سب سے بڑا فائدہ یہ ہے کہ یہ ایک سے زیادہ WAR/EAR/JAR آرکائیو کے ذریعے نصب ہے۔ لیکن یہ کیسے انسٹال ہے؟ کنٹینرز کے اندر مائیکرو سروسز کو ماؤنٹ کرنے کا بہترین طریقہ۔ کنٹینر ایک مکمل طور پر ترتیب شدہ ورچوئل آپریٹنگ سسٹم ہے جس میں ضروری ماحول کو ترتیب دیا گیا ہے، جو ہارڈ ویئر سسٹم کے وسائل تک رسائی کو الگ کرنے میں مدد کرتا ہے جس پر کنٹینر نصب ہے۔ مارکیٹ میں سب سے مشہور حل یقینا Docker ہے ۔ IaaS سے ورچوئل مشینیں (بطور ایک سروس) جیسے AWS بھی مائیکرو سروسز کو ماؤنٹ کرنے کے لیے ٹھیک کام کر سکتی ہیں، لیکن نسبتاً ہلکے وزن والی مائیکرو سروسز وہ تمام وسائل استعمال نہیں کر سکتیں جو ورچوئل مشین میں ہیں، جس سے استعمال کے منافع کو کم کیا جا سکتا ہے۔ آپ OSGI (اوپن سروس گیٹ وے انیشی ایٹو) پیکیج کا استعمال کرتے ہوئے اپنی مائیکرو سروسز بھی ماؤنٹ کر سکتے ہیں ۔ اس صورت میں، تمام مائیکرو سروسز ایک ہی JVM میں چلیں گی، لیکن اس میں کنٹرول اور تنہائی کے درمیان تجارت کے مسائل شامل ہیں۔ مائیکرو سروسز: نقصانات صرف اس وجہ سے کہ "یہ سب اچھا ہے" اور "ہم نے اسے پہلے نہیں دیکھا" کا مطلب یہ نہیں ہے کہ کوئی نقصانات نہیں ہیں۔ ذیل میں درد کے ممکنہ علاقوں کی فہرست ہے جو مائیکرو سروس آرکیٹیکچر اپنے ساتھ لاتا ہے:
  • تقسیم شدہ نظام کو تیار کرنا مشکل ہوسکتا ہے۔ اس سے میرا مطلب ہے کہ تمام اجزاء اب آزاد خدمات ہیں - آپ کو ماڈیولز کے درمیان گزرنے والی درخواستوں کو بہت احتیاط سے سنبھالنے کی ضرورت ہے۔ ایسا منظر نامہ ہو سکتا ہے جہاں ایک ماڈیول جواب نہیں دے رہا ہے، جو آپ کو سسٹم کے کریش ہونے سے بچنے کے لیے اضافی کوڈ لکھنے پر مجبور کر رہا ہے۔ یہ زیادہ مشکل ہو سکتا ہے اگر ریموٹ کالیں تاخیر سے حساس ہوں ۔
  • ایک سے زیادہ ڈیٹا بیس اور لین دین کا انتظام ایک حقیقی درد ہوسکتا ہے۔
  • مائیکرو سروس ایپلی کیشنز کی جانچ کرنا بوجھل ہو سکتا ہے۔ یک سنگی ایپلی کیشن کا استعمال کرتے ہوئے، ہمیں صرف سرور پر WAR/EAR/JAR آرکائیو چلانے اور اس بات کو یقینی بنانا ہوگا کہ یہ ڈیٹا بیس سے منسلک ہے۔ اور مائیکرو سروسز میں، ٹیسٹنگ شروع ہونے سے پہلے ہر انفرادی سروس کو شروع کرنا ضروری ہے۔
  • ایپلی کیشنز کو بڑھانا مشکل ہوسکتا ہے۔ انہیں متعدد خدمات کے ارد گرد ہم آہنگی کی ضرورت ہو سکتی ہے جو WAR کنٹینر کی طرح آسان نہیں ہوسکتی ہیں۔
.... بلاشبہ، صحیح آلات اور طریقوں سے ان نقصانات سے بچا جا سکتا ہے۔ لیکن انہیں خود مدد کی ضرورت ہوتی ہے اور تمام مسائل کو مکمل طور پر حل نہیں کرتے۔ مضمون کا ترجمہ CloudAcademy ویب سائٹ سے کیا گیا تھا ۔ مفت ترجمہ. ہر کوئی کمنٹس میں اپنے خیالات کا اظہار کرنے کے لیے آزاد ہے۔ وہ ضرور پڑھی جائیں گی۔ اصل مضمون میرا گیتوب اکاؤنٹ
تبصرے
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION