دودو IS آرڪيٽيڪچر جي تاريخ: پوئتي آفيس جو رستو

حبر دنيا کي تبديل ڪري رهيو آهي. اسان هڪ سال کان وڌيڪ وقت تائين بلاگنگ ڪري رهيا آهيون. اٽڪل ڇهه مهينا اڳ، اسان کي Khabrovites کان مڪمل طور تي منطقي موٽ ملي هئي: ”ڊوڊو، توهان هر هنڌ چوندا آهيو ته توهان جو پنهنجو سسٽم آهي. ۽ هي نظام ڇا آهي؟ ۽ ڇو هڪ پيزا زنجير ان جي ضرورت آهي؟

اسان ويٺا، سوچيو ۽ محسوس ڪيو ته توهان صحيح آهيو. اسان پنهنجي آڱرين تي سڀ ڪجهه بيان ڪرڻ جي ڪوشش ڪندا آهيون، پر اهو ٽڪر ٽڪر ۾ اچي ٿو ۽ ڪٿي به سسٽم جي مڪمل وضاحت ناهي. اهڙيءَ طرح معلومات گڏ ڪرڻ، ليکڪن جي ڳولا ۽ ڊوڊو IS بابت مضمونن جو هڪ سلسلو لکڻ جو هڪ ڊگهو سفر شروع ٿيو. اچو ته هلون!

قبوليتون: توهان جي راءِ اسان سان شيئر ڪرڻ لاءِ مهرباني. هن جي مهرباني، اسان آخرڪار سسٽم کي بيان ڪيو، هڪ ٽيڪنيڪل ريڊار مرتب ڪيو ۽ جلد ئي اسان جي عملن جو هڪ وڏو تفصيل ڪڍي ڇڏيندو. توهان جي بغير، اسان اتي 5 سالن تائين ويٺا آهيون.

مضمونن جو سلسلو "Dodo IS ڇا آهي؟" بابت ٻڌائي ٿو:

1. Dodo IS ۾ ابتدائي monolith (2011-2015). (جاري آهي…)
2. پوئين آفيس جو رستو: الڳ بيس ۽ بس. (توهان هتي آهيو)
3. ڪلائنٽ جي پاسي جو رستو: بيس مٿان منهن (2016-2017). (جاري آهي...)
4. حقيقي microservices جي تاريخ. (2018-2019). (جاري آهي...)
5. monolith جي آري ختم ڪئي وئي ۽ فن تعمير جي استحڪام. (جاري آهي...)

جيڪڏھن توھان ڪجھھ ڄاڻڻ ۾ دلچسپي رکو ٿا - تبصرن ۾ لکو.

مصنف کان تاريخ جي وضاحت تي راء
آئون باقاعده طور تي "سسٽم آرڪيٽيڪچر" جي موضوع تي نون ملازمن لاء هڪ اجلاس منعقد ڪندو آهيان. اسان ان کي سڏيندا آهيون “Intro to Dodo IS Architecture” ۽ اهو نون ڊولپرز لاءِ آن بورڊنگ عمل جو حصو آهي. اسان جي فن تعمير بابت، ان جي خاصيتن جي باري ۾، مون کي بيان ڪرڻ لاء هڪ خاص تاريخي انداز پيدا ڪيو آهي.

روايتي طور تي، اسان سسٽم کي اجزاء جي هڪ سيٽ جي طور تي ڏسون ٿا (ٽيڪنيڪل يا اعلي سطحي)، ڪاروباري ماڊل جيڪي هڪ ٻئي سان رابطو ڪن ٿا ڪجهه مقصد حاصل ڪرڻ لاء. ۽ جيڪڏهن اهڙي نظر هڪ ڊزائن لاء صحيح آهي، پوء اهو وضاحت ۽ سمجھڻ لاء بلڪل مناسب ناهي. هتي ڪيترائي سبب آهن:

• حقيقت ان کان مختلف آهي جيڪا ڪاغذ تي آهي. هر شي ڪم نه ڪندو آهي جيئن رٿابندي ڪئي وئي آهي. ۽ اسان دلچسپي رکون ٿا ته اهو اصل ۾ ڪيئن نڪتو ۽ ڪم ڪري ٿو.
• معلومات جي مسلسل پيشڪش. حقيقت ۾، توهان تاريخ جي شروعات کان وٺي موجوده حالت ڏانهن وڃو.
• سادي کان پيچيده تائين. عام طور تي نه، پر اسان جي صورت ۾ اهو آهي. فن تعمير کي آسان طريقن کان وڌيڪ پيچيده طريقن ڏانهن منتقل ڪيو ويو. گهڻو ڪري پيچيدگي جي ذريعي، عمل درآمد جي رفتار ۽ استحڪام جا مسئلا حل ڪيا ويا، ۽ گڏوگڏ ٻين ڪيترن ئي ملڪيتن جي فهرست مان غير فعال گهرجن (هتي ٻين ضرورتن سان متضاد پيچيدگي بابت چڱي طرح ٻڌايو).

2011 ۾، دودو IS فن تعمير هن طرح ڏٺو:

2020 تائين، اهو ٿورو وڌيڪ پيچيده ٿي چڪو آهي ۽ هن وانگر ٿي چڪو آهي:

