Dodo IS ဗိသုကာသမိုင်း- အစောပိုင်း Monolith

ဒါမှမဟုတ် monolith ပါတဲ့ မပျော်တဲ့ ကုမ္ပဏီတိုင်းက သူ့နည်းသူ့ဟန်နဲ့ မပျော်ဘူး။

Dodo IS စနစ် ဖွံ့ဖြိုးတိုးတက်မှုသည် 2011 ခုနှစ်တွင် Dodo Pizza လုပ်ငန်းကဲ့သို့ ချက်ချင်းစတင်ခဲ့သည်။ ၎င်းသည် လုပ်ငန်းလုပ်ငန်းစဉ်များ၏ ပြီးပြည့်စုံပြီး စုစုပေါင်း ဒစ်ဂျစ်တယ်အသွင်ကူးပြောင်းရေး အယူအဆအပေါ် အခြေခံခဲ့သည်။ သူတို့ဘာသာသူတို့2011 ခုနှစ်တွင်ပင်မေးခွန်းများနှင့်သံသယများစွာကိုဖြစ်ပေါ်စေခဲ့သည်။ သို့သော် ယခု ကျွန်ုပ်တို့သည် ဤလမ်းကို 9 နှစ်တိုင်တိုင် လျှောက်လှမ်းခဲ့သည် - မော်နီတာတစ်ခုဖြင့် စတင်ခဲ့သော ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဖွံ့ဖြိုးတိုးတက်မှုဖြင့်၊

ဤဆောင်းပါးသည် "ဗိသုကာလက်ရာကို အဘယ်ကြောင့် ပြန်လည်ရေးသားပြီး ဤမျှကြီးမားသောနှင့် ရှည်လျားသောပြောင်းလဲမှုများကို ပြုလုပ်ရသနည်း" ဟူသော မေးခွန်းများအတွက် "အဖြေ" ဖြစ်သည်။ ယခင်ဆောင်းပါးသို့ ပြန်သွားရန် "Dodo IS ဗိသုကာ၏သမိုင်း- ရုံးနောက်ကြောင်းလမ်း". Dodo IS ၏ဖွံ့ဖြိုးတိုးတက်မှုစတင်ပုံ၊ မူရင်းဗိသုကာပုံသဏ္ဍာန်၊ မော်ဂျူးအသစ်များပေါ်လာပုံနှင့် ကြီးမားသောအပြောင်းအလဲများပြုလုပ်ရသည့် ပြဿနာများကြောင့် စတင်ပါမည်။

"Dodo IS ဆိုတာ ဘာလဲ" ဆောင်းပါးစီးရီးများ။ အကြောင်းပြောပြသည်-

1. Dodo IS (2011-2015) ရှိ အစောပိုင်း monolith (သင်ဒီမှာပါ)

2. Back Office လမ်းကြောင်း- သီးခြားအခြေစိုက်စခန်းများနှင့် ဘတ်စ်ကား.

3. ဖောက်သည်ဘက်မှ လမ်းကြောင်း- အောက်ခြေမျက်နှာစာ (2016-2017)။ (ဆောင်ရွက်ဆဲဖြစ်သည်...)

4. စစ်မှန်သော microservices များ၏သမိုင်း။ (၂၀၁၈-၂၀၁၉)။ (ဆောင်ရွက်ဆဲဖြစ်သည်...)

5. မော်လီတုံးကို အချောထည်ပြုလုပ်ပြီး ဗိသုကာလက်ရာကို တည်ငြိမ်အောင်ပြုလုပ်ပါ။ (ဆောင်ရွက်ဆဲဖြစ်သည်...)

မူလဗိသုကာ

2011 ခုနှစ်တွင် Dodo IS ဗိသုကာလက်ရာသည် ဤကဲ့သို့ ဖြစ်သည်-

ဗိသုကာပညာရှိ ပထမဆုံး သင်ခန်းစာမှာ အမှာစာလက်ခံခြင်း ဖြစ်သည်။ လုပ်ငန်းလုပ်ငန်းစဉ်မှာ-

• ဖောက်သည်သည် ပီဇာကို ခေါ်သည်၊

• မန်နေဂျာက ဖုန်းကို ကောက်ကိုင်လိုက်သည်။

• ဖုန်းဖြင့်အမှာစာလက်ခံသည်

• ၎င်းကို အမှာစာလက်ခံသည့် အင်တာဖေ့စ်တွင် အပြိုင်ဖြည့်ပေးသည်- ၎င်းသည် ကလိုင်းယင့်အကြောင်း အချက်အလက်၊ မှာယူမှုအသေးစိတ်အချက်အလက်များ၊ ပေးပို့မှုလိပ်စာတို့ကို ထည့်သွင်းစဉ်းစားသည်။ 

သတင်းအချက်အလက်စနစ်၏ မျက်နှာပြင်သည် ဤကဲ့သို့ ဖြစ်သည်..။

အောက်တိုဘာလ 2011 မှ ပထမဆုံးဗားရှင်း

ဇန်နဝါရီ 2012 တွင် အနည်းငယ် တိုးတက်လာသည်။

Dodo Pizza သတင်းအချက်အလက်စနစ် ပေးပို့ခြင်း ပီဇာ စားသောက်ဆိုင်

ပထမအမှာစာယူခြင်း module ၏ဖွံ့ဖြိုးတိုးတက်မှုအတွက်အရင်းအမြစ်များကိုကန့်သတ်ခဲ့သည်။ မြန်မြန်ဆန်ဆန်နဲ့ အသင်းငယ်လေးတွေနဲ့ အများကြီး လုပ်ခဲ့ရပါတယ်။ အဖွဲ့ငယ်လေးသည် အနာဂတ်စနစ်တစ်ခုလုံးအတွက် အုတ်မြစ်ချပေးသော developer 2 ဦးဖြစ်သည်။

၎င်းတို့၏ ပထမဆုံး ဆုံးဖြတ်ချက်သည် နည်းပညာအစုအဝေး၏ ကံကြမ္မာကို ဆုံးဖြတ်သည်-

• ASP.NET MVC၊ C# ဘာသာစကားတွင် နောက်ကွယ်။ developer များသည် dotnetchiki ဖြစ်သည်၊ ဤ stack သည်သူတို့အတွက်ရင်းနှီးပြီးနှစ်သက်စရာကောင်းသည်။

• Bootstrap နှင့် JQuery တွင် Frontend- ကိုယ်တိုင်ရေးထားသော ပုံစံများနှင့် scripts များတွင် အသုံးပြုသူကြားခံများ။ 

• MySQL ဒေတာဘေ့စ်- လိုင်စင်ကုန်ကျစရိတ်မရှိ၊ အသုံးပြုရလွယ်ကူသည်။

• Windows Server ရှိဆာဗာများသည် .NET သည် Windows အောက်တွင်သာရှိနိုင်သောကြောင့်ဖြစ်သည် (ကျွန်ုပ်တို့သည် Mono ကိုဆွေးနွေးမည်မဟုတ်ပါ)။

ရုပ်ပိုင်းဆိုင်ရာအရ၊ ဤအရာအားလုံးကို "အိမ်ရှင်၌ အပ်နှံခြင်း" တွင် ဖော်ပြထားပါသည်။ 

Order Intake Application Architecture

