د دودو IS معمارۍ تاریخ: یو ابتدايي مونولیت

یا د یو واحد سره هر ناخوښه شرکت په خپله طریقه ناخوښه دی.

د ډوډو IS سیسټم پراختیا سمدلاسه پیل شوه، لکه د دوډو پیزا سوداګرۍ، په 2011 کې. دا د سوداګرۍ پروسې بشپړ او بشپړ ډیجیټل کولو مفکورې پراساس و ، او په خپله، کوم چې حتی په 2011 کې د ډیرو پوښتنو او شکونو لامل شو. مګر اوس د 9 کلونو لپاره موږ دا لاره تعقیب کوو - زموږ د خپل پرمختګ سره، کوم چې د یو واحد سره پیل شوی.

دا مقاله دې پوښتنو ته "ځواب" دی چې "ولې جوړښت بیا لیکل او دومره لوی او اوږدمهاله بدلونونه رامینځته کول؟" بیرته پخوانۍ مقالې ته "د ډوډو IS معمارۍ تاریخ: د شا دفتر لاره". زه به له دې سره پیل وکړم چې د Dodo IS پراختیا څنګه پیل شوه، اصلي جوړښت څنګه ښکاري، څنګه نوي ماډلونه ښکاره شول، او د کومو ستونزو له امله چې په لویه کچه بدلونونه باید رامنځته شي.

د مقالو لړۍ "دودو IS څه شی دی؟" په اړه وايي:

1. په Dodo IS (2011-2015). (تاسو دلته یاست)

2. د شاته دفتر لاره: جلا اډې او بس.

3. د پیرودونکي اړخ لاره: د بیس څخه مخ مخ (2016-2017). (د پرمختګ په حال کې...)

4. د اصلي مایکرو خدماتو تاریخ. (2018-2019). (د پرمختګ په حال کې...)

5. د معمارۍ د مونولیت او ثبات پای ته رسیدل. (د پرمختګ په حال کې...)

ابتدايي جوړښت

په 2011 کې، د Dodo IS جوړښت داسې ښکاري:

په جوړښت کې لومړی ماډل د امر منل دي. د سوداګرۍ پروسه دا وه:

• پیرودونکی پیزیریا ته زنګ وهي؛

• مدیر تلیفون پورته کوي؛

• د تلیفون له لارې امر مني؛

• دا د امر منلو انٹرفیس کې موازي ډکوي: دا د پیرودونکي په اړه معلومات په پام کې نیسي ، د امر توضیحاتو معلومات ، د تحویل پته. 

د معلوماتو سیسټم انٹرفیس یو څه داسې ښکاري ...

د اکتوبر 2011 څخه لومړۍ نسخه:

د 2012 په جنوري کې یو څه ښه شوی

د ډوډو پیزا معلوماتو سیسټم تحویلي پیزا رستورانت

د لومړي امر اخیستلو ماډل پراختیا لپاره سرچینې محدودې وې. موږ باید ډیر څه وکړو، په چټکۍ سره او د کوچني ټیم سره. یو کوچنی ټیم 2 پراختیا کونکي دي چې د راتلونکي ټول سیسټم بنسټ یې کېښود.

د دوی لومړۍ پریکړه د ټیکنالوژۍ سټیک برخلیک وټاکه:

• په ASP.NET MVC، C# ژبه کې شالید. پراختیا کونکي dotnetchiki وو، دا سټیک د دوی لپاره پیژندل شوی او خوندور و.

• په بوټسټریپ او JQuery کې فرنټ اینډ: په ځان لیکل شوي سټایلونو او سکریپټونو کې د کارونکي انٹرفیس. 

• د MySQL ډیټابیس: د جواز لګښت نشته، کارول اسانه دي.

• په وینډوز سرور کې سرورونه، ځکه چې .NET بیا یوازې د وینډوز لاندې کیدی شي (موږ به د مونو په اړه بحث ونه کړو).

په فزیکي توګه، دا ټول په "د کوربه کې وقف" کې څرګند شوي. 

د انټیک غوښتنلیک آرکیټیکچر امر کړئ

