ہیلو، ابر. ایک نئے کورس کے سلسلے کے لیے اندراج ابھی OTUS پر کھلا ہے۔ . کورس کے آغاز کے موقع پر، میں آپ کے ساتھ اپنا اصل مضمون شیئر کرنا چاہتا ہوں۔
تعارف
معلوماتی نظام کی تعمیر کے دوران تعمیراتی طرز کا انتخاب بنیادی تکنیکی فیصلوں میں سے ایک ہے۔ مضامین کے اس سلسلے میں، میں ایپلی کیشنز کی تعمیر کے لیے سب سے زیادہ مقبول آرکیٹیکچرل اسٹائلز کا تجزیہ کرنے اور اس سوال کا جواب دینے کی تجویز پیش کرتا ہوں کہ کون سا طرز تعمیر سب سے زیادہ افضل ہے۔ پریزنٹیشن کے عمل میں، میں ایک منطقی سلسلہ تیار کرنے کی کوشش کروں گا جو یک سنگی سے لے کر مائیکرو سروسز تک آرکیٹیکچرل اسٹائل کی ترقی کی وضاحت کرتا ہے۔
تاریخ کا ایک تھوڑا سا
اگر آپ ڈویلپرز سے پوچھنے کی کوشش کرتے ہیں: "ہمیں مائیکرو سروسز کی ضرورت کیوں ہے؟"، تو آپ کو مختلف قسم کے جوابات ملیں گے۔ آپ یہ سنیں گے کہ مائیکرو سروسز اسکیل ایبلٹی کو بہتر بناتی ہیں، کوڈ کو سمجھنے میں آسان بناتی ہیں، غلطی کی برداشت کو بہتر بناتی ہیں، اور کبھی کبھی آپ سنیں گے کہ وہ آپ کو "اپنے کوڈ کو صاف کرنے" کی اجازت دیتے ہیں۔ آئیے مائیکرو سروسز کے ظہور کے پیچھے مقصد کو سمجھنے کے لیے تاریخ پر نظر ڈالیں۔
مختصراً، ہماری موجودہ تفہیم میں مائیکرو سروسز اس طرح پیدا ہوئیں: 2011 میں، جیمز لیوس نے مختلف کمپنیوں کے کام کا تجزیہ کرتے ہوئے، ایک نئے "مائیکرو ایپ" پیٹرن کے ظہور کی طرف توجہ مبذول کروائی، جس نے SOA کی تعیناتی کو تیز کرنے کے لحاظ سے بہتر بنایا۔ خدمات کچھ دیر بعد، 2012 میں، ایک آرکیٹیکچر سمٹ میں، پیٹرن کا نام مائیکرو سروس رکھ دیا گیا۔ اس طرح، مائیکرو سروسز متعارف کرانے کا ابتدائی مقصد بدنام زمانہ کو بہتر بنانا تھا۔ بازار جانے کا وقت.
مائیکرو سروسز 2015 میں ہائپ کی لہر پر تھیں۔ کچھ مطالعات کے مطابق، ایک بھی کانفرنس مائیکرو سروسز کے موضوع پر رپورٹ کے بغیر مکمل نہیں ہوئی۔ مزید یہ کہ، کچھ کانفرنسیں خصوصی طور پر مائیکرو سروسز کے لیے وقف تھیں۔ آج کل، بہت سے پراجیکٹ اس طرز تعمیر کا استعمال شروع کر دیتے ہیں، اور اگر اس پروجیکٹ میں بہت سارے لیگیسی کوڈ ہوتے ہیں، تو مائیکرو سروسز کی طرف منتقلی شاید فعال طور پر کی جا رہی ہے۔
مندرجہ بالا سب کے باوجود، ڈیولپرز کی کافی کم تعداد اب بھی "مائیکرو سروس" کے تصور کی وضاحت کر سکتی ہے۔ لیکن ہم اس پر تھوڑی دیر بعد بات کریں گے...
یک سنگی
تعمیراتی انداز جو مائیکرو سروسز سے متصادم ہے وہ یک سنگی (یا سب میں ایک) ہے۔ یہ بتانا شاید کوئی معنی نہیں رکھتا کہ یک سنگی کیا ہے، اس لیے میں فوری طور پر اس طرز تعمیر کے نقصانات کی فہرست دوں گا، جس نے تعمیراتی طرز کی مزید ترقی کا آغاز کیا: سائز، کنیکٹیویٹی، تعیناتی، توسیع پذیری، وشوسنییتا اور سختی۔ ذیل میں میں تجویز کرتا ہوں کہ ہر ایک کوتاہیوں پر الگ الگ نظر ڈالیں۔
سائز
مونولیتھ بہت بڑا ہے۔ اور یہ عام طور پر ایک بہت بڑے ڈیٹا بیس کے ساتھ بات چیت کرتا ہے۔ ایپلیکیشن اتنی بڑی ہو جاتی ہے کہ ایک ڈویلپر کو بالکل بھی سمجھ نہیں آتی۔ صرف وہی لوگ جنہوں نے اس کوڈ پر کام کرنے میں کافی وقت صرف کیا ہے وہ یک سنگی کے ساتھ اچھی طرح سے کام کر سکتے ہیں، جبکہ ابتدائی افراد یک سنگی کو معلوم کرنے کی کوشش میں کافی وقت صرف کریں گے اور اس بات کی کوئی گارنٹی نہیں ہے کہ وہ اس کا پتہ لگا لیں گے۔ عام طور پر، جب کسی یک سنگی کے ساتھ کام کرتے ہیں، تو ہمیشہ کچھ "مشروط" سینئر ہوتے ہیں جو یک سنگی کو کم و بیش اچھی طرح جانتے ہیں اور ڈیڑھ سال کے اندر دوسرے نئے ڈویلپرز کے ہاتھ مار دیتے ہیں۔ قدرتی طور پر، اس طرح کی مشروط سینئر ناکامی کا ایک واحد نقطہ ہے، اور اس کی روانگی monolith کی موت کا باعث بن سکتی ہے۔
ربط
یک سنگی "مٹی کی ایک بڑی گیند" ہے، جس میں تبدیلیاں غیر متوقع نتائج کا باعث بن سکتی ہیں۔ ایک جگہ پر تبدیلیاں کرکے، آپ دوسری جگہ پر یک سنگی کو نقصان پہنچا سکتے ہیں (وہی "آپ نے کان کھجا، *@ گرا")۔ یہ اس حقیقت کی وجہ سے ہے کہ یک سنگی کے اجزاء میں بہت پیچیدہ اور سب سے اہم بات یہ ہے کہ غیر واضح تعلقات ہیں۔
تعیناتی
اجزا کے درمیان پیچیدہ رشتوں کی وجہ سے یک سنگی کی تعیناتی اس کی اپنی رسم کے ساتھ ایک طویل عمل ہے۔ اس طرح کی رسم عام طور پر مکمل طور پر معیاری نہیں ہوتی ہے اور اسے "زبانی طور پر" منتقل کیا جاتا ہے۔
سکالٹیبل
Monolith ماڈیولز میں متضاد وسائل کی ضروریات ہوسکتی ہیں، جس میں ہارڈ ویئر کے معاملے میں سمجھوتہ کرنے کی ضرورت ہوتی ہے۔ تصور کریں کہ آپ کے پاس خدمات A اور B پر مشتمل ایک یک سنگی ہے۔ سروس A ہارڈ ڈرائیو کے سائز کا مطالبہ کر رہی ہے، اور سروس B RAM پر مانگ رہی ہے۔ اس صورت میں، یا تو وہ مشین جس پر یک سنگی نصب ہے دونوں خدمات کے تقاضوں کو پورا کرے، یا آپ کو دستی طور پر، مصنوعی طور پر کسی ایک سروس کو غیر فعال کرنا پڑے گا۔
ایک اور مثال (زیادہ کلاسک): سروس A سروس B کے مقابلے میں بہت زیادہ مقبول ہے، لہذا آپ چاہتے ہیں کہ وہاں 100 سروسز A، اور 10 سروسز B ہوں۔ دوبارہ، دو اختیارات: یا تو ہم 100 مکمل یک سنگی تعینات کریں، یا پھر کچھ پر خدمات B کو دستی طور پر غیر فعال کرنا ہوگا۔
وشوسنییتا
چونکہ تمام سروسز ایک ساتھ واقع ہیں، اگر یک سنگی گر جائے تو تمام سروسز ایک ساتھ گر جاتی ہیں۔ درحقیقت، یہ اتنا برا نہیں ہوسکتا ہے، کم از کم تقسیم شدہ نظام میں کوئی جزوی ناکامی نہیں ہوگی، لیکن دوسری طرف، فعالیت میں ایک بگ کی وجہ سے جو 0.001% صارفین استعمال کرتے ہیں، آپ تمام صارفین کو کھو سکتے ہیں۔ آپ کے سسٹم کا۔
جڑتا
یک سنگی کے سائز کی وجہ سے، نئی ٹیکنالوجیز کو تبدیل کرنا مشکل ہے۔ نتیجے کے طور پر، اسی سینئر کو برقرار رکھنا ایک الگ کام ہے۔ پراجیکٹ کے آغاز میں چنا گیا ٹیکنالوجی اسٹیک ایک بلاک بن سکتا ہے جو پروڈکٹ کی ترقی میں رکاوٹ ہے۔
حاصل يہ ہوا
اگلی بار ہم اس بارے میں بات کریں گے کہ کس طرح لوگوں نے اجزاء اور SOA میں جا کر ان مسائل کو حل کرنے کی کوشش کی۔
مزید پڑھ:
ماخذ: www.habr.com