ထို့နောက် လူတိုင်းသည် အသေးစားဝန်ဆောင်မှုများအကြောင်း ပြောဆိုနေကြပြီး SOA ကို ကြီးမားသောပရောဂျက်များတွင် ၅ နှစ်ကြာအသုံးပြုခဲ့သည်၊ ဥပမာ၊ WCF ကို ၂၀၀၆ ခုနှစ်တွင် ထုတ်ပြန်ခဲ့သည်။ ဒါပေမယ့် သူတို့ဟာ ယုံကြည်စိတ်ချရပြီး သက်သေပြတဲ့ အဖြေတစ်ခုကို ရွေးချယ်ခဲ့ပါတယ်။

ဒီမှာပါ။

Asp.Net MVC သည် ဖောင်တစ်ခု သို့မဟုတ် ဖောက်သည်တစ်ဦးထံမှ တောင်းဆိုမှုအရ ဆာဗာကို တင်ဆက်ခြင်းဖြင့် HTML စာမျက်နှာကို တင်ဆက်ပေးသည့် Razor ဖြစ်သည်။ ကလိုင်းယင့်တွင်၊ CSS နှင့် JS script များသည် အချက်အလက်များကို ပြသထားပြီးဖြစ်ပြီး လိုအပ်ပါက JQuery မှတဆင့် AJAX တောင်းဆိုမှုများကို လုပ်ဆောင်ပါ။

ဆာဗာပေါ်ရှိ တောင်းဆိုမှုများသည် *Controller အတန်းများတွင် ပြီးဆုံးသည်၊၊ နောက်ဆုံး HTML စာမျက်နှာ၏ လုပ်ဆောင်မှုနှင့် မျိုးဆက်တို့ကို နည်းလမ်းဖြင့် ပြုလုပ်သည့် *Controller အတန်းများတွင် အဆုံးသတ်သည်။ ထိန်းချုပ်သူများသည် *ဝန်ဆောင်မှုများဟုခေါ်သော ယုတ္တိဗေဒအလွှာတစ်ခုထံ တောင်းဆိုမှုများ ပြုလုပ်သည်။ ဝန်ဆောင်မှုတစ်ခုစီသည် လုပ်ငန်း၏ ကဏ္ဍအချို့နှင့် သက်ဆိုင်သည်-

• ဥပမာအားဖြင့် DepartmentStructureService သည် ဌာနဆိုင်ရာများတွင် ပီဇာနှင့်ပတ်သက်သော အချက်အလက်များကို ထုတ်ပေးသည်။ ဌာနတစ်ခုသည် တစ်ခုတည်းသော franchisee မှလည်ပတ်သော pizzerias အုပ်စုတစ်ခုဖြစ်သည်။

• ReceivingOrdersService သည် လက်ခံပြီး အမိန့်၏ဖွဲ့စည်းပုံကို တွက်ချက်သည်။

• နှင့် SmsService သည် API ဝန်ဆောင်မှုများကိုခေါ်ဆိုခြင်းဖြင့် SMS ပေးပို့ရန် SMS ပေးပို့ခဲ့သည်။

ဝန်ဆောင်မှုများသည် ဒေတာဘေ့စ်မှ ဒေတာများကို စီမံဆောင်ရွက်သည်၊ သိမ်းဆည်းထားသော လုပ်ငန်းဆိုင်ရာ ယုတ္တိဗေဒ။ ဝန်ဆောင်မှုတစ်ခုစီတွင် သင့်လျော်သောအမည်ဖြင့် တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော *Repositories ရှိသည်။ ၎င်းတို့တွင် ဒေတာဘေ့စ်တွင် သိမ်းဆည်းထားသော လုပ်ထုံးလုပ်နည်းများနှင့် မြေပုံထုတ်သည့် အလွှာတစ်ခုအတွက် စုံစမ်းမေးမြန်းမှုများ ပါရှိပြီးဖြစ်သည်။ အထူးသဖြင့် အစီရင်ခံခြင်းဒေတာထုတ်ပေးသော သိုလှောင်ခန်းများတွင် စီးပွားရေးဆိုင်ရာ ယုတ္တိရှိမှုများစွာရှိသည်။ ORM ကို အသုံးမချပါ၊ လူတိုင်း လက်ဖြင့်ရေးထားသော sql ကို အားကိုးသည်။ 

ဒိုမိန်းမော်ဒယ်နှင့် ဘုံအကူအတန်းအစား၊ ဥပမာ၊ အမှာစာကို သိမ်းဆည်းသည့် အမှာစာအတန်းအစားလည်း ရှိပါသည်။ တူညီသောနေရာ၌၊ အလွှာတွင်၊ ရွေးချယ်ထားသော ငွေကြေးအရ ဖော်ပြထားသည့် စာသားကို ပြောင်းလဲရန် အထောက်အပံတစ်ခုရှိသည်။

ဤအရာအားလုံးကို ထိုသို့သောပုံစံဖြင့် ကိုယ်စားပြုနိုင်သည်-

အမိန့်လမ်း

ထိုသို့သော အမှာစာတစ်ခုကို ဖန်တီးရန် ရိုးရှင်းသော ကနဦးနည်းလမ်းကို စဉ်းစားပါ။

အစပိုင်းတွင်၊ ဆိုက်သည်တည်ငြိမ်ခဲ့သည်။ ၎င်းတွင် စျေးနှုန်းများပါရှိပြီး အပေါ်ပိုင်းတွင် ဖုန်းနံပါတ်တစ်ခုနှင့် "ပီဇာလိုချင်ပါက ဖုန်းနံပါတ်ကိုခေါ်ဆို၍ မှာယူပါ။" မှာယူရန်အတွက်၊ ကျွန်ုပ်တို့သည် ရိုးရှင်းသောစီးဆင်းမှုကို အကောင်အထည်ဖော်ရန် လိုအပ်သည်- 

• ဖောက်သည်သည် စျေးနှုန်းများနှင့်အတူ အငြိမ်ဆိုက်သို့ လာရောက်လည်ပတ်သည်၊ ထုတ်ကုန်များကို ရွေးချယ်ကာ ဆိုက်ပေါ်ရှိ နံပါတ်ကို ခေါ်ဆိုသည်။

• ဖောက်သည်သည် အော်ဒါတွင် သူတို့ထည့်လိုသော ထုတ်ကုန်များကို အမည်ပေးသည်။

• သူ့လိပ်စာနဲ့ နာမည်ပေးတယ်။

• အော်ပရေတာက အော်ဒါလက်ခံတယ်။

• မှာယူမှုကို လက်ခံထားသော အမှာစာကြားခံတွင် ပြသထားသည်။

၎င်းသည် menu ကိုပြသခြင်းဖြင့်စတင်သည်။ အကောင့်ဝင်ထားသော သုံးစွဲသူ-အော်ပရေတာသည် တစ်ကြိမ်လျှင် မှာယူမှုတစ်ခုသာ လက်ခံသည်။ ထို့ကြောင့်၊ မူကြမ်းလှည်းကို သူ၏ session တွင် သိမ်းဆည်းထားနိုင်သည် (အသုံးပြုသူ၏ session ကို memory တွင် သိမ်းဆည်းထားသည်)။ ကုန်ပစ္စည်းများနှင့် ဖောက်သည်အချက်အလက် ပါ၀င်သည့် လှည်းအရာဝတ္ထုတစ်ခု ရှိပါသည်။

ဖောက်သည်က ထုတ်ကုန်အမည်ပေးသည်၊ အော်ပရေတာက ကလစ်နှိပ်သည်။ + ထုတ်ကုန်၏ဘေးတွင်၊ တောင်းဆိုချက်တစ်ခုဆာဗာသို့ပေးပို့သည်။ ထုတ်ကုန်နှင့်ပတ်သက်သည့် အချက်အလက်ကို ဒေတာဘေ့စ်မှ ဆွဲထုတ်ပြီး ထုတ်ကုန်နှင့်ပတ်သက်သည့် အချက်အလက်များကို လှည်းသို့ ထည့်ပေးသည်။

