ڈوڈو آئی ایس آرکیٹیکچر کی تاریخ: ایک ابتدائی مونولتھ

یا یک سنگی کے ساتھ ہر ناخوش کمپنی اپنے طریقے سے ناخوش ہے۔

ڈوڈو آئی ایس سسٹم کی ترقی فوری طور پر شروع ہوئی، ڈوڈو پیزا کے کاروبار کی طرح - 2011 میں۔ یہ کاروباری عمل کے مکمل اور مکمل ڈیجیٹائزیشن کے خیال پر مبنی تھا، اور اپنے بل بوتے پےجس نے 2011 میں بھی کئی سوالات اور شکوک و شبہات کو جنم دیا۔ لیکن اب 9 سالوں سے ہم اس راستے پر چل رہے ہیں - اپنی ترقی کے ساتھ، جس کا آغاز یک سنگی سے ہوا تھا۔

یہ مضمون ان سوالوں کا "جواب" ہے "کیوں فن تعمیر کو دوبارہ لکھا جائے اور اتنی بڑے پیمانے پر اور طویل مدتی تبدیلیاں کیوں کی جائیں؟" پچھلے مضمون تک "ڈوڈو آئی ایس فن تعمیر کی تاریخ: پچھلے دفتر کا راستہ". میں شروع کروں گا کہ ڈوڈو IS کی ترقی کیسے شروع ہوئی، ابتدائی فن تعمیر کیسا تھا، نئے ماڈیول کیسے ظاہر ہوئے، اور کن مسائل کی وجہ سے بڑے پیمانے پر تبدیلیاں کرنا پڑیں۔

مضامین کی سیریز "ڈوڈو آئی ایس کیا ہے؟" کے بارے میں بتاتا ہے:

1. ڈوڈو IS میں ابتدائی یک سنگی (2011-2015)۔ (آپ یہاں ہیں)

2. بیک آفس کا راستہ: علیحدہ اڈے اور بس.

3. کلائنٹ کی طرف کا راستہ: بیس کے اوپر اگواڑا (2016-2017)۔ (کام جاری ہے...)

4. حقیقی مائیکرو سروسز کی تاریخ۔ (2018-2019)۔ (کام جاری ہے...)

5. یک سنگی کی آری ختم اور فن تعمیر کا استحکام۔ (کام جاری ہے...)

ابتدائی فن تعمیر

2011 میں، ڈوڈو IS فن تعمیر اس طرح نظر آیا:

فن تعمیر میں پہلا ماڈیول آرڈر کی قبولیت ہے۔ کاروباری عمل اس طرح تھا:

• ایک گاہک پزیریا کو کال کرتا ہے؛

• مینیجر فون اٹھاتا ہے۔

• فون پر آرڈر لیتا ہے؛

• ایک ہی وقت میں، یہ اسے آرڈر کی قبولیت کے انٹرفیس میں بھرتا ہے: کلائنٹ کے بارے میں معلومات، آرڈر کی تفصیلات پر ڈیٹا، اور ڈیلیوری ایڈریس کو مدنظر رکھا جاتا ہے۔ 

انفارمیشن سسٹم کا انٹرفیس کچھ اس طرح نظر آیا...

اکتوبر 2011 سے پہلا ورژن:

جنوری 2012 میں قدرے بہتری آئی

انفارمیشن سسٹم ڈوڈو پیزا ڈیلیوری پیزا ریسٹورنٹ

پہلے آرڈر لینے والے ماڈیول کو تیار کرنے کے وسائل محدود تھے۔ بہت کچھ کرنا ضروری تھا، جلدی اور ایک چھوٹی ٹیم کے ساتھ۔ چھوٹی ٹیم 2 ڈویلپرز پر مشتمل ہے جنہوں نے مستقبل کے پورے نظام کی بنیاد رکھی۔

ان کے پہلے فیصلے نے ٹیکنالوجی اسٹیک کی مستقبل کی قسمت کا تعین کیا:

• ASP.NET MVC، C# زبان پر بیک اینڈ۔ ڈویلپر ڈاٹ نیٹر تھے؛ یہ اسٹیک ان کے لیے مانوس اور خوشگوار تھا۔

• بوٹسٹریپ اور JQuery پر فرنٹ اینڈ: کسٹم اسٹائل اور اسکرپٹس پر مبنی یوزر انٹرفیس۔ 

• MySQL ڈیٹا بیس: لائسنس کی کوئی قیمت نہیں، استعمال میں آسان۔

• ونڈوز سرور پر سرورز، کیونکہ .NET پھر صرف ونڈوز پر ہو سکتا ہے (ہم مونو پر بات نہیں کریں گے)۔

جسمانی طور پر، یہ سب "میزبان کی میز" میں ظاہر کیا گیا تھا۔ 

آرڈر کی منظوری کی درخواست کا فن تعمیر