هي ارتقا ڪيئن ٿيو؟ سسٽم جي مختلف حصن جي ضرورت ڇو آهي؟ ڪهڙا تعميراتي فيصلا ڪيا ويا ۽ ڇو؟ اچو ته مضمونن جي هن سلسلي ۾ ڳوليون.

2016 جو پهريون مسئلو: ڇو خدمتن کي monolith ڇڏڻ گهرجي

چڪر مان پهريون آرٽيڪل انهن خدمتن جي باري ۾ هوندو جيڪي پهريون ڀيرو مونولٿ کان الڳ ٿيڻ وارا هئا. توھان کي ان حوالي سان ٻڌائڻ لاءِ، مان توھان کي ٻڌايان ٿو ته 2016 جي شروعات تائين اسان کي سسٽم ۾ ڪھڙا مسئلا ھئا، جن کي اسان کي سروسز جي الڳ ٿيڻ سان معاملو ڪرڻو پيو.

هڪ واحد MySql ڊيٽابيس، جنهن ۾ سڀئي ايپليڪيشنون جيڪي ان وقت موجود هيون Dodo IS ۾ انهن جا رڪارڊ لکيا. ان جا نتيجا هي هئا:

• ڳري لوڊ (پڙهڻ جي حساب سان 85 سيڪڙو درخواستن سان).
• بنياد وڌي ويو آهي. انهي جي ڪري، ان جي قيمت ۽ حمايت هڪ مسئلو بڻجي ويو.
• ناڪامي جو واحد نقطو. جيڪڏهن ڊيٽابيس ڏانهن هڪ ايپليڪيشن لکڻ اوچتو ان کي وڌيڪ فعال طور تي ڪرڻ شروع ڪيو، پوء ٻين ايپليڪيشنن ان کي پاڻ تي محسوس ڪيو.
• اسٽوريج ۽ سوالن ۾ غير موثريت. گهڻو ڪري ڊيٽا ڪجهه ڍانچي ۾ محفوظ ڪئي وئي هئي جيڪا ڪجهه منظرنامن لاءِ آسان هئي پر ٻين لاءِ مناسب نه هئي. انڊيڪس ڪجهه عملن کي تيز ڪري ٿو، پر ٻين کي سست ڪري سگھي ٿو.
• ڪجھ مسئلا جلدي ٺاهي ڪيچز کي ختم ڪري ڇڏيا ويا ۽ بنيادي طور تي پڙهڻ واري نقل (هي هڪ الڳ مضمون ٿيندو)، پر انهن کي صرف وقت حاصل ڪرڻ جي اجازت ڏني وئي ۽ بنيادي طور تي مسئلو حل نه ڪيو.

مسئلو خود monolith جي موجودگي هو. ان جا نتيجا هي هئا:

• اڪيلو ۽ نادر رليز.
• ماڻهن جي وڏي تعداد جي گڏيل ترقي ۾ مشڪلات.
• نيون ٽيڪنالاجيون، نوان فريم ورڪ ۽ لائبريريون آڻڻ ۾ ناڪامي.

بنيادي ۽ monolith سان مسئلا ڪيترائي ڀيرا بيان ڪيا ويا آهن، مثال طور، 2018 جي ​​شروعات ۾ حادثن جي حوالي سان (منچ وانگر، يا ٽيڪنيڪل قرض بابت ڪجھ لفظ, جنهن ڏينهن دودو ايس ايس بند ٿي ويو. هم وقت ساز اسڪرپٽ и فينڪس خاندان مان دودو پکيءَ جي ڪهاڻي. دودو IS جو عظيم زوال)، تنهنڪري مان گهڻو نه رهندس. مون کي صرف اهو چوڻ ڏيو ته اسان وڌيڪ لچڪ ڏيڻ چاهيون ٿا جڏهن خدمتون ترقي ڪندي. سڀ کان پهريان، اهو انهن جو تعلق آهي جيڪي سڄي سسٽم ۾ سڀ کان وڌيڪ لوڊ ۽ روٽ هئا - Auth ۽ Tracker.

پوئين آفيس جو رستو: الڳ بيس ۽ بس

باب نيويگيشن

1. مونولٿ اسڪيم 2016
2. مونولٿ کي انلوڊ ڪرڻ شروع ڪيو: آٿ ۽ ٽريڪر علحدگي
   
3. Auth ڇا ڪندو آهي؟
4. لوڊ ڪٿي آهن؟
5. اڻ لوڊ ڪرڻ جو اختيار
6. ٽريڪٽر ڇا ڪندو آهي؟
7. لوڊ ڪٿي آهن؟
8. ان لوڊ ڪرڻ وارو ٽريڪٽر

مونولٿ اسڪيم 2016

هتي Dodo IS 2016 monolith جا مکيه بلاڪ آهن، ۽ هيٺ ڏنل انهن جي مکيه ڪمن جو هڪ نقل آهي.

