ڈوڈو آئی ایس آرکیٹیکچر کی تاریخ: بیک آفس پاتھ

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

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

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

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

1. ڈوڈو IS میں ابتدائی یک سنگی (2011-2015)۔ (کام جاری ہے...)
2. دفتر کا پچھلا راستہ: علیحدہ اڈے اور بس۔ (آپ یہاں ہیں)
3. کلائنٹ کی طرف کا راستہ: بیس کے اوپر اگواڑا (2016-2017)۔ (کام جاری ہے...)
4. حقیقی مائیکرو سروسز کی تاریخ۔ (2018-2019)۔ (کام جاری ہے...)
5. یک سنگی کی آری ختم اور فن تعمیر کا استحکام۔ (کام جاری ہے...)

اگر آپ کچھ اور جاننا چاہتے ہیں تو - تبصرے میں لکھیں۔

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

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

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

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

2020 تک، یہ کچھ زیادہ پیچیدہ ہو گیا ہے اور اس طرح ہو گیا ہے:

یہ ارتقاء کیسے ہوا؟ نظام کے مختلف حصوں کی ضرورت کیوں ہے؟ کون سے تعمیراتی فیصلے کیے گئے اور کیوں؟ آئیے مضامین کے اس سلسلے میں تلاش کرتے ہیں۔

2016 کے پہلے مسائل: خدمات کو یک سنگی کیوں چھوڑنا چاہیے۔

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

ایک واحد MySql ڈیٹا بیس، جس میں ڈوڈو IS میں اس وقت موجود تمام ایپلیکیشنز نے اپنے ریکارڈ لکھے۔ اس کے نتائج یہ تھے:

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

مسئلہ خود monolith کی موجودگی کا تھا۔. اس کے نتائج یہ تھے:

• سنگل اور نایاب ریلیز۔
• لوگوں کی ایک بڑی تعداد کی مشترکہ نشوونما میں دشواری۔
• نئی ٹیکنالوجی، نئے فریم ورک اور لائبریریاں لانے میں ناکامی۔

بیس اور یک سنگی کے ساتھ مسائل کو کئی بار بیان کیا گیا ہے، مثال کے طور پر، 2018 کے اوائل میں کریشوں کے تناظر میں (منچ کی طرح بنیں، یا تکنیکی قرض کے بارے میں کچھ الفاظ, جس دن ڈوڈو آئی ایس رک گیا۔ غیر مطابقت پذیر اسکرپٹ и فینکس خاندان کے ڈوڈو پرندے کی کہانی۔ ڈوڈو آئی ایس کا عظیم زوال)، تو میں زیادہ نہیں رہوں گا۔ میں صرف یہ کہوں گا کہ ہم خدمات تیار کرتے وقت مزید لچک دینا چاہتے تھے۔ سب سے پہلے، یہ ان لوگوں سے متعلق ہے جو پورے سسٹم میں سب سے زیادہ بھرے ہوئے اور جڑ تھے - Auth اور Tracker۔

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

باب نیویگیشن

1. یک سنگی اسکیم 2016
2. مونولیتھ کو اتارنا شروع کرنا: تصدیق اور ٹریکر کی علیحدگی
   
3. Auth کیا کرتا ہے؟
4. بوجھ کہاں سے ہے؟
5. Auth اتار رہا ہے۔
6. ٹریکر کیا کرتا ہے؟
7. بوجھ کہاں سے ہے؟
8. ان لوڈنگ ٹریکر

یک سنگی اسکیم 2016

ڈوڈو IS 2016 یک سنگی کے اہم بلاکس یہ ہیں، اور بالکل نیچے ان کے اہم کاموں کی نقل ہے۔