ပွောဆို. ဟုတ်ကဲ့၊ ဒီမှာ ဒေတာဘေ့စ်ကနေ ထုတ်ကုန်ကို ဆွဲထုတ်လို့မရပေမယ့် ရှေ့တန်းကနေ လွှဲပြောင်းပါ။ ဒါပေမယ့် ရှင်းရှင်းလင်းလင်းပြောရရင်တော့ database ထဲက လမ်းကြောင်းကို အတိအကျ ပြခဲ့တယ်။ 

ထို့နောက် client ၏လိပ်စာနှင့်အမည်ကိုရိုက်ထည့်ပါ။ 

"အမှာစာဖန်တီးရန်" ကိုနှိပ်သောအခါ-

• တောင်းဆိုချက်ကို OrderController.SaveOrder() သို့ ပေးပို့သည်။

• ကျွန်ုပ်တို့သည် အစည်းအဝေးမှ လှည်းကိုရရှိသည်၊ ကျွန်ုပ်တို့လိုအပ်သော ပမာဏတွင် ကုန်ပစ္စည်းများရှိပါသည်။

• ကျွန်ုပ်တို့သည် ကလိုင်းယင့်အကြောင်း အချက်အလက်များဖြင့် လှည်းကို ဖြည့်စွက်ပြီး ၎င်းကို ဒေတာဘေ့စ်တွင် သိမ်းဆည်းထားသည့် ReceivingOrderService အတန်း၏ AddOrder နည်းလမ်းသို့ ပေးပို့ပါသည်။ 

• ဒေတာဘေ့စ်တွင် အမှာစာ၊ အမှာစာ၏ဖွဲ့စည်းပုံ၊ client နှင့် ဇယားများပါရှိပြီး ၎င်းတို့အားလုံးကို ချိတ်ဆက်ထားသည်။

• အမှာစာပြသသည့် အင်တာဖေ့စ်သည် သွားကာ နောက်ဆုံးအမှာစာများကို ဆွဲထုတ်ပြီး ၎င်းတို့ကို ပြသသည်။

မော်ဂျူးအသစ်များ

အမိန့်ယူခြင်းသည် အရေးကြီးပြီး လိုအပ်ပါသည်။ ရောင်းရန်အမှာစာမရှိပါက ပီဇာလုပ်ငန်းကို သင်မလုပ်နိုင်ပါ။ ထို့ကြောင့်၊ စနစ်သည် ၂၀၁၂ ခုနှစ်မှ ၂၀၁၅ ခုနှစ်အတွင်း ခန့်မှန်းခြေအားဖြင့် လုပ်ဆောင်နိုင်စွမ်းကို စတင်ရရှိလာသည်။ ဤအချိန်အတောအတွင်း၊ ငါခေါ်မည့်စနစ်၏ ကွဲပြားသောတုံးများစွာ ပေါ်လာသည်။ မော်ဂျူးများဝန်ဆောင်မှု သို့မဟုတ် ထုတ်ကုန်၏ သဘောတရားကို ဆန့်ကျင်သည်။ 

မော်ဂျူးတစ်ခုသည် ဘုံလုပ်ငန်းရည်မှန်းချက်အချို့ဖြင့် ပေါင်းစပ်ထားသော လုပ်ဆောင်ချက်များအစုအဝေးတစ်ခုဖြစ်သည်။ တစ်ချိန်တည်းမှာပင် ၎င်းတို့သည် ရုပ်ပိုင်းဆိုင်ရာ တူညီသော အသုံးချမှုတွင် ရှိနေသည်။

Modules များကို system blocks ဟုခေါ်နိုင်သည်။ ဥပမာအားဖြင့်၊ ဤသည်မှာ အစီရင်ခံခြင်း module တစ်ခု၊ admin interfaces၊ မီးဖိုချောင်ရှိအစားအစာခြေရာခံကိရိယာ, ခွင့်ပြုချက်။ ၎င်းတို့အားလုံးသည် မတူညီသော အသုံးပြုသူ အင်တာဖေ့စ်များဖြစ်ပြီး အချို့မှာ မတူညီသော အမြင်စတိုင်များပင် ရှိသည်။ တစ်ချိန်တည်းမှာပင်၊ အရာအားလုံးသည် အပလီကေးရှင်းတစ်ခု၊ လုပ်ဆောင်နေသည့် လုပ်ငန်းစဉ်တစ်ခု၏ ဘောင်အတွင်းတွင် ရှိနေသည်။ 

နည်းပညာအရ၊ မော်ဂျူးများကို ဧရိယာအဖြစ် ဒီဇိုင်းထုတ်ခဲ့သည် (ထိုကဲ့သို့သော အကြံအစည်သည်ပင် ရှိနေသေးသည်။ asp.net core) ရှေ့တန်း၊ မော်ဒယ်များနှင့် ၎င်းတို့၏ ကိုယ်ပိုင် ထိန်းချုပ်ကိရိယာ အတန်းများအတွက် သီးခြားဖိုင်များ ရှိသည်။ ရလဒ်အနေနဲ့ ဒီကနေ စနစ်ပြောင်းခဲ့တယ်..။

...ဤသို့

အချို့သော modules များကို သီးခြား sites (executable project) ဖြင့် အကောင်အထည်ဖော်ပြီး လုံးဝသီးခြားလုပ်ဆောင်နိုင်စွမ်းကြောင့်ဖြစ်ပြီး တစ်စိတ်တစ်ပိုင်းအားဖြင့် အနည်းငယ် သီးခြားပိုမိုအာရုံစိုက်ထားသော ဖွံ့ဖြိုးတိုးတက်မှုကြောင့်ဖြစ်သည်။ ဤ-

• ဆိုက်ကို - ပထမဗားရှင်း ဆိုက် dodopizza.ru ။

• ထုတ်ကုန်: 1C အတွက် Dodo IS မှ အစီရင်ခံစာများ တင်ခြင်း။ 

• ကိုယ်ရေးကိုယ်တာ - ဝန်ထမ်း၏ကိုယ်ရေးကိုယ်တာအကောင့်။ သီးခြားတီထွင်ထားပြီး ၎င်း၏ကိုယ်ပိုင်ဝင်ပေါက်အမှတ်နှင့် သီးခြားဒီဇိုင်းရှိသည်။

• fs - statics hosting ပရောဂျက်တစ်ခု။ နောက်ပိုင်းတွင် ကျွန်ုပ်တို့သည် ၎င်းနှင့်ဝေးရာသို့ ပြောင်းရွှေ့ကာ တည်ငြိမ်မှုအားလုံးကို Akamai CDN သို့ ရွှေ့ခဲ့သည်။ 

ကျန်သောဘလောက်များသည် BackOffice အပလီကေးရှင်းတွင်ရှိသည်။ 

အမည် ရှင်းလင်းချက်

• Cashier - စားသောက်ဆိုင် ငွေကိုင်။

• ShiftManager - "Shift Manager" အခန်းကဏ္ဍအတွက် အင်တာဖေ့စ်များ- ပီဇာရောင်းချမှုဆိုင်ရာ လုပ်ငန်းဆောင်ရွက်မှုစာရင်းအင်းများ၊ ကုန်ပစ္စည်းများကို ရပ်တန့်စာရင်းတွင် ထည့်သွင်းနိုင်မှု၊ မှာယူမှုကို ပြောင်းလဲပါ။