ڪيشيئر پهچائڻ. ڪوريئرز لاءِ حساب ڪتاب، ڪوريئرز کي آرڊر جاري ڪرڻ.
رابطي جو مرڪز. آپريٽر ذريعي آرڊر جي قبوليت.
سائيٽ. اسان جون ويب سائيٽون (dodopizza.ru، dodopizza.co.uk، dodopizza.by، وغيره).
ليکڪ. پوئتي آفيس لاء اختيار ۽ تصديق جي خدمت.
ٽرڪر. رڌڻي ۾ آرڊر ٽريڪٽر. آرڊر تيار ڪرڻ وقت تياري جي حالتن کي نشانو بڻائڻ جي خدمت.
ريسٽورنٽ جي ڪيش ڊيسڪ. ريسٽورنٽ ۾ آرڊر وٺڻ، ڪيشيئر انٽرفيس.
ٻاھر موڪليو. اڪائونٽنگ لاءِ 1C ۾ رپورٽون اپ لوڊ ڪرڻ.
نوٽيفڪيشن ۽ انوائس. باورچی خانه ۾ وائس حڪم (مثال طور، "نئون پيزا اچي ويو") + ڪوريئرز لاءِ انوائس پرنٽنگ.
شفٽ مئنيجر. شفٽ مئنيجر جي ڪم لاء انٽرفيس: آرڊر جي فهرست، ڪارڪردگي گراف، ملازمن جي شفٽ کي منتقلي.
آفيس مينيجر. فرنچائز ۽ مئنيجر جي ڪم لاء انٽرفيس: ملازمن جي استقبال، پزيريا جي ڪم تي رپورٽون.
ريسٽورنٽ اسڪور بورڊ. پيزيريا ۾ ٽي وي تي مينيو ڊسپلي.
منتظم. سيٽنگون مخصوص پزيريا ۾: مينيو، قيمتون، اڪائونٽنگ، پرومو ڪوڊ، پروموشنز، ويب سائيٽ بينر، وغيره.
ملازم جو ذاتي اڪائونٽ. ملازمن جي ڪم جي شيڊول، ملازمن جي باري ۾ معلومات.
باورچی خانه جي ترغيب بورڊ. هڪ الڳ اسڪرين جيڪا باورچی خانه ۾ لڪي رهي آهي ۽ پيزا ٺاهيندڙن جي رفتار کي ڏيکاري ٿي.
ڪميونيڪيشن. ايس ايم ايس ۽ اي ميل موڪلڻ.
فائل اسٽوريج. جامد فائلون حاصل ڪرڻ ۽ جاري ڪرڻ لاءِ پنهنجي خدمت.

مسئلا حل ڪرڻ جي پهرين ڪوشش اسان جي مدد ڪئي، پر اهي صرف هڪ عارضي مهلت هئا. اهي سسٽم حل نه ٿي ويا، تنهنڪري اهو واضح هو ته ڪجهه بنيادن سان ڪرڻو پوندو. مثال طور، عام ڊيٽابيس کي ورهائڻ لاء ڪيترن ئي خاص ماڻهن ۾.

مونولٿ کي انلوڊ ڪرڻ شروع ڪيو: آٿ ۽ ٽريڪر علحدگي

مکيه خدمتون جيڪي پوءِ رڪارڊ ڪيون ويون ۽ ڊيٽابيس مان پڙهيل ٻين کان وڌيڪ:

1. آٿت. پوئتي آفيس لاء اختيار ۽ تصديق جي خدمت.
2. ٽريڪٽر. رڌڻي ۾ آرڊر ٽريڪٽر. آرڊر تيار ڪرڻ وقت تياري جي حالتن کي نشانو بڻائڻ جي خدمت.

Auth ڇا ڪندو آهي؟

Auth هڪ خدمت آهي جنهن ذريعي صارف واپس آفيس ۾ لاگ ان ٿيندا آهن (اتي ڪلائنٽ جي پاسي تي هڪ الڳ آزاد داخلا آهي). درخواست ۾ اهو پڻ چيو ويو آهي ته پڪ ڪرڻ لاء گهربل رسائي جا حق موجود آهن ۽ اهي حق آخري لاگ ان کان تبديل نه ٿيا آهن. ان جي ذريعي، ڊوائيسز پزيريا ۾ داخل ٿين ٿا.

مثال طور، اسان هال ۾ لڳل ٽي وي تي ختم ٿيل آرڊر جي حالتن سان هڪ ڊسپلي کولڻ چاهيون ٿا. ان کان پوء اسان auth.dodopizza.ru کوليو، چونڊيو "لاگ ان هڪ ڊيوائس طور"، هڪ ڪوڊ ظاهر ٿئي ٿو جيڪو هڪ خاص صفحي ۾ داخل ٿي سگهي ٿو شفٽ مئنيجر جي ڪمپيوٽر تي، ظاهر ڪري ٿو ڊوائيس جو قسم (ڊوائيس). ٽي وي پاڻ پنهنجي پزيريا جي گهربل انٽرفيس تي سوئچ ڪندو ۽ انهن گراهڪن جا نالا ظاهر ڪرڻ شروع ڪندو جن جا آرڊر اتي تيار آهن.

لوڊ ڪٿي آهن؟

پوئين آفيس جو هر لاگ ان ٿيل صارف ڊيٽابيس ڏانهن وڃي ٿو، هر درخواست لاءِ صارف جي ٽيبل تي، صارف کي sql سوال ذريعي ٻاهر ڪڍي ٿو ۽ چيڪ ڪري ٿو ته ڇا هن وٽ هن صفحي تائين گهربل رسائي ۽ حق آهن.