کیشئر ڈیلیوری۔ کوریئرز کے لیے اکاؤنٹنگ، کوریئرز کو آرڈر جاری کرنا۔
رابطہ مرکز. آپریٹر کے ذریعے احکامات کی قبولیت۔
سائٹ. ہماری ویب سائٹس (dodopizza.ru، dodopizza.co.uk، dodopizza.by، وغیرہ)۔
مصنف. بیک آفس کے لیے اجازت اور تصدیق کی خدمت۔
ٹریکر۔. کچن میں ٹریکر آرڈر کریں۔ آرڈر تیار کرتے وقت تیاری کے حالات کو نشان زد کرنے کی خدمت۔
ریستوراں کا کیش ڈیسک. ایک ریستوراں، کیشئر انٹرفیس میں آرڈر لینا۔
برآمد. اکاؤنٹنگ کے لیے 1C میں رپورٹس اپ لوڈ کرنا۔
اطلاعات اور رسیدیں. باورچی خانے میں صوتی احکامات (مثال کے طور پر، "نیا پیزا آگیا") + کورئیر کے لیے انوائس پرنٹنگ۔
شفٹ مینیجر. شفٹ مینیجر کے کام کے لیے انٹرفیس: آرڈرز کی فہرست، کارکردگی کا گراف، ملازمین کی شفٹ میں منتقلی۔
دفتر کا منتظم. فرنچائزی اور مینیجر کے کام کے لیے انٹرفیس: ملازمین کا استقبال، پزیریا کے کام پر رپورٹس۔
ریستوراں اسکور بورڈ. پزیریا میں ٹی وی پر مینو ڈسپلے۔
منتظم. ایک مخصوص پزیریا میں ترتیبات: مینو، قیمتیں، اکاؤنٹنگ، پرومو کوڈز، پروموشنز، ویب سائٹ بینرز وغیرہ۔
ملازم کا ذاتی اکاؤنٹ. ملازمین کے کام کا نظام الاوقات، ملازمین کے بارے میں معلومات۔
کچن موٹیویشن بورڈ. ایک الگ اسکرین جو کچن میں لٹکتی ہے اور پیزا بنانے والوں کی رفتار دکھاتی ہے۔
مواصلات. ایس ایم ایس اور ای میل بھیج رہا ہے۔
فائل اسٹوریج. جامد فائلیں وصول کرنے اور جاری کرنے کے لیے اپنی سروس۔

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

مونولیتھ کو اتارنا شروع کرنا: تصدیق اور ٹریکر کی علیحدگی

اہم خدمات جو پھر ڈیٹا بیس سے دوسروں سے زیادہ ریکارڈ اور پڑھتی ہیں:

1. تصنیف بیک آفس کے لیے اجازت اور تصدیق کی خدمت۔
2. ٹریکر کچن میں ٹریکر آرڈر کریں۔ آرڈر تیار کرتے وقت تیاری کے حالات کو نشان زد کرنے کی خدمت۔

Auth کیا کرتا ہے؟

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

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

بوجھ کہاں سے ہے؟

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

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

Auth اتار رہا ہے۔

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

WAS کام کی اصل اسکیم مندرجہ ذیل تھی:

میں تھوڑی وضاحت کرنا چاہوں گا کہ اس نے کیسے کام کیا:

1. باہر سے ایک درخواست بیک اینڈ پر آتی ہے (وہاں Asp.Net MVC ہے)، اپنے ساتھ ایک سیشن کوکی لاتی ہے، جو Redis(1) سے سیشن ڈیٹا حاصل کرنے کے لیے استعمال ہوتی ہے۔ یہ یا تو رسائی کے بارے میں معلومات پر مشتمل ہے، اور پھر کنٹرولر تک رسائی کھلی ہے (3,4)، یا نہیں۔
2. اگر رسائی نہیں ہے تو، آپ کو اجازت دینے کے طریقہ کار سے گزرنا ہوگا۔ یہاں، سادگی کے لیے، اسے اسی وصف میں راستے کے حصے کے طور پر دکھایا گیا ہے، حالانکہ یہ لاگ ان پیج پر منتقلی ہے۔ مثبت منظر نامے کی صورت میں، ہم صحیح طریقے سے مکمل ہونے والا سیشن حاصل کریں گے اور بیک آفس کنٹرولر کے پاس جائیں گے۔
3. اگر ڈیٹا ہے، تو آپ کو صارف کے ڈیٹا بیس میں مطابقت کے لیے اسے چیک کرنے کی ضرورت ہے۔ کیا اس کا کردار بدل گیا ہے، کیا اب اسے صفحہ پر آنے کی اجازت نہیں دی جانی چاہیے؟ اس صورت میں، سیشن (1) حاصل کرنے کے بعد، آپ کو براہ راست ڈیٹا بیس پر جانا ہوگا اور تصدیقی منطق کی تہہ (2) کا استعمال کرتے ہوئے صارف کی رسائی کو چیک کرنا ہوگا۔ اگلا، یا تو لاگ ان صفحہ پر، یا کنٹرولر پر جائیں۔ اتنا آسان نظام، لیکن بالکل معیاری نہیں۔
4. اگر تمام طریقہ کار کو منظور کر لیا جاتا ہے، تو ہم کنٹرولرز اور طریقوں میں منطق میں آگے بڑھ جاتے ہیں۔

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

بننا۔ چنانچہ انہوں نے کیا:

اس نقطہ نظر میں کئی مسائل ہیں۔ مثال کے طور پر، کسی عمل کے اندر کسی طریقہ کو کال کرنا HTTP کے ذریعے کسی بیرونی سروس کو کال کرنے جیسا نہیں ہے۔ تاخیر، وشوسنییتا، برقرار رکھنے، آپریشن کی شفافیت بالکل مختلف ہیں۔ Andrey Morevskiy نے اپنی رپورٹ میں اس طرح کے مسائل کے بارے میں مزید تفصیل سے بات کی۔ "مائیکرو سروسز کے 50 شیڈز".