اس وقت، ہر کوئی پہلے سے ہی مائیکرو سروسز کے بارے میں بات کر رہا تھا، اور SOA کو تقریباً 5 سال سے بڑے پروجیکٹس میں استعمال کیا جا رہا تھا، مثال کے طور پر، WCF کو 2006 میں جاری کیا گیا تھا۔ لیکن پھر انہوں نے ایک قابل اعتماد اور ثابت شدہ حل کا انتخاب کیا۔

یہ رہا.

Asp.Net MVC Razor ہے، جو فارم یا کلائنٹ کی درخواست پر، سرور پر رینڈرنگ کے ساتھ ایک HTML صفحہ تیار کرتا ہے۔ کلائنٹ پر، CSS اور JS اسکرپٹ پہلے سے ہی معلومات کو ظاہر کرتے ہیں اور اگر ضروری ہو تو، JQuery کے ذریعے AJAX کی درخواستیں انجام دیتے ہیں۔

سرور پر درخواستیں *کنٹرولر کلاسز میں آتی ہیں، جہاں طریقہ کار پر کارروائی کرتا ہے اور حتمی HTML صفحہ تیار کرتا ہے۔ کنٹرولرز منطق کی ایک پرت سے درخواستیں کرتے ہیں جسے *Services کہتے ہیں۔ خدمات میں سے ہر ایک کاروبار کے کسی نہ کسی پہلو سے مطابقت رکھتی ہے:

• مثال کے طور پر، DepartmentStructureService نے پزیریا اور محکموں کے بارے میں معلومات فراہم کیں۔ محکمہ پزیریا کا ایک گروپ ہوتا ہے جس کا انتظام ایک فرنچائزی کرتا ہے۔

• ReceivingOrdersService موصول ہوئی اور آرڈر کے مواد کا حساب لگایا۔

• اور ایس ایم ایس سروس نے ایس ایم ایس بھیجنے کے لیے API سروسز کو کال کرکے ایس ایم ایس بھیجا۔

خدمات نے ڈیٹا بیس سے ڈیٹا پر کارروائی کی اور کاروباری منطق کو ذخیرہ کیا۔ ہر سروس میں مناسب نام کے ساتھ ایک یا زیادہ *ذخیرے ہوتے تھے۔ ان میں ڈیٹا بیس میں ذخیرہ شدہ طریقہ کار اور میپرز کی ایک پرت سے متعلق سوالات پہلے ہی موجود تھے۔ ذخیروں میں کاروباری منطق تھی، خاص طور پر ان میں سے بہت سے جنہوں نے رپورٹنگ ڈیٹا تیار کیا۔ ORM استعمال نہیں کیا گیا تھا، سب نے ہاتھ سے لکھے ہوئے sql پر انحصار کیا۔ 

ڈومین ماڈل اور عام مددگار کلاسوں کی ایک پرت بھی تھی، مثال کے طور پر، آرڈر کلاس، جو آرڈر کو محفوظ کرتی ہے۔ وہاں، پرت میں، منتخب کرنسی کے مطابق ڈسپلے ٹیکسٹ کو تبدیل کرنے کے لیے ایک مددگار موجود تھا۔

یہ سب اس ماڈل کی طرف سے پیش کیا جا سکتا ہے:

آرڈر کرنے کا طریقہ

آئیے اس طرح کا آرڈر بنانے کے لیے ایک آسان ابتدائی طریقہ پر غور کریں۔

ابتدائی طور پر سائٹ جامد تھی۔ اس پر قیمتیں تھیں اور سب سے اوپر ایک فون نمبر اور لکھا ہوا تھا "اگر آپ پیزا چاہتے ہیں تو اس نمبر پر کال کریں اور آرڈر کریں۔" آرڈر کرنے کے لیے، ہمیں ایک سادہ بہاؤ کو لاگو کرنے کی ضرورت ہے: 

• کلائنٹ قیمتوں کے ساتھ ایک مستحکم ویب سائٹ پر جاتا ہے، مصنوعات کا انتخاب کرتا ہے اور ویب سائٹ پر درج نمبر پر کال کرتا ہے۔

• گاہک ان پروڈکٹس کو نام دیتا ہے جنہیں وہ آرڈر میں شامل کرنا چاہتا ہے۔

• اپنا پتہ اور نام بتاتا ہے۔

• آپریٹر آرڈر کو قبول کرتا ہے۔

• آرڈر قبول شدہ آرڈرز کے انٹرفیس میں ظاہر ہوتا ہے۔

یہ سب مینو ڈسپلے کے ساتھ شروع ہوتا ہے۔ ایک لاگ ان آپریٹر صارف ایک وقت میں صرف ایک آرڈر قبول کرتا ہے۔ لہذا، ڈرافٹ کارٹ کو اس کے سیشن میں محفوظ کیا جا سکتا ہے (صارف کا سیشن میموری میں محفوظ ہوتا ہے)۔ ایک کارٹ آبجیکٹ ہے جس میں پروڈکٹس اور کسٹمر کی معلومات ہیں۔

