دنیا ساکن نہیں ہے۔ ترقی نئے تکنیکی چیلنجز پیدا کرتی ہے۔ بدلتے ہوئے تقاضوں کے مطابق، معلوماتی نظام کے فن تعمیر کو تیار ہونا چاہیے۔ آج ہم تقریب سے چلنے والے فن تعمیر، کنکرنسی، کنکرنسی، غیر مطابقت کے بارے میں بات کریں گے، اور آپ ایرلنگ میں ان سب کے ساتھ کیسے سکون سے رہ سکتے ہیں۔
تعارف
ڈیزائن کردہ نظام کے سائز اور اس کے لیے ضروریات کے مطابق، ہم، ڈویلپرز، نظام میں معلومات کے تبادلے کا طریقہ منتخب کرتے ہیں۔ زیادہ تر معاملات میں، خدمات کے تعامل کو منظم کرنے کے لیے، بروکر کے ساتھ کام کرنے کا آپشن ہو سکتا ہے، مثال کے طور پر، RabbitMQ یا کافکا پر مبنی۔ لیکن بعض اوقات واقعات کا بہاؤ، SLA اور سسٹم پر کنٹرول کی سطح ایسی ہوتی ہے کہ ریڈی میڈ میسجنگ ہمارے لیے موزوں نہیں ہے۔ بلاشبہ، آپ ٹرانسپورٹ کی تہہ اور کلسٹر کی تشکیل کی ذمہ داری لے کر نظام کو تھوڑا پیچیدہ بنا سکتے ہیں، مثال کے طور پر ZeroMQ یا nanomsg کا استعمال۔ لیکن اگر سسٹم میں معیاری ایرلنگ کلسٹر کی کافی تھرو پٹ اور صلاحیتیں ہیں، تو ایک اضافی ہستی کو متعارف کرانے کے معاملے میں تفصیلی مطالعہ اور معاشی جواز درکار ہے۔
رد عمل کی تقسیم شدہ ایپلی کیشنز کا موضوع کافی وسیع ہے۔ مضمون کی شکل میں رکھنے کے لیے، آج کی بحث کا موضوع صرف یکساں ماحول ہو گا جو ایرلنگ/ایلیکسیر پر بنایا گیا ہے۔ ایرلنگ/او ٹی پی ماحولیاتی نظام آپ کو کم سے کم کوشش کے ساتھ ایک رد عمل والے فن تعمیر کو نافذ کرنے کی اجازت دیتا ہے۔ لیکن کسی بھی صورت میں، ہمیں ایک پیغام رسانی کی پرت کی ضرورت ہوگی۔
نظریاتی بنیاد
ڈیزائن اہداف اور رکاوٹوں کی وضاحت کے ساتھ شروع ہوتا ہے۔ بنیادی مقصد ترقی کی خاطر ترقی کے شعبے میں نہیں ہے۔ ہمیں ایک محفوظ اور قابل توسیع ٹول حاصل کرنے کی ضرورت ہے جس کی بنیاد پر ہم مختلف سطحوں کی جدید ایپلی کیشنز بناسکتے ہیں اور سب سے اہم بات یہ ہے کہ: سنگل سرور ایپلی کیشنز سے شروع ہو کر ایک چھوٹے سامعین کی خدمت کریں، جو بعد میں 50 تک کے کلسٹرز میں ترقی کر سکتے ہیں۔ -60 نوڈس، کلسٹر فیڈریشن کے ساتھ ختم ہوتے ہیں۔ اس طرح، بنیادی مقصد حتمی نظام کی ترقی اور ملکیت کی لاگت کو کم کرکے زیادہ سے زیادہ منافع حاصل کرنا ہے۔
آئیے حتمی نظام کے لیے 4 اہم تقاضوں کو اجاگر کرتے ہیں:
- Сواقعہ پر مبنی
نظام ہمیشہ واقعات کے بہاؤ سے گزرنے اور ضروری اعمال انجام دینے کے لیے تیار رہتا ہے۔ - Мتوسیع پذیری
انفرادی بلاکس کو عمودی اور افقی طور پر پیمانہ کیا جا سکتا ہے۔ پورے نظام کو لامحدود افقی ترقی کے قابل ہونا چاہیے؛ - Оغلطی کی رواداری.
تمام سطحوں اور تمام خدمات کو ناکامیوں سے خود بخود بازیافت کرنے کے قابل ہونا چاہئے؛ - Гجوابی وقت کی ضمانت۔
وقت قیمتی ہے اور صارفین کو زیادہ انتظار نہیں کرنا چاہیے۔
"چھوٹا انجن جو کر سکتا تھا" کے بارے میں پرانی پریوں کی کہانی یاد ہے؟ ڈیزائن کردہ نظام کو کامیابی کے ساتھ پروٹو ٹائپ مرحلے سے باہر نکلنے اور ترقی پسند ہونے کے لیے، اس کی بنیاد کو کم از کم ضروریات کو پورا کرنا چاہیے۔ SMOG.
بنیادی ڈھانچے کے آلے اور تمام خدمات کی بنیاد کے طور پر پیغام رسانی میں ایک اور نکتہ شامل کیا گیا ہے: پروگرامرز کے لیے استعمال میں آسانی۔
واقعہ پر مبنی
کسی ایپلیکیشن کو ایک سرور سے کلسٹر تک بڑھنے کے لیے، اس کے فن تعمیر کو ڈھیلے جوڑے کو سپورٹ کرنا چاہیے۔ غیر مطابقت پذیر ماڈل اس ضرورت کو پورا کرتا ہے۔ اس میں، بھیجنے والا اور وصول کنندہ پیغام کی معلومات کے بوجھ کا خیال رکھتے ہیں اور سسٹم کے اندر ٹرانسمیشن اور روٹنگ کی فکر نہیں کرتے۔
سکالٹیبل
اسکیل ایبلٹی اور سسٹم کی کارکردگی ایک دوسرے کے ساتھ ہیں۔ درخواست کے اجزاء کو تمام دستیاب وسائل کو استعمال کرنے کے قابل ہونا چاہیے۔ ہم صلاحیت کو جتنی زیادہ مؤثر طریقے سے استعمال کر سکتے ہیں اور ہمارے پروسیسنگ کے طریقے جتنے زیادہ بہتر ہوں گے، ہم سامان پر اتنا ہی کم پیسہ خرچ کریں گے۔
ایک مشین کے اندر، ایرلنگ ایک انتہائی مسابقتی ماحول پیدا کرتا ہے۔ کنکرنسی اور متوازی کے درمیان توازن ایرلنگ VM کے لیے دستیاب آپریٹنگ سسٹم تھریڈز کی تعداد اور ان دھاگوں کو استعمال کرنے والے شیڈیولرز کی تعداد کو منتخب کر کے سیٹ کیا جا سکتا ہے۔
ایرلنگ عمل ریاست کا اشتراک نہیں کرتے اور نان بلاکنگ موڈ میں کام کرتے ہیں۔ یہ روایتی بلاکنگ پر مبنی ایپلی کیشنز کے مقابلے نسبتاً کم لیٹنسی اور زیادہ تھرو پٹ فراہم کرتا ہے۔ ایرلانگ کا شیڈیولر CPU اور IO کی منصفانہ تقسیم کو یقینی بناتا ہے، اور بلاکنگ کی عدم موجودگی ایپ کو زیادہ بوجھ یا ناکامی کے دوران بھی جواب دینے کی اجازت دیتی ہے۔
کلسٹر کی سطح پر ڈسپوزل کا مسئلہ بھی موجود ہے۔ یہ ضروری ہے کہ کلسٹر میں تمام مشینیں یکساں طور پر لوڈ ہوں اور نیٹ ورک اوورلوڈ نہ ہو۔ آئیے ایک صورت حال کا تصور کریں: صارف کی ٹریفک آنے والے بیلنسرز (ہاپروکسی، نگینکس، وغیرہ) پر اترتی ہے، وہ دستیاب بیک اینڈز کے سیٹ کے درمیان پروسیسنگ کی درخواستوں کو یکساں طور پر تقسیم کرتے ہیں۔ ایپلیکیشن کے بنیادی ڈھانچے کے اندر، مطلوبہ انٹرفیس کو نافذ کرنے والی سروس صرف آخری میل ہے اور اسے ابتدائی درخواست کا جواب دینے کے لیے متعدد دیگر خدمات کی درخواست کرنے کی ضرورت ہوگی۔ اندرونی درخواستوں کو بھی روٹنگ اور توازن کی ضرورت ہوتی ہے۔
ڈیٹا کے بہاؤ کو مؤثر طریقے سے منظم کرنے کے لیے، میسجنگ کو ڈویلپرز کو روٹنگ اور لوڈ بیلنسنگ کو منظم کرنے کے لیے ایک انٹرفیس فراہم کرنا چاہیے۔ اس کی بدولت، ڈویلپرز مائیکرو سروس پیٹرن (مجموعی، پراکسی، چین، برانچ، وغیرہ) کا استعمال کرتے ہوئے معیاری مسائل اور جو شاذ و نادر ہی پیدا ہوتے ہیں، دونوں کو حل کرنے کے قابل ہو جائیں گے۔
کاروباری نقطہ نظر سے، اسکیل ایبلٹی رسک مینجمنٹ ٹولز میں سے ایک ہے۔ سب سے اہم چیز یہ ہے کہ سامان کا بہترین استعمال کرکے صارفین کی درخواستوں کو پورا کیا جائے:
- جب ترقی کے نتیجے میں سامان کی طاقت بڑھ جاتی ہے۔ یہ نامکمل سافٹ ویئر کی وجہ سے بیکار نہیں ہوگا۔ ایرلنگ عمودی طور پر اسکیل کرتا ہے اور ہمیشہ تمام CPU کور اور دستیاب میموری کو استعمال کرنے کے قابل ہوگا۔
- بادل کے ماحول میں، ہم موجودہ یا پیش گوئی شدہ بوجھ اور ضمانت SLA کے لحاظ سے سامان کی مقدار کا انتظام کر سکتے ہیں۔
غلطی کی رواداری
آئیے دو محوروں پر غور کریں: "ناکامیاں ناقابل قبول ہیں" اور "ناکامی ہمیشہ رہے گی۔" کاروبار کے لیے، سافٹ ویئر کی ناکامی کا مطلب ہے پیسے کا نقصان، اور اس سے بھی بدتر، ساکھ کا نقصان۔ ممکنہ نقصانات اور غلطی برداشت کرنے والے سافٹ ویئر تیار کرنے کی لاگت کے درمیان توازن، ایک سمجھوتہ اکثر پایا جا سکتا ہے۔
مختصر مدت میں، ایک فن تعمیر جس میں غلطی کی رواداری شامل ہوتی ہے، آف دی شیلف کلسٹرنگ حل خریدنے پر پیسے بچاتا ہے۔ وہ مہنگے ہیں اور ان میں کیڑے بھی ہیں۔
طویل مدتی میں، ایک غلطی برداشت کرنے والا فن تعمیر ترقی کے تمام مراحل میں کئی گنا زیادہ ادائیگی کرتا ہے۔
کوڈ بیس کے اندر پیغام رسانی آپ کو ترقی کے مرحلے پر سسٹم کے اندر اجزاء کے تعامل کو تفصیل سے کام کرنے کی اجازت دیتی ہے۔ یہ ناکامیوں کا جواب دینے اور ان کا انتظام کرنے کے کام کو آسان بناتا ہے، کیونکہ تمام اہم اجزاء ناکامیوں کو ہینڈل کرتے ہیں، اور نتیجے میں آنے والا نظام جانتا ہے کہ ڈیزائن کے لحاظ سے ناکامی کے بعد خود بخود معمول پر کیسے آنا ہے۔
ردعمل
ناکامیوں سے قطع نظر، درخواست کو درخواستوں کا جواب دینا اور SLA سے ملنا چاہیے۔ حقیقت یہ ہے کہ لوگ انتظار نہیں کرنا چاہتے، لہذا کاروباری اداروں کو اس کے مطابق ڈھال لینا چاہیے۔ زیادہ سے زیادہ ایپلی کیشنز کے انتہائی جوابدہ ہونے کی توقع ہے۔
ریسپانسیو ایپلیکیشنز قریب قریب حقیقی وقت میں کام کرتی ہیں۔ Erlang VM نرم ریئل ٹائم موڈ میں کام کرتا ہے۔ کچھ شعبوں کے لیے، جیسے کہ اسٹاک ٹریڈنگ، ادویات، اور صنعتی آلات کا کنٹرول، سخت ریئل ٹائم موڈ اہم ہے۔
جوابی نظام UX کو بہتر بناتے ہیں اور کاروبار کو فائدہ پہنچاتے ہیں۔
ابتدائی خلاصہ
اس مضمون کی منصوبہ بندی کرتے وقت، میں میسجنگ بروکر بنانے اور اس کی بنیاد پر پیچیدہ نظام بنانے کے اپنے تجربے کو شیئر کرنا چاہتا تھا۔ لیکن نظریاتی اور تحریکی حصہ کافی وسیع نکلا۔
مضمون کے دوسرے حصے میں، میں ایکسچینج پوائنٹس، پیغام رسانی کے نمونوں اور ان کے اطلاق کے نفاذ کی باریکیوں کے بارے میں بات کروں گا۔
تیسرے حصے میں ہم خدمات کو منظم کرنے، روٹنگ اور توازن کے عمومی مسائل پر غور کریں گے۔ آئیے اسکیل ایبلٹی کے عملی پہلو کے بارے میں بات کرتے ہیں اور سسٹمز کی فالٹ ٹولرنس۔
پہلے حصے کا اختتام۔
تصویر .
ماخذ: www.habr.com