• OfficeManager - "Pizzeria Manager" နှင့် "Franchisee" အခန်းကဏ္ဍများအတွက် အင်တာဖေ့စ်များ။ ဤတွင် ပီဇာကို တည်ထောင်ခြင်း၊ ၎င်း၏ ဘောနပ်စ် အရောင်းမြှင့်တင်မှုများ၊ ဝန်ထမ်းများနှင့် အလုပ်လက်ခံခြင်း၊ အစီရင်ခံစာများ အတွက် စုစည်းထားသော လုပ်ဆောင်ချက်များ ဖြစ်သည်။

• PublicScreens - ပီဇာတွင်ချိတ်ထားသော TV နှင့် တက်ဘလက်များအတွက် အင်တာဖေ့စ်များ။ တီဗီများသည် မီနူးများ၊ ကြော်ငြာအချက်အလက်များ၊ ပေးပို့ချိန်တွင် မှာယူမှုအခြေအနေများကို ပြသပေးပါသည်။ 

၎င်းတို့သည် ဘုံဝန်ဆောင်မှုအလွှာ၊ ဘုံ Dodo.Core ဒိုမိန်းအတန်းအစား ဘလောက်နှင့် ဘုံအခြေခံကို အသုံးပြုခဲ့သည်။ တခါတရံမှာ သူတို့အချင်းချင်း အသွင်ကူးပြောင်းရေးတလျှောက် ဦးဆောင်သွားနိုင်တယ်။ dodopizza.ru သို့မဟုတ် personal.dodopizza.ru ကဲ့သို့သော ဆိုက်များအပါအဝင် အထွေထွေဝန်ဆောင်မှုများသို့ သွားခဲ့သည်။

မော်ဂျူးအသစ်များ ပေါ်လာသောအခါ၊ ကျွန်ုပ်တို့သည် ဖန်တီးထားပြီးဖြစ်သော ဝန်ဆောင်မှုကုဒ်များ၊ ဒေတာဘေ့စ်အတွင်း သိမ်းဆည်းထားသော လုပ်ထုံးလုပ်နည်းများနှင့် ဇယားများကို အမြင့်ဆုံးအထိ ပြန်လည်အသုံးပြုရန် ကြိုးစားခဲ့သည်။ 

စနစ်တွင်ပြုလုပ်ထားသော module များ၏စကေးကို ပိုမိုကောင်းမွန်စွာနားလည်ရန်အတွက် ဤနေရာတွင် 2012 မှ ဖွံ့ဖြိုးတိုးတက်မှုအစီအစဥ်များပါရှိသော diagram တစ်ခုဖြစ်သည်။

2015 တွင် အရာအားလုံးသည် မြေပုံပေါ်တွင် ရှိနေပြီး ထုတ်လုပ်မှုတွင် ပိုမိုများပြားလာခဲ့သည်။

• အမှာစာလက်ခံမှုကို အော်ပရေတာမှ လက်ခံသည့် အဆက်အသွယ်စင်တာ၏ သီးခြားဘလောက်တစ်ခုအဖြစ် ကြီးထွားလာသည်။

• ပီဇာများတွင် မီနူးများနှင့် အချက်အလက် ချိတ်ဆွဲထားသော အများသူငှာ မျက်နှာပြင်များ ရှိခဲ့သည်။

• အမှာစာအသစ်ရောက်ရှိလာသောအခါတွင် "New Pizza" အသံမက်ဆေ့ချ်ကို အလိုအလျောက်ဖွင့်ပေးသည့် မီးဖိုချောင်တွင် မော်ဂျူးတစ်ခုရှိပြီး ပို့ကုန်အတွက် ပြေစာကိုလည်း ရိုက်နှိပ်ပေးပါသည်။ ၎င်းသည် မီးဖိုချောင်ရှိ လုပ်ငန်းစဉ်များကို များစွာရိုးရှင်းစေပြီး ဝန်ထမ်းများအား ရိုးရှင်းသော လုပ်ငန်းဆောင်ရွက်မှုများစွာဖြင့် အာရုံထွေပြားခြင်းမှ ကင်းဝေးစေပါသည်။

• ပို့ဆောင်မှုယူနစ်သည် သီးခြား Delivery Checkout တစ်ခုဖြစ်လာပြီး၊ ၎င်းမှာယခင်အပြောင်းအရွှေ့ကိုယူခဲ့သော အမြန်ချောပို့သူထံ အမိန့်ထုတ်ပေးပါသည်။ သူ၏အလုပ်ချိန်ကို လစာတွက်ချက်ရန် ထည့်သွင်းစဉ်းစားသည်။ 

တဆက်တည်းတွင်၊ 2012 ခုနှစ်မှ 2015 ခုနှစ်အတွင်း developer 10 ကျော် ပေါ်လာပြီး ပီဇာ 35 ခု ဖွင့်လှစ်ကာ ရိုမေးနီးယားတွင် စနစ်ကို အသုံးချကာ အမေရိကန်တွင် ဆိုင်ခွဲများ ဖွင့်လှစ်ရန်အတွက် ပြင်ဆင်ခဲ့သည်။ developer များသည် အလုပ်အားလုံးကို မလုပ်ဆောင်တော့ဘဲ အဖွဲ့များခွဲထားသည်။ တစ်ခုစီသည် စနစ်၏ ကိုယ်ပိုင် အစိတ်အပိုင်းတွင် အထူးပြုသည်။ 

ပြဿနာများ

ဗိသုကာပညာကြောင့် အပါအဝင် (ဒါပေမယ့်) မသာ။

ခြေရင်း၌ မငြိမ်မသက် ဖြစ်နေသည်။

အခြေခံတစ်ခုကတော့ အဆင်ပြေပါတယ်။ ဆက်စပ်ဒေတာဘေ့စ်များတွင်တည်ဆောက်ထားသောကိရိယာများ၏ကုန်ကျစရိတ်ဖြင့်၎င်း၌တစ်သမတ်တည်းအောင်မြင်နိုင်သည်။ အထူးသဖြင့် ဇယားအနည်းငယ်နှင့် ဒေတာအနည်းငယ်သာရှိလျှင် ၎င်းကို ရင်းနှီးပြီး အဆင်ပြေပါသည်။

ဒါပေမယ့် ဖွံ့ဖြိုးတိုးတက်မှု 4 နှစ်ကြာလာတာနဲ့အမျှ ဒေတာဘေ့စ်မှာ ဇယားပေါင်း 600 ခန့်၊ သိမ်းဆည်းထားတဲ့ လုပ်ထုံးလုပ်နည်း 1500 ခန့်ရှိလာပြီး အများစုမှာ ယုတ္တိဗေဒလည်း ပါရှိပါတယ်။ ကံမကောင်းစွာပဲ၊ သိမ်းဆည်းထားသောလုပ်ထုံးလုပ်နည်းများသည် MySQL နှင့်အလုပ်လုပ်သောအခါတွင်များစွာသောအကျိုးကျေးဇူးများမရရှိပါ။ ၎င်းတို့ကို အခြေခံအားဖြင့် ကက်ရှ်မလုပ်ဘဲ ၎င်းတို့တွင် လော့ဂျစ်ကို သိမ်းဆည်းခြင်းသည် ဖွံ့ဖြိုးတိုးတက်မှုနှင့် အမှားရှာပြင်ခြင်းကို ရှုပ်ထွေးစေသည်။ ကုဒ်ပြန်သုံးရတာလည်း ခက်ပါတယ်။