کلائنٹ پروڈکٹ کا نام دیتا ہے، آپریٹر کلک کرتا ہے۔ + پروڈکٹ کے ساتھ، اور سرور کو ایک درخواست بھیجی جاتی ہے۔ پروڈکٹ کے بارے میں معلومات کو ڈیٹا بیس سے نکالا جاتا ہے اور پروڈکٹ کے بارے میں معلومات کارٹ میں شامل کی جاتی ہیں۔

نوٹ. ہاں، یہاں آپ کو پروڈکٹ کو ڈیٹا بیس سے باہر نہیں نکالنا ہوگا، بلکہ اسے سامنے والے سرے سے منتقل کرنا ہوگا۔ لیکن وضاحت کے لیے، میں نے اڈے سے بالکل راستہ دکھایا۔ 

اگلا، کلائنٹ کا پتہ اور نام درج کریں۔ 

جب آپ "آرڈر بنائیں" پر کلک کریں:

• ہم OrderController.SaveOrder() کو درخواست بھیجتے ہیں۔

• ہمیں سیشن سے کارٹ ملتا ہے، ہماری ضرورت کی مقدار میں پروڈکٹس موجود ہیں۔

• ہم کلائنٹ کے بارے میں معلومات کے ساتھ کارٹ کی تکمیل کرتے ہیں اور اسے RecevingOrderService کلاس کے AddOrder طریقہ میں منتقل کرتے ہیں، جہاں اسے ڈیٹا بیس میں محفوظ کیا جاتا ہے۔ 

• ڈیٹا بیس میں آرڈر کے ساتھ میزیں، آرڈر کے مواد، کلائنٹ، اور وہ سب منسلک ہیں۔

• آرڈر ڈسپلے انٹرفیس جاتا ہے اور تازہ ترین آرڈرز نکالتا ہے اور انہیں دکھاتا ہے۔

نئے ماڈیولز

حکم وصول کرنا اہم اور ضروری تھا۔ اگر آپ کے پاس فروخت کا آرڈر نہیں ہے تو آپ پیزا کا کاروبار نہیں چلا سکتے۔ لہذا، نظام نے فعالیت کو حاصل کرنا شروع کر دیا - تقریبا 2012 سے 2015 تک. اس وقت کے دوران، سسٹم کے بہت سے مختلف بلاکس نمودار ہوئے، جنہیں میں کال کروں گا۔ ماڈیولزسروس یا پروڈکٹ کے تصور کے برخلاف۔ 

ایک ماڈیول افعال کا ایک مجموعہ ہے جو کچھ مشترکہ کاروباری مقصد سے متحد ہوتا ہے۔ مزید یہ کہ وہ جسمانی طور پر ایک ہی درخواست میں واقع ہیں۔

ماڈیولز کو سسٹم بلاکس کہا جا سکتا ہے۔ مثال کے طور پر، یہ ایک رپورٹنگ ماڈیول ہے، ایڈمن انٹرفیس، کچن پروڈکٹ ٹریکر، اجازت یہ سب مختلف یوزر انٹرفیس ہیں، کچھ کے مختلف بصری انداز بھی ہوتے ہیں۔ مزید یہ کہ، سب کچھ ایک ایپلیکیشن، ایک چل رہا عمل کے اندر ہے۔ 

تکنیکی طور پر، ماڈیولز کو ایریا کے طور پر ڈیزائن کیا گیا تھا (یہ آئیڈیا یہاں تک برقرار رہا۔ asp.net کور)۔ فرنٹ اینڈ، ماڈلز کے ساتھ ساتھ ان کی اپنی کنٹرولر کلاسز کے لیے الگ فائلیں تھیں۔ نتیجے کے طور پر، نظام کو اس طرح سے تبدیل کر دیا گیا تھا ...

...اس کے لیے:

کچھ ماڈیولز کو الگ الگ سائٹس (قابل عمل پراجیکٹ) کے ذریعے لاگو کیا جاتا ہے، مکمل طور پر الگ فعالیت کی وجہ سے اور جزوی طور پر کچھ الگ، زیادہ توجہ مرکوز ترقی کی وجہ سے۔ یہ:

• سائٹ - پہلا ورژن ویب سائٹ dodopizza.ru.

• برآمد: 1C کے لیے Dodo IS سے رپورٹس ڈاؤن لوڈ کرنا۔ 

• ذاتی - ملازم کا ذاتی اکاؤنٹ۔ اسے الگ سے تیار کیا گیا تھا اور اس کا اپنا داخلہ پوائنٹ اور الگ ڈیزائن ہے۔

• fs - جامد ہوسٹنگ کے لیے پروجیکٹ۔ بعد میں ہم اس سے دور ہو گئے، تمام جامد مواد کو اکامائی CDN میں منتقل کر دیا۔ 