بیا هرڅوک دمخه د مایکرو خدماتو په اړه خبرې کولې، او SOA د 5 کلونو لپاره په لویو پروژو کې کارول کیده، د بیلګې په توګه، WCF په 2006 کې خپور شو. مګر بیا دوی یو باوري او ثابت حل غوره کړ.

دلته دی.

Asp.Net MVC Razor دی، کوم چې د فارم یا پیرودونکي څخه غوښتنه کوي، د سرور رینډرینګ سره HTML پاڼه وړاندې کوي. په پیرودونکي کې، CSS او JS سکریپټونه دمخه معلومات ښکاره کوي او که اړتیا وي، د JQuery له لارې د AJAX غوښتنې ترسره کوي.

په سرور کې غوښتنې د *کنټرولر ټولګیو کې پای ته رسیږي، چیرې چې د وروستي HTML پاڼې پروسس او تولید په میتود کې ترسره کیږي. کنټرولر د منطق یوې طبقې ته د *Services په نوم غوښتنې کوي. د خدماتو هر یو د سوداګرۍ ځینې اړخونو سره مطابقت لري:

• د مثال په توګه، د ډیپارټمنټ ساختماني خدماتو د پیزاریا په اړه معلومات ورکړل، د څانګو په اړه. ډیپارټمنټ د پیزیریا یوه ډله ده چې د یو واحد فرنچائز لخوا پرمخ وړل کیږي.

• ReceivingOrdersService ومنله او د امر ترکیب یې محاسبه کړ.

• او SmsService د API خدماتو د زنګ وهلو له لارې SMS لیږلی ترڅو SMS واستوي.

خدمتونه د ډیټابیس څخه پروسس شوي ډاټا، د سوداګرۍ منطق ذخیره کوي. هر خدمت د مناسب نوم سره یو یا ډیر * ذخیره درلوده. دوی دمخه په ډیټابیس کې د زیرمه شوي طرزالعملونو او د نقشو یو پرت پوښتنې درلودې. په ذخیره کې د سوداګرۍ منطق شتون درلود، په ځانګړې توګه په هغو کې چې د راپور ورکولو ډاټا یې خپره کړې. ORM نه کارول شوی، هرڅوک په لاس لیکل شوي sql باندې تکیه کوي. 

د ډومین ماډل او عام مرستندویه ټولګیو یو پرت هم شتون درلود، د بیلګې په توګه، د نظم ټولګی چې امر ذخیره کوي. په ورته ځای کې، په پرت کې، د ټاکل شوي اسعارو سره سم د ښودلو متن بدلولو لپاره یو مرستندوی و.

دا ټول د داسې ماډل لخوا استازیتوب کیدی شي:

د نظم لاره

د داسې نظم د جوړولو لپاره یو ساده ابتدايي لاره په پام کې ونیسئ.

په پیل کې، سایټ جامد و. په دې کې قیمتونه وو، او په سر کې - د تلیفون شمیره او لیکنه "که تاسو پیزا غواړئ - شمیره ته زنګ ووهئ او امر وکړئ." د امر کولو لپاره، موږ باید یو ساده جریان پلي کړو: 

• پیرودونکی د نرخونو سره جامد سایټ څخه لیدنه کوي ، محصولات غوره کوي او په سایټ کې لیست شوي شمیرې ته زنګ وهي.

• پیرودونکي هغه محصولات نوموي چې دوی غواړي په امر کې اضافه کړي.

• خپل ادرس او نوم ورکوي.

• آپریټر امر مني.

• امر د منل شوي امر انٹرفیس کې ښودل شوی.

دا ټول د مینو ښودلو سره پیل کیږي. یو ننوتل شوی کارونکي چلونکی په یو وخت کې یوازې یو امر مني. له همدې امله، د مسودې کارټ د هغه په ​​​​غونډه کې زیرمه کیدی شي (د کارونکي ناسته په حافظه کې زیرمه شوې ده). دلته د کارټ څیز شتون لري چې محصولات او د پیرودونکي معلومات لري.