ဇယားများစွာတွင် သင့်လျော်သော အညွှန်းများ မရှိခဲ့ပါ။ဆန့်ကျင်ဘက်အားဖြင့် တစ်နေရာရာတွင် ထည့်သွင်းရန် ခက်ခဲစေသည့် အညွှန်းကိန်းများ အများအပြားရှိသည်။ ဇယား 20 ခန့်ကို ပြင်ဆင်ရန် လိုအပ်သည် - အမှာစာတစ်ခုဖန်တီးရန် ငွေလွှဲခသည် 3-5 စက္ကန့်ခန့် ကြာနိုင်သည်။ 

ဇယားများရှိ ဒေတာများသည် အသင့်လျော်ဆုံးပုံစံဖြင့် အမြဲတမ်းမဟုတ်ပေ။. တစ်နေရာရာမှာ denormalization လုပ်ဖို့လိုတယ်။ ပုံမှန်လက်ခံရရှိသည့်ဒေတာ၏တစ်စိတ်တစ်ပိုင်းသည် XML ဖွဲ့စည်းတည်ဆောက်ပုံပုံစံကော်လံတစ်ခုတွင်ရှိပြီး၊ ၎င်းသည် လုပ်ဆောင်ချိန်ကိုတိုးစေကာ မေးမြန်းချက်များကို ရှည်လျားစေပြီး ဖွံ့ဖြိုးတိုးတက်မှုကို ရှုပ်ထွေးစေသည်။

တူညီတဲ့ စားပွဲတွေကို အရမ်းထုတ်လုပ်ခဲ့ကြတယ်။ ကွဲပြားသောတောင်းဆိုမှုများ. အထူးသဖြင့် အထက်ဖော်ပြပါ ဇယားကဲ့သို့ လူကြိုက်များသော စားပွဲများ ကြုံတွေ့ခဲ့ရသည်။ အမိန့် သို့မဟုတ် စားပွဲများ ပီဇာဆိုင်ကို. ၎င်းတို့ကို မီးဖိုချောင်ရှိ လုပ်ငန်းဆောင်ရွက်မှုဆိုင်ရာ အင်တာဖေ့စ်များ၊ ခွဲခြမ်းစိတ်ဖြာချက်များ ပြသရန် ၎င်းတို့ကို အသုံးပြုခဲ့သည်။ အခြားဆိုက်က ၎င်းတို့ကို ဆက်သွယ်ခဲ့သည် (dodopizza.ru) အချိန်မရွေး တောင်းဆိုမှု အများအပြား ရုတ်တရက် ရောက်လာနိုင်သည်။ 

ဒေတာများကို စုစည်းထားခြင်းမရှိပါ။ အခြေစိုက်စခန်းကို အသုံးပြု၍ ပျံသန်းမှုတွင် တွက်ချက်မှုများစွာ ပြုလုပ်ခဲ့သည်။ ၎င်းသည် မလိုအပ်သော တွက်ချက်မှုများနှင့် အပိုဝန်ကို ဖန်တီးခဲ့သည်။ 

မကြာခဏ ကုဒ်သည် ဒေတာဘေ့စ်သို့ ရောက်သွားတတ်သည်။ အစုလိုက်အပြုံလိုက် လည်ပတ်မှု လုံလောက်မှု မရှိသောနေရာတွင်၊ တစ်နေရာရာတွင် တောင်းဆိုချက်တစ်ခုကို အရှိန်မြှင့်ရန်နှင့် ယုံကြည်စိတ်ချရမှုကို တိုးမြှင့်ရန်အတွက် ကုဒ်မှတဆင့် အများအပြားသို့ ဖြန့်ကြက်ရန် လိုအပ်ပါသည်။ 

ကုဒ်တွင် ပေါင်းစပ်မှုနှင့် ရှုပ်ထွေးမှု

လုပ်ငန်း၏တစ်စိတ်တစ်ပိုင်းအတွက် တာဝန်ရှိသည်ဟု ယူဆရသည့် မော်ဂျူးများသည် ၎င်းကို ရိုးသားစွာ မလုပ်ခဲ့ပါ။. ၎င်းတို့ထဲမှ အချို့သည် အခန်းကဏ္ဍများအတွက် လုပ်ဆောင်ချက်များ ထပ်တူရှိနေသည်။ ဥပမာအားဖြင့်၊ ၎င်း၏မြို့၌ ကွန်ရက်စျေးကွက်ရှာဖွေရေး လုပ်ဆောင်ချက်အတွက် တာဝန်ရှိသော ပြည်တွင်းစျေးကွက်ရှာဖွေသူသည် "Admin" အင်တာဖေ့စ် (ပရိုမိုးရှင်းများဖန်တီးရန်) နှင့် "Office Manager" အင်တာဖေ့စ် (လုပ်ငန်းအပေါ် အရောင်းမြှင့်တင်မှုများ၏ အကျိုးသက်ရောက်မှုများကို ကြည့်ရှုရန်) နှစ်ခုလုံးကို အသုံးပြုရမည်ဖြစ်သည်။ မှန်ပါသည်၊ မော်ဂျူးနှစ်ခုလုံးတွင် ဘောနပ်စ်ပရိုမိုးရှင်းများဖြင့် လုပ်ဆောင်သော တူညီသောဝန်ဆောင်မှုကို အသုံးပြုခဲ့သည်။

ဝန်ဆောင်မှုများ (monolithic ကြီးမားသော ပရောဂျက်တစ်ခုအတွင်း အတန်းများ) သည် ၎င်းတို့၏ အချက်အလက်များကို ကြွယ်ဝစေရန် အချင်းချင်း ခေါ်ဆိုနိုင်သည်။

ဒေတာသိမ်းဆည်းသည့် မော်ဒယ်အတန်းများနှင့်အတူ၊ code များတွင် အလုပ် ကွဲပြားစွာ ဆောင်ရွက်ခဲ့ပါသည်။. လိုအပ်သောကွက်လပ်များကို သတ်မှတ်ရန် တစ်နေရာ၌ တည်ဆောက်သူများရှိခဲ့သည်။ ဒါကို အများသူငှာ ပိုင်ဆိုင်မှုအားဖြင့် တစ်နေရာရာမှာ လုပ်ခဲ့တာပါ။ ဒေတာဘေ့စ်မှ ဒေတာရယူခြင်းနှင့် အသွင်ပြောင်းခြင်းမှာ မတူညီပါ။ 

ယုတ္တိဗေဒသည် ထိန်းချုပ်ကိရိယာများ သို့မဟုတ် ဝန်ဆောင်မှုအတန်းများတွင် ဖြစ်ခဲ့သည်။ 

ဤအရာများသည် အသေးအဖွဲပြဿနာများဟုထင်ရသော်လည်း ၎င်းတို့သည် ဖွံ့ဖြိုးတိုးတက်မှုကို အလွန်နှေးကွေးစေပြီး အရည်အသွေးကို လျော့ကျစေပြီး မတည်ငြိမ်မှုနှင့် ချို့ယွင်းမှုများကို ဖြစ်စေသည်။ 

ရှုပ်ထွေးသော ကြီးမားသော ဖွံ့ဖြိုးတိုးတက်မှု