باقی بلاکس بیک آفس ایپلی کیشن میں واقع تھے۔ 

ناموں کی وضاحت:

• کیشئر - ریسٹورانٹ کیش رجسٹر۔

• ShiftManager - "Shift Manager" کے کردار کے لیے انٹرفیس: پزیریا کی فروخت پر آپریشنل اعدادوشمار، مصنوعات کو اسٹاپ لسٹ میں ڈالنے کی صلاحیت، آرڈر تبدیل کرنا۔

• OfficeManager - "Pizzeria Manager" اور "Franchisee" کے کرداروں کے لیے انٹرفیس۔ یہاں آپ پزیریا قائم کرنے، اس کے بونس پروموشنز، ملازمین کے ساتھ کام کرنے اور وصول کرنے کے فنکشنز اور رپورٹس تلاش کر سکتے ہیں۔

• پبلک اسکرینز - ٹی وی اور ٹیبلیٹ کے لیے انٹرفیس جو پزیریا میں لٹک رہے ہیں۔ ٹی وی ڈیلیوری پر مینو، اشتہاری معلومات، اور آرڈر کی حیثیت دکھاتے ہیں۔ 

انہوں نے ایک مشترکہ سروس پرت، Dodo.Core ڈومین کلاسز کا ایک مشترکہ بلاک، اور ایک مشترکہ بنیاد کا استعمال کیا۔ کبھی کبھی وہ اب بھی ایک دوسرے کے حصئوں سے گزر سکتے تھے۔ اس کے علاوہ، انفرادی سائٹس، جیسے dodopizza.ru یا personal.dodopizza.ru، نے بھی عام خدمات تک رسائی حاصل کی۔

جب نئے ماڈیولز نمودار ہوئے، ہم نے کوشش کی کہ پہلے سے بنائے گئے کوڈ کو زیادہ سے زیادہ استعمال کریں جو پہلے سے خدمات، ذخیرہ شدہ طریقہ کار اور ڈیٹا بیس میں ٹیبلز کے لیے ہیں۔ 

سسٹم میں بنائے گئے ماڈیولز کے پیمانے کی بہتر تفہیم کے لیے، یہاں 2012 کا ایک خاکہ ہے جس میں ترقیاتی منصوبے ہیں:

2015 تک، سب کچھ ٹریک پر تھا اور اس سے بھی زیادہ پیداوار میں تھا۔

• آرڈر کی قبولیت رابطہ مرکز کے ایک علیحدہ بلاک میں بڑھ گئی ہے، جہاں آپریٹر کے ذریعہ آرڈر کو قبول کیا جاتا ہے۔

• مینو اور معلومات کے ساتھ عوامی اسکرینیں pizzerias میں نمودار ہوئی ہیں۔

• باورچی خانے میں ایک ماڈیول ہے جو نیا آرڈر آنے پر خود بخود صوتی پیغام "نیو پیزا" چلاتا ہے، اور کورئیر کے لیے ایک رسید بھی پرنٹ کرتا ہے۔ یہ باورچی خانے میں عمل کو بہت آسان بناتا ہے اور ملازمین کو بڑی تعداد میں سادہ کاموں سے مشغول نہیں ہونے دیتا ہے۔

• ڈیلیوری بلاک ایک علیحدہ ڈیلیوری کیشئر بن گیا، جہاں کورئیر کو آرڈر جاری کیا گیا، جو پہلے اپنی شفٹ لے چکا تھا۔ اس کی تنخواہ کا حساب لگانے کے لیے اس کے اوقات کار کو مدنظر رکھا گیا۔ 

متوازی طور پر، 2012 سے 2015 تک، 10 سے زیادہ ڈویلپرز نمودار ہوئے، 35 پزیریا کھولے گئے، سسٹم کو رومانیہ میں تعینات کیا گیا اور امریکہ میں پوائنٹس کھولنے کے لیے تیار کیا گیا۔ ڈویلپرز اب تمام کاموں میں شامل نہیں تھے بلکہ ٹیموں میں تقسیم تھے۔ ہر ایک نظام کے اپنے حصے میں مہارت رکھتا ہے۔ 

مسائل

بشمول فن تعمیر کی وجہ سے (لیکن نہ صرف)۔

بیس میں افراتفری

ایک بنیاد آسان ہے۔ مستقل مزاجی حاصل کرنا ممکن ہے، اور متعلقہ ڈیٹا بیس میں بنائے گئے ٹولز کی قیمت پر۔ اس کے ساتھ کام کرنا واقف اور آسان ہے، خاص طور پر اگر کچھ میزیں اور بہت کم ڈیٹا ہوں۔