پیرودونکي د محصول نوم ورکوي، چلونکی یې کلیک کوي + د محصول تر څنګ، او یوه غوښتنه سرور ته لیږل کیږي. د محصول په اړه معلومات د ډیټابیس څخه ایستل کیږي او د محصول په اړه معلومات په کارټ کې اضافه کیږي.

تبصره. هو، دلته تاسو نشئ کولی محصول له ډیټابیس څخه راوباسئ، مګر دا د مخکینۍ برخې څخه لیږدئ. مګر د وضاحت لپاره، ما د ډیټابیس څخه سمه لاره وښودله. 

بیا، د پیرودونکي پته او نوم دننه کړئ. 

کله چې تاسو "آرډر جوړ کړئ" کلیک وکړئ:

• غوښتنه OrderController.SaveOrder() ته لیږل کیږي.

• موږ د ناستې څخه کارټ ترلاسه کوو، په هغه مقدار کې محصولات شتون لري چې موږ ورته اړتیا لرو.

• موږ کارټ د پیرودونکي په اړه د معلوماتو سره ضمیمه کوو او دا د ترلاسه کولو آرډر خدمت ټولګي AddOrder میتود ته انتقالوو، چیرې چې دا ډیټابیس ته خوندي کیږي. 

• ډیټابیس د ترتیب سره میزونه لري، د ترتیب ترکیب، پیرودونکي، او دا ټول تړلي دي.

• د امر ښودلو انٹرفیس ځي او وروستي امرونه راوباسي او ښیې.

نوي ماډلونه

د امر اخیستل مهم او اړین وو. تاسو نشئ کولی د پیزا سوداګرۍ ترسره کړئ که تاسو د پلورلو امر نلرئ. له همدې امله، سیسټم د فعالیت ترلاسه کولو پیل وکړ - نږدې له 2012 څخه تر 2015 پورې. د دې وخت په جریان کې، د سیسټم ډیری مختلف بلاکونه ښکاره شول، کوم چې زه به یې ووایم ماډلونهلکه څنګه چې د خدمت یا محصول مفهوم سره مخالف دی. 

ماډل د دندو یوه ټولګه ده چې د یو څه ګډ سوداګرۍ هدف لخوا متحد کیږي. په ورته وخت کې، دوی په فزیکي توګه په ورته غوښتنلیک کې دي.

ماډلونه د سیسټم بلاکس بلل کیدی شي. د مثال په توګه، دا د راپور ورکولو ماډل دی، د اډمین انٹرفیس، په پخلنځي کې د خوړو تعقیبونکی, اجازه ورکول. دا ټول مختلف کاروونکي انٹرفیسونه دي، ځینې حتی مختلف لید سټایلونه لري. په ورته وخت کې، هرڅه د یو غوښتنلیک په چوکاټ کې دي، یو روان بهیر. 

په تخنیکي توګه، ماډلونه د ساحې په توګه ډیزاین شوي (دا ډول نظر حتی پاتې دی asp.net کور). د فرنټ اینډ ، ماډلونو او همدارنګه د دوی خپل کنټرولر ټولګیو لپاره جلا فایلونه شتون درلود. د پایلې په توګه، سیسټم له دې څخه بدل شو ...

... پدې کې:

ځینې ​​ماډلونه د جلا سایټونو (د اجرا وړ پروژې) لخوا پلي کیږي، د بشپړ جلا فعالیت له امله او یو څه د یو څه جلا، ډیر متمرکز پرمختګ له امله. دا:

• وېبپاڼه - لومړۍ نسخه سایټ dodopizza.ru.

• د صادراتو د: د 1C لپاره د Dodo IS څخه راپورونه پورته کول. 

• د شخصي - د کارمند شخصي حساب. دا په جلا توګه رامینځته شوی او خپل د ننوتلو نقطه او جلا ډیزاین لري.

• fs - د احصایې کوربه کولو لپاره یوه پروژه. وروسته موږ له هغې څخه لیرې شو، ټول احصایې د اکامي CDN ته لیږدول. 

پاتې بلاکونه د BackOffice غوښتنلیک کې وو. 