ဖွံ့ဖြိုးတိုးတက်ရေးမှာ အခက်အခဲတွေ ပေါ်လာတယ်။. စနစ်၏ကွဲပြားခြားနားသောလုပ်ကွက်များပြုလုပ်ရန်လိုအပ်သည်နှင့်အပြိုင်ဖြစ်သည်။ အစိတ်အပိုင်းတစ်ခုစီ၏ လိုအပ်ချက်များကို ကုဒ်တစ်ခုတည်းအဖြစ် ဖြည့်ဆည်းရန် ပို၍ခက်ခဲလာသည်။ အစိတ်အပိုင်းအားလုံးကို တစ်ချိန်တည်းတွင် သဘောတူရန် မလွယ်ကူခဲ့ပါ။ ၎င်းတွင်ထည့်သွင်းထားသောနည်းပညာများတွင်အထူးသဖြင့်အခြေခံနှင့်ရှေ့တန်းနှင့်ပတ်သက်သောကန့်သတ်ချက်များရှိသည်။ အထူးသဖြင့် သုံးစွဲသူဝန်ဆောင်မှုများ (ဝဘ်ဆိုက်) တွင် အဆင့်မြင့်ဘောင်များဆီသို့ JQuery ကို စွန့်လွှတ်ရန် လိုအပ်ပါသည်။

စနစ်၏ အချို့သော အစိတ်အပိုင်းများတွင်၊ ၎င်းအတွက် ပိုမိုသင့်လျော်သော ဒေတာဘေ့စ်များကို အသုံးပြုနိုင်သည်။. ဥပမာအားဖြင့်၊ နောက်ပိုင်းတွင် ကျွန်ုပ်တို့သည် အမှာစာခြင်းတောင်းတစ်ခုကို သိမ်းဆည်းရန် Redis မှ CosmosDB သို့ပြောင်းခြင်းအတွက် အသုံးပြုမှုကိစ္စရပ်ရှိသည်။ 

၎င်းတို့၏ နယ်ပယ်တွင် ပါ၀င်နေသော အဖွဲ့များနှင့် ဆော့ဖ်ဝဲရေးသားသူများသည် ၎င်းတို့၏ ဝန်ဆောင်မှုများအတွက် ဖွံ့ဖြိုးတိုးတက်မှု နှင့် ဖြန့်ချိမှု နှစ်ခုစလုံးအတွက် ၎င်းတို့၏ ဝန်ဆောင်မှုများအတွက် ပိုမိုကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ကို အလိုရှိကြသည်မှာ ထင်ရှားသည်။ ပဋိပက္ခများ ပေါင်းစည်းခြင်း၊ လွတ်မြောက်ခြင်းကိစ္စများ။ အကယ်၍ developer 5 ဦးအတွက် ဤပြဿနာသည် အရေးမပါပါက၊ ထို့နောက် 10 နှင့်အတူ၊ ၎င်းထက်ပို၍ပင် စီစဉ်ထားသော တိုးတက်မှုနှင့်အတူ အရာအားလုံးသည် ပိုမိုလေးနက်လာမည်ဖြစ်သည်။ ရှေ့တွင် မိုဘိုင်းအက်ပလီကေးရှင်းတစ်ခု ဖွံ့ဖြိုးတိုးတက်လာစေရန် (၎င်းသည် 2017 ခုနှစ်တွင် စတင်ခဲ့ပြီး 2018 ခုနှစ်တွင် ၎င်းသည် ကြီးကြီးမားမားပြုတ်ကျ). 

စနစ်၏ မတူညီသော အစိတ်အပိုင်းများသည် မတူညီသော တည်ငြိမ်မှု အဆင့်များ လိုအပ်သည်။ဒါပေမယ့် စနစ်ရဲ့ ခိုင်မာတဲ့ ချိတ်ဆက်မှုတွေကြောင့်၊ ဒါကို ကျွန်တော်တို့ မစွမ်းဆောင်နိုင်ခဲ့ပါဘူး။ ကုဒ်သည် အသုံးများပြီး ပြန်သုံးနိုင်သော၊ ဒေတာဘေ့စ်နှင့် ဒေတာသည်လည်း တူညီသောကြောင့် ဆိုက်ပေါ်ရှိ အမှာစာလက်ခံရာတွင် အက်ဒ်မင်ဘောင်ရှိ လုပ်ဆောင်ချက်အသစ်တစ်ခု ဖော်ဆောင်ရာတွင် အမှားအယွင်းဖြစ်သွားနိုင်သည်။

ဤကဲ့သို့သော monolithic-modular ဗိသုကာ၏ဘောင်အတွင်းတွင်ဤအမှားများနှင့်ပြဿနာများကိုရှောင်ရှားရန်ဖြစ်နိုင်သည်- တာဝန်ခွဲဝေမှုပြုလုပ်ပါ၊ ကုဒ်နှင့်ဒေတာဘေ့စ်နှစ်ခုလုံးကိုပြန်လည်ပြုပြင်ပါ၊ အလွှာများကိုတစ်ခုနှင့်တစ်ခုမှရှင်းလင်းစွာခွဲထုတ်ပြီးအရည်အသွေးကိုနေ့စဉ်စောင့်ကြည့်ပါ။ . သို့သော် ရွေးချယ်ထားသော ဗိသုကာဆိုင်ရာ ဖြေရှင်းချက်များနှင့် စနစ်၏ လုပ်ဆောင်နိုင်စွမ်းကို လျင်မြန်စွာ ချဲ့ထွင်ခြင်းအပေါ် အာရုံစိုက်ခြင်းက တည်ငြိမ်မှုဆိုင်ရာ ပြဿနာများကို ဖြစ်စေသည်။

The Power of the Mind ဘလော့ဂ်ကို စားသောက်ဆိုင်များတွင် ငွေသားစာရင်းသွင်းပုံ

အကယ်၍ pizzeria network (နှင့် load) သည် တူညီသော အရှိန်အဟုန်ဖြင့် ဆက်လက်ကြီးထွားနေပါက၊ အချိန်အတော်ကြာပြီးနောက်တွင် စနစ်သည် မြင့်တက်လာမည်မဟုတ်ပေ။ 2015 တွင်စတင်ကြုံတွေ့နေရသောပြဿနာများကိုကောင်းစွာဥပမာအားဖြင့်ဤတွင်ဤသို့သောဇာတ်လမ်းဖြစ်ပါသည်။ 

ဘလော့မှာ "စိတ်စွမ်းအား” သည် ကွန်ရက်တစ်ခုလုံး၏နှစ်အတွက် ဝင်ငွေဆိုင်ရာဒေတာကိုပြသသည့် ဝစ်ဂျက်တစ်ခုဖြစ်သည်။ ဝစ်ဂျက်သည် ဤဒေတာကို ပံ့ပိုးပေးသည့် Dodo အများသူငှာ API ကို ဝင်ရောက်ခဲ့သည်။ ဤစာရင်းအင်းကို လောလောဆယ်တွင် ရရှိနိုင်ပါသည်။ http://dodopizzastory.com/. ဝစ်ဂျက်ကို စာမျက်နှာတိုင်းတွင် ပြသထားပြီး စက္ကန့် 20 တိုင်း timer တစ်ခုပေါ်တွင် တောင်းဆိုမှုများ ပြုလုပ်ခဲ့သည်။ တောင်းဆိုချက်သည် api.dodopizza.ru သို့သွားပြီး တောင်းဆိုခဲ့သည်-

• ကွန်ရက်ရှိ ပီဇာအရေအတွက်၊

• နှစ်စကတည်းက ကွန်ရက်ဝင်ငွေ စုစုပေါင်း၊

• ယနေ့အတွက်ဝင်ငွေ။