لیکن 4 سال کی ترقی کے دوران، ڈیٹا بیس میں تقریباً 600 میزیں، 1500 ذخیرہ شدہ طریقہ کار تھے، جن میں سے بہت سے منطق بھی تھے۔ بدقسمتی سے، MySQL کے ساتھ کام کرتے وقت ذخیرہ شدہ طریقہ کار زیادہ فائدہ فراہم نہیں کرتے ہیں۔ وہ ڈیٹا بیس کے ذریعہ محفوظ نہیں ہیں، اور ان میں منطق کو ذخیرہ کرنا ترقی اور ڈیبگنگ کو پیچیدہ بناتا ہے۔ کوڈ کو دوبارہ استعمال کرنا بھی مشکل ہے۔

بہت سی میزوں میں مناسب اشاریہ جات نہیں تھے۔، کہیں، اس کے برعکس، بہت سارے اشاریہ جات تھے، جس نے اندراج مشکل بنا دیا۔ تقریباً 20 ٹیبلز میں ترمیم کرنا پڑی- آرڈر بنانے کے لیے لین دین میں تقریباً 3-5 سیکنڈ لگ سکتے ہیں۔ 

جدولوں میں موجود ڈیٹا ہمیشہ مناسب شکل میں نہیں ہوتا تھا۔. کہیں ڈی نارملائزیشن کرنا ضروری تھا۔ باقاعدگی سے موصول ہونے والے ڈیٹا میں سے کچھ XML ڈھانچے کی شکل میں ایک کالم میں تھا، جس نے عمل درآمد کے وقت میں اضافہ کیا، سوالات کو بڑھایا اور پیچیدہ ترقی کی۔

ایک ہی میزیں بہت سے مشروط تھیں۔ متضاد درخواستیں. مقبول میزیں، جیسا کہ اوپر ذکر کردہ جدول، خاص طور پر متاثر ہوئے تھے۔ احکامات یا میزیں پزجفیریا. وہ باورچی خانے اور تجزیات میں آپریشنل انٹرفیس کو ظاہر کرنے کے لیے استعمال کیے گئے تھے۔ سائٹ نے ان سے بھی رابطہ کیا (dodopizza.ru)، جہاں کسی بھی وقت بہت ساری درخواستیں اچانک پہنچ سکتی ہیں۔ 

ڈیٹا اکٹھا نہیں کیا گیا۔ اور بیس کا استعمال کرتے ہوئے مکھی پر بہت سے حساب کتاب ہوئے۔ اس سے غیر ضروری حساب کتاب اور اضافی بوجھ پیدا ہوا۔ 

اکثر کوڈ ڈیٹا بیس میں چلا جاتا ہے جب یہ ایسا نہیں کر سکتا تھا۔ کہیں بلک آپریشنز کی کمی تھی، کہیں تیز رفتاری اور قابل اعتمادی بڑھانے کے لیے ایک درخواست کو کوڈ کے ذریعے کئی میں تقسیم کرنا ضروری ہوگا۔ 

کوڈ میں ہم آہنگی اور الجھن

جن ماڈیولز کو کاروبار کے اپنے حصے کا ذمہ دار ہونا چاہیے تھا وہ ایمانداری سے نہیں کر پائے. ان میں سے کچھ کے پاس کرداروں کے لیے افعال کی نقل تھی۔ مثال کے طور پر، ایک مقامی مارکیٹر جو اپنے شہر میں کسی نیٹ ورک کی مارکیٹنگ کی سرگرمی کا ذمہ دار ہے، اسے "ایڈمن" انٹرفیس (پروموشنز سیٹ اپ کرنے کے لیے) اور "آفس مینیجر" انٹرفیس (پروموشنز کے اثرات کو دیکھنے کے لیے) دونوں استعمال کرنا ہوں گے۔ کاروبار)۔ بلاشبہ، دونوں ماڈیولز کے اندر ایک ہی سروس کا استعمال کیا گیا، جس نے بونس پروموشنز کے ساتھ کام کیا۔

خدمات (ایک یک سنگی بڑے پروجیکٹ کے اندر کلاسز) اپنے ڈیٹا کو بہتر بنانے کے لیے ایک دوسرے کو کال کر سکتی ہیں۔

خود ماڈل کلاسز کے ساتھ جو ڈیٹا کو اسٹور کرتے ہیں، کوڈ میں کام مختلف طریقے سے کیا گیا تھا۔. کہیں کنسٹرکٹرز تھے جن کے ذریعے آپ مطلوبہ فیلڈز کی وضاحت کر سکتے تھے۔ کہیں یہ کام پبلک پراپرٹیز کے ذریعے کیا گیا۔ یقینا، ڈیٹا بیس سے ڈیٹا حاصل کرنا اور تبدیل کرنا مختلف تھا۔ 

منطق یا تو کنٹرولرز یا سروس کلاسز میں تھی۔ 

یہ معمولی مسائل کی طرح لگتے ہیں، لیکن انہوں نے ترقی کو بہت سست کر دیا اور معیار کو کم کر دیا، جس سے عدم استحکام اور کیڑے پیدا ہوئے۔ 