د نوم تشریح:

• کیشیر - د رستورانت کیشیر.

• ShiftManager - د "شفټ مدیر" رول لپاره انٹرفیسونه: د پیزیریا پلور عملیاتي احصایې ، د سټاپ لیست کې د محصولاتو ایښودلو وړتیا ، ترتیب بدل کړئ.

• OfficeManager - د "Pizzeria Manager" او "Franchisee" رولونو لپاره انٹرفیسونه. دلته د پیزایریا تنظیم کولو ، د هغې د بونس ترویج ، د کارمندانو سره ترلاسه کول او کار کولو لپاره راټول شوي فعالیتونه دي ، راپورونه.

• عامه سکرینونه - د تلویزیونونو او ټابلیټونو لپاره انٹرفیسونه چې په پیزیریا کې ځړول کیږي. تلویزیونونه د سپارلو پر مهال مینو، د اعلاناتو معلومات، د امر حالت ښکاره کوي. 

دوی یو عام خدمت پرت، یو عام Dodo.Core ډومین کلاس بلاک، او یو عام بیس کارولی. ځینې ​​​​وختونه دوی کولی شي یو بل ته د لیږد په اوږدو کې رهبري کړي. د انفرادي سایټونو په شمول، لکه dodopizza.ru یا personal.dodopizza.ru، عمومي خدماتو ته لاړل.

کله چې نوي ماډلونه ښکاره شول، موږ هڅه وکړه چې د خدماتو دمخه رامینځته شوي کوډ، ذخیره شوي پروسیجرونه او میزونه په ډیټابیس کې تر اعظمي حد پورې وکاروو. 

په سیسټم کې د جوړ شوي ماډلونو پیمانه د ښه پوهیدو لپاره، دلته د پرمختیایي پالنونو سره د 2012 څخه یو انځور دی:

په 2015 کې، هرڅه په نقشه کې وو او حتی نور هم په تولید کې وو.

• د امر منل د تماس مرکز په جلا بلاک کې وده کړې، چیرې چې امر د آپریټر لخوا منل کیږي.

• په پیزایریا کې د مینو او معلوماتو ځړولو سره عامه سکرینونه وو.

• پخلنځی یو ماډل لري چې په اوتومات ډول غږیز پیغام "نوی پیزا" غږوي کله چې نوی آرډر راشي، او د کوریر لپاره انوائس چاپوي. دا په پخلنځي کې پروسې خورا ساده کوي، کارمندانو ته اجازه ورکوي چې د لوی شمیر ساده عملیاتو لخوا ګډوډ نشي.

• د تحویلي واحد د تحویلي جلا چیک آوټ شو ، چیرې چې کوریر ته امر صادر شوی و چې دمخه یې لیږد کړی و. د هغه کاري وخت د معاشونو د محاسبې لپاره په پام کې نیول شوی و. 

په موازي توګه، له 2012 څخه تر 2015 پورې، له 10 څخه ډیر پراختیا کونکي راښکاره شول، 35 پیزاریا پرانستل شول، سیسټم یې رومانیا ته ځای په ځای کړ او په متحده ایالاتو کې د پلورنځیو پرانیستلو لپاره چمتو شول. پراختیا کونکي نور د ټولو دندو سره معامله نه کوي، مګر په ټیمونو ویشل شوي. هر یو د سیسټم په خپله برخه کې تخصص لري. 

ستونزې

په شمول د معمارۍ له امله (مګر نه یوازې).

په اډه کې ګډوډي

یو اساس اسانه دی. ثبات پدې کې ترلاسه کیدی شي ، او د اړوندو ډیټابیسونو کې رامینځته شوي وسیلو په لګښت. د دې سره کار کول پیژندل شوي او اسانه دي ، په ځانګړي توګه که چیرې لږ میزونه او لږ معلومات شتون ولري.