تصدیق کی خدمت اور اس کے ساتھ، ڈیوائس سروس کو بیک آفس کے لیے استعمال کیا جاتا ہے، یعنی پروڈکشن میں استعمال ہونے والی خدمات اور انٹرفیس کے لیے۔ کلائنٹ کی خدمات (جیسے ویب سائٹ یا موبائل ایپلیکیشن) کے لیے توثیق بغیر کسی Auth کا استعمال کیے الگ سے ہوتی ہے۔ علیحدگی میں تقریباً ایک سال لگا، اور اب ہم دوبارہ اس موضوع سے نمٹ رہے ہیں، سسٹم کو نئی تصدیقی خدمات (معیاری پروٹوکول کے ساتھ) میں منتقل کر رہے ہیں۔

جدائی میں اتنا عرصہ کیوں لگا؟
راستے میں بہت سے مسائل تھے جنہوں نے ہمیں سست کیا:

1. ہم صارف، ڈیوائس، اور تصدیقی ڈیٹا کو ملک کے مخصوص ڈیٹا بیس سے ایک میں منتقل کرنا چاہتے تھے۔ ایسا کرنے کے لیے، ہمیں تمام ٹیبلز اور استعمال کو int identifier سے عالمی UUId شناخت کنندہ میں ترجمہ کرنا پڑا (حال ہی میں اس کوڈ کو دوبارہ بنایا گیا رومن بکن "Uuid - ایک چھوٹی ساخت کی ایک بڑی کہانی" اور اوپن سورس پروجیکٹ پرائمری)۔ صارف کے ڈیٹا کو ذخیرہ کرنے کی (چونکہ یہ ذاتی معلومات ہے) کی اپنی حدود ہیں اور کچھ ممالک کے لیے انہیں الگ سے ذخیرہ کرنا ضروری ہے۔ لیکن صارف کی عالمی آئی ڈی ہونی چاہیے۔
2. ڈیٹا بیس میں بہت سی جدولوں میں آپریشن کرنے والے صارف کے بارے میں آڈٹ کی معلومات ہوتی ہیں۔ اس کے لیے مستقل مزاجی کے لیے ایک اضافی میکانزم کی ضرورت تھی۔
3. اے پی آئی سروسز کی تخلیق کے بعد، دوسرے نظام میں منتقلی کا ایک طویل اور بتدریج دور تھا۔ سوئچنگ صارفین کے لیے بغیر کسی رکاوٹ کے ہونا چاہیے اور دستی کام کی ضرورت تھی۔

پزیریا میں ڈیوائس رجسٹریشن اسکیم:

توثیق اور آلات کی خدمت کو نکالنے کے بعد عمومی فن تعمیر:

نوٹ. 2020 کے لیے، ہم Auth کے ایک نئے ورژن پر کام کر رہے ہیں، جو OAuth 2.0 کی اجازت کے معیار پر مبنی ہے۔ یہ معیار کافی پیچیدہ ہے، لیکن یہ پاس تھرو توثیق سروس تیار کرنے کے لیے مفید ہے۔ مضمون میں "اجازت کی باریکیاں: OAuth 2.0 ٹیکنالوجی کا ایک جائزہہم نے الیکسی چیرنائیف نے اس معیار کے بارے میں ہر ممکن حد تک آسان اور واضح طور پر بتانے کی کوشش کی تاکہ آپ اس کے مطالعہ میں وقت بچائیں۔

ٹریکر کیا کرتا ہے؟

اب بھری ہوئی خدمات کے دوسرے کے بارے میں. ٹریکر دوہری کردار ادا کرتا ہے:

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

جب کوئی نیا پروڈکٹ آرڈر میں ظاہر ہوتا ہے (مثال کے طور پر، پیزا)، تو یہ رولنگ آؤٹ ٹریکر اسٹیشن پر جاتا ہے۔ اس اسٹیشن پر، ایک پیزا بنانے والا ہے جو مطلوبہ سائز کا ایک بن لیتا ہے اور اسے رول آؤٹ کرتا ہے، جس کے بعد وہ ٹریکر ٹیبلٹ پر نوٹ کرتا ہے کہ اس نے اپنا کام مکمل کر لیا ہے اور رولڈ ڈو بیس کو اگلے اسٹیشن پر منتقل کر دیا ہے - "Initiation" .

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

ٹریکر "راسکٹکا" کے اسٹیشن پر ٹیبلٹ کی سکرین اس طرح دکھائی دیتی ہے

بوجھ کہاں سے ہے؟