بڑی ترقی کی پیچیدگی

ترقی میں ہی مشکلات پیدا ہوئیں. یہ نظام کے مختلف بلاکس بنانے کے لئے ضروری تھا، اور متوازی میں. ہر جزو کی ضروریات کو ایک کوڈ میں فٹ کرنا مشکل ہوتا گیا۔ ایک ہی وقت میں تمام اجزاء کو راضی کرنا اور خوش کرنا آسان نہیں تھا۔ اس میں ٹیکنالوجی کی حدود شامل ہیں، خاص طور پر بیس اور فرنٹ اینڈ کے حوالے سے۔ اعلیٰ سطحی فریم ورک کے حق میں JQuery کو ترک کرنا ضروری تھا، خاص طور پر کلائنٹ سروسز (ویب سائٹ) کے معاملے میں۔

سسٹم کے کچھ حصے ڈیٹا بیس استعمال کر سکتے ہیں جو اس کے لیے زیادہ موزوں ہیں۔. مثال کے طور پر، بعد میں ہمارے پاس آرڈر کی ٹوکری کو ذخیرہ کرنے کے لیے Redis سے CosmosDB پر سوئچ کرنے کی ایک مثال تھی۔ 

اپنی فیلڈ میں ٹیمیں اور ڈویلپرز واضح طور پر اپنی خدمات کے لیے مزید آزادی چاہتے ہیں، ترقی کے لحاظ سے اور رول آؤٹ کے لحاظ سے۔ انضمام کے دوران تنازعات، ریلیز کے دوران مسائل۔ اگر 5 ڈویلپرز کے لیے یہ مسئلہ غیر معمولی ہے، تو 10 کے ساتھ، اور اس سے بھی زیادہ منصوبہ بند ترقی کے ساتھ، سب کچھ زیادہ سنگین ہو جائے گا۔ اور جو آنے والا تھا وہ ایک موبائل ایپلیکیشن کی ترقی تھی (اس کی شروعات 2017 میں ہوئی تھی، اور 2018 میں تھی بڑا زوال). 

نظام کے مختلف حصوں کو مختلف استحکام کے اشارے کی ضرورت ہوتی ہے۔لیکن سسٹم کے مضبوط کنیکٹیویٹی کی وجہ سے، ہم یہ فراہم نہیں کر سکے۔ ایڈمن پینل میں ایک نیا فنکشن تیار کرتے وقت ایک خرابی سائٹ پر آرڈر کی منظوری کی صورت میں نکل سکتی تھی، کیونکہ کوڈ عام اور دوبارہ قابل استعمال ہے، ڈیٹا بیس اور ڈیٹا بھی ایک جیسا ہے۔

اس طرح کے یک سنگی ماڈیولر فن تعمیر کے فریم ورک کے اندر ان غلطیوں اور مسائل سے بچنا شاید ممکن ہو گا: ذمہ داریوں کی علیحدگی بنائیں، کوڈ اور ڈیٹا بیس دونوں کو ریفیکٹر کریں، ایک دوسرے سے واضح طور پر پرتیں الگ کریں، اور ہر روز معیار کی نگرانی کریں۔ لیکن منتخب کردہ آرکیٹیکچرل حل اور نظام کی فعالیت کو تیزی سے بڑھانے پر توجہ کے باعث استحکام کے معاملات میں مسائل پیدا ہوئے۔

بلاگ پاور آف مائنڈ ریستوراں میں کیش رجسٹر کیسے رکھتا ہے۔

اگر پزیریا نیٹ ورک کی ترقی (اور لوڈ) اسی رفتار سے جاری رہی تو تھوڑی دیر کے بعد قطرے ایسے ہوں گے کہ نظام ٹھیک نہیں ہوگا۔ درج ذیل کہانی ان مسائل کو اچھی طرح سے بیان کرتی ہے جن کا ہم نے 2015 سے سامنا کرنا شروع کیا تھا۔ 

بلاگ میں "دماغی طاقت"وہاں ایک ویجیٹ تھا جس نے پورے نیٹ ورک کے لئے سال کے لئے آمدنی کا ڈیٹا دکھایا۔ ویجیٹ نے عوامی ڈوڈو API تک رسائی حاصل کی، جو یہ ڈیٹا فراہم کرتا ہے۔ یہ اعدادوشمار اب پر دستیاب ہیں۔ http://dodopizzastory.com/. ویجیٹ ہر صفحے پر دکھایا گیا تھا اور ہر 20 سیکنڈ میں ٹائمر پر درخواستیں کی گئی تھیں۔ درخواست api.dodopizza.ru پر گئی اور پوچھا:

• نیٹ ورک میں pizzerias کی تعداد؛

• سال کے آغاز سے نیٹ ورک کی کل آمدنی؛

• آج کی آمدنی.