مګر د 4 کلونو په پراختیا کې، ډیټابیس شاوخوا 600 میزونه، 1500 ذخیره شوي طرزالعملونه، چې ډیری یې منطق هم درلود. افسوس، ذخیره شوي پروسیجرونه د MySQL سره کار کولو په وخت کې ډیره ګټه نه راوړي. دوی د بیس لخوا زیرمه شوي ندي ، او په دوی کې د منطق ذخیره کول پراختیا او ډیبګ کول پیچلي کوي. د کوډ بیا کارول هم ستونزمن دي.

ډیری میزونه مناسب شاخصونه نه درلودل، په کوم ځای کې ، برعکس ، دلته ډیری شاخصونه شتون درلود ، کوم چې دا یې دننه کول ستونزمن کړي. دا اړینه وه چې شاوخوا 20 جدولونه تعدیل کړئ - د امر رامینځته کولو معامله شاوخوا 3-5 ثانیې وخت نیسي. 

په جدولونو کې معلومات تل په مناسب شکل کې نه و. په کوم ځای کې دا اړینه وه چې غیر عادي کول ترسره کړي. په منظمه توګه د ترلاسه شویو معلوماتو یوه برخه د XML جوړښت په بڼه په کالم کې وه، دا د اجرا کولو وخت زیات کړ، پوښتنې یې اوږدې کړې او پراختیا یې پیچلې کړه.

ورته میزونو ته خورا تولید شوي متفاوت غوښتنې. مشهور میزونه په ځانګړې توګه زیانمن شوي، لکه پورته ذکر شوي جدول. امر یا میزونه د پیزا پلورنځی. دوی په پخلنځي کې د عملیاتي انٹرفیسونو ښودلو لپاره کارول شوي، تحلیلونه. بل سایټ دوی سره اړیکه ونیوله (dodopizza.ru)، چیرې چې په هر وخت کې ډیری غوښتنې ناڅاپه راځي. 

معلومات راټول شوي ندي او ډیری محاسبې د اډې په کارولو سره په الوتنه کې ترسره شوې. دا غیر ضروري حسابونه او اضافي بار رامینځته کوي. 

ډیری وختونه کوډ ډیټابیس ته لاړ کله چې دا نشي کولی. په ځینو ځایونو کې کافي عملیات نه وو، چیرته چې دا به اړین وي چې یوه غوښتنه د کوډ له لارې څو ته خپره شي ترڅو د اعتبار چټکتیا او زیاتوالی ومومي. 

په کوډ کې همغږي او ګډوډي

هغه ماډلونه چې باید د دوی د سوداګرۍ برخې مسؤل وي دا په صادقانه توګه ترسره نه کړل. ځینې ​​یې د رولونو لپاره د دندو نقلونه درلودل. د مثال په توګه، یو ځایی بازار موندونکی چې په خپل ښار کې د شبکې د بازار موندنې فعالیت مسولیت لري باید دواړه "اډمین" انٹرفیس (د ترویجونو رامینځته کولو لپاره) او د "دفتر مدیر" انٹرفیس (د سوداګرۍ په اړه د ترویجونو اغیزو لیدلو لپاره) وکاروي. البته، د دواړو ماډلونو دننه ورته خدمت کارول شوی چې د بونس ترویج سره کار کوي.

خدمتونه (د یوې واحدې لویې پروژې دننه ټولګي) کولی شي یو بل ته زنګ ووهي ترڅو خپل معلومات بډایه کړي.

د ماډل ټولګیو سره چې پخپله ډاټا ذخیره کوي، په کوډ کې کار په بل ډول ترسره شو. په کوم ځای کې جوړونکي شتون درلود چې له لارې یې د اړینو ساحو مشخص کول ممکن وو. په ځینو ځایونو کې دا د عامه ملکیتونو له لارې ترسره شوي. البته، د ډیټابیس څخه د معلوماتو ترلاسه کول او بدلول مختلف وو. 

منطق یا په کنټرولرانو یا د خدماتو په ټولګیو کې و. 

داسې ښکاري چې دا کوچنۍ مسلې دي، مګر دوی په پراخه کچه پرمختګ ورو کړی او کیفیت یې کم کړی، چې د بې ثباتۍ او کیچونو المل ګرځي. 

د لوی پرمختګ پیچلتیا