ဝင်ငွေဆိုင်ရာ ကိန်းဂဏန်း အချက်အလက် တောင်းခံမှုသည် ဒေတာဘေ့စ်သို့ တိုက်ရိုက်သွားခဲ့ပြီး အမှာစာများအတွက် ဒေတာကို စတင်တောင်းဆိုခြင်း၊ ဒေတာများ စုစည်းခြင်းနှင့် ပမာဏကို ထုတ်ပေးခြင်းတို့ စတင်ခဲ့သည်။ 

စားသောက်ဆိုင်များရှိ ငွေရှင်းကောင်တာများသည် တူညီသောအမှာစာစားပွဲသို့သွားကာ ယနေ့အတွက်လက်ခံရရှိသည့်အမှာစာစာရင်းကို ဖြုတ်ချပြီး အမှာစာအသစ်များကို ၎င်းတွင်ထည့်သွင်းထားသည်။ ငွေသားစာရင်းသွင်းသူများသည် ၎င်းတို့၏တောင်းဆိုမှုများကို 5 စက္ကန့်တိုင်း သို့မဟုတ် စာမျက်နှာပြန်လည်ဆန်းသစ်ခြင်းတွင် ပြုလုပ်သည်။

ပုံကြမ်းသည် ဤကဲ့သို့မြင်ရသည်-

ဆောင်းဦးရာသီတွင် Fyodor Ovchinnikov သည် သူ၏ဘလော့ဂ်တွင် ရှည်လျားပြီး ရေပန်းစားသော ဆောင်းပါးတစ်ပုဒ်ကို ရေးသားခဲ့သည်။ လူတော်တော်များများက ဘလော့ဂ်ကိုလာပြီး အားလုံးကို ဂရုတစိုက်နဲ့ စတင်ဖတ်ကြပါတယ်။ လာလာသူတိုင်းသည် ဆောင်းပါးကိုဖတ်နေချိန်တွင် ဝင်ငွေဝစ်ဂျက်သည် ကောင်းမွန်စွာအလုပ်လုပ်ပြီး API ကို စက္ကန့် 20 တိုင်း တောင်းဆိုပါသည်။

API သည် ကွင်းဆက်ရှိ ပီဇာဆိုင်အားလုံးအတွက် ယခုနှစ်အစမှစပြီး မှာယူမှုအားလုံး၏ ပေါင်းလဒ်ကို တွက်ချက်ရန် သိမ်းဆည်းထားသော လုပ်ထုံးလုပ်နည်းဟု ခေါ်သည်။ စုစည်းမှုသည် အလွန်ရေပန်းစားသော အမှာစာဇယားကို အခြေခံထားသည်။ အဲဒီတုန်းက ဖွင့်ထားတဲ့ စားသောက်ဆိုင်အားလုံးရဲ့ ငွေသားစားပွဲခုံတွေအားလုံး အဲဒီကိုသွားပါ။ ငွေရှင်းကောင်တာများက တုံ့ပြန်မှုရပ်သွားကာ မှာယူမှုများကို လက်မခံပါ။ ၎င်းတို့ကိုလည်း ဆိုက်မှ လက်ခံခြင်း မပြုပါ၊ ခြေရာခံသူတွင် မပေါ်ဘဲ၊ shift manager သည် ၎င်းတို့ကို ၎င်း၏ ဖေ့စ်ဘုတ်တွင် မတွေ့နိုင်ပါ။ 

ဒါက တစ်ခုတည်းသော ဇာတ်လမ်းမဟုတ်ပါဘူး။ 2015 ခုနှစ် နှောင်းပိုင်းတွင်၊ သောကြာနေ့တိုင်းတွင် စနစ်၏ ဝန်သည် အရေးကြီးပါသည်။ ကျွန်ုပ်တို့သည် အများသူငှာ API ကို အကြိမ်များစွာ ပိတ်ခဲ့ပြီး တစ်ကြိမ်တွင် မည်သည့်အရာမှ မကူညီနိုင်ခဲ့သောကြောင့် ဆိုက်ကိုပင် ပိတ်ခဲ့ရသည်။ လေးလံသောဝန်ဆောင်မှုအောက်တွင် ပိတ်ပစ်ရန် အမိန့်ပေးသည့် ဝန်ဆောင်မှုများစာရင်းပင် ရှိသေးသည်။

ယခုအချိန်မှစ၍ ကျွန်ုပ်တို့၏ဝန်ထုပ်ဝန်ပိုးများနှင့် စနစ်တည်ငြိမ်မှုအတွက် ကျွန်ုပ်တို့၏ရုန်းကန်မှုသည် (ဆောင်းဦး 2015 မှ 2018 ခုနှစ်ဆောင်းဦးရာသီအထိ) စတင်ပါသည်။ အဲ့တုန်းက ဖြစ်သွားတာပါ"ကြီးစွာသောကျဆုံးခြင်း” . ထို့အပြင်၊ တခါတရံတွင် ကျရှုံးမှုများလည်း ဖြစ်ပေါ်ခဲ့ပြီး အချို့မှာ အလွန်အကဲဆတ်သော်လည်း မတည်ငြိမ်မှု၏ ယေဘူယျကာလကို ကျော်လွန်သွားသည်ဟု ယူဆနိုင်ပါသည်။

လုပ်ငန်းများ အရှိန်အဟုန်ဖြင့် ကြီးထွားလာသည်။

ဘာလို့ချက်ချင်းမပြီးနိုင်တာလဲ။ အောက်ပါဇယားများကိုသာကြည့်ပါ။

2014-2015 ခုနှစ်တွင် ရိုမေးနီးယားတွင် ဖွင့်လှစ်ခဲ့ပြီး US တွင် ဖွင့်လှစ်ရန် ပြင်ဆင်နေပါသည်။

ကွန်ရက်သည် အလွန်လျင်မြန်စွာ ကြီးထွားလာကာ နိုင်ငံအသစ်များ ဖွင့်လှစ်ကာ ပီဇာပုံစံအသစ်များ ပေါ်လာသည်၊ ဥပမာ၊ ပီဇာစားသောက်ဆိုင်တွင် ဖွင့်လှစ်ခဲ့သည်။ ဤအရာအားလုံးသည် Dodo IS လုပ်ငန်းဆောင်တာများ ချဲ့ထွင်ခြင်းအတွက် အထူးအာရုံစိုက်ရန် လိုအပ်ပါသည်။ မီးဖိုချောင်တွင် ခြေရာခံခြင်း၊ စနစ်ရှိ ထုတ်ကုန်များနှင့် ဆုံးရှုံးမှုများအတွက် စာရင်းကိုင်ခြင်းမရှိဘဲ အစားအသောက်တရားရုံးခန်းမတွင် အမှာစာထုတ်ပေးခြင်းကို ပြသခြင်းမရှိဘဲ၊ ကျွန်ုပ်တို့သည် "မှန်ကန်သော" ဗိသုကာပညာနှင့် "မှန်ကန်သော" ချဉ်းကပ်မှုအကြောင်း ပြောနေမည်မဟုတ်ပေ။ ဖွံ့ဖြိုးတိုးတက်လာပါပြီ။

ဗိသုကာပညာကို အချိန်မီပြန်လည်ပြင်ဆင်ခြင်းနှင့် နည်းပညာဆိုင်ရာပြဿနာများကို ယေဘူယျအာရုံစိုက်ခြင်းအတွက် နောက်ထပ်အတားအဆီးတစ်ခုမှာ 2014 ခုနှစ် အကျပ်အတည်းဖြစ်သည်။ ဤကဲ့သို့သောအရာများသည် အထူးသဖြင့် Dodo Pizza ကဲ့သို့သော လူငယ်စီးပွားရေးလုပ်ငန်းတစ်ခုအတွက် အသင်းများကြီးထွားရန် အခွင့်အလမ်းများအပေါ် ခက်ခဲစေသည်။

