دودو آئي ايس آرڪيٽيڪچر جي تاريخ: هڪ ابتدائي مونولٿ

يا هر ناخوش ڪمپني هڪ واحد سان گڏ پنهنجي طريقي سان ناخوش آهي.

Dodo IS سسٽم جي ترقي فوري طور تي شروع ٿي، جهڙوڪ ڊوڊو پيزا ڪاروبار، 2011 ۾. اهو ڪاروباري عملن جي مڪمل ۽ مجموعي ڊجيٽلائيزيشن جي خيال تي ٻڌل هو، ۽ پاڻ تي2011ع ۾ به ڪيترن ئي سوالن ۽ شڪ جو سبب بڻيو. پر هاڻي 9 سالن تائين اسان هن رستي تي عمل ڪري رهيا آهيون - اسان جي پنهنجي ترقي سان، جيڪو هڪ monolith سان شروع ٿيو.

هي آرٽيڪل سوالن جو هڪ "جواب" آهي "فن تعمير کي ٻيهر لکڻ ۽ اهڙيون وڏي پيماني تي ۽ ڊگهي مدي واريون تبديليون ڇو؟" پوئين مضمون ڏانهن واپس "دودو جي تاريخ آرڪيٽيڪچر: واپس آفيس جو رستو". مان شروع ڪندس ته ڊوڊو IS جي ترقي ڪيئن شروع ٿي، اصل فن تعمير ڪيئن نظر آيو، نوان ماڊل ڪيئن ظاهر ٿيا، ۽ ڪهڙن مسئلن جي ڪري وڏي پيماني تي تبديليون ڪرڻيون پيون.

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

1. Dodo IS ۾ ابتدائي monolith (2011-2015). (توهان هتي آهيو)

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

3. ڪلائنٽ جي پاسي جو رستو: بيس مٿان منهن (2016-2017). (جاري آهي...)

4. حقيقي microservices جي تاريخ. (2018-2019). (جاري آهي...)

5. monolith جي آري ختم ڪئي وئي ۽ فن تعمير جي استحڪام. (جاري آهي...)

شروعاتي فن تعمير

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

فن تعمير ۾ پهريون ماڊل آرڊر قبوليت آهي. ڪاروباري عمل هو:

• گراهڪ پيززيريا کي سڏي ٿو؛

• مينيجر فون کڻي ٿو؛

• فون ذريعي آرڊر قبول ڪري ٿو؛

• آرڊر جي قبوليت واري انٽرفيس ۾ ان کي متوازي ۾ ڀري ٿو: اهو ڪلائنٽ بابت معلومات، آرڊر جي تفصيل تي ڊيٽا، پهچائڻ جو پتو وٺندو آهي. 

انفارميشن سسٽم جو انٽرفيس ڪجهه هن طرح نظر آيو ...

آڪٽوبر 2011 کان پهريون نسخو:

جنوري 2012 ۾ ٿورو بهتر ٿيو

دودو پيزا انفارميشن سسٽم پهچائڻ پيزا ريسٽورنٽ

پهرين آرڊر وٺڻ واري ماڊل جي ترقي لاءِ وسيلا محدود هئا. اسان کي تمام گهڻو ڪرڻو هو، جلدي ۽ هڪ ننڍڙي ٽيم سان. هڪ ننڍڙي ٽيم 2 ڊولپرز آهي جنهن سڄي مستقبل جي سسٽم جو بنياد رکيو.

انهن جو پهريون فيصلو ٽيڪنالاجي اسٽيڪ جي قسمت جو اندازو لڳايو:

• ASP.NET MVC تي پس منظر، C# ٻولي. ڊولپرز dotnetchiki هئا، هي اسٽيڪ انهن لاء واقف ۽ خوشگوار هو.

• Bootstrap ۽ JQuery تي فرنٽيڊ: يوزر انٽرفيس پاڻمرادو لکيل اسلوب ۽ اسڪرپٽ تي. 

• MySQL ڊيٽابيس: لائسنس جي قيمت ناهي، استعمال ڪرڻ آسان.

• ونڊوز سرور تي سرور، ڇاڪاڻ ته .NET پوء صرف ونڊوز جي تحت ٿي سگهي ٿو (اسان مونو تي بحث نه ڪنداسين).

جسماني طور تي، اهو سڀ ڪجهه بيان ڪيو ويو آهي "هوسٽ تي وقف". 

آرڊر انٽيڪ ايپليڪيشن آرڪيٽيڪچر

پوء هرڪو اڳ ۾ ئي microservices جي باري ۾ ڳالهائي رهيو هو، ۽ SOA 5 سالن تائين وڏي منصوبن ۾ استعمال ڪيو ويو، مثال طور، WCF 2006 ۾ جاري ڪيو ويو. پر پوء اهي هڪ قابل اعتماد ۽ ثابت حل چونڊيو.

هتي اهو آهي.

Asp.Net MVC Razor آهي، جيڪو، فارم يا ڪلائنٽ کان درخواست تي، سرور رينڊرنگ سان گڏ هڪ HTML صفحو پيش ڪري ٿو. ڪلائنٽ تي، CSS ۽ JS اسڪرپٽ اڳ ۾ ئي معلومات ڏيکاري ٿو ۽، جيڪڏهن ضروري هجي ته، JQuery ذريعي AJAX درخواستون انجام ڏيو.

سرور تي درخواستون *ڪنٽرولر طبقن ۾ ختم ٿينديون آهن، جتي آخري HTML پيج جي پروسيسنگ ۽ نسل طريقي سان ٿيندي آهي. ڪنٽرولر درخواستون ٺاهي منطق جي هڪ پرت ڏانهن جنهن کي *Services سڏيو ويندو آهي. خدمتن مان هر هڪ ڪاروبار جي ڪجهه پهلو سان لاڳاپيل آهي:

• مثال طور، DepartmentStructureService پيززيريا تي، ڊپارٽمينٽس تي معلومات ڏني. هڪ ڊپارٽمينٽ هڪ واحد فرنچائز پاران هلائيندڙ پيززيريا جو هڪ گروپ آهي.

• ReceivingOrdersService قبول ڪيو ۽ ترتيب جي ترتيب جي حساب سان.

• ۽ ايس ايم ايس سروس ايس ايم ايس موڪلڻ لاءِ API خدمتن کي ڪال ڪندي ايس ايم ايس موڪليو.

خدمتون ڊيٽابيس مان پروسيس ٿيل ڊيٽا، محفوظ ٿيل ڪاروباري منطق. هر خدمت ۾ هڪ يا وڌيڪ *مناسب نالي سان ريپوزٽريون هيون. اهي پهريان ئي ڊيٽابيس ۾ محفوظ ڪيل طريقا ۽ ميپرز جي هڪ پرت لاءِ سوالن تي مشتمل هئا. اسٽوريج ۾ ڪاروباري منطق هئي، خاص طور تي انهن ۾ گهڻو ڪجهه جيڪي رپورٽنگ ڊيٽا جاري ڪن ٿا. ORM استعمال نه ڪيو ويو، هرڪو هٿ سان لکيل sql تي ڀروسو ڪيو. 

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

هي سڀ اهڙي نموني جي نمائندگي ڪري سگهجي ٿو:

آرڊر جو طريقو

اهڙي ترتيب ٺاهڻ لاء هڪ سادي ابتدائي طريقي تي غور ڪريو.

شروعات ۾، سائيٽ جامد هئي. ان تي قيمتون هيون، ۽ مٿي تي - هڪ فون نمبر ۽ لکت "جيڪڏهن توهان پيزا چاهيو ٿا - نمبر ڪال ڪريو ۽ آرڊر." حڪم ڪرڻ لاء، اسان کي هڪ سادي وهڪري کي لاڳو ڪرڻ جي ضرورت آهي: 

• گراهڪ قيمتن سان گڏ جامد سائيٽ جو دورو ڪري ٿو، پراڊڪٽس کي چونڊي ٿو ۽ سائيٽ تي ڏنل نمبر کي سڏي ٿو.

• گراهڪ انهن شين جو نالو ڏئي ٿو جيڪي اهي آرڊر ۾ شامل ڪرڻ چاهيندا آهن.

• سندس ائڊريس ۽ نالو ڏئي ٿو.

• آپريٽر آرڊر قبول ڪري ٿو.

• آرڊر قبول ٿيل آرڊر انٽرفيس ۾ ڏيکاريل آهي.

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

ڪسٽمر پراڊڪٽ جو نالو ڏئي ٿو، آپريٽر ڪلڪ ڪري ٿو + پيداوار جي اڳيان، ۽ هڪ درخواست سرور ڏانهن موڪلي وئي آهي. پراڊڪٽ بابت معلومات ڊيٽابيس مان ڪڍي وئي آهي ۽ پراڊڪٽ بابت معلومات ڪارٽ ۾ شامل ڪئي وئي آهي.

ويچاري. ها، هتي توهان ڊيٽابيس مان پراڊڪٽ نه ٿا ڪڍو، پر ان کي فرنٽ اينڊ تان منتقل ڪريو. پر وضاحت لاءِ، مون ڊيٽابيس مان بلڪل رستو ڏيکاريو. 

اڳيون، ڪلائنٽ جو پتو ۽ نالو داخل ڪريو. 

جڏهن توهان ڪلڪ ڪريو "آرڊر ٺاهيو":

• درخواست OrderController.SaveOrder() ڏانهن موڪلي وئي آهي.

• اسان سيشن مان ڪارٽ حاصل ڪندا آهيون، اسان کي گهربل مقدار ۾ مصنوعات موجود آهن.

• اسان ڪارٽ کي ڪلائنٽ بابت معلومات سان گڏ ڪريون ٿا ۽ ان کي حاصل ڪريون ٿا AddOrder طريقي سان RecevingOrderService ڪلاس، جتي اهو ڊيٽابيس ۾ محفوظ ڪيو ويو آهي. 

• ڊيٽابيس ۾ آرڊر سان گڏ جدول، ترتيب جي ترتيب، ڪلائنٽ، ۽ اهي سڀئي ڳنڍيل آهن.

• آرڊر ڊسپلي انٽرفيس وڃي ٿو ۽ تازو آرڊر ڪڍي ٿو ۽ انهن کي ڏيکاري ٿو.

نئون ماڊلز

حڪم وٺڻ ضروري ۽ ضروري هو. توهان پيزا ڪاروبار نٿا ڪري سگهو جيڪڏهن توهان وٽ وڪڻڻ جو آرڊر نه آهي. تنهن ڪري، سسٽم ڪارڪردگي حاصل ڪرڻ شروع ڪيو - تقريبن 2012 کان 2015 تائين. هن عرصي دوران، سسٽم جا ڪيترائي مختلف بلاڪ ظاهر ٿيا، جن کي آئون سڏيندس ماڊلز, جيئن خدمت يا پيداوار جي تصور جي مخالفت. 

ھڪڙو ماڊل ھڪڙي ڪمن جو ھڪڙو سيٽ آھي جيڪي ھڪڙي عام ڪاروباري مقصد سان متحد آھن. ساڳئي وقت، اهي جسماني طور تي ساڳئي ايپليڪيشن ۾ آهن.

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

ٽيڪنيڪل طور تي، ماڊلز ايريا جي طور تي ٺهيل هئا (اهڙو خيال اڃا تائين رهي ٿو asp.net ڪور). فرنٽ اينڊ، ماڊلز ۽ گڏوگڏ انهن جي پنهنجي ڪنٽرولر ڪلاسن لاءِ الڳ فائلون هيون. نتيجي طور، سسٽم هن کان تبديل ٿي ويو ...

... هن ۾:

ڪجهه ماڊلز الڳ سائيٽن (قابل عمل پروجيڪٽ) طرفان لاڳو ڪيا ويا آهن، مڪمل طور تي الڳ ڪارڪردگي جي ڪري ۽ جزوي طور تي ٿوري الڳ، وڌيڪ مرڪوز ترقي جي ڪري. هي:

• سائيٽ - پهريون نسخو سائيٽ dodopizza.ru.

• ٻاھر موڪليو1C لاءِ Dodo IS کان رپورٽون اپ لوڊ ڪندي. 

• ذاتي - ملازم جي ذاتي اڪائونٽ. اهو الڳ الڳ ترقي يافته هو ۽ ان جو پنهنجو داخلا نقطو ۽ الڳ ڊيزائن آهي.

• fs - هڪ پروجيڪٽ جي ميزباني لاءِ اسٽيٽڪس. بعد ۾ اسان ان کان پري هليا ويا، سڀني اسٽيٽيڪس کي اڪامي سي ڊي اين ڏانهن منتقل ڪيو. 

باقي بلاڪ BackOffice ايپليڪيشن ۾ هئا. 

نالي جي وضاحت:

• ڪيشيئر - ريسٽورنٽ ڪيشيئر.

• ShiftManager - "Shift Manager" جي ڪردار لاءِ انٽرفيس: پزيريا سيلز تي آپريشنل انگ اکر، اسٽاپ لسٽ تي پروڊڪٽس رکڻ جي صلاحيت، آرڊر تبديل ڪريو.

• OfficeManager - "Pizzeria Manager" ۽ "Franchisee" ڪردارن لاءِ انٽرفيس. هتي گڏ ڪيا ويا آهن هڪ پززيريا قائم ڪرڻ لاءِ افعال، ان جي بونس پروموشنز، وصول ڪرڻ ۽ ملازمن سان ڪم ڪرڻ، رپورٽون.

• پبلڪ اسڪرين - ٽي وي ۽ ٽيبلٽس لاءِ انٽرفيس جيڪي پيزيريا ۾ لٽڪيل آهن. ٽي وي ڊسپلي مينيو، اشتهارن جي معلومات، ترسيل تي آرڊر جي صورتحال. 

انهن هڪ عام خدمت پرت استعمال ڪيو، هڪ عام Dodo.Core ڊومين ڪلاس بلاڪ، ۽ هڪ عام بنياد. ڪڏهن ڪڏهن اهي اڃا به هڪ ٻئي ڏانهن منتقلي جي اڳواڻي ڪري سگھن ٿا. انفرادي سائيٽن سميت، جهڙوڪ dodopizza.ru يا personal.dodopizza.ru، عام خدمتن ڏانهن ويا.

جڏهن نوان ماڊل ظاهر ٿيا، اسان ڪوشش ڪئي ته اڳ ۾ ئي ٺاهيل ڪوڊ آف سروسز، ذخيرو ٿيل طريقا ۽ ڊيٽابيس ۾ جدولن کي وڌ ۾ وڌ استعمال ڪيو وڃي. 

سسٽم ۾ ٺهيل ماڊلز جي ماپ کي بهتر سمجهڻ لاءِ، هتي 2012 کان ڊولپمينٽ منصوبن سان گڏ هڪ خاڪو آهي:

2015 تائين، هر شي نقشي تي هئي ۽ اڃا به وڌيڪ پيداوار ۾ هئي.

• آرڊر جي قبوليت رابطي سينٽر جي هڪ الڳ بلاڪ ۾ وڌي وئي آهي، جتي آرڊر آپريٽر طرفان قبول ڪيو ويندو آهي.

• پيزيريا ۾ مينيو ۽ معلومات سان گڏ پبلڪ اسڪرينون لٽڪيل هيون.

• باورچی خانه ۾ هڪ ماڊل آهي جيڪو خودڪار طور تي آواز وارو پيغام "نئون پيزا" ادا ڪري ٿو جڏهن نئون آرڊر اچي ٿو، ۽ ڪوريئر لاء هڪ انوائس پڻ ڇپائي ٿو. اهو باورچی خانه ۾ عملن کي تمام گهڻو آسان بڻائي ٿو، ملازمن کي اجازت ڏئي ٿو ته وڏي تعداد ۾ سادي عملن کان پريشان نه ٿئي.

• ترسيل يونٽ هڪ الڳ ترسيل چيڪ آئوٽ بڻجي ويو، جتي ڪوريئر کي حڪم جاري ڪيو ويو جيڪو اڳ ۾ شفٽ ورتو هو. هن جي ڪم جو وقت حساب ڪتاب جي حساب سان ورتو ويو آهي. 