هر هڪ ڊوائيس ساڳيو ئي ڪري ٿو صرف ڊوائيس ٽيبل سان، ان جي ڪردار ۽ ان جي رسائي جي جانچ ڪندي. ماسٽر ڊيٽابيس ڏانهن درخواستن جو هڪ وڏو تعداد ان جي لوڊشيڊنگ ۽ انهن عملن لاءِ عام ڊيٽابيس جي وسيلن جي ضايع ٿيڻ جي ڪري ٿي.

اڻ لوڊ ڪرڻ جو اختيار

Auth وٽ ھڪڙو الڳ ٿيل ڊومين آھي، اھو آھي، صارفين، لاگ ان يا ڊوائيسز بابت ڊيٽا سروس ۾ داخل ٿئي ٿو (وقتي طور تي) ۽ اتي رھي ٿو. جيڪڏهن ڪنهن کي انهن جي ضرورت آهي، ته هو ڊيٽا لاء هن خدمت ڏانهن ويندي.

WAS. ڪم جي اصل اسڪيم هن ريت هئي:

مان ٿورڙي وضاحت ڪرڻ چاهيان ٿو ته اهو ڪيئن ڪم ڪيو:

1. ٻاهران هڪ درخواست پس منظر تي اچي ٿي (اتي آهي Asp.Net MVC)، ان سان گڏ هڪ سيشن ڪوڪي آڻيندو آهي، جيڪو Redis (1) کان سيشن ڊيٽا حاصل ڪرڻ لاءِ استعمال ڪيو ويندو آهي. اهو يا ته رسائي بابت معلومات تي مشتمل آهي، ۽ پوء ڪنٽرولر تائين رسائي کليل آهي (3,4)، يا نه.
2. جيڪڏهن رسائي نه آهي، توهان کي اجازت ڏيڻ جي طريقيڪار ذريعي وڃڻ جي ضرورت آهي. هتي، سادگي لاء، اهو ساڳيو خاصيت ۾ رستي جي حصي طور ڏيکاريل آهي، جيتوڻيڪ اهو لاگ ان صفحي ڏانهن منتقلي آهي. هڪ مثبت منظر جي صورت ۾، اسان کي صحيح طور تي مڪمل سيشن حاصل ڪنداسين ۽ واپس آفيس ڪنٽرولر ڏانهن وڃو.
3. جيڪڏهن ڊيٽا آهي، ته توهان کي ان کي جانچڻ جي ضرورت آهي صارف جي بنياد ۾ مطابقت لاء. ڇا هن جو ڪردار تبديل ٿي چڪو آهي، ڇا هن کي هاڻي صفحي تي وڃڻ نه ڏنو وڃي؟ انهي صورت ۾، سيشن حاصل ڪرڻ کان پوء (1)، توهان کي سڌو سنئون ڊيٽابيس ڏانهن وڃڻ جي ضرورت آهي ۽ تصديق ڪندڙ منطق پرت استعمال ڪندي صارف جي رسائي جي جانچ ڪريو (2). اڳيون، يا ته لاگ ان صفحي ڏانهن، يا ڪنٽرولر ڏانهن وڃو. اهڙي سادي نظام، پر ڪافي معياري نه آهي.
4. جيڪڏهن سڀئي طريقا گذري ويا آهن، پوء اسان اڳتي وڌون ٿا منطق ۾ ڪنٽرولرز ۽ طريقن ۾.

استعمال ڪندڙ جي ڊيٽا ٻين سڀني ڊيٽا کان الڳ ڪئي وئي آهي، اهو هڪ الڳ رڪنيت واري جدول ۾ ذخيرو ٿيل آهي، AuthService منطق جي پرت جا افعال شايد اي پي آئي طريقا بڻجي سگهن ٿيون. ڊومين جون حدون واضح طور تي بيان ڪيون ويون آهن: صارفين، انهن جا ڪردار، رسائي ڊيٽا، رسائي فراهم ڪرڻ ۽ رد ڪرڻ. هر شيءِ نظر اچي ٿي ته جيئن ان کي الڳ خدمت ۾ ڪڍي سگهجي.

ٿيو. تنهن ڪري هنن ڪيو:

هن طريقي سان ڪيترائي مسئلا آهن. مثال طور، هڪ عمل جي اندر هڪ طريقي کي ڪال ڪرڻ ساڳيو نه آهي جيئن http ذريعي هڪ ٻاهرين خدمت کي سڏڻ. دير، اعتبار، برقرار رکڻ، آپريشن جي شفافيت مڪمل طور تي مختلف آهن. Andrey Morevskiy پنهنجي رپورٽ ۾ اهڙن مسئلن بابت وڌيڪ تفصيل سان ڳالهايو. "مائڪرو سروسز جا 50 رنگ".