ہر ایک پزیریا میں ٹریکر کے ساتھ تقریباً پانچ گولیاں ہوتی ہیں۔ 2016 میں، ہمارے پاس 100 سے زیادہ پزیریا تھے (اور اب 600 سے زیادہ)۔ ہر ایک ٹیبلیٹ ہر 10 سیکنڈ میں ایک بار بیک اینڈ سے درخواست کرتا ہے اور آرڈر ٹیبل (کلائنٹ اور ایڈریس کے ساتھ کنکشن)، آرڈر کمپوزیشن (مصنوعات کے ساتھ کنکشن اور مقدار کا اشارہ)، موٹیویشن اکاؤنٹنگ ٹیبل ( دبانے کا وقت اس میں ٹریک کیا جاتا ہے)۔ جب پیزا بنانے والا ٹریکر پر کسی پروڈکٹ پر کلک کرتا ہے، تو ان تمام ٹیبلز میں اندراجات کو اپ ڈیٹ کر دیا جاتا ہے۔ آرڈر ٹیبل عام ہے، اس میں آرڈر قبول کرتے وقت انسرٹس، سسٹم کے دوسرے حصوں سے اپ ڈیٹس اور متعدد ریڈنگز بھی ہوتی ہیں، مثال کے طور پر، ایک ٹی وی پر جو پیزیریا میں لٹکا ہوا ہے اور گاہکوں کو تیار شدہ آرڈر دکھاتا ہے۔

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

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

WAS اصل فن تعمیر یہ تھا:

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

ان لوڈنگ ٹریکر

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

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

آرڈر کے حالات کو تبدیل کرنے کی اسکیم اس طرح نظر آتی ہے:

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

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

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

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

قدم بہ قدم راستہ ترتیب دیں۔
آرڈر کا راستہ آرڈر سورس سروسز میں سے ایک سے شروع ہوتا ہے۔ ریسٹورنٹ کا کیشیئر یہ ہے:

1. چیک آؤٹ پر، آرڈر مکمل طور پر تیار ہے، اور اسے ٹریکر کو بھیجنے کا وقت آگیا ہے۔ جس ایونٹ میں ٹریکر کو سبسکرائب کیا جاتا ہے اسے پھینک دیا جاتا ہے۔
2. ٹریکر، اپنے لیے آرڈر قبول کرتا ہے، اسے اپنے ڈیٹا بیس میں محفوظ کرتا ہے، جس سے ایونٹ "آرڈر ایکپٹڈ بائی دی ٹریکر" بنتا ہے اور اسے RMQ کو بھیجتا ہے۔
3. فی آرڈر ایونٹ بس میں پہلے ہی کئی ہینڈلرز سبسکرائب کر چکے ہیں۔ ہمارے لیے، وہ جو یک سنگی بنیاد کے ساتھ ہم آہنگی پیدا کرتا ہے اہم ہے۔
4. ہینڈلر ایک ایونٹ وصول کرتا ہے، اس میں سے ڈیٹا منتخب کرتا ہے جو اس کے لیے اہم ہوتا ہے: ہمارے معاملے میں، یہ آرڈر کی حیثیت "ٹریکر کے ذریعے قبول شدہ" ہے اور مین ڈیٹا بیس میں اس کے آرڈر کی ہستی کو اپ ڈیٹ کرتا ہے۔

اگر کسی کو یک سنگی ٹیبل آرڈرز سے آرڈر کی ضرورت ہو تو آپ اسے وہاں سے بھی پڑھ سکتے ہیں۔ مثال کے طور پر، شفٹ مینیجر میں آرڈرز انٹرفیس کو اس کی ضرورت ہے:

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

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

Auth اور Tracker میں تبدیلیوں کے بعد حتمی فن تعمیر

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

اس طرح کے مواد کے فوائد (یا اس کی کمی) پر غور کرتے ہوئے، میں اس نتیجے پر پہنچا کہ واقعات کی مکمل تاریخوں، تفصیلی پسپائی اور اپنے ماضی کے فیصلوں کے تجزیے کے بغیر مسلسل ترقی ناممکن ہے۔

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

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

ڈوڈو آئی ایس کے کس حصے کے بارے میں آپ اگلے مضمون میں جاننا چاہیں گے؟

• 24,1٪ڈوڈو IS میں ابتدائی یک سنگی (2011-2015)14

• 24,1٪پہلے مسائل اور ان کا حل (2015-2016)14

• 20,7٪کلائنٹ سائیڈ پاتھ: اگواڑا اوور بیس (2016-2017)12

• 36,2٪حقیقی مائیکرو سروسز کی تاریخ (2018-2019)21

• 44,8٪یک سنگی کی مکمل آری اور فن تعمیر کا استحکام 26

• 29,3٪سسٹم کی ترقی کے لیے مزید منصوبوں کے بارے میں 17

• 19,0٪میں ڈوڈو IS11 کے بارے میں کچھ نہیں جاننا چاہتا

58 صارفین نے ووٹ دیا۔ 6 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com