ریونیو کے اعدادوشمار کی درخواست سیدھی ڈیٹا بیس پر گئی اور آرڈرز پر ڈیٹا کی درخواست کرنا شروع کر دی، ڈیٹا کو براہ راست جمع کر کے رقم جاری کریں۔ 

ریستورانوں میں کیش رجسٹر آرڈرز کی اسی میز پر گئے، آج کے لیے قبول کیے گئے آرڈرز کی فہرست اپ لوڈ کی، اور اس میں نئے آرڈرز شامل کیے گئے۔ کیش رجسٹر ہر 5 سیکنڈ میں اپنی درخواستیں دیتے تھے یا جب صفحہ ریفریش ہوتا تھا۔

خاکہ اس طرح نظر آیا:

موسم خزاں میں ایک دن، فیوڈور اوچنیکوف نے اپنے بلاگ پر ایک طویل اور مقبول مضمون لکھا۔ بہت سارے لوگ بلاگ پر آئے اور سب کچھ غور سے پڑھنے لگے۔ جب کہ آنے والے لوگوں میں سے ہر ایک مضمون پڑھ رہا تھا، ریونیو ویجیٹ نے ٹھیک سے کام کیا اور ہر 20 سیکنڈ میں API کی درخواست کی۔

API نے نیٹ ورک میں موجود تمام پزیریاز کے لیے سال کے آغاز سے لے کر اب تک کے تمام آرڈرز کی مقدار کا حساب لگانے کے لیے ایک ذخیرہ شدہ طریقہ کار کہا ہے۔ جمع آرڈر ٹیبل پر مبنی تھا، جو بہت مشہور ہے۔ اس وقت تمام کھلے ریستورانوں کے تمام کیش رجسٹر اس پر جاتے ہیں۔ کیش رجسٹروں نے جواب دینا بند کر دیا اور احکامات کو قبول نہیں کیا گیا۔ انہیں سائٹ سے بھی قبول نہیں کیا گیا، ٹریکر پر ظاہر نہیں ہوئے، اور شفٹ مینیجر انہیں اپنے انٹرفیس میں نہیں دیکھ سکتا تھا۔ 

یہ واحد کہانی نہیں ہے۔ 2015 کے موسم خزاں تک، ہر جمعہ کو سسٹم پر بوجھ انتہائی نازک تھا۔ کئی بار ہم نے عوامی API کو آف کیا، اور ایک بار ہمیں سائٹ کو بھی بند کرنا پڑا کیونکہ کچھ بھی مدد نہیں کر رہا تھا۔ یہاں تک کہ بھاری بوجھ کے تحت بند ہونے کے حکم کے ساتھ خدمات کی ایک فہرست بھی تھی۔

اس وقت سے، بوجھ کے ساتھ اور نظام کے استحکام کے لیے ہماری جدوجہد شروع ہوتی ہے (موسم خزاں 2015 سے خزاں 2018 تک)۔ تب یہ ہوا"گریٹ فال" اس کے علاوہ، بعض اوقات ناکامیاں بھی ہوتی ہیں، جن میں سے کچھ بہت حساس ہوتی ہیں، لیکن اب عدم استحکام کے عمومی دور کو ختم سمجھا جا سکتا ہے۔

تیزی سے کاروبار کی ترقی

یہ "فوری طور پر ٹھیک" کیوں نہیں ہو سکتا؟ صرف مندرجہ ذیل گراف کو دیکھیں۔

اس کے علاوہ 2014-2015 میں رومانیہ میں ایک افتتاحی اور USA میں ایک افتتاحی تیاری کی جا رہی تھی۔

یہ سلسلہ بہت تیزی سے بڑھتا گیا، نئے ممالک کھل گئے، پزیریا کے نئے فارمیٹس نمودار ہوئے، مثال کے طور پر، فوڈ کورٹ میں ایک پزیریا کھلا۔ یہ سب خاص طور پر ڈوڈو آئی ایس کے افعال کو وسعت دینے پر خاص توجہ کی ضرورت ہے۔ ان تمام افعال کے بغیر، باورچی خانے میں ٹریکنگ کے بغیر، نظام میں مصنوعات اور نقصانات کا حساب کتاب، فوڈ کورٹ ہال میں آرڈرز کی ترسیل کو ظاہر کیے بغیر، اس بات کا امکان نہیں ہے کہ اب ہم "درست" فن تعمیر اور "درست" کے بارے میں بات کریں گے۔ "ترقی کا نقطہ نظر.

فن تعمیر کی بروقت نظر ثانی اور تکنیکی مسائل پر عام توجہ کی راہ میں ایک اور رکاوٹ 2014 کا بحران تھا۔ ایسی چیزیں ٹیموں کی ترقی کے مواقع کو نقصان پہنچاتی ہیں، خاص طور پر ڈوڈو پیزا جیسے نوجوان کاروبار کے لیے۔

فوری حل جنہوں نے مدد کی۔