تصديق جي خدمت ۽، ان سان گڏ، ڊوائيس سروس واپس آفيس لاء استعمال ڪيو ويندو آهي، اهو آهي، پيداوار ۾ استعمال ڪيل خدمتن ۽ انٽرنيٽ لاء. ڪلائنٽ سروسز لاءِ تصديق (جهڙوڪ ويب سائيٽ يا موبائل ايپليڪيشن) الڳ الڳ ٿئي ٿي بغير استعمال ڪرڻ جي. علحدگيءَ ۾ اٽڪل ھڪ سال لڳي ويو، ۽ ھاڻي اسان وري ھن موضوع سان ڳالھائي رھيا آھيون، سسٽم کي نئين تصديق واري خدمتن ڏانھن منتقل ڪري رھيا آھيون (معياري پروٽوڪول سان).

علحدگيءَ ۾ ايترو وقت ڇو پيو؟
رستي ۾ ڪيترائي مسئلا هئا جن اسان کي سست ڪيو:

1. اسان چاهيون ٿا ته صارف، ڊوائيس، ۽ تصديق واري ڊيٽا کي ملڪ جي مخصوص ڊيٽابيس مان هڪ ۾ منتقل ڪيو وڃي. ائين ڪرڻ لاءِ، اسان کي int identifier کان عالمي UUId سڃاڻپ ڪندڙ تائين سڀني جدولن ۽ استعمال جو ترجمو ڪرڻو پوندو (تازو ئي هن ڪوڊ کي ٻيهر ڪم ڪيو رومن Bukin "Uuid - هڪ ننڍي جوڙجڪ جي هڪ وڏي ڪهاڻي" ۽ اوپن سورس پروجيڪٽ پرائمري). صارف جي ڊيٽا کي محفوظ ڪرڻ (جيئن ته اها ذاتي معلومات آهي) ان جون حدون آهن ۽ ڪجهه ملڪن لاءِ ان کي الڳ الڳ ذخيرو ڪرڻ ضروري آهي. پر صارف جي عالمي سڃاڻپ هجڻ ضروري آهي.
2. ڊيٽابيس ۾ ڪيترن ئي جدولن ۾ استعمال ڪندڙ جي باري ۾ آڊٽ معلومات آهي جنهن آپريشن ڪيو. انهي کي استحڪام لاء اضافي ميڪانيزم جي ضرورت آهي.
3. api-Services جي ٺهڻ کان پوء، اتي هڪ ڊگهي ۽ تدريجي دور جي هڪ ٻئي نظام ڏانهن منتقلي هئي. سوئچنگ کي استعمال ڪندڙن لاءِ بيحد ۽ ضروري دستي ڪم ڪرڻو پوندو.

هڪ pizzeria ۾ ڊوائيس رجسٽريشن اسڪيم:

Auth ۽ ڊوائيسز سروس جي نڪرڻ کان پوء عام فن تعمير:

ويچاري. 2020 لاءِ، اسان Auth جي نئين ورزن تي ڪم ڪري رهيا آهيون، جيڪو OAuth 2.0 اختيار ڪرڻ واري معيار تي ٻڌل آهي. اهو معيار ڪافي پيچيده آهي، پر اهو هڪ پاس-ذريعي تصديق جي خدمت کي ترقي ڪرڻ لاء ڪارائتو آهي. مضمون ۾ "اختيار جي ذيلي ذخيري: OAuth 2.0 ٽيڪنالاجي جو هڪ جائزو» اسان Alexey Chernyaev ڪوشش ڪئي ته معيار جي باري ۾ آسان ۽ واضح طور تي ٻڌايان ته جيئن توهان ان جي مطالعي ۾ وقت بچائي.

ٽريڪٽر ڇا ڪندو آهي؟

هاڻي لوڊ ٿيل خدمتن جي سيڪنڊ بابت. ٽريڪٽر هڪ ٻه ڪردار انجام ڏئي ٿو:

• هڪ پاسي، هن جو ڪم اهو آهي ته ملازمن کي باورچی خانه ۾ ڏيکاريو ته في الحال ڪم ۾ ڪهڙا آرڊر آهن، ڪهڙي شين کي هاڻي پکا ڪرڻ جي ضرورت آهي.
• ٻئي طرف، باورچی خانه ۾ سڀني عملن کي ڊجيٽل ڪرڻ لاء.

جڏهن هڪ نئين پراڊڪٽ آرڊر ۾ ظاهر ٿئي ٿي (مثال طور، پيزا)، اهو وڃي ٿو رولنگ آئوٽ ٽريڪر اسٽيشن. ھن اسٽيشن تي ھڪڙو پيزا ٺاھيندڙ آھي جيڪو گھربل سائيز جو بن کڻي ٿو ۽ ان کي رول آئوٽ ڪري ٿو، جنھن کان پوءِ ھو ٽريڪر ٽيبليٽ تي نوٽ ڪري ٿو ته ھن پنھنجو ڪم پورو ڪري ورتو آھي ۽ ڦريل ٻوٽي کي ايندڙ اسٽيشن ڏانھن منتقل ڪري ٿو - ”شروع“. .

اتي، ايندڙ پيزا ٺاهيندڙ پيزا ڀريندو آهي، پوءِ ٽيبل تي نوٽ ڪندو آهي ته هن پنهنجو ڪم پورو ڪيو آهي ۽ پيزا کي اوون ۾ رکي ٿو (هي پڻ هڪ الڳ اسٽيشن آهي جنهن کي ٽيبليٽ تي نوٽ ڪرڻ گهرجي). اهڙو نظام شروع کان وٺي دودو ۾ هو ۽ دودو داعش جي وجود جي شروعات کان وٺي. اهو توهان کي مڪمل طور تي ٽريڪ ڪرڻ ۽ سڀني ٽرانزيڪشن کي ڊجيٽل ڪرڻ جي اجازت ڏئي ٿو. ان کان علاوه، ٽريڪٽر مشورو ڏئي ٿو ته هڪ خاص پراڊڪٽ کي ڪيئن پکا ڪجي، هر قسم جي پراڊڪٽ کي ان جي پيداواري اسڪيمن جي مطابق هدايت ڪري ٿو، پراڊڪٽ لاءِ مناسب پچائڻ جو وقت محفوظ ڪري ٿو، ۽ پراڊڪٽ تي سڀني عملن کي ٽريڪ ڪري ٿو.

اهڙي طرح ٽيبل جي اسڪرين ٽريڪٽر جي اسٽيشن تي "Raskatka" وانگر ڏسڻ ۾ اچي ٿي

لوڊ ڪٿي آهن؟

هر هڪ پيزيريا ۾ اٽڪل پنج ٽيبلون آهن جن ۾ هڪ ٽريڪٽر آهي. 2016 ۾، اسان وٽ 100 کان وڌيڪ پزيريا هئا (۽ هاڻي 600 کان وڌيڪ). هر ٽيبليٽ هر 10 سيڪنڊن ۾ هڪ ڀيرو پس منظر ڏانهن هڪ درخواست ڪري ٿو ۽ آرڊر ٽيبل مان ڊيٽا کي ڇڪي ٿو (ڪلائنٽ ۽ ايڊريس سان ڪنيڪشن)، آرڊر جي جوڙجڪ (پراڊڪٽ سان ڪنيڪشن ۽ مقدار جو اشارو)، موويشن اڪائونٽنگ ٽيبل (جي دٻائڻ جو وقت ان ۾ ٽريڪ ٿيل آهي). جڏهن هڪ پيزا ٺاهيندڙ ٽريڪر تي هڪ پراڊڪٽ تي ڪلڪ ڪري ٿو، انهن سڀني جدولن ۾ داخل ٿيڻ کي اپڊيٽ ڪيو ويندو آهي. آرڊر ٽيبل عام آهي، ان ۾ پڻ شامل آهن جڏهن هڪ آرڊر قبول ڪيو وڃي، سسٽم جي ٻين حصن مان تازه ڪاريون ۽ ڪيترائي پڙهڻ، مثال طور، هڪ ٽي وي تي جيڪو پزيريا ۾ لٽڪيل آهي ۽ گراهڪن کي مڪمل آرڊر ڏيکاري ٿو.

لوڊ سان جدوجهد جي دور ۾، جڏهن هر شيء ۽ هر شيء کي ڪيش ڪيو ويو ۽ بيس جي غير مطابقت واري نقل ڏانهن منتقل ڪيو ويو، ٽريڪر سان اهي آپريشن ماسٽر بيس ڏانهن وڃڻ جاري رهيو. ڪو به دير نه هجڻ گهرجي، ڊيٽا کي اپڊيٽ ٿيڻ گهرجي، هم وقت سازي کان ٻاهر ناقابل قبول آهي.

ان سان گڏ، انھن تي پنھنجي جدولن ۽ انڊيڪسز جي کوٽ سبب انھن جي استعمال لاءِ تيار ڪيل وڌيڪ مخصوص سوالن کي لکڻ جي اجازت نه ڏني وئي. مثال طور، اهو ڪارائتو ٿي سگهي ٿو هڪ ٽريڪٽر لاءِ آرڊر ٽيبل تي پيزيريا لاءِ انڊيڪس. اسان هميشه ٽريڪٽر ڊيٽابيس مان پيززيريا آرڊر کي هٽايو. ساڳئي وقت، آرڊر حاصل ڪرڻ لاء، اهو ايترو ضروري ناهي ته اهو ڪهڙي پيززيريا ۾ اچي ٿو، اهو وڌيڪ اهم آهي ته ڪسٽمر اهو آرڊر ڪيو آهي. ۽ مطلب ته ڪلائنٽ تي انڊيڪس ضروري آهي. اهو پڻ ضروري ناهي ته ٽريڪٽر لاءِ آرڊر ٽيبل ۾ آرڊر سان لاڳاپيل پرنٽ ٿيل رسيد يا بونس پروموشنز جي سڃاڻپ کي محفوظ ڪري. هي معلومات اسان جي ٽريڪٽر سروس لاء دلچسپي جي ناهي. ھڪڙي عام monolithic ڊيٽابيس ۾، ٽيبل صرف سڀني استعمال ڪندڙن جي وچ ۾ سمجھوتي ٿي سگھي ٿو. هي اصل مسئلن مان هڪ هو.

WAS. اصل فن تعمير هو:

جدا جدا عملن ۾ ورهائجي وڃڻ کان پوءِ به، اڪثر ڪوڊ جو بنياد مختلف خدمتن لاءِ عام رهيو. ڪنٽرولرز جي هيٺان سڀ ڪجهه اڪيلو هو ۽ ساڳئي مخزن ۾ رهندو هو. اسان استعمال ڪيو خدمتن جا عام طريقا، مخزن، هڪ عام بنياد، جنهن ۾ عام ٽيبل رکيل آهن.

ان لوڊ ڪرڻ وارو ٽريڪٽر

ٽريڪٽر سان بنيادي مسئلو اهو آهي ته ڊيٽا کي مختلف ڊيٽابيس جي وچ ۾ هم وقت سازي ٿيڻ گهرجي. اهو پڻ آهي ان جو بنيادي فرق آٿ سروس جي الڳ ٿيڻ کان، آرڊر ۽ ان جي حيثيت تبديل ٿي سگهي ٿي ۽ مختلف خدمتن ۾ ظاهر ٿيڻ گهرجي.

اسان ريسٽورنٽ جي چيڪ آئوٽ تي آرڊر قبول ڪندا آهيون (هي هڪ خدمت آهي)، اهو ڊيٽابيس ۾ "قبول ٿيل" جي حيثيت ۾ ذخيرو ٿيل آهي. ان کان پوء، هن کي ٽريڪٽر ڏانهن وڃڻ گهرجي، جتي هو پنهنجي حيثيت کي ڪيترائي ڀيرا تبديل ڪندو: "باورچي" کان "پيڪ ٿيل" تائين. ساڳئي وقت، ڪيشئر يا شفٽ مئنيجر انٽرفيس مان ڪجهه بيروني اثر آرڊر سان ٿي سگھي ٿو. آئون ٽيبل ۾ انهن جي وضاحت سان آرڊر جون حالتون ڏيندس:

آرڊر جي حالتن کي تبديل ڪرڻ جو منصوبو هن طرح نظر اچي ٿو:

حالتون مختلف نظامن جي وچ ۾ تبديل ٿين ٿيون. ۽ هتي ٽريڪٽر هڪ حتمي سسٽم ناهي جنهن ۾ ڊيٽا بند ٿيل آهي. اسان ڏٺو آهي ته اهڙي صورت ۾ ورهاڱي لاءِ ڪيترائي ممڪن طريقا:

1. اسان سڀني حڪمن جي عملن کي ھڪڙي خدمت ۾ مرڪوز ڪريون ٿا. اسان جي حالت ۾، هي اختيار تمام گهڻي خدمت جي ضرورت آهي آرڊر سان ڪم ڪرڻ لاء. جيڪڏهن اسان ان تي روڪي، اسان کي ٻيو monolith حاصل ڪري سگهون ٿا. اسان مسئلو حل نه ڪنداسين.
2. هڪ سسٽم ٻئي کي ڪال ڪري ٿو. ٻيو اختيار اڳ ۾ ئي وڌيڪ دلچسپ آهي. پر ان سان، ڪالن جي زنجير ممڪن آهي (cascading ناڪامي)، اجزاء جي رابطي اعلي آهي، ان کي منظم ڪرڻ وڌيڪ ڏکيو آهي.
3. اسان واقعن کي منظم ڪريون ٿا، ۽ هر خدمت انهن واقعن ذريعي ٻئي سان رابطو ڪري ٿي. نتيجي طور، اهو ٽيون اختيار هو، جيڪو چونڊيو ويو، جنهن جي مطابق سڀئي خدمتون هڪ ٻئي سان واقعن کي مٽائڻ شروع ڪن ٿا.

حقيقت اها آهي ته اسان ٽيون اختيار چونڊيو آهي مطلب ته ٽريڪٽر وٽ پنهنجو ڊيٽابيس هوندو، ۽ آرڊر ۾ هر تبديلي لاء، اهو ان بابت هڪ واقعو موڪليندو، جنهن ۾ ٻيون خدمتون سبسڪرپشن ڪن ٿيون ۽ جيڪو پڻ ماسٽر ڊيٽابيس ۾ اچي ٿو. هن کي ڪرڻ لاء، اسان کي ڪجهه خدمت جي ضرورت آهي جيڪا خدمتن جي وچ ۾ پيغام پهچائڻ کي يقيني بڻائي.

ان وقت تائين، اسان وٽ اڳ ۾ ئي RabbitMQ اسٽيڪ ۾ هو، تنهنڪري ان کي پيغام بروکر طور استعمال ڪرڻ جو حتمي فيصلو. ڊراگرام رستوران ڪيشيئر کان ٽريڪر ذريعي آرڊر جي منتقلي کي ڏيکاري ٿو، جتي اهو مينيجر جي آرڊر انٽرفيس تي ان جي حيثيت ۽ ڊسپلي کي تبديل ڪري ٿو. ٿيو:

ترتيب وار قدم قدم قدم
آرڊر جو رستو شروع ٿئي ٿو ھڪڙي آرڊر ماخذ خدمتن مان. هتي ريسٽورنٽ جو ڪيشيئر آهي:

1. چيڪ آئوٽ تي، آرڊر مڪمل طور تي تيار آهي، ۽ اهو ان کي ٽريڪٽر ڏانهن موڪلڻ جو وقت آهي. اهو واقعو جنهن ۾ ٽريڪٽر سبسڪرائب ڪيو ويو آهي اڇلايو ويو آهي.
2. ٽريڪر، پاڻ لاءِ آرڊر قبول ڪري، ان کي پنهنجي ڊيٽابيس ۾ محفوظ ڪري، ايونٽ ٺاهي ”آرڊر قبول ڪيو ويو ٽريڪر“ ۽ ان کي RMQ ڏانهن موڪلي ٿو.
3. اتي ڪيترائي ھينڊلر آھن اڳ ۾ ئي رڪنيت حاصل ڪئي آھي ايونٽ بس في آرڊر. اسان جي لاءِ، جيڪو هڪ واحد بنياد سان هم وقت سازي ڪري ٿو اهم آهي.
4. هينڊلر هڪ ايونٽ وصول ڪري ٿو، ان مان ڊيٽا چونڊي ٿو جيڪو ان لاءِ اهم آهي: اسان جي صورت ۾، اها آرڊر جي حيثيت آهي "ٽرئڪر پاران قبول ٿيل" ۽ ان جي آرڊر جي اداري کي مکيه ڊيٽابيس ۾ تازه ڪاري ڪري ٿو.

جيڪڏهن ڪنهن کي ضرورت آهي ته monolithic ٽيبل آرڊر مان آرڊر، ته پوءِ توهان ان کي اتان به پڙهي سگهو ٿا. مثال طور، شفٽ مئنيجر ۾ آرڊر انٽرفيس کي هن جي ضرورت آهي:

ٻيون سڀئي خدمتون پڻ رڪنيت حاصل ڪري سگھن ٿيون ٽريڪر کان واقعن کي ترتيب ڏيڻ لاءِ انھن کي پاڻ لاءِ استعمال ڪرڻ لاءِ.

جيڪڏهن ٿوري دير کان پوءِ آرڊر ڪم ۾ ورتو وڃي ته پوءِ ان جي اسٽيٽس پهرين ان جي ڊيٽابيس (ٽريڪر ڊيٽابيس) ۾ تبديل ٿي ويندي آهي ۽ پوءِ فوري طور تي ”آرڊر ان پروگريس“ واقعو پيدا ٿيندو آهي. اهو پڻ RMQ ۾ اچي ٿو، جتان اهو هڪ واحد ڊيٽابيس ۾ هم وقت سازي ڪيو ويو آهي ۽ ٻين خدمتن ڏانهن پهچايو ويو آهي. رستي ۾ مختلف مسئلا ٿي سگهن ٿا، انهن جي باري ۾ وڌيڪ تفصيل Zhenya Peshkov جي رپورٽ ۾ ملي ڪري سگهجي ٿو ٽريڪر ۾ واقعن جي تسلسل جي عمل جي تفصيل بابت.

Auth ۽ Tracker ۾ تبديلين کان پوء فائنل فن تعمير

وچولي نتيجن جو خلاصو: شروعات ۾، مون کي خيال هو ته ڊوڊو IS سسٽم جي نون سالن جي تاريخ کي هڪ مضمون ۾ پيڪ ڪيو. مون کي تڪڙو ۽ آسانيء سان ارتقاء جي مرحلن بابت ڳالهائڻ چاهيو. بهرحال، مواد لاء ويٺي، مون محسوس ڪيو ته هر شيء ان کان وڌيڪ پيچيده ۽ دلچسپ آهي.

اهڙي مواد جي فائدن (يا ان جي گھٽتائي) تي غور ڪندي، مان ان نتيجي تي پهتو آهيان ته مسلسل ترقي ڪرڻ ناممڪن آهي بغير واقعات جي مڪمل تاريخن، تفصيلي پس منظر ۽ منهنجي ماضي جي فيصلن جي تجزيي کان سواء.

مون کي اميد آهي ته اهو توهان لاء مفيد ۽ دلچسپ هو اسان جي رستي بابت سکڻ لاء. ھاڻي مون کي ھڪڙي پسند سان منهن ڏيڻو پيو آھي ڊوڊو IS سسٽم جو ڪھڙو حصو ايندڙ مضمون ۾ بيان ڪرڻ لاءِ: تبصرن ۾ لکو يا ووٽ ڏيو.

صرف رجسٽرڊ استعمال ڪندڙ سروي ۾ حصو وٺي سگهن ٿا. سائن ان ڪريو، توهان جي مهرباني.

Dodo IS جي ڪهڙي حصي بابت توهان ايندڙ مضمون ۾ ڄاڻڻ چاهيندا؟

• 24,1٪Dodo IS ۾ ابتدائي monolith (2011-2015)14

• 24,1٪پهريون مسئلا ۽ انهن جو حل (2015-2016)14

• 20,7٪ڪلائنٽ پاسي وارو رستو: بيس مٿان منهن (2016-2017) 12

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

• 44,8٪monolith جي مڪمل ڏٺو ۽ فن تعمير جي استحڪام26

• 29,3٪سسٽم جي ترقي لاء وڌيڪ منصوبن بابت 17

• 19,0٪مان Dodo IS11 بابت ڪجهه به ڄاڻڻ نٿو چاهيان

58 صارفين ووٽ ڏنو. 6 استعمال ڪندڙن کي روڪيو ويو.

جو ذريعو: www.habr.com