پخپله په پرمختګ کې ستونزې رامنځته شوې. دا اړینه وه چې د سیسټم مختلف بلاکونه جوړ کړي، او په موازي توګه. په یو واحد کوډ کې د هرې برخې اړتیاوې په زیاتیدونکي توګه ستونزمنې شوې. په ورته وخت کې د ټولو برخو موافقه کول او خوښول اسانه ندي. پدې کې اضافه شوي په ټیکنالوژۍ کې محدودیتونه ، په ځانګړي توګه د بیس او فرنټ اینډ په اړه. دا اړینه وه چې jQuery د لوړې کچې چوکاټونو په لور پریږدي، په ځانګړې توګه د پیرودونکي خدماتو (ویب پاڼې) په برخه کې.

د سیسټم په ځینو برخو کې، د دې لپاره ډیر مناسب ډیټابیسونه کارول کیدی شي.. د مثال په توګه ، وروسته موږ د آرډر باسکیټ ذخیره کولو لپاره له Redis څخه CosmosDB ته د حرکت کولو قضیه درلوده. 

ټیمونه او پراختیا کونکي چې د دوی په ساحه کې ښکیل دي په واضح ډول د دوی خدماتو لپاره د پراختیا او رول آوټ دواړو شرایطو کې ډیر خپلواکي غواړي. شخړې یوځای کړئ، مسلې خوشې کړئ. که د 5 پراختیا کونکو لپاره دا ستونزه مهمه نه وي، نو د 10 سره، او حتی د پالن شوي ودې سره، هرڅه به ډیر جدي شي. او مخکې باید د ګرځنده اپلیکیشن پراختیا وي (دا په 2017 کې پیل شو ، او په 2018 کې دا و. لوی سقوط). 

د سیسټم مختلفې برخې د ثبات مختلف کچې ته اړتیا لري، مګر د سیسټم قوي ارتباط له امله موږ نشو کولی دا چمتو کړو. په اډمین پینل کې د نوي فنکشن په پراختیا کې یوه تېروتنه ممکن په سایټ کې د امر په منلو کې ترسره شوې وي ، ځکه چې کوډ عام او د بیا کارولو وړ دی ، ډیټابیس او ډیټا هم ورته دي.

دا به شاید ممکنه وي چې د داسې یو واحد - ماډلر جوړښت په چوکاټ کې د دې غلطیو او ستونزو څخه مخنیوی وشي: د مسؤلیت ویش رامینځته کړئ ، دواړه کوډ او ډیټابیس ریفیکٹر کړئ ، پرتونه په روښانه ډول له یو بل څخه جلا کړئ ، هره ورځ کیفیت وڅارئ. مګر غوره شوي معماري حلونه او د سیسټم د فعالیت ګړندۍ پراختیا باندې تمرکز د ثبات په برخه کې ستونزې رامینځته کړې.

څنګه د ذهن ځواک بلاګ په رستورانتونو کې نغدي راجسترونه واچوي

که چیرې د پیزایریا شبکې وده (او بار) په ورته سرعت دوام وکړي ، نو یو څه وروسته به سقوط داسې وي چې سیسټم به راپورته نشي. ښه هغه ستونزې په ګوته کوي چې موږ یې په 2015 کې ورسره مخ شوي یو، دلته ورته کیسه ده. 

په بلاګ کې "د ذهن ځواک"یو ویجټ و چې د ټولې شبکې کال لپاره د عاید په اړه معلومات ښیې. ویجټ د Dodo عامه API ته لاسرسی موندلی، کوم چې دا ډاټا چمتو کوي. دا احصایه اوس مهال شتون لري http://dodopizzastory.com/. ویجټ په هره پاڼه کې ښودل شوی و او په هر 20 ثانیو کې یې په ټایمر کې غوښتنې کولې. غوښتنه api.dodopizza.ru ته لاړه او غوښتنه یې وکړه:

• په شبکه کې د pizzerias شمېر؛

• د کال له پیل راهیسې د شبکې ټول عاید؛

• د نن ورځې عاید.

