مائیکرو سروسز ایک بڑی ایپلیکیشن کو ڈھیلے جوڑے ہوئے ماڈیولز میں توڑنے کا ایک طریقہ ہے جو ایک سادہ API کے ذریعے ایک دوسرے کے ساتھ بات چیت کرتے ہیں۔
حال ہی میں، صرف گونگے لوگوں نے مائیکرو سروسز کے بارے میں بات نہیں کی ہے۔ یہ زیادہ سے زیادہ مقبول ہوتا جا رہا ہے۔ ماڈیولر آرکیٹیکچرل سٹائل خاص طور پر کلاؤڈ بیسڈ ماحول کے لیے موزوں لگتا ہے اور مقبولیت میں بڑھ رہا ہے۔ اس سے پہلے کہ ہم تفصیلات میں جائیں، آئیے ہر چیز کا برڈز آئی ویو لیتے ہیں ۔ لہذا: مائیکرو سروسز ایک بڑے پروجیکٹ کو چھوٹے، آزاد اور ڈھیلے طریقے سے جوڑے ہوئے ماڈیولز میں توڑنے کا ایک طریقہ ہے۔ آزاد ماڈیول واضح طور پر متعین اور مجرد کاموں کے لیے ذمہ دار ہیں اور ایک سادہ اور قابل رسائی API کے ذریعے ایک دوسرے کے ساتھ بات چیت کرتے ہیں۔ دوسرے لفظوں میں، مائیکرو سروسز پیچیدہ، زیادہ تر ویب ایپلیکیشنز کو ڈیزائن کرنے کے لیے محض ایک مختلف آرکیٹیکچرل اسٹائل ہیں۔ لیکن موجودہ تعمیراتی حل جیسے SOA (سروس پر مبنی فن تعمیر) کے بارے میں کیا برا ہے؟ SOA کا استعمال کرتے ہوئے لکھے گئے زیادہ تر جدید انٹرپرائز حل کافی اچھے طریقے سے کام کرتے نظر آتے ہیں۔ صنعت کو ان دنوں جن چیلنجز کا سامنا ہے ان میں سے کچھ کے بارے میں بات کرنے کا یہ بہترین وقت ہو سکتا ہے... آئیے ایک سادہ سی مثال کے ساتھ شروعات کرتے ہیں۔ ہم کہتے ہیں کہ مجھے جاوا میں لکھی ہوئی کلاسک ایپلیکیشن چلانے کی ضرورت ہے۔ پہلے میں یوزر انٹرفیس تیار کروں گا، پھر بزنس لاجک پرت، جس میں کئی اجزاء ہوں گے جو UI کے ساتھ تعامل کریں گے، اور آخر میں ڈیٹا بیس کی تہہ، جو مستقل ڈیٹا بیس تک قابل رسائی ہوگی۔ اب اس حقیقت کے مطابق کہ میں ایپلی کیشن چلانا چاہتا ہوں، میں ایک WAR/EAR/JAR بناؤں گا اور اسے سرور (جیسے JBoss، Tomcat یا WebLogic) پر ماؤنٹ کروں گا۔ چونکہ یہ سب ایک میں ہوتا ہے، مجھے ایک یک سنگی ایپلی کیشن ملتی ہے، جس کا مطلب ہے کہ تمام اجزاء ایک جگہ پر ہیں... تصویر میں مثال:
زیادہ تر امکان ہے کہ آپ اس طریقہ کار سے پہلے ہی واقف ہیں اور اسے استعمال کر چکے ہیں، لیکن خیال یہ ہے کہ اس مثال کو یہ بتانے کے لیے استعمال کیا جائے کہ اس تعمیراتی حل کو استعمال کرتے ہوئے ڈویلپرز کو کن چیلنجوں کا سامنا کرنا پڑے گا۔ یک سنگی ایپلی کیشن: چیلنجز چیلنجز
خدا مائیکرو سروسز کسی بھی تعمیراتی حل میں سب سے اہم خصوصیات میں سے ایک اسکیل ایبلٹی ہے۔ جب میں پہلی بار مائیکرو سروسز سیکھ رہا تھا، میں نے دیکھا کہ ہر چیز کتاب "دی آرٹ آف اسکیل ایبلٹی" کے اقتباسات سے ملتی جلتی ہے۔ یہ بحث کے لیے ایک بہترین آغاز اور جگہ ہے۔ یہ کتاب نام نہاد "اسکیل ایبلٹی کیوب" ماڈل کی وضاحت کرتی ہے، جو تین جہتی اسکیل ایبلٹی سسٹم کی وضاحت کرتی ہے:
جیسا کہ آپ دیکھ سکتے ہیں، X محور "افقی اسکیلنگ" کی وضاحت کرتا ہے (جسے ہم نے دیکھا ہے کہ یک سنگی فن تعمیر کے لیے بھی دستیاب ہے)، Y محور مختلف خدمت کے اجزاء کو الگ کرنے کے معنی میں اسکیلنگ کی نمائندگی کرتا ہے ۔ Z محور کا خیال اس وقت سمجھا جاتا ہے جب ڈیٹا کو تقسیم کیا جاتا ہے اور ایپلی کیشن درخواستیں بھیجتی ہے جہاں ڈیٹا واقع ہے۔ یعنی یہ سب ایک جگہ پر نہیں ہیں۔ Y محور کا خیال وہی ہے جس پر ہم مزید تفصیل سے توجہ مرکوز کریں گے۔ یہ محور ایک فنکشنل سڑن کی نمائندگی کرتا ہے ۔ اس حکمت عملی میں، مختلف افعال کو آزاد خدمات کے طور پر سمجھا جا سکتا ہے۔ لہذا، پوری ایپلیکیشن کو صرف اس وقت ماؤنٹ کرنے سے جب سب کچھ ہو جائے، ڈویلپر انفرادی خدمات کو ایک دوسرے سے آزادانہ طور پر ماؤنٹ کر سکتے ہیں اور دوسروں کے اپنے ماڈیولز پر کام ختم کرنے کا انتظار نہیں کر سکتے۔ یہ نہ صرف ترقی کے وقت کو بہتر بنائے گا، بلکہ ایپلی کیشن کے باقی اجزاء کے بارے میں فکر کیے بغیر تبدیلی اور دوبارہ وائر کرنے کی لچک بھی پیش کرے گا۔ آئیے اس خاکہ کا موازنہ پچھلے یک سنگی سے کرتے ہیں:
مائیکرو سروسز: فوائد مائیکرو سروسز کے فوائد انٹرپرائز ڈویلپرز جیسے Amazon، Netflix، Ebay کو اس نقطہ نظر کو استعمال کرنے کے لیے راضی کرنے کے لیے کافی ہیں۔ یک سنگی آرکیٹیکچرل ایپلی کیشنز کے برعکس، مائیکرو سروسز:
- جیسے جیسے ایپلیکیشن بڑھتی ہے، اسی طرح لکھے گئے کوڈ کی مقدار بھی بڑھتی ہے، جو ہر بار جب آپ کو اسے کھولنے کی ضرورت ہوتی ہے تو ترقی کے ماحول کو اوورلوڈ کر سکتا ہے۔ یہ یقینی طور پر ڈویلپر کی کارکردگی کو کم کرتا ہے۔
- چونکہ ہر چیز کو ایک جگہ پر نصب کرنا ہوتا ہے، اس لیے اس سے یہ حقیقت سامنے آتی ہے کہ کسی دوسری پروگرامنگ لینگویج کو تبدیل کرنا یا دوسری ٹیکنالوجیز کو تبدیل کرنا ایک بڑا مسئلہ ہے۔ مثال کے طور پر، آپ نے جاوا میں ایک درخواست لکھی، اور تھوڑی دیر کے بعد کوٹلن سامنے آیا اور آپ اسے دوبارہ لکھنے کے لیے بے چین تھے، کیونکہ اسے ٹھنڈا، بہتر، تیز تر
قرار دیا گیا تھا۔یک سنگی استعمال کے ساتھ، ری فیکٹرنگ کے بارے میں سوچنا بھی حقیقی درد کا باعث بنے گا، اس عمل کا ذکر نہ کرنا۔ اس وقت بہت ساری ایپلی کیشنز ہیں جو اس طرح بنائی گئی ہیں اور کوڈ کی لائنوں کی تعداد صرف ناقابل یقین ہے۔ - اگر اجزاء میں سے کوئی بھی کسی وجہ سے کام کرنا
چھوڑ دیتا ہےتو پوری ایپلیکیشن بھی کریش ہو جائے گی۔ ذرا تصور کریں کہ ایک ویب ایپلیکیشن ہے جس میں ماڈیولز ہیں جیسے اجازت، ادائیگی، تاریخ وغیرہ۔ اور کسی وجہ سے ان میں سے ایک ٹوٹ جاتا ہے۔ یہ کاروبار کے لیے اور اس کے نتیجے میں، ڈویلپرز کے لیے محض ایک جھٹکا ہے۔ - یک سنگی ایپلیکیشن کی پیمائش صرف اسی قسم کی دوسری ایپلی کیشن کو بڑھا کر حاصل کی جا سکتی ہے۔ لیکن کیا ہوگا اگر آپ کو صرف ایک جزو کو پیمانہ کرنے کی ضرورت ہے، نہ کہ پوری درخواست کو۔ کتنے وسائل ضائع ہوں گے؟
- اس کا ترقیاتی عمل اور ایپلیکیشن کی تنصیب کے عمل پر بڑا اثر پڑ سکتا ہے۔ ایپلی کیشن جتنی بڑی ہوگی، اتنا ہی اہم یہ ہے کہ ڈویلپرز ایپلیکیشن کو چھوٹے کام کرنے والے حصوں میں تقسیم کر سکتے ہیں۔ چونکہ یک سنگی ایپلی کیشن میں تمام ماڈیولز ایک دوسرے سے جڑے ہوتے ہیں، اس لیے ڈویلپر ان ماڈیولز کو ایک دوسرے سے آزادانہ طور پر کام/ماؤنٹ نہیں کر سکتے۔ چونکہ ڈویلپرز ایک دوسرے پر انحصار کرتے ہیں، ترقی کا وقت بڑھ جاتا ہے۔
- اجزاء کی ناکامی کی تنہائی کو بہتر بناتا ہے: بڑی ایپلی کیشنز مؤثر طریقے سے چلتی رہ سکتی ہیں چاہے ایک ماڈیول ناکام ہو جائے۔
- ایک ٹیکنالوجی اسٹیک کے لیے ایپلیکیشن کی وابستگی کو ختم کرتا ہے: اگر آپ کسی سروس پر ایک نیا ٹیکنالوجی اسٹیک آزمانا چاہتے ہیں، تو آگے بڑھیں۔ انحصار ایک یک سنگی کے مقابلے میں بہت ہلکا ہوگا، اور ہر چیز کو پیچھے ہٹانا بھی بہت آسان ہوگا۔ ایک ایپلیکیشن میں جتنا کم کوڈ ہوگا، کام کرنا اتنا ہی آسان ہوگا۔
- نئے ملازمین کے لیے سروس کی فعالیت کو سمجھنا بہت آسان بناتا ہے۔
- تقسیم شدہ نظام کو تیار کرنا مشکل ہوسکتا ہے۔ اس سے میرا مطلب ہے کہ تمام اجزاء اب آزاد خدمات ہیں - آپ کو ماڈیولز کے درمیان گزرنے والی درخواستوں کو بہت احتیاط سے سنبھالنے کی ضرورت ہے۔ ایسا منظر نامہ ہو سکتا ہے جہاں ایک ماڈیول جواب نہیں دے رہا ہے، جو آپ کو سسٹم کے کریش ہونے سے بچنے کے لیے اضافی کوڈ لکھنے پر مجبور کر رہا ہے۔ یہ زیادہ مشکل ہو سکتا ہے اگر ریموٹ کالیں تاخیر سے حساس ہوں ۔
- ایک سے زیادہ ڈیٹا بیس اور لین دین کا انتظام ایک حقیقی درد ہوسکتا ہے۔
- مائیکرو سروس ایپلی کیشنز کی جانچ کرنا بوجھل ہو سکتا ہے۔ یک سنگی ایپلی کیشن کا استعمال کرتے ہوئے، ہمیں صرف سرور پر WAR/EAR/JAR آرکائیو چلانے اور اس بات کو یقینی بنانا ہوگا کہ یہ ڈیٹا بیس سے منسلک ہے۔ اور مائیکرو سروسز میں، ٹیسٹنگ شروع ہونے سے پہلے ہر انفرادی سروس کو شروع کرنا ضروری ہے۔
- ایپلی کیشنز کو بڑھانا مشکل ہوسکتا ہے۔ انہیں متعدد خدمات کے ارد گرد ہم آہنگی کی ضرورت ہو سکتی ہے جو WAR کنٹینر کی طرح آسان نہیں ہوسکتی ہیں۔
GO TO FULL VERSION