အကူအညီဖြစ်စေသော အမြန်ဖြေရှင်းနည်းများ

ပြဿနာတွေ ဖြေရှင်းဖို့ လိုအပ်တယ်။ သမရိုးကျအားဖြင့် ဖြေရှင်းနည်းများကို အုပ်စု ၂ စု ခွဲခြားနိုင်သည်။

• မီးငြိမ်းသတ်ပြီး ဘေးကင်းမှု အနည်းငယ်ကို ပေးစွမ်းပြီး ပြောင်းလဲရန် အချိန်ကို ပေးဆောင်သော အမြန်ပစ္စည်းများ။

• စနစ်ကျပြီးတော့ ရှည်တယ်။ မော်ဂျူးအများအပြားကို ပြန်လည်အင်ဂျင်နီယာချုပ်ခြင်း၊ monolithic ဗိသုကာလက်ရာကို သီးခြားဝန်ဆောင်မှုများအဖြစ် ပိုင်းခြားခြင်း (၎င်းတို့အများစုမှာ အသေးစားမဟုတ်သော်လည်း၊ မက်ခရိုဝန်ဆောင်မှုများသာဖြစ်ပြီး ၎င်းနှင့်ပတ်သက်သည့် တစ်စုံတစ်ရာရှိပါသည်။ Andrey Morevskiy ၏အစီရင်ခံစာ). 

အမြန်ပြောင်းလဲမှုများ၏ ခြောက်သွေ့စာရင်းမှာ အောက်ပါအတိုင်းဖြစ်သည်။

အခြေခံမာစတာကို ချဲ့ထွင်ပါ။

ဟုတ်ပါတယ်၊ ဝန်ထုပ်ဝန်ပိုးကိုကိုင်တွယ်ဖြေရှင်းရန်ပထမဆုံးလုပ်ဆောင်သောအရာမှာဆာဗာ၏စွမ်းရည်ကိုတိုးမြှင့်ရန်ဖြစ်သည်။ ၎င်းသည် မာစတာဒေတာဘေ့စ်နှင့် ဝဘ်ဆာဗာများအတွက် လုပ်ဆောင်ခဲ့ခြင်းဖြစ်သည်။ ကံမကောင်းစွာပဲ၊ ဒါက ကန့်သတ်ချက်တစ်ခုအထိသာ ဖြစ်နိုင်ပြီး စျေးကြီးလွန်းတယ်။

2014 ခုနှစ်မှစတင်၍ Azure သို့ကျွန်ုပ်တို့ပြောင်းရွှေ့ခဲ့သည်၊ ထိုအချိန်ကဆောင်းပါးတွင်ဤအကြောင်းအရာကိုရေးသားခဲ့သည်Microsoft Azure Cloud ကို အသုံးပြု၍ Dodo Pizza ပီဇာကို မည်ကဲ့သို့ ပေးပို့သည်” . သို့သော် အခြေခံအတွက် ဆာဗာတွင် ဆက်တိုက်တိုးလာပြီးနောက် ကုန်ကျစရိတ်ကို ဆန့်ကျင်လာကြသည်။ 

စာဖတ်ရန်အတွက် အခြေခံပုံတူများ

အခြေစိုက်စခန်းအတွက် ပုံစံတူ နှစ်ခုကို ပြုလုပ်ခဲ့သည်။

ပုံတူဖတ်ပါ။ ကိုးကားချက်များအတွက်. လမ်းညွှန်များ၊ အမျိုးအစား၊ မြို့၊ လမ်း၊ ပီဇာ၊ ထုတ်ကုန်များ (ဒိုမိန်းပြောင်းသည်) နှင့် အနည်းငယ်နှောင့်နှေးမှုကို လက်ခံနိုင်သော အင်တာဖေ့စ်များတွင် ၎င်းကို ဖတ်ရန် အသုံးပြုသည်။ ဤပုံတူများထဲမှ ၂ ခုရှိသည်၊ ကျွန်ုပ်တို့သည် သခင်များကဲ့သို့ပင် ၎င်းတို့၏ရရှိနိုင်မှုကို အာမခံပါသည်။

အစီရင်ခံစာတောင်းဆိုမှုများအတွက် ReadReplica. ဤဒေတာဘေ့စ်တွင် ရရှိနိုင်မှုနည်းသော်လည်း အစီရင်ခံစာအားလုံး ၎င်းထံရောက်သွားသည်။ ကြီးမားသောဒေတာပြန်လည်တွက်ချက်မှုများအတွက် ကြီးမားသောတောင်းဆိုမှုများရှိပါစေ၊ သို့သော် ၎င်းတို့သည် ပင်မဒေတာဘေ့စ်နှင့် လုပ်ငန်းလည်ပတ်မှုအင်တာဖေ့စ်များကို မထိခိုက်စေပါ။ 

ကုဒ်ထဲတွင် Caches

ကုဒ်တွင် မည်သည့်နေရာတွင်မှ ကက်ရှ်မရှိပါ (လုံးဝ)။ ၎င်းသည် တင်ထားသောဒေတာဘေ့စ်သို့ ထပ်လောင်းတောင်းဆိုမှုများ၊ အမြဲတမ်းမလိုအပ်ဘဲ တောင်းဆိုမှုများဖြစ်ပေါ်စေခဲ့သည်။ ကက်ရှ်များသည် ပထမဆုံး မန်မိုရီအတွင်းနှင့် ပြင်ပကက်ရှ်ဝန်ဆောင်မှုတစ်ခုဖြစ်သည့် Redis ဖြစ်သည်။ အချိန်အားဖြင့် အရာအားလုံး ပျက်သွားသည်၊ ဆက်တင်များကို ကုဒ်တွင် သတ်မှတ်ထားပါသည်။

နောက်ခံဆာဗာများစွာ

များပြားလာသော အလုပ်တာဝန်များကို ကိုင်တွယ်ရန် အပလီကေးရှင်း၏ နောက်ခံကို အတိုင်းအတာ ချိန်ညှိရန် လိုအပ်ပါသည်။ iis-ဆာဗာတစ်ခုမှ အစုအဝေးတစ်ခု ပြုလုပ်ရန် လိုအပ်ပါသည်။ ကျွန်တော်တို့ ပြန်ချိန်းထားတယ်။ လျှောက်လွှာအစည်းအဝေး မန်မိုရီမှ RedisCache သို့၊ ၎င်းသည် ရိုးရှင်းသော load balancer နောက်ကွယ်ရှိ server အများအပြားကို round robin ဖြင့် ပြုလုပ်နိုင်စေခဲ့သည်။ ပထမတော့ Redis ကို ကက်ရှ်တွေအတွက် အသုံးပြုခဲ့ပြီး အများအပြား ကွဲထွက်သွားခဲ့ပါတယ်။ 

ရလဒ်အနေနဲ့ ဗိသုကာပညာက ပိုရှုပ်ထွေးလာတယ်..။

… ဒါပေမယ့် တင်းမာမှုအချို့ကို ဖယ်ရှားပစ်လိုက်တယ်။

ထို့နောက် ကျွန်ုပ်တို့လုပ်ဆောင်ခဲ့သည့် အစိတ်အပိုင်းများကို ပြန်လည်လုပ်ဆောင်ရန် လိုအပ်ပါသည်။ ဒီအကြောင်းကို နောက်အပိုင်းမှာ ပြောပါမယ်။

source: www.habr.com