آپ نے اپنے یک سنگی کو مائیکرو سروسز میں نئے سرے سے ڈیزائن کرنے میں مہینوں گزارے ہیں، اور آخر کار سب لوگ سوئچ کو پلٹانے کے لیے اکٹھے ہو گئے ہیں۔ آپ پہلے ویب پیج پر جائیں... اور کچھ نہیں ہوتا۔ آپ اسے دوبارہ لوڈ کریں - اور پھر کچھ بھی اچھا نہیں، سائٹ اتنی سست ہے کہ کئی منٹ تک جواب نہیں دیتی۔ کیا ہوا؟
اپنی گفتگو میں، جمی بوگارڈ ایک حقیقی زندگی کی مائیکرو سروس ڈیزاسٹر پر "پوسٹ مارٹم" کرے گا۔ وہ ماڈلنگ، ڈیولپمنٹ، اور پروڈکشن کے مسائل دکھائے گا جو اس نے دریافت کیے ہیں، اور کس طرح اس کی ٹیم نے آہستہ آہستہ نئے تقسیم شدہ یک سنگی کو سنجیدگی کی آخری تصویر میں تبدیل کیا۔ اگرچہ ڈیزائن کی غلطیوں کو مکمل طور پر روکنا ناممکن ہے، لیکن آپ کم از کم ڈیزائن کے عمل کے آغاز میں مسائل کی نشاندہی کر سکتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ حتمی مصنوعہ ایک قابل اعتماد تقسیم شدہ نظام بن جائے۔
سب کو ہیلو، میں جمی ہوں اور آج آپ یہ سننے جا رہے ہیں کہ مائیکرو سروسز بناتے وقت آپ میگا آفات سے کیسے بچ سکتے ہیں۔ یہ ایک کمپنی کی کہانی ہے جس کے لیے میں نے تقریباً ڈیڑھ سال کام کیا تاکہ ان کے جہاز کو برف کے تودے سے ٹکرانے سے بچایا جا سکے۔ اس کہانی کو صحیح طریقے سے بتانے کے لیے، ہمیں وقت پر واپس جانا پڑے گا اور اس کے بارے میں بات کرنی ہوگی کہ یہ کمپنی کہاں سے شروع ہوئی اور وقت کے ساتھ ساتھ اس کا IT انفراسٹرکچر کیسے ترقی کر رہا ہے۔ اس آفت میں ان بے گناہوں کے ناموں کی حفاظت کے لیے میں نے اس کمپنی کا نام بدل کر بیل کمپیوٹرز رکھ دیا ہے۔ اگلی سلائیڈ دکھاتی ہے کہ 90 کی دہائی کے وسط میں ایسی کمپنیوں کا آئی ٹی انفراسٹرکچر کیسا تھا۔ یہ کمپیوٹر ہارڈویئر اسٹور کو چلانے کے لیے ایک بڑے عالمگیر فالٹ ٹولرنٹ HP ٹینڈم مین فریم سرور کا ایک مخصوص فن تعمیر ہے۔
انہیں تمام آرڈرز، سیلز، ریٹرن، پروڈکٹ کیٹلاگ اور کسٹمر بیس کو منظم کرنے کے لیے ایک نظام بنانے کی ضرورت تھی، اس لیے انھوں نے اس وقت سب سے عام مین فریم حل کا انتخاب کیا۔ اس بہت بڑے سسٹم میں کمپنی کے بارے میں ہر طرح کی معلومات، ہر ممکن چیز موجود تھی اور ہر لین دین اس مین فریم کے ذریعے کیا جاتا تھا۔ انہوں نے اپنے تمام انڈے ایک ٹوکری میں رکھے اور سوچا کہ یہ عام بات ہے۔ صرف ایک چیز جو یہاں شامل نہیں ہے وہ ہے میل آرڈر کیٹلاگ اور فون کے ذریعے آرڈر دینا۔
وقت گزرنے کے ساتھ ساتھ یہ نظام بڑا اور بڑا ہوتا گیا اور اس میں کچرے کی ایک بڑی مقدار جمع ہوتی گئی۔ اس کے علاوہ، COBOL دنیا کی سب سے زیادہ اظہار خیال کرنے والی زبان نہیں ہے، اس لیے یہ نظام کباڑ کا ایک بڑا، یک سنگی ٹکڑا بن کر ختم ہوا۔ 2000 تک، انہوں نے دیکھا کہ بہت سی کمپنیوں کی ویب سائٹس ہیں جن کے ذریعے وہ اپنے تمام کاروبار کو چلاتے ہیں، اور اپنی پہلی تجارتی ڈاٹ کام ویب سائٹ بنانے کا فیصلہ کیا۔
ابتدائی ڈیزائن بہت اچھا لگ رہا تھا اور اس میں ایک اعلیٰ سطحی سائٹ bell.com اور انفرادی ایپلیکیشنز کے لیے متعدد ذیلی ڈومینز شامل تھے: catalog.bell.com، accounts.bell.com، orders.bell.com، پروڈکٹ سرچ search.bell۔ com. ہر ذیلی ڈومین نے ASP.Net 1.0 فریم ورک اور اس کے اپنے ڈیٹا بیس کا استعمال کیا، اور ان سب نے سسٹم بیک اینڈ سے بات کی۔ تاہم، تمام احکامات پر ایک ہی بڑے مین فریم کے اندر عملدرآمد اور عملدرآمد جاری رہا، جس میں تمام ردی کی ٹوکری باقی رہی، لیکن سامنے کا حصہ انفرادی ایپلی کیشنز اور علیحدہ ڈیٹا بیس کے ساتھ علیحدہ ویب سائٹس تھیں۔
لہذا نظام کا ڈیزائن منظم اور منطقی نظر آیا، لیکن اصل نظام وہی تھا جیسا کہ اگلی سلائیڈ میں دکھایا گیا ہے۔
تمام عناصر نے ایک دوسرے کو کالز کو ایڈریس کیا، APIs تک رسائی حاصل کی، تھرڈ پارٹی ڈی ایل ایل ایمبیڈڈ، اور اسی طرح کی۔ اکثر ایسا ہوتا تھا کہ ورژن کنٹرول سسٹم کسی اور کا کوڈ پکڑ لیتے، اسے پروجیکٹ کے اندر دھکیل دیتے، اور پھر سب کچھ ٹوٹ جاتا۔ ایم ایس ایس کیو ایل سرور 2005 نے لنک سرورز کا تصور استعمال کیا، اور اگرچہ میں نے سلائیڈ پر تیر نہیں دکھائے، لیکن ہر ڈیٹا بیس نے ایک دوسرے سے بات بھی کی، کیونکہ کئی ڈیٹا بیس سے حاصل کردہ ڈیٹا کی بنیاد پر ٹیبل بنانے میں کوئی حرج نہیں ہے۔
چونکہ اب ان کے پاس سسٹم کے مختلف منطقی علاقوں کے درمیان کچھ علیحدگی تھی، اس لیے یہ گندگی کے بٹے ہوئے بلاب بن گئے، جس میں کچرے کا سب سے بڑا ٹکڑا ابھی بھی مین فریم کے پس منظر میں باقی ہے۔
مزے کی بات یہ تھی کہ یہ مین فریم بیل کمپیوٹرز کے حریفوں نے بنایا تھا اور اب بھی ان کے ٹیکنیکل کنسلٹنٹس نے اسے برقرار رکھا تھا۔ اپنی ایپلی کیشنز کی غیر تسلی بخش کارکردگی پر قائل، کمپنی نے ان سے چھٹکارا حاصل کرنے اور سسٹم کو دوبارہ ڈیزائن کرنے کا فیصلہ کیا۔
موجودہ ایپلیکیشن 15 سال سے پروڈکشن میں تھی، جو ASP.Net پر مبنی ایپلی کیشنز کے لیے ایک ریکارڈ ہے۔ سروس نے پوری دنیا سے آرڈرز قبول کیے، اور اس ایک درخواست سے سالانہ آمدنی ایک بلین ڈالر تک پہنچ گئی۔ منافع کا ایک اہم حصہ bell.com ویب سائٹ کے ذریعہ تیار کیا گیا تھا۔ بلیک فرائیڈے پر، سائٹ کے ذریعے دیے گئے آرڈرز کی تعداد کئی ملین تک پہنچ گئی۔ تاہم، موجودہ فن تعمیر نے کسی بھی ترقی کی اجازت نہیں دی، کیونکہ نظام کے عناصر کے سخت باہمی ربط نے عملی طور پر سروس میں کوئی تبدیلی کرنے کی اجازت نہیں دی۔
سب سے سنگین مسئلہ ایک ملک سے آرڈر دینے، دوسرے میں اس کی ادائیگی اور تیسرے کو بھیجنے میں ناکامی تھی، اس حقیقت کے باوجود کہ عالمی کمپنیوں میں ایسی تجارتی اسکیم بہت عام ہے۔ موجودہ ویب سائٹ نے اس طرح کی کسی چیز کی اجازت نہیں دی، لہذا انہیں فون پر ان آرڈرز کو قبول کرنا پڑا۔ اس کی وجہ سے کمپنی تیزی سے فن تعمیر کو تبدیل کرنے کے بارے میں سوچ رہی ہے، خاص طور پر مائیکرو سروسز پر سوئچ کرنے کے بارے میں۔
انہوں نے دوسری کمپنیوں کو دیکھ کر ہوشیار کام کیا یہ دیکھنے کے لئے کہ انہوں نے اسی طرح کے مسئلے کو کیسے حل کیا ہے۔ ان میں سے ایک حل Netflix سروس آرکیٹیکچر تھا، جو ایک API اور ایک بیرونی ڈیٹا بیس کے ذریعے منسلک مائکرو سروسز پر مشتمل ہے۔
بیل کمپیوٹرز کی انتظامیہ نے کچھ بنیادی اصولوں پر عمل کرتے ہوئے صرف اس طرح کے فن تعمیر کا فیصلہ کیا۔ سب سے پہلے، انہوں نے مشترکہ ڈیٹا بیس اپروچ کا استعمال کرکے ڈیٹا ڈپلیکیشن کو ختم کیا۔ کوئی ڈیٹا نہیں بھیجا گیا؛ اس کے برعکس، ہر ایک جس کو اس کی ضرورت تھی اسے مرکزی ذریعہ پر جانا پڑا۔ اس کے بعد تنہائی اور خود مختاری تھی - ہر سروس دوسروں سے آزاد تھی۔ انہوں نے بالکل ہر چیز کے لیے Web API استعمال کرنے کا فیصلہ کیا - اگر آپ ڈیٹا حاصل کرنا چاہتے ہیں یا کسی اور سسٹم میں تبدیلیاں کرنا چاہتے ہیں تو یہ سب کچھ Web API کے ذریعے کیا گیا تھا۔ آخری بڑی چیز ایک نیا مین فریم تھا جسے "بیل آن بیل" کہا جاتا تھا جیسا کہ حریفوں کے ہارڈ ویئر پر مبنی "بیل" مین فریم کے برخلاف تھا۔
لہذا، 18 مہینوں کے دوران، انہوں نے ان بنیادی اصولوں کے گرد نظام بنایا اور اسے پری پروڈکشن میں لایا۔ ویک اینڈ کے بعد کام پر واپس آ کر، ڈویلپرز اکٹھے ہو گئے اور ان تمام سرورز کو آن کر دیا جن سے نیا سسٹم منسلک تھا۔ 18 مہینے کام، سینکڑوں ڈویلپرز، جدید ترین بیل ہارڈ ویئر - اور کوئی مثبت نتیجہ نہیں! اس سے بہت سارے لوگوں کو مایوسی ہوئی ہے کیونکہ انہوں نے اس سسٹم کو اپنے لیپ ٹاپ پر کئی بار چلایا ہے اور سب کچھ ٹھیک تھا۔
وہ اس مسئلے کو حل کرنے میں اپنا سارا پیسہ لگانے میں ہوشیار تھے۔ انہوں نے سوئچ کے ساتھ جدید ترین سرور ریک نصب کیے، گیگابٹ آپٹیکل فائبر کا استعمال کیا، انتہائی طاقتور سرور ہارڈ ویئر جس میں RAM کی دیوانی مقدار ہے، یہ سب منسلک کیا، اسے کنفیگر کیا - اور پھر، کچھ بھی نہیں! پھر انہیں شبہ ہونے لگا کہ اس کی وجہ ٹائم آؤٹ ہو سکتی ہے، اس لیے انہوں نے تمام ویب سیٹنگز، تمام API سیٹنگز میں جا کر ٹائم آؤٹ کنفیگریشن کو زیادہ سے زیادہ ویلیوز پر اپ ڈیٹ کر دیا، تاکہ وہ صرف بیٹھ کر کچھ ہونے کا انتظار کر سکیں۔ سائٹ پر. انہوں نے انتظار کیا اور انتظار کیا اور ساڑھے 9 منٹ تک انتظار کیا جب تک کہ ویب سائٹ آخر کار لوڈ نہیں ہوئی۔
اس کے بعد، ان پر یہ خیال آیا کہ موجودہ صورت حال کا ایک گہرا تجزیہ ضروری ہے، اور انہوں نے ہمیں دعوت دی۔ پہلی چیز جو ہمیں معلوم ہوئی وہ یہ تھی کہ ترقی کے تمام 18 مہینوں کے دوران، ایک بھی حقیقی "مائیکرو" نہیں بنایا گیا - ہر چیز صرف بڑی ہوتی گئی۔ اس کے بعد، ہم نے تباہی کی وجہ کو سمجھنے کے لیے پوسٹ مارٹم لکھنا شروع کیا، جسے "ریٹرو اسپیکٹیو" یا "سیڈ ریٹرو اسپیکٹیو" کے نام سے بھی جانا جاتا ہے، جسے "الزام کا طوفان" بھی کہا جاتا ہے، جو کہ "دماغی طوفان" کی طرح ہے۔
ہمارے پاس کئی اشارے تھے، جن میں سے ایک API کال کے وقت مکمل ٹریفک سیچوریشن تھا۔ جب آپ یک سنگی سروس آرکیٹیکچر استعمال کرتے ہیں، تو آپ فوری طور پر سمجھ سکتے ہیں کہ اصل میں کیا غلط ہوا ہے کیونکہ آپ کے پاس ایک ہی اسٹیک ٹریس ہے جو ہر اس چیز کی اطلاع دیتا ہے جس کی وجہ سے ناکامی ہوسکتی ہے۔ ایسی صورت میں جہاں سروسز کا ایک گروپ بیک وقت ایک ہی API تک رسائی حاصل کرتا ہے، وہاں WireShark جیسے اضافی نیٹ ورک مانیٹرنگ ٹولز استعمال کرنے کے علاوہ ٹریس کو ٹریک کرنے کا کوئی طریقہ نہیں ہے، جس کی بدولت آپ ایک درخواست کا جائزہ لے سکتے ہیں اور یہ جان سکتے ہیں کہ اس کے نفاذ کے دوران کیا ہوا ہے۔ چنانچہ ہم نے ایک ویب صفحہ لیا اور تقریباً 2 ہفتے اس پہیلی کے ٹکڑوں کو ایک ساتھ رکھنے، اس پر طرح طرح کی کالیں کرنے اور تجزیہ کرنے میں گزارے کہ ان میں سے ہر ایک کی وجہ کیا ہے۔
اس تصویر کو دیکھو. یہ ظاہر کرتا ہے کہ ایک بیرونی درخواست سروس کو بہت سی اندرونی کالیں کرنے کا اشارہ کرتی ہے جو واپس لوٹتی ہیں۔ یہ پتہ چلتا ہے کہ ہر اندرونی کال اس درخواست کو آزادانہ طور پر پورا کرنے کے قابل ہونے کے لیے اضافی ہپس بناتی ہے، کیونکہ یہ ضروری معلومات حاصل کرنے کے لیے کہیں اور نہیں جا سکتی۔ یہ تصویر کالوں کے ایک بے معنی جھڑپ کی طرح نظر آتی ہے، جیسا کہ بیرونی درخواست اضافی خدمات کو کال کرتی ہے، جو کہ دیگر اضافی خدمات کو کال کرتی ہے، اور اسی طرح، تقریباً اشتہاری لامحدود۔
اس خاکہ میں سبز رنگ ایک نیم دائرہ دکھاتا ہے جس میں سروسز ایک دوسرے کو کال کرتی ہیں - سروس A سروس B کو کال کرتی ہے، سروس B سروس C کو کال کرتی ہے، اور یہ سروس A کو دوبارہ کال کرتی ہے۔ نتیجتاً، ہمیں "تقسیم تعطل" ملتا ہے۔ ایک درخواست نے ایک ہزار نیٹ ورک API کالز تخلیق کیں، اور چونکہ سسٹم میں بلٹ ان فالٹ ٹولرنس اور لوپ پروٹیکشن نہیں ہے، اگر ان API کالوں میں سے ایک بھی ناکام ہو جائے تو درخواست ناکام ہو جائے گی۔
ہم نے کچھ ریاضی کی۔ ہر API کال کا SLA 150 ms اور 99,9% اپ ٹائم سے زیادہ نہیں تھا۔ ایک درخواست کی وجہ سے 200 مختلف کالیں ہوئیں، اور بہترین صورت میں، صفحہ 200 x 150 ms = 30 سیکنڈز میں دکھایا جا سکتا ہے۔ قدرتی طور پر، یہ کوئی اچھا نہیں تھا. 99,9% اپ ٹائم کو 200 سے ضرب کرتے ہوئے، ہمیں 0% دستیابی ملی۔ یہ پتہ چلتا ہے کہ یہ فن تعمیر شروع سے ہی ناکامی سے دوچار تھا۔
ہم نے ڈویلپرز سے پوچھا کہ وہ 18 ماہ کے کام کے بعد اس مسئلے کو کیسے پہچاننے میں ناکام رہے؟ یہ پتہ چلا کہ انہوں نے صرف اس کوڈ کے لئے SLA شمار کیا جو وہ چلاتے تھے، لیکن اگر ان کی سروس نے کسی اور سروس کو کال کی، تو انہوں نے اس وقت کو اپنے SLA میں شمار نہیں کیا۔ ہر وہ چیز جو ایک عمل کے اندر شروع کی گئی تھی 150 ms کی قدر پر قائم تھی، لیکن دوسرے سروس کے عمل تک رسائی نے کل تاخیر کو کئی گنا بڑھا دیا۔ پہلا سبق سیکھا گیا: "کیا آپ اپنے SLA کے کنٹرول میں ہیں، یا SLA آپ کے کنٹرول میں ہے؟" ہمارے معاملے میں، یہ بعد میں تھا.
اگلی چیز جو ہم نے دریافت کی وہ یہ تھی کہ وہ تقسیم شدہ کمپیوٹنگ کے غلط تصورات کے بارے میں جانتے تھے، جسے پیٹر ڈیچ اور جیمز گوسلنگ نے وضع کیا تھا، لیکن انہوں نے اس کے پہلے حصے کو نظر انداز کر دیا۔ اس میں کہا گیا ہے کہ "نیٹ ورک قابل اعتماد ہے،" "صفر تاخیر،" اور "لامحدود تھرو پٹ" غلط فہمیاں ہیں۔ دیگر غلط فہمیوں میں یہ بیانات شامل ہیں کہ "نیٹ ورک محفوظ ہے،" "ٹپولوجی کبھی نہیں بدلتی،" "یہاں ہمیشہ صرف ایک منتظم ہوتا ہے،" "ڈیٹا کی منتقلی کی لاگت صفر ہے،" اور "نیٹ ورک یکساں ہے۔"
انہوں نے غلطی کی کیونکہ انہوں نے مقامی مشینوں پر اپنی سروس کا تجربہ کیا اور کبھی بھی بیرونی خدمات سے رابطہ نہیں کیا۔ مقامی طور پر ترقی کرتے ہوئے اور مقامی کیشے کا استعمال کرتے ہوئے، انہیں کبھی بھی نیٹ ورک ہاپس کا سامنا نہیں کرنا پڑا۔ ترقی کے تمام 18 مہینوں میں، انہوں نے ایک بار بھی نہیں سوچا کہ اگر بیرونی خدمات متاثر ہوں تو کیا ہو سکتا ہے۔
اگر آپ پچھلی تصویر میں سروس کی حدود کو دیکھیں تو آپ دیکھ سکتے ہیں کہ وہ سب غلط ہیں۔ بہت سارے ذرائع ہیں جو سروس کی حدود کی وضاحت کرنے کے بارے میں مشورہ دیتے ہیں، اور زیادہ تر یہ غلط کرتے ہیں، جیسے کہ اگلی سلائیڈ پر مائیکروسافٹ۔
یہ تصویر MS بلاگ کی ہے جس کے عنوان پر "مائیکرو سروسز کیسے بنائیں"۔ یہ ایک سادہ ویب ایپلیکیشن، کاروباری منطق کا ایک بلاک، اور ایک ڈیٹا بیس دکھاتا ہے۔ درخواست براہ راست آتی ہے، شاید ویب کے لیے ایک سرور، کاروبار کے لیے ایک سرور اور ڈیٹا بیس کے لیے ایک سرور ہے۔ اگر آپ ٹریفک بڑھائیں گے تو تصویر تھوڑی بدل جائے گی۔
یہاں دو ویب سرورز کے درمیان ٹریفک کو تقسیم کرنے کے لیے ایک لوڈ بیلنسر آتا ہے، ویب سروس اور بزنس لاجک کے درمیان موجود ایک کیش، اور بزنس لاجک اور ڈیٹا بیس کے درمیان دوسرا کیش۔ یہ بالکل وہی آرکیٹیکچر بیل ہے جو 2000 کی دہائی کے وسط میں لوڈ بیلنسنگ اور بلیو/گرین ڈیپلائمنٹ ایپلی کیشن کے لیے استعمال کیا گیا تھا۔ کچھ وقت تک سب کچھ ٹھیک کام کرتا تھا، کیونکہ یہ اسکیم یک سنگی ڈھانچے کے لیے تھی۔
مندرجہ ذیل تصویر سے پتہ چلتا ہے کہ کس طرح MS ایک یک سنگی سے مائیکرو سروسز کی طرف جانے کی تجویز کرتا ہے - بس ہر ایک اہم خدمات کو الگ الگ مائیکرو سروسز میں تقسیم کرنا۔ اس اسکیم کے نفاذ کے دوران ہی بیل نے غلطی کی تھی۔
انہوں نے اپنی تمام خدمات کو مختلف درجوں میں تقسیم کیا، جن میں سے ہر ایک بہت سی انفرادی خدمات پر مشتمل تھی۔ مثال کے طور پر، ویب سروس میں مواد کی رینڈرنگ اور تصدیق کے لیے مائیکرو سروسز شامل تھیں، بزنس لاجک سروس آرڈرز اور اکاؤنٹ کی معلومات پر کارروائی کے لیے مائیکرو سروسز پر مشتمل تھی، ڈیٹا بیس کو خصوصی ڈیٹا کے ساتھ مائیکرو سروسز کے ایک گروپ میں تقسیم کیا گیا تھا۔ ویب، کاروباری منطق، اور ڈیٹا بیس دونوں ہی بے وطن خدمات تھیں۔
تاہم، یہ تصویر مکمل طور پر غلط تھی کیونکہ اس نے کمپنی کے آئی ٹی کلسٹر سے باہر کسی کاروباری یونٹ کا نقشہ نہیں بنایا تھا۔ اس اسکیم میں بیرونی دنیا کے ساتھ کسی بھی تعلق کو مدنظر نہیں رکھا گیا تھا، اس لیے یہ واضح نہیں تھا کہ، مثال کے طور پر، تیسرے فریق کے کاروباری تجزیات کو کیسے حاصل کیا جائے۔ میں نوٹ کرتا ہوں کہ ان کے پاس انفرادی ملازمین کے کیریئر کو ترقی دینے کے لیے کئی خدمات بھی ایجاد کی گئی تھیں جنہوں نے اس کے لیے زیادہ سے زیادہ رقم حاصل کرنے کے لیے زیادہ سے زیادہ لوگوں کا انتظام کرنے کی کوشش کی۔
ان کا خیال تھا کہ مائیکرو سروسز میں جانا اتنا ہی آسان ہے جتنا کہ ان کے اندرونی N-tier فزیکل لیئر انفراسٹرکچر کو لینا اور اس پر Docker کو چسپاں کرنا۔ آئیے ایک نظر ڈالتے ہیں کہ روایتی N-tier فن تعمیر کیسا لگتا ہے۔
یہ 4 سطحوں پر مشتمل ہے: UI صارف انٹرفیس کی سطح، کاروباری منطق کی سطح، ڈیٹا تک رسائی کی سطح اور ڈیٹا بیس۔ زیادہ ترقی پسند DDD (ڈومین سے چلنے والا ڈیزائن)، یا سافٹ ویئر پر مبنی فن تعمیر ہے، جہاں دو درمیانی سطحیں ڈومین آبجیکٹ اور ایک ذخیرہ ہیں۔
میں نے اس فن تعمیر میں تبدیلی کے مختلف شعبوں، ذمہ داری کے مختلف شعبوں کو دیکھنے کی کوشش کی۔ ایک عام N-tier ایپلی کیشن میں، تبدیلی کے مختلف شعبوں کی درجہ بندی کی جاتی ہے جو ڈھانچے کو عمودی طور پر اوپر سے نیچے تک پھیلاتے ہیں۔ یہ کیٹلاگ، انفرادی کمپیوٹرز پر کی جانے والی کنفیگ سیٹنگز، اور چیک آؤٹ چیکس ہیں، جنہیں میری ٹیم نے ہینڈل کیا تھا۔
اس اسکیم کی خاصیت یہ ہے کہ تبدیلی کے ان شعبوں کی حدود نہ صرف کاروباری منطق کی سطح کو متاثر کرتی ہیں بلکہ ڈیٹا بیس تک بھی پھیلتی ہیں۔
آئیے دیکھتے ہیں کہ خدمت کا مطلب کیا ہے۔ سروس کی تعریف کی 6 خصوصیات ہیں - یہ سافٹ ویئر ہے جو:
- ایک مخصوص تنظیم کی طرف سے بنایا اور استعمال کیا؛
- سسٹم کے اندر کسی خاص قسم کی معلومات کے مواد، پروسیسنگ اور/یا فراہمی کے لیے ذمہ دار ہے؛
- مخصوص آپریشنل ضروریات کو پورا کرنے کے لیے بنایا، تعینات اور آزادانہ طور پر چلایا جا سکتا ہے۔
- صارفین اور دیگر خدمات کے ساتھ بات چیت کرتا ہے، معاہدوں یا معاہدہ کی ضمانتوں پر مبنی معلومات فراہم کرتا ہے۔
- خود کو غیر مجاز رسائی سے بچاتا ہے، اور اس کی معلومات کو نقصان سے بچاتا ہے۔
- ناکامیوں کو اس طرح سنبھالتا ہے کہ وہ معلومات کو نقصان کا باعث نہ بنیں۔
ان تمام خصوصیات کو ایک لفظ "خودمختاری" میں بیان کیا جا سکتا ہے۔ خدمات ایک دوسرے سے آزادانہ طور پر کام کرتی ہیں، کچھ پابندیوں کو پورا کرتی ہیں، اور معاہدوں کی وضاحت کرتی ہیں جن کی بنیاد پر لوگ اپنی مطلوبہ معلومات حاصل کر سکتے ہیں۔ میں نے مخصوص ٹیکنالوجیز کا ذکر نہیں کیا، جن کا استعمال خود واضح ہے۔
اب آئیے مائیکرو سروسز کی تعریف کو دیکھتے ہیں:
- ایک مائیکرو سروس سائز میں چھوٹی ہے اور ایک مخصوص مسئلہ کو حل کرنے کے لیے ڈیزائن کیا گیا ہے۔
- مائیکرو سروس خود مختار ہے؛
- مائیکرو سروس آرکیٹیکچر بناتے وقت، ٹاؤن پلاننگ کا استعارہ استعمال کیا جاتا ہے۔ یہ سیم نیومین کی کتاب بلڈنگ مائیکرو سروسز کی تعریف ہے۔
Bounded Context کی تعریف ایرک ایونز کی کتاب Domain-driven Design سے لی گئی ہے۔ یہ ڈی ڈی ڈی میں ایک بنیادی نمونہ ہے، ایک آرکیٹیکچر ڈیزائن سینٹر جو حجمی آرکیٹیکچرل ماڈلز کے ساتھ کام کرتا ہے، انہیں مختلف باؤنڈڈ سیاق و سباق میں تقسیم کرتا ہے اور ان کے درمیان تعاملات کو واضح طور پر بیان کرتا ہے۔
سیدھے الفاظ میں، ایک پابند سیاق و سباق اس دائرہ کار کی نشاندہی کرتا ہے جس میں ایک خاص ماڈیول استعمال کیا جاسکتا ہے۔ اس تناظر میں ایک منطقی طور پر متحد ماڈل ہے جسے دیکھا جا سکتا ہے، مثال کے طور پر، آپ کے کاروباری ڈومین میں۔ اگر آپ آرڈرز میں شامل اہلکاروں سے پوچھیں گے کہ "کلائنٹ کون ہے"، تو آپ کو ایک تعریف ملے گی، اگر آپ سیلز میں شامل افراد سے پوچھیں گے، تو آپ کو دوسری ملے گی، اور اداکار آپ کو تیسری تعریف دیں گے۔
لہذا، باؤنڈڈ سیاق و سباق کہتا ہے کہ اگر ہم اس بات کی واضح تعریف نہیں دے سکتے کہ ہماری خدمات کا صارف کیا ہے، تو آئیے ان حدود کی وضاحت کریں جن کے اندر ہم اس اصطلاح کے معنی کے بارے میں بات کر سکتے ہیں، اور پھر ان مختلف تعریفوں کے درمیان منتقلی کے مقامات کی وضاحت کریں۔ یعنی، اگر ہم آرڈر دینے کے نقطہ نظر سے کسی کلائنٹ کے بارے میں بات کر رہے ہیں، تو اس کا مطلب ہے یہ اور وہ، اور اگر سیلز کے نقطہ نظر سے، اس کا مطلب ہے یہ اور وہ۔
مائیکرو سرویس کی اگلی تعریف کسی بھی قسم کی اندرونی کارروائیوں کا انکیپسولیشن ہے، جو کام کے عمل کے اجزا کے ماحول میں "رساو" کو روکتی ہے۔ اس کے بعد "بیرونی تعاملات، یا بیرونی مواصلات کے لیے واضح معاہدوں کی تعریف" آتی ہے، جس کی نمائندگی SLAs سے واپس آنے والے معاہدوں کے خیال سے ہوتی ہے۔ آخری تعریف سیل کا استعارہ ہے، یا سیل، جس کا مطلب ہے مائیکرو سروس کے اندر آپریشنز کے ایک سیٹ کا مکمل انکیپسولیشن اور اس میں بیرونی دنیا کے ساتھ مواصلت کے لیے ریسیپٹرز کی موجودگی۔
لہذا ہم نے بیل کمپیوٹرز کے لڑکوں سے کہا، "ہم آپ کے پیدا کردہ کسی بھی افراتفری کو ٹھیک نہیں کر سکتے کیونکہ آپ کے پاس اسے کرنے کے لیے پیسے نہیں ہیں، لیکن ہم صرف ایک سروس کو ٹھیک کریں گے تاکہ یہ سب کچھ ہو جائے۔ احساس." اس مقام پر، میں آپ کو یہ بتا کر شروع کروں گا کہ ہم نے اپنی واحد سروس کو کیسے ٹھیک کیا تاکہ اس نے ساڑھے 9 منٹ سے زیادہ تیزی سے درخواستوں کا جواب دیا۔
22:30 منٹ
بہت جلد جاری رکھا جائے گا...
تھوڑا سا اشتہار
ہمارے ساتھ رہنے کے لیے آپ کا شکریہ۔ کیا آپ کو ہمارے مضامین پسند ہیں؟ مزید دلچسپ مواد دیکھنا چاہتے ہیں؟ آرڈر دے کر یا دوستوں کو مشورہ دے کر ہمارا ساتھ دیں، , انٹری لیول سرورز کا ایک انوکھا اینالاگ، جو ہم نے آپ کے لیے ایجاد کیا تھا: (RAID1 اور RAID10 کے ساتھ دستیاب، 24 کور تک اور 40GB DDR4 تک)۔
ایمسٹرڈیم میں Equinix Tier IV ڈیٹا سینٹر میں Dell R730xd 2 گنا سستا؟ صرف یہاں نیدرلینڈ میں! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 سے! کے بارے میں پڑھا
ماخذ: www.habr.com