د عاید په اړه د احصایو غوښتنه مستقیم ډیټابیس ته لاړه او د امرونو په اړه د معلوماتو غوښتنه یې پیل کړه ، په الوتنه کې د معلوماتو راټولول او اندازه ورکول. 

په رستورانتونو کې د نغدو میزونو ورته د سپارښتنو میز ته لاړ، د نن ورځې لپاره د ترلاسه شوي سپارښتنو لیست یې پورته کړ، او نوي فرمایشونه یې اضافه کړل. د نغدو راجستر کونکو خپلې غوښتنې په هر 5 ثانیو کې یا په پاڼه ریفریش کړې.

انځور داسې ښکاریده:

په یوه مني کې، فیودور اوچینیکوف په خپل بلاګ کې یوه اوږده او مشهوره مقاله ولیکه. ډیری خلک بلاګ ته راغلل او هرڅه یې په دقت سره لوستل پیل کړل. پداسې حال کې چې هر یو راغلی خلک مقاله لوستل، د عوایدو ویجټ په سمه توګه کار کاوه او په هر 20 ثانیو کې یې د API غوښتنه کوله.

API په شبکه کې د ټولو پیزیریا لپاره د کال له پیل راهیسې د ټولو امرونو مجموعه محاسبه کولو لپاره زیرمه شوې کړنالره وبلله. مجموعه د امر جدول پر بنسټ وه، کوم چې خورا مشهور دی. پدې وخت کې د ټولو خلاص رستورانتونو ټول نغدي میزونه دې ته ځي. د نغدو میزونو ځواب ویل بند کړل، امرونه ونه منل شول. دوی د سایټ څخه هم ندي منل شوي، په ټریکر کې نه ښکاري، د شفټ مدیر نشي کولی دوی په خپل انٹرفیس کې وګوري. 

دا یوازینۍ کیسه نه ده. د 2015 په مني کې، هره جمعه د سیسټم بار خورا مهم و. څو ځله موږ عامه API بند کړ، او یوځل، موږ حتی باید سایټ بند کړو، ځکه چې هیڅ شی مرسته نه ده کړې. حتی د درنو بارونو لاندې د بندولو امر سره د خدماتو لیست شتون درلود.

له اوس څخه، د بارونو سره زموږ مبارزه او د سیسټم د ثبات لپاره پیل کیږي (د 2015 له مني څخه تر 2018 پورې). دا هغه وخت پېښ شو "لوی سقوط". برسېره پردې، کله ناکله ناکامۍ هم رامنځ ته شوې، ځینې یې خورا حساس دي، مګر اوس د بې ثباتۍ عمومي دوره تیریدل ګڼل کیدی شي.

د سوداګرۍ چټکه وده

ولې دا سمدلاسه نشي ترسره کیدی؟ یوازې لاندې چارټونو ته وګورئ.

همدارنګه په 2014-2015 کې په رومانیا کې پرانستل شو او په متحده ایالاتو کې د پرانستلو لپاره چمتووالی و.

شبکه خورا ګړندۍ وده وکړه ، نوي هیوادونه پرانستل شول ، د پیزاریا نوي فارمیټونه څرګند شول ، د مثال په توګه ، د خواړو په محکمه کې پیزاریا پرانستل شو. دا ټول د پام وړ پاملرنې ته اړتیا لري په ځانګړې توګه د Dodo IS د فعالیتونو پراختیا ته. د دې ټولو دندو پرته ، په پخلنځی کې تعقیب کولو پرته ، په سیسټم کې د محصولاتو او زیانونو محاسبه کول ، د خواړو محکمې تالار کې د حکم صادر کول ، موږ به په سختۍ سره د "سمه" جوړښت او "سمه" چلند په اړه وغږیږو. اوس پرمختګ.

د معمارۍ د وخت د بیاکتنې او په عمومي ډول تخنیکي ستونزو ته د پاملرنې بل خنډ د 2014 کال بحران و. د دې په څیر شیان د ټیمونو وده کولو فرصتونو ته سخت زیان رسوي ، په ځانګړي توګه د ډوډو پیزا په څیر د ځوان سوداګرۍ لپاره.