مسائل کے حل کی ضرورت ہے۔ روایتی طور پر، حل 2 گروپوں میں تقسیم کیا جا سکتا ہے:

• تیز رفتار جو آگ کو بجھاتے ہیں اور ہمیں حفاظت کا ایک چھوٹا مارجن دیتے ہیں اور ہمیں تبدیل کرنے کا وقت خریدتے ہیں۔

• سیسٹیمیٹک اور اس لیے طویل۔ متعدد ماڈیولز کو دوبارہ انجینئر کرنا، یک سنگی فن تعمیر کو الگ الگ خدمات میں تقسیم کرنا (ان میں سے زیادہ تر مائیکرو نہیں ہیں، بلکہ میکرو سروسز ہیں، اور اس کے بارے میں بہت کچھ ہے۔ اینڈری موروسکی کی رپورٹ). 

فوری تبدیلیوں کی خشک فہرست یہ ہے:

بیس ماسٹر کو اسکیل کریں۔

بلاشبہ، لوڈ کا مقابلہ کرنے کے لیے سب سے پہلی چیز سرور کی طاقت کو بڑھانا ہے۔ یہ ماسٹر ڈیٹا بیس اور ویب سرورز کے لیے کیا گیا تھا۔ افسوس، یہ صرف ایک خاص حد تک ممکن ہے؛ اس سے آگے یہ بہت مہنگا ہو جاتا ہے۔

2014 کے بعد سے، ہم Azure میں چلے گئے ہیں؛ ہم نے اس موضوع کے بارے میں اس وقت کے مضمون میں بھی لکھا تھا۔ڈوڈو پیزا مائیکروسافٹ ایزور کلاؤڈ کا استعمال کرتے ہوئے پیزا کیسے ڈیلیور کرتا ہے۔" لیکن سرور میں اضافے کی ایک سیریز کے بعد، بیس کی قیمت ایک حد تک پہنچ گئی۔ 

پڑھنے کے لیے ڈیٹا بیس کی نقلیں

ہم نے بیس کے لئے دو نقلیں بنائیں:

ریپلیکا پڑھیں ڈائریکٹری کی درخواستوں کے لیے. یہ ڈائرکٹری پڑھنے کے لیے استعمال کیا جاتا ہے، جیسے شہر، گلی، پزیریا، مصنوعات (آہستہ آہستہ تبدیل شدہ ڈومین)، اور ان انٹرفیس میں جہاں تھوڑی تاخیر قابل قبول ہے۔ ان میں سے 2 نقلیں تھیں، ہم نے ماسٹر کی طرح ان کی دستیابی کو یقینی بنایا۔

رپورٹ کی درخواستوں کے لیے نقل پڑھیں. اس ڈیٹا بیس کی دستیابی کم تھی، لیکن تمام رپورٹس اس پر چلی گئیں۔ ان کے پاس بہت زیادہ ڈیٹا کی دوبارہ گنتی کے لیے بھاری درخواستیں ہوسکتی ہیں، لیکن وہ مرکزی ڈیٹا بیس اور آپریشنل انٹرفیس کو متاثر نہیں کرتے ہیں۔ 

کوڈ میں کیش

کوڈ میں کہیں بھی کوئی کیچ نہیں تھا (بالکل)۔ اس کی وجہ سے اضافی، ہمیشہ ضروری نہیں، بھری ہوئی ڈیٹا بیس کی درخواستیں ہوئیں۔ سب سے پہلے، کیش میموری میں تھے اور ایک بیرونی کیش سروس پر، یہ Redis تھی۔ سب کچھ وقت کے مطابق غلط تھا، کوڈ میں ترتیبات کی وضاحت کی گئی تھی۔

پسدید کے لیے ایک سے زیادہ سرورز

بڑھتے ہوئے بوجھ کو برداشت کرنے کے لیے ایپلیکیشن کے بیک اینڈ کو بھی چھوٹا کرنا پڑا۔ ایک IIS سرور سے کلسٹر بنانا ضروری تھا۔ ہم منتقل ہوگئے درخواست سیشن RedisCache پر میموری سے، جس نے راؤنڈ رابن کے ساتھ ایک سادہ لوڈ بیلنسر کے پیچھے کئی سرور بنانا ممکن بنایا۔ پہلے تو وہی ریڈیس استعمال کیا جاتا تھا جیسا کہ کیچز کے لیے، پھر وہ کئی حصوں میں تقسیم ہو گئے۔ 

نتیجے کے طور پر، فن تعمیر زیادہ پیچیدہ ہو گیا ...

...لیکن کچھ تناؤ دور ہو گیا تھا۔

اور پھر بھاری بھرکم اجزاء کو دوبارہ کرنا ضروری تھا، جو ہم نے اٹھایا۔ اس بارے میں ہم اگلے حصے میں بات کریں گے۔

ماخذ: www.habr.com