متوازي طور تي، 2012 کان 2015 تائين، 10 کان وڌيڪ ڊولپرز ظاهر ٿيا، 35 پيززيريا کوليا، سسٽم کي رومانيا ڏانهن پهچايو ۽ آمريڪا ۾ دڪانن جي افتتاح لاء تيار ڪيو. ڊولپرز هاڻي سڀني ڪمن سان معاملو نه ڪيو، پر ٽيمن ۾ ورهايو ويو. هر هڪ سسٽم جي پنهنجي حصي ۾ ماهر. 

پريشاني

جنهن ۾ فن تعمير جي ڪري (پر نه رڳو).

بنياد ۾ افراتفري

ھڪڙو بنياد آسان آھي. ان ۾ تسلسل حاصل ڪري سگھجي ٿو، ۽ اوزارن جي خرچ تي، جيڪو لاڳاپا ڊيٽابيس ۾ ٺاھيو ويو آھي. ان سان ڪم ڪرڻ واقف ۽ آسان آهي، خاص طور تي جيڪڏهن ڪجهه ٽيبل ۽ ٿورڙي ڊيٽا آهن.

پر 4 سالن جي ترقيءَ کان پوءِ، ڊيٽابيس ۾ اٽڪل 600 ٽيبلون، 1500 ذخيرو ٿيل طريقا، جن مان گھڻن ۾ منطق پڻ ھئي. افسوس، ذخيرو ٿيل طريقا گهڻو فائدو نه آڻيندا آهن جڏهن MySQL سان ڪم ڪري رهيا آهن. اهي بنيادي طور تي محفوظ نه ڪيا ويا آهن، ۽ انهن ۾ منطق کي محفوظ ڪرڻ ترقي ۽ ڊيبنگ کي پيچيده ڪري ٿو. ڪوڊ ٻيهر استعمال پڻ ڏکيو آهي.

گھڻن جدولن ۾ مناسب انڊيڪس نه ھئا، ڪٿي، ان جي برعڪس، اتي تمام گھڻا انڊيڪس هئا، جن کي داخل ڪرڻ ڏکيو ٿي ويو. اٽڪل 20 جدولن کي تبديل ڪرڻ جي ضرورت ھئي - ھڪڙو آرڊر ٺاھڻ لاء ٽرانزيڪشن تقريبا 3-5 سيڪنڊ وٺي سگھي ٿو. 

جدولن ۾ موجود ڊيٽا هميشه مناسب شڪل ۾ نه هئي. ڪٿي ڪٿي denormalization ڪرڻ ضروري هو. باقاعده حاصل ڪيل ڊيٽا جو حصو ھڪڙي ڪالمن ۾ ھڪڙي XML ساخت جي صورت ۾ ھو، ھن عمل جي وقت کي وڌايو، سوالن کي وڌايو ۽ ترقي کي پيچيده ڪيو.

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

ڊيٽا گڏ نه ڪيو ويو ۽ بيس استعمال ڪندي اڏام تي ڪيترائي حساب ڪيا ويا. اهو غير ضروري حساب ۽ اضافي لوڊ پيدا ڪيو. 

گهڻو ڪري ڪوڊ ڊيٽابيس ڏانهن ويو جڏهن اهو ائين نه ڪري سگهيو. ڪٿي ته ڪافي بلڪ آپريشن نه هئا، ته ڪٿي اهو ضروري هوندو ته هڪ درخواست کي ڪوڊ ذريعي ڪيترن ئي ۾ پکڙجي ته جيئن تيز رفتاري ۽ اعتماد کي وڌايو وڃي. 

ضابطي ۾ هم آهنگي ۽ اوچتو

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

خدمتون (هڪ واحد وڏي منصوبي اندر ڪلاس) هڪ ٻئي کي سڏي سگهي ٿو انهن جي ڊيٽا کي بهتر ڪرڻ لاء.

پاڻ ماڊل طبقن سان جيڪي ڊيٽا کي ذخيرو ڪن ٿا، ڪوڊ ۾ ڪم مختلف طريقي سان ڪيو ويو. ڪٿي ڪٿي اهڙا تعميراتي به هئا جن جي ذريعي گهربل فيلڊ کي بيان ڪرڻ ممڪن هو. ڪٿي ڪٿي اهو ڪم سرڪاري ملڪيتن ذريعي ڪيو ويو. يقينن، ڊيٽابيس مان ڊيٽا حاصل ڪرڻ ۽ تبديل ڪرڻ مختلف هئي. 

منطق يا ته ڪنٽرولرز ۾ هئي يا سروس ڪلاس ۾. 

اهي معمولي مسئلا نظر اچن ٿا، پر انهن ترقي کي تمام گهڻو سست ڪيو ۽ معيار کي گهٽايو، جنهن جي نتيجي ۾ عدم استحڪام ۽ ڪيڙا. 

وڏي ترقي جي پيچيدگي

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

سسٽم جي ڪجهه حصن ۾، ڊيٽابيس هن لاء وڌيڪ مناسب استعمال ڪري سگھجن ٿيون.. مثال طور، بعد ۾ اسان وٽ استعمال جي صورت هئي Redis کان CosmosDB ڏانهن منتقل ڪرڻ لاءِ آرڊر ٽوڪري کي ذخيرو ڪرڻ لاءِ. 

ٽيمون ۽ ڊولپرز انهن جي فيلڊ ۾ شامل آهن واضح طور تي انهن جي خدمتن لاءِ وڌيڪ خودمختياري چاهيون ٿا، ٻنهي جي ترقي ۽ رول آئوٽ جي لحاظ کان. ضم ٿيڻ، مسئلن کي ڇڏڻ. جيڪڏهن 5 ڊولپرز لاء اهو مسئلو غير معمولي آهي، پوء 10 سان، ۽ اڃا به وڌيڪ، منصوبابندي ڪيل ترقي سان، هر شيء وڌيڪ سنجيده ٿي ويندي. ۽ اڳتي وڌڻو هو هڪ موبائل ايپليڪيشن جي ترقي (اهو 2017 ۾ شروع ٿيو، ۽ 2018 ۾ اهو هو وڏو زوال). 

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

اهو ممڪن آهي ته انهن غلطين ۽ مسئلن کان بچڻ لاء اهڙي monolithic-ماڊل آرڪيٽيڪچر جي فريم ورڪ ۾: ذميواري جو هڪ حصو ٺاهيو، ڪوڊ ۽ ڊيٽابيس ٻنهي کي ريفڪٽر ڪريو، واضح طور تي هڪ ٻئي کان پرت کي الڳ ڪريو، هر روز معيار جي نگراني ڪريو. پر چونڊيل آرڪيٽيڪچرل حل ۽ سسٽم جي ڪارڪردگي جي تيز رفتار وڌائڻ تي ڌيان جي استحڪام جي لحاظ کان مسئلن جو سبب بڻيو.

ڪيئن پاور آف دي مائنڊ بلاگ ريسٽورنٽ ۾ ڪيش رجسٽر رکيا

جيڪڏهن پيزيريا نيٽ ورڪ جي واڌ (۽ لوڊ) ساڳئي رفتار سان جاري رهي، پوء ٿوري دير کان پوء گر ٿيندو ته سسٽم اڀري نه سگهندو. چڱيءَ طرح بيان ڪري ٿو انهن مسئلن کي جن کي اسان 2015 کان منهن ڏيڻ شروع ڪيو، هتي هڪ اهڙي ڪهاڻي آهي. 

بلاگ ۾ "دماغي طاقت”هڪ ويجيٽ هئي جيڪا پوري نيٽ ورڪ جي سال جي آمدني تي ڊيٽا ڏيکاري ٿي. ويجيٽ Dodo عوامي API تائين رسائي حاصل ڪئي، جيڪا هي ڊيٽا مهيا ڪري ٿي. هي انگ اکر في الحال موجود آهي http://dodopizzastory.com/. ويجيٽ هر صفحي تي ڏيکاريو ويو ۽ هر 20 سيڪنڊن تي ٽائمر تي درخواستون ڪيون ويون. درخواست api.dodopizza.ru ڏانهن ويو ۽ عرض ڪيو:

• نيٽ ورڪ ۾ pizzerias جو تعداد؛

• سال جي شروعات کان وٺي مجموعي نيٽ ورڪ آمدني؛

• اڄ لاء آمدني.

آمدني تي انگن اکرن جي درخواست سڌو ڊيٽابيس ڏانهن ويو ۽ آرڊر تي ڊيٽا جي درخواست ڪرڻ شروع ڪيو، پرواز تي ڊيٽا گڏ ڪرڻ ۽ رقم ڏيڻ شروع ڪيو. 

ريسٽورنٽ ۾ ڪيش ڊيسڪون آرڊر جي ساڳي ٽيبل تي ويا، اڄ تائين حاصل ڪيل آرڊرن جي لسٽ کي لوڊ ڪيو، ۽ ان ۾ نوان آرڊر شامل ڪيا ويا. ڪيش رجسٽرز پنهنجون درخواستون هر 5 سيڪنڊن يا صفحي تي ريفريش ڪيو.

خاڪو هن طرح نظر آيو:

هڪ زوال، Fyodor Ovchinnikov پنهنجي بلاگ تي هڪ ڊگهو ۽ مشهور مضمون لکيو. ڪيترائي ماڻهو بلاگ تي آيا ۽ هر شي کي غور سان پڙهڻ شروع ڪيو. جڏهن ته هر هڪ ماڻهو جيڪو آيو هو آرٽيڪل پڙهي رهيو هو، آمدني ويجٽ صحيح ڪم ڪيو ۽ هر 20 سيڪنڊن ۾ API جي درخواست ڪئي.

API سڏجي ٿو ھڪڙي ذخيرو ٿيل طريقيڪار کي ڳڻڻ لاءِ سال جي شروعات کان وٺي سڀني آرڊرن جي زنجير جي زنجير لاءِ. مجموعو آرڊر ٽيبل تي ٻڌل هو، جيڪو تمام مشهور آهي. ان وقت سڀني کليل ريسٽورنٽ جا سڀ ڪيش ڊيسڪ ان ڏانهن ويندا آهن. ڪيش ڊيسڪ جواب ڏيڻ بند ڪيو، آرڊر قبول نه ڪيا ويا. اهي پڻ سائيٽ مان قبول نه ڪيا ويا، ٽريڪٽر تي ظاهر نه ٿيا، شفٽ مينيجر انهن کي پنهنجي انٽرفيس ۾ ڏسي نه سگهيو. 

هي واحد ڪهاڻي نه آهي. 2015 جي زوال تائين، هر جمعه تي سسٽم تي لوڊ نازڪ هو. ڪيترائي ڀيرا اسان عوامي API کي بند ڪيو، ۽ هڪ ڀيرو، اسان کي سائيٽ کي به بند ڪرڻو پيو، ڇاڪاڻ ته ڪجھ به مدد نه ڪئي. اتي پڻ خدمتن جي ھڪڙي فهرست ھئي جنھن ۾ بھاري بوجھ ھيٺ بند ٿيل آرڊر.

هن وقت کان، لوڊ سان اسان جي جدوجهد شروع ٿئي ٿي ۽ سسٽم جي استحڪام لاء (خزان 2015 کان 2018 تائين). تڏهن ائين ٿيو“وڏو زوال". ان کان سواء، ڪڏهن ڪڏهن ناڪاميون پڻ ٿينديون آهن، ڪجهه تمام حساس هئا، پر عدم استحڪام جي عام دور کي هاڻي سمجهي سگهجي ٿو.

تيز ڪاروبار ترقي

اهو فوري طور تي ڇو نه ٿي سگهيو؟ بس هيٺ ڏنل چارٽ ڏسو.

2014-2015 ۾ پڻ رومانيا ۾ هڪ افتتاح هو ۽ آمريڪا ۾ هڪ افتتاح تيار ٿي رهيو هو.

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

فن تعمير جي بروقت نظرثاني ۽ عام طور تي فني مسئلن تي ڌيان ڏيڻ لاء هڪ ٻيو رڪاوٽ 2014 جو بحران هو. اهڙيون شيون ٽيمن کي وڌڻ جي موقعن تي سخت ڌڪ لڳن ٿيون، خاص طور تي هڪ نوجوان ڪاروبار لاءِ جيئن دودو پيزا.

تڪڙو حل جيڪي مدد ڪئي

مسئلن جي حل جي ضرورت آهي. روايتي طور، حل 2 گروپن ۾ تقسيم ڪري سگهجي ٿو:

• تيز رفتار جيڪي باهه کي وجھي ۽ حفاظت جو ننڍڙو مارجن ڏيو ۽ اسان کي تبديل ڪرڻ لاء وقت خريد ڪريو.

• سسٽماتي ۽، تنهن ڪري، ڊگهو. ڪيترن ئي ماڊيولن جي ري انجنيئرنگ، هڪ واحد فن تعمير کي جدا جدا خدمتن ۾ ورهائڻ (انهن مان گھڻا مائڪرو نه آهن، بلڪه ميڪرو خدمتون، ۽ ان بابت ڪجهه آهي. Andrey Morevskiy جي رپورٽ). 

جلدي تبديلين جي خشڪ فهرست ھيٺ ڏنل آھي:

اسڪيل اپ بنيادي ماسٽر

يقينن، پهرين شيء جيڪا لوڊ سان معاملو ڪرڻ لاء ڪيو ويندو آهي سرور جي صلاحيت وڌائڻ آهي. اهو ڪيو ويو ماسٽر ڊيٽابيس ۽ ويب سرورز لاءِ. افسوس، اهو صرف هڪ خاص حد تائين ممڪن آهي، پوء اهو تمام مهانگو ٿيندو.

2014 کان وٺي، اسان Azure ڏانهن منتقل ڪيو ويو آهي، اسان هن وقت هن مضمون بابت پڻ لکيو آهي "ڪيئن ڊوڊو پيزا Microsoft Azure ڪلائوڊ استعمال ڪندي پيزا پهچائي ٿو". پر بنيادي طور تي سرور ۾ واڌ جي هڪ سيريز کان پوء، اهي قيمت جي خلاف آيا. 

پڙهڻ لاء بنيادي replicas

بنياد لاءِ ٻه نقل ڪيا ويا:

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

رپورٽ جي درخواستن لاءِ ريپليڪا پڙهو. ھن ڊيٽابيس ۾ گھٽ دستيابي ھئي، پر سڀ رپورٽون ان ڏانھن ويون. اچو ته انهن کي وڏي ڊيٽا جي حساب سان ڳري درخواستون هجن، پر اهي مکيه ڊيٽابيس ۽ آپريشنل انٽرفيس کي متاثر نه ڪندا آهن. 

ڪوڊ ۾ ڪيش

ڪوڊ ۾ ڪٿي به ڪيش نه هئا (سڀني ۾). انهي جي نتيجي ۾ اضافي، هميشه ضروري ناهي، لوڊ ٿيل ڊيٽابيس ڏانهن درخواستون. ڪيش پهريان ٻئي ميموري ۾ هئا ۽ هڪ ٻاهرين ڪيش سروس تي، اها هئي ريڊيس. وقت جي لحاظ کان سڀڪنھن شيء کي باطل ڪيو ويو، سيٽنگون ڪوڊ ۾ بيان ڪيا ويا.

گھڻن پس منظر سرور

وڌايل ڪم لوڊ کي سنڀالڻ لاءِ ايپليڪيشن جي پس منظر کي پڻ اسڪيل ڪرڻ جي ضرورت آهي. اهو ضروري هو ته هڪ iis-server مان هڪ ڪلستر ٺاهڻ. اسان ٻيهر شيڊول ڪيو آهي ايپليڪيشن سيشن ميموري کان وٺي RedisCache تائين، جنهن کي گول رابن سان گڏ هڪ سادي لوڊ بيلنس جي پويان ڪيترن ئي سرور ٺاهڻ ممڪن بڻائي. پهرين ۾، ساڳيو ريڊس ڪيچ لاء استعمال ڪيو ويو، پوء ان کي ڪيترن ئي حصن ۾ ورهايو ويو. 

نتيجي طور، فن تعمير وڌيڪ پيچيده ٿي چڪو آهي ...

... پر ڪجهه تڪرار ختم ٿي ويو.

۽ پوء اهو ضروري هو ته لوڊ ٿيل اجزاء کي ٻيهر ڪرڻو پوندو، جيڪو اسان ورتو. اسان ان بابت ايندڙ حصي ۾ ڳالهائينداسين.

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