ګړندي حلونه چې مرسته یې کړې

ستونزې د حل اړتیا لري. په دودیز ډول، حلونه په 2 ګروپونو ویشل کیدی شي:

• ګړندي هغه چې اور غورځوي او د خوندیتوب لږه برخه ورکوي او موږ ته د بدلون لپاره وخت اخلي.

• سیسټمیک او له همدې امله، اوږد. د یو شمیر ماډلونو بیا انجینر کول ، د یو واحد معمارۍ په جلا خدماتو ویشل (ډیری یې مایکرو ندي ، بلکه میکرو خدمتونه دي ، او پدې اړه یو څه شتون لري. د اندری موریفسکي راپور). 

د چټک بدلونونو وچ لیست په لاندې ډول دی:

د بیس ماسټر اندازه کول

البته، لومړی شی چې د بارونو سره معامله کولو لپاره ترسره کیږي د سرور ظرفیت لوړول دي. دا د ماسټر ډیټابیس او ویب سرورونو لپاره ترسره شوی. افسوس، دا یوازې یو ټاکلی حد پورې ممکن دی، بیا دا خورا ګران کیږي.

د 2014 راهیسې، موږ Azure ته تللي یو، موږ د دې موضوع په اړه هم په مقاله کې لیکلي "څنګه ډوډو پیزا د مایکروسافټ ازور کلاوډ په کارولو سره پیزا وړاندې کوي". مګر د اډې لپاره په سرور کې د یو لړ زیاتوالي وروسته، دوی د لګښت په وړاندې راغلل. 

د لوستلو لپاره بنسټیز نقلونه

د اډې لپاره دوه نقلونه جوړ شوي وو:

ریپلیکا ولولئ د حوالې غوښتنې لپاره. دا د لارښودونو لوستلو لپاره کارول کیږي ، ډول ، ښار ، کوڅه ، پیزاریا ، محصولات (وروسته بدل شوی ډومین) ، او په هغه انٹرفیسونو کې چیرې چې یو کوچنی ځنډ د منلو وړ وي. د دې نقلونو څخه 2 شتون درلود، موږ د ماسټرانو په څیر د دوی شتون ډاډمن کړ.

د راپور غوښتنو لپاره ریپلیکا ولولئ. دا ډیټابیس ټیټ شتون درلود، مګر ټول راپورونه ورته لاړل. اجازه راکړئ چې دوی د لوی ډیټا بیاکتنې لپاره درنې غوښتنې ولري، مګر دوی اصلي ډیټابیس او عملیاتي انٹرفیس اغیزه نه کوي. 

په کوډ کې کیچ

په کوډ کې هیڅ کیچ شتون نلري (په هیڅ ډول). دا د بار شوي ډیټابیس ته اضافي ، تل اړین ندي ، غوښتنې لامل شوي. کیچونه لومړی دواړه په حافظه کې او په بهرني کیچ خدمت کې وو ، دا ریډیس و. هرڅه د وخت په تیریدو سره باطل شوي، ترتیبات په کوډ کې مشخص شوي.

ډیری بیکینډ سرورونه

د غوښتنلیک شالید ته هم اړتیا وه چې د ډیری کاري بارونو اداره کولو لپاره اندازه شي. دا اړینه وه چې د یو iis-server څخه کلستر جوړ کړئ. موږ بیا مهالویش کړی دی د غوښتنلیک غونډه له حافظې څخه ریډیس کیچ ته ، کوم چې دا ممکنه کړې چې د راؤنډ رابین سره د ساده بار بیلنسر شاته څو سرورونه رامینځته کړي. په لومړي سر کې، ورته ریډیس د کیچونو په توګه کارول کیده، بیا دا په څو برخو ویشل شوی. 

د پایلې په توګه، جوړښت خورا پیچلی شوی ...

خو یو څه تشنج لرې شو.

او بیا دا اړینه وه چې بار شوي اجزا بیا ترسره کړئ، کوم چې موږ ترسره کړي. په دې اړه به په راتلونکې برخه کې خبرې وکړو.

سرچینه: www.habr.com