မင်္ဂလာပါ! ကျွန်ုပ်၏အမည်မှာ Vadim Madison ဖြစ်ပြီး Avito System Platform ဖွံ့ဖြိုးတိုးတက်ရေးကို ဦးဆောင်ပါသည်။ ကုမ္ပဏီမှ ကျွန်ုပ်တို့သည် monolithic ဗိသုကာလက်ရာမှ microservices တစ်ခုသို့ မည်ကဲ့သို့ ရွေ့ပြောင်းမည်ကို တစ်ကြိမ်ထက်ပို၍ ပြောကြားထားသည်။ မိုက်ခရိုဝန်ဆောင်မှုများမှ အကောင်းဆုံးရယူပြီး ၎င်းတို့တွင် မပျောက်ကွယ်သွားစေရန် ကျွန်ုပ်တို့၏အခြေခံအဆောက်အအုံကို မည်သို့ပြောင်းလဲခဲ့သည်ကို မျှဝေရန် အချိန်ကျရောက်ပြီဖြစ်သည်။ ဤနေရာတွင် PaaS က ကျွန်ုပ်တို့ကို ကူညီပေးပုံ၊ ဖြန့်ကျက်မှုကို ရိုးရှင်းအောင်ပြုလုပ်နည်းနှင့် microservice ဖန်တီးမှုကို တစ်ချက်နှိပ်ရုံဖြင့် လျှော့ချနည်း - ဆက်ဖတ်ပါ။ အောက်တွင်ကျွန်တော်ရေးထားသောအရာအားလုံးသည် Avito တွင်အပြည့်အဝအကောင်အထည်ဖော်သည်မဟုတ်ပါ၊ အချို့သည်ကျွန်ုပ်တို့၏ပလပ်ဖောင်းကိုတည်ဆောက်ပုံဖြစ်သည်။

(ဤဆောင်းပါး၏အဆုံးတွင်၊ microservice ဗိသုကာပညာရှင် Chris Richardson မှသုံးရက်ကြာဆွေးနွေးပွဲသို့တက်ရောက်ရန်အခွင့်အရေးအကြောင်းပြောပါမည်။

ကျွန်ုပ်တို့သည် မိုက်ခရိုဝန်ဆောင်မှုများသို့ မည်သို့ရောက်လာသနည်း။

Avito သည် ကမ္ဘာပေါ်တွင် အကြီးမားဆုံး အမျိုးအစားခွဲထားသော ဆိုက်များထဲမှ တစ်ခုဖြစ်ပြီး တစ်နေ့လျှင် ကြော်ငြာအသစ် 15 သန်းကျော် လွှင့်တင်လျက်ရှိသည်။ ကျွန်ုပ်တို့၏ ကျောထောက်နောက်ခံသည် တစ်စက္ကန့်လျှင် တောင်းဆိုချက်ပေါင်း 20 ကျော်ကို လက်ခံပါသည်။ ကျွန်ုပ်တို့တွင် လက်ရှိတွင် အသေးစားဝန်ဆောင်မှု ရာပေါင်းများစွာရှိသည်။

ကျွန်ုပ်တို့သည် မိုက်ခရိုဝန်ဆောင်မှုဗိသုကာကို တည်ဆောက်နေသည်မှာ နှစ်အတော်ကြာနေပြီဖြစ်သည်။ အတိအကျ - ကျွန်ုပ်တို့၏လုပ်ဖော်ကိုင်ဖက်များကိုအတိအကျမည်မျှ ပြောတယ် RIT++ 2017 ရှိ ကျွန်ုပ်တို့၏ကဏ္ဍတွင်၊ CodeFest 2017 တွင် (ကြည့်ပါ။ видео) Sergey Orlov နှင့် Mikhail Prokopchuk တို့က အဘယ်ကြောင့် ကျွန်ုပ်တို့သည် မိုက်ခရိုဝန်ဆောင်မှုများသို့ ကူးပြောင်းရန်လိုအပ်ကြောင်းနှင့် Kubernetes က ဤနေရာတွင် အဘယ်အခန်းကဏ္ဍမှ ပါဝင်ခဲ့သည်ကို အသေးစိတ်ရှင်းပြခဲ့သည်။ ကောင်းပြီ၊ ယခု ကျွန်ုပ်တို့သည် ထိုသို့သော ဗိသုကာတစ်ခုတွင် မွေးရာပါရှိသည့် အတိုင်းအတာကုန်ကျစရိတ်များကို လျှော့ချရန် အရာအားလုံးကို လုပ်ဆောင်နေပါသည်။

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

ယခု PaaS CLI utility တွင်၊ ဝန်ဆောင်မှုအသစ်တစ်ခုကို command တစ်ခုတည်းဖြင့် ဖန်တီးထားပြီး ဒေတာဘေ့စ်အသစ်တစ်ခုကို နောက်ထပ်နှစ်ခုထပ်ထည့်ကာ Stage သို့ ဖြန့်ကျက်ထားသည်။

Microservice fragmentation ခေတ်ကို ဘယ်လိုကျော်လွှားမလဲ၊

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

ထို့အပြင်၊ မိုက်ခရိုဆားဗစ်ဗိသုကာတစ်ခု ထိရောက်စေရန်အတွက်၊ လုပ်ငန်းစဉ်များစွာကို ထူထောင်ရန် လိုအပ်သည်-

• သစ်ခုတ်ခြင်း၊
• ခြေရာခံခြင်း (Jaeger);
• အမှားစုစည်းမှု (Sentry);
• Kubernetes (Event Stream Processing) မှ အခြေအနေများ၊ မက်ဆေ့ချ်များ၊
• ပြိုင်ပွဲကန့်သတ်ချက် / circuit breaker (သင် Hystrix ကိုသုံးနိုင်သည်);
• ဝန်ဆောင်မှုချိတ်ဆက်မှုကို ထိန်းချုပ်ခြင်း (ကျွန်ုပ်တို့သည် Netramesh ကိုအသုံးပြုသည်)။
• စောင့်ကြည့်ရေး (Grafana);
• စည်းဝေးပွဲ (TeamCity);
• ဆက်သွယ်ရေးနှင့် အသိပေးချက် (Slack၊ အီးမေးလ်);
•အလုပ်ခြေရာခံ; (Jira)
• စာရွက်စာတမ်းပြင်ဆင်ခြင်း။

စနစ်သည် ၎င်း၏ခိုင်မာမှုကို မဆုံးရှုံးစေရန်နှင့် ၎င်းကိုအတိုင်းအတာတစ်ခုအထိ ထိရောက်မှုရှိစေရန် သေချာစေရန်၊ ကျွန်ုပ်တို့သည် Avito ရှိ မိုက်ခရိုဝန်ဆောင်မှုအဖွဲ့အစည်းကို ပြန်လည်စဉ်းစားခဲ့သည်။

ကျွန်ုပ်တို့သည် မိုက်ခရိုဝန်ဆောင်မှုများကို မည်သို့စီမံခန့်ခွဲမည်နည်း။

Avito microservices အများအပြားကြားတွင် တစ်စုတစ်စည်းတည်း "ပါတီမူဝါဒ" ကို အကောင်အထည်ဖော်ရန် အောက်ပါအကူအညီ။

• အခြေခံအဆောက်အဦများကို အလွှာများခွဲခြင်း၊
• ဝန်ဆောင်မှုအဖြစ် ပလပ်ဖောင်း (PaaS) အယူအဆ၊
• မိုက်ခရိုဝန်ဆောင်မှုများဖြင့် ဖြစ်ပျက်သမျှကို စောင့်ကြည့်ခြင်း။

Infrastructure abstraction အလွှာတွင် အလွှာသုံးလွှာ ပါဝင်သည်။ အပေါ်ကနေ အောက်ကို သွားရအောင်။

A. ထိပ်တန်း - ဝန်ဆောင်မှုကွက်။ အစပိုင်းတွင် ကျွန်ုပ်တို့သည် Istio ကို စမ်းသုံးကြည့်သော်လည်း ၎င်းသည် ကျွန်ုပ်တို့၏ volumes များအတွက် အလွန်စျေးကြီးသော အရင်းအမြစ်များစွာကို အသုံးပြုကြောင်း တွေ့ရှိရပါသည်။ ထို့ကြောင့် ဗိသုကာအဖွဲ့မှ အကြီးတန်းအင်ဂျင်နီယာ Alexander Lukyanchenko သည် သူ၏ကိုယ်ပိုင်ဖြေရှင်းချက်ကို တီထွင်ခဲ့သည်- Netramesh (Open Source တွင်ရနိုင်သည်)၊ ကျွန်ုပ်တို့သည် ထုတ်လုပ်ရေးတွင် လက်ရှိအသုံးပြုနေပြီး Istio ထက် အဆများစွာနည်းသော အရင်းအမြစ်များကို စားသုံးသည် (သို့သော် Istio ကြွားလုံးထုတ်နိုင်သည့် အရာအားလုံးကို မလုပ်ပါ)။
B. အလတ်စား - Kubernetes။ ၎င်းပေါ်တွင် ကျွန်ုပ်တို့သည် မိုက်ခရိုဝန်ဆောင်မှုများကို အသုံးချပြီး လုပ်ဆောင်ပါသည်။
ဂ။ အောက်ခြေ - သတ္တုဗလာ။ ကျွန်ုပ်တို့သည် OpenStack ကဲ့သို့သော တိမ်များ သို့မဟုတ် အရာများကို မသုံးသော်လည်း သတ္တုဗလာကို လုံး၀ အားကိုးပါသည်။

အလွှာအားလုံးကို PaaS ဖြင့် ပေါင်းစပ်ထားသည်။ ပြီးတော့ ဒီပလပ်ဖောင်းမှာ အပိုင်းသုံးပိုင်း ပါဝင်ပါတယ်။

I. မီးစက်များCLI utility မှတဆင့်ထိန်းချုပ်ထားသည်။ developer သည် microservice တစ်ခုကို မှန်ကန်သောနည်းဖြင့် ဖန်တီးပြီး အနည်းဆုံး ကြိုးစားအားထုတ်မှုဖြင့် ကူညီပေးသူဖြစ်သည်။

II စုစည်းစုဆောင်းသူ အသုံးများသော ဒက်ရှ်ဘုတ်မှတဆင့် ကိရိယာအားလုံးကို ထိန်းချုပ်နိုင်သည်။

III သိုလှောင်မှု. သိသာထင်ရှားသောလုပ်ဆောင်ချက်များအတွက် အစပျိုးမှုများကို အလိုအလျောက်သတ်မှတ်ပေးသည့် အချိန်ဇယားဆွဲသူများနှင့် ချိတ်ဆက်သည်။ ထိုသို့သောစနစ်ကြောင့် Jira တွင်တစ်စုံတစ်ဦးမှလုပ်ဆောင်ရန်မေ့သွားသောကြောင့်လုပ်ဆောင်စရာတစ်ခုမျှမလွတ်သွားပါ။ ၎င်းအတွက် ကျွန်ုပ်တို့သည် Atlas ဟုခေါ်သော စက်တွင်းတူးလ်ကို အသုံးပြုသည်။

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

Standard Microservice Development pipeline သည် မည်သို့အလုပ်လုပ်သနည်း။

ယေဘုယျအားဖြင့်၊ microservice ဖန်တီးမှု ကွင်းဆက်သည် ဤကဲ့သို့ ဖြစ်သည်-

CLI-push → ဆက်တိုက်ပေါင်းစည်းခြင်း → ဖုတ် → အသုံးချခြင်း → အတုစမ်းသပ်မှုများ → ကိန္နရီစမ်းသပ်မှုများ → ညှစ်စမ်းသပ်ခြင်း → ထုတ်လုပ်မှု → ပြုပြင်ထိန်းသိမ်းခြင်း။

ဤအစီအစဥ်အတိုင်း တိတိကျကျ ဖြတ်သန်းကြပါစို့။

CLI-တွန်း

• အသေးစားဝန်ဆောင်မှုတစ်ခု ဖန်တီးခြင်း။.
developer တိုင်းကို microservices လုပ်နည်းသင်ပေးရန် အချိန်အတော်ကြာအောင် ရုန်းကန်ခဲ့ရသည်။ ယင်းတွင် မြစ်ဆုံတွင် အသေးစိတ် ညွှန်ကြားချက်များ ရေးသားခြင်း ပါဝင်သည်။ ဒါပေမယ့် အစီအစဥ်တွေ ပြောင်းလဲပြီး အားဖြည့်ပေးခဲ့တယ်။ ရလဒ်မှာ ခရီးအစတွင် ပိတ်ဆို့မှုတစ်ခု ပေါ်လာသည်- မိုက်ခရိုဝန်ဆောင်မှုများကို စတင်ရန် အချိန်များစွာယူခဲ့ရပြီး ၎င်းတို့၏ ဖန်တီးမှုအတွင်း ပြဿနာများ မကြာခဏ ပေါ်ပေါက်နေဆဲဖြစ်သည်။

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

— ပုံစံခွက်တစ်ခုအရ ဝန်ဆောင်မှုတစ်ခုကို ဖန်တီးသည် — အဆင့်ဆင့်၊ “wizard” မုဒ်တွင်။ Avito နောက်ခံတွင် PHP၊ Golang နှင့် Python တို့တွင် အဓိကပရိုဂရမ်းမင်းဘာသာစကားများအတွက် နမူနာပုံစံများရှိသည်။

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

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

- ၎င်းသည် တိုက်ရိုက်စည်းဝေးပွဲကို ကိုယ်တိုင်လုပ်ဆောင်သည်။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာတစ်ဦးသည် ၎င်း၏ IDE မှတစ်ဆင့် မိုက်ခရိုဝန်ဆောင်မှုတစ်ခုတွင် တစ်ခုခုကို ပြုပြင်ခဲ့သည်ဆိုကြပါစို့။ utility သည် ဖိုင်စနစ်အတွင်း အပြောင်းအလဲများကို မြင်တွေ့ရပြီး ၎င်းတို့အပေါ် အခြေခံ၍ အပလီကေးရှင်း (Golang အတွက်) ကို ပြန်လည်တည်ဆောက်ပြီး ပြန်လည်စတင်သည်။ PHP အတွက်၊ ကျွန်ုပ်တို့သည် cube အတွင်းရှိ directory ကို ရိုးရှင်းစွာ ပေးပို့ပြီး တိုက်ရိုက်ပြန်တင်ခြင်းကို "အလိုအလျောက်" ရရှိပါသည်။

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

• Microservice ဖြန့်ကျက်ခြင်း။.

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

I. Dockerfile။

II ပြင်ဆင်မှု။
III ခက်ခက်ခဲခဲနှင့် ပါဝင်သည့် ဦးမုံဇယား၊

- ဇယားများကိုယ်တိုင်;
- ပုံစံများ;
— မတူညီသောပတ်ဝန်းကျင်များကိုထည့်သွင်းစဉ်းစားသောတိကျသောတန်ဖိုးများ။

Kubernetes manifests များကို ပြန်လည်ပြုပြင်ခြင်းမှ နာကျင်မှုကို ကျွန်ုပ်တို့ ဖယ်ရှားခဲ့ပြီးဖြစ်သောကြောင့် ၎င်းတို့ကို ယခု အလိုအလျောက် ထုတ်ပေးပါသည်။ သို့သော် အရေးအကြီးဆုံးမှာ၊ ၎င်းတို့သည် ဖြန့်ကျက်မှုကို ကန့်သတ်ချက်အထိ ရိုးရှင်းစေသည်။ ယခုမှစ၍ ကျွန်ုပ်တို့တွင် Dockerfile တစ်ခုရှိပြီး developer မှ config တစ်ခုလုံးကို app.toml ဖိုင်တိုတစ်ခုတည်းတွင် ရေးပေးပါသည်။

ဟုတ်ကဲ့၊ app.toml ကိုယ်တိုင်က တစ်မိနစ်လောက် လုပ်စရာမရှိပါဘူး။ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုပေးမည့်နေရာနှင့် မည်မျှမိတ္တူများကို သတ်မှတ်ပေးသည် ( dev ဆာဗာတွင်၊ အဆင့်မြှင့်တင်မှု၊ ထုတ်လုပ်မှုတွင်) နှင့် ၎င်း၏မှီခိုမှုများကို ညွှန်ပြပါသည်။ [အင်ဂျင်] ဘလောက်ရှိ လိုင်းအရွယ်အစား = "small" ကို သတိပြုပါ။ ၎င်းသည် Kubernetes မှတစ်ဆင့် ဝန်ဆောင်မှုအတွက် ခွဲဝေပေးမည့် ကန့်သတ်ချက်ဖြစ်သည်။

ထို့နောက် config ကိုအခြေခံ၍ လိုအပ်သော Helm ဇယားများအားလုံးကို အလိုအလျောက်ထုတ်ပေးပြီး ဒေတာဘေ့စ်များနှင့်ချိတ်ဆက်မှုများကို ဖန်တီးပါသည်။

• အခြေခံအတည်ပြုချက်။ ထိုသို့သောစစ်ဆေးမှုများသည်လည်း အလိုအလျောက်ဖြစ်သည်။
ခြေရာခံရန် လိုအပ်သည်-
- Dockerfile ရှိပါသလား။
— app.toml ရှိပါသလား။
- စာရွက်စာတမ်းရှိပါသလား။
- မှီခိုမှုဟာ အစဉ်လိုက်ရှိလား။
- သတိပေးချက်စည်းမျဉ်းများ သတ်မှတ်ပြီးပြီလား။
နောက်ဆုံးအချက်အနေဖြင့်- ဝန်ဆောင်မှုပိုင်ရှင်သည် မည်သည့်ထုတ်ကုန်မက်ထရစ်များကို စောင့်ကြည့်ရန် ဆုံးဖြတ်သည်။

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

I. ဝန်ဆောင်မှု၏ အကျဉ်းချုပ်ဖော်ပြချက်. ၎င်းကိုဘာကြောင့်လိုအပ်ကြောင်းနှင့် ၎င်းကိုဘာကြောင့်လိုအပ်ကြောင်း စာသားအနည်းငယ်ဖော်ပြသည်။

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

III ရှေ့ပြေးစာအုပ်. ဝန်ဆောင်မှုစတင်ခြင်းဆိုင်ရာ လမ်းညွှန်တိုတိုနှင့် ၎င်းကို ကိုင်တွယ်ခြင်း၏ ရှုပ်ထွေးမှုများ။

IV အမြဲမေးလေ့ရှိသောမေးခွန်းများသင့်လုပ်ဖော်ကိုင်ဖက်များ ဝန်ဆောင်မှုနှင့် အလုပ်လုပ်ရာတွင် ကြုံတွေ့ရမည့် ပြဿနာများကို ကြိုတင်ခန့်မှန်းရန် ကောင်းမွန်ပါသည်။

V. API အတွက် အဆုံးမှတ်များ၏ ဖော်ပြချက်. သင်သွားမည့်နေရာများကို ရုတ်တရက်မသတ်မှတ်ပါက၊ သင့်လုပ်ငန်းနှင့်ပတ်သက်သည့် microservices ၏လုပ်ဖော်ကိုင်ဖက်များသည် ၎င်းအတွက် သေချာပေါက်နီးပါးပေးချေလိမ့်မည်။ ယခု ကျွန်ုပ်တို့သည် Swagger ကိုအသုံးပြုပြီး ဤအတွက် အတိုချုံးဟုခေါ်သော ကျွန်ုပ်တို့၏ဖြေရှင်းချက်ကို အသုံးပြုပါသည်။

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

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

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

စဉ်ဆက်မပြတ်ပေါင်းစည်းရေး

• သိုလှောင်မှုများကို ပြင်ဆင်နေပါသည်။
• TeamCity တွင် ပိုက်လိုင်းတစ်ခု ဖန်တီးခြင်း။
• အခွင့်အရေး သတ်မှတ်ခြင်း။
• ဝန်ဆောင်မှုပိုင်ရှင်များကို ရှာဖွေပါ။ ဤနေရာတွင် ဟိုက်ဘရစ်အစီအစဥ်တစ်ခု ရှိသည် - လက်ဖြင့်အမှတ်အသားပြုခြင်းနှင့် PaaS မှ အနည်းဆုံး အလိုအလျောက်လုပ်ဆောင်ခြင်း ဝန်ဆောင်မှုများကို အခြားဖွံ့ဖြိုးရေးအဖွဲ့သို့ ပံ့ပိုးမှုပေးရန် သို့မဟုတ် ဥပမာအားဖြင့် ဝန်ဆောင်မှုဆော့ဖ်ဝဲထုတ်လုပ်သူမှ နုတ်ထွက်သည့်အခါ ဝန်ဆောင်မှုများ အပြည့်အဝ အလိုအလျောက်စနစ်ပျက်သွားပါသည်။
• Atlas တွင် ဝန်ဆောင်မှုတစ်ခု မှတ်ပုံတင်ခြင်း။ (အထက်တွင်ကြည့်ပါ)။ ၎င်း၏ပိုင်ရှင်များနှင့်မှီခိုမှုအားလုံးနှင့်အတူ။
• ရွှေ့ပြောင်းမှုများကို စစ်ဆေးခြင်း။ ၎င်းတို့ထဲမှ တစ်ခုခုသည် အန္တရာယ်ဖြစ်နိုင်ချေ ရှိမရှိ စစ်ဆေးပါသည်။ ဥပမာအားဖြင့်၊ ၎င်းတို့ထဲမှ တစ်ခုတွင် ဝန်ဆောင်မှု၏ မတူညီသောဗားရှင်းများကြားတွင် data schema ၏ လိုက်ဖက်ညီမှုကို ချိုးဖျက်နိုင်သော ပြောင်းလဲမှုဇယားတစ်ခု သို့မဟုတ် အခြားအရာတစ်ခု ပေါ်လာပါသည်။ ထို့နောက် ရွှေ့ပြောင်းခြင်းအား လုပ်ဆောင်မည်မဟုတ်သော်လည်း စာရင်းသွင်းမှုတစ်ခုတွင် ထည့်သွင်းထားသည် - ၎င်းကို အသုံးပြုရန် ဘေးကင်းသည့်အခါတွင် PaaS သည် ဝန်ဆောင်မှုပိုင်ရှင်ထံ အချက်ပြရပါမည်။

မုန့်ဖုတ်

နောက်တစ်ဆင့်မှာ ထုပ်ပိုးခြင်းဝန်ဆောင်မှုများ ဖြန့်ကျက်ခြင်းမပြုမီ။

• လျှောက်လွှာကိုတည်ဆောက်ခြင်း။ ဂန္တဝင်စကားအရ - Docker ပုံတစ်ခု။
• ဝန်ဆောင်မှုကိုယ်တိုင်နှင့် ဆက်စပ်အရင်းအမြစ်များအတွက် Helm ဇယားများ၏ မျိုးဆက်။ ဒေတာဘေ့စ်နှင့် ကက်ရှ်များအတွက် ပါဝင်သည်။ ၎င်းတို့ကို CLI-push အဆင့်တွင် ထုတ်ပေးသည့် app.toml config နှင့်အညီ ၎င်းတို့ကို အလိုအလျောက် ဖန်တီးထားသည်။
• ဆိပ်ကမ်းများဖွင့်ရန် စီမံခန့်ခွဲသူများအတွက် လက်မှတ်များ ဖန်တီးခြင်း။ (လိုအပ်သောအခါ)။
• ယူနစ်စမ်းသပ်မှုများ လုပ်ဆောင်ခြင်းနှင့် ကုဒ်အကျုံးဝင်မှုကို တွက်ချက်ခြင်း။. ကုဒ်အကျုံးဝင်မှုသည် သတ်မှတ်ထားသော သတ်မှတ်ချက်ထက် အောက်တွင်ရှိနေပါက၊ ဝန်ဆောင်မှုသည် ပိုမိုအသုံးပြုနိုင်တော့မည် မဟုတ်ပါ - ဖြန့်ကျက်ရန်။ လက်ခံနိုင်လောက်ပြီဆိုလျှင် ဝန်ဆောင်မှုအား "အဆိုးမြင်ခြင်း" ကိန်းဂဏန်းအဖြစ် သတ်မှတ်ပေးမည်- ထို့နောက်၊ အချိန်ကြာလာသည်နှင့်အမျှ ညွှန်ပြမှုတွင် တိုးတက်မှုမရှိခဲ့ပါက၊ ဆော့ဖ်ဝဲရေးသားသူသည် စမ်းသပ်မှုဆိုင်ရာ တိုးတက်မှုမရှိကြောင်း အသိပေးချက်ကို လက်ခံရရှိလိမ့်မည် ( ပြီးတော့ တစ်ခုခုလုပ်ရမှာပေါ့။)
• Memory နှင့် CPU ကန့်သတ်ချက်များကို စာရင်းပြုစုခြင်း။. ကျွန်ုပ်တို့သည် Golang တွင် အသေးစားဝန်ဆောင်မှုများကို အဓိကရေးသားပြီး Kubernetes တွင် လုပ်ဆောင်ပါသည်။ ထို့ကြောင့် Golang ဘာသာစကား၏ထူးခြားချက်နှင့်ဆက်စပ်နေသော သိမ်မွေ့မှုတစ်ခု- ပုံမှန်အားဖြင့်၊ စတင်သောအခါ၊ စက်ပေါ်ရှိ cores အားလုံးကို အသုံးပြုသည်၊ GOMAXPROCS variable ကို အတိအကျမသတ်မှတ်ထားပါက၊ ၎င်းဝန်ဆောင်မှုများစွာကို စက်တစ်ခုတည်းတွင် စတင်သောအခါ၊ ၎င်းတို့သည် စတင်သည် အရင်းအမြစ်များကို ယှဉ်ပြိုင်ရန်၊ အချင်းချင်း နှောင့်ယှက်ခြင်း၊ အကယ်၍ သင်သည် အပလီကေးရှင်းအား အငြင်းအခုံမရှိဘဲ လုပ်ဆောင်ပြီး အရင်းအမြစ်မုဒ်အတွက် အပြိုင်အဆိုင်လုပ်ဆောင်ပါက အောက်ပါဂရပ်များသည် လုပ်ဆောင်ချက်အချိန်ကို မည်သို့ပြောင်းလဲသည်ကို ပြသသည်။ (ဂရပ်ဖစ်များ၏အရင်းအမြစ်များ ဒီမှာ).

အကောင်အထည်ဖော်ချိန်နည်းတာက ပိုကောင်းပါတယ်။ အများဆုံး- 643ms၊ အနည်းဆုံး- 42ms။ ဓာတ်ပုံကို ကလစ်နှိပ်လို့ရတယ်။

ခွဲစိတ်ဖို့ အချိန်နည်းတာက ပိုကောင်းပါတယ်။ အများဆုံး- 14091 ns၊ အနည်းဆုံး- 151 ns။ ဓာတ်ပုံကို ကလစ်နှိပ်လို့ရတယ်။

စည်းဝေးပွဲပြင်ဆင်သည့်အဆင့်တွင်၊ သင်သည် ဤကိန်းရှင်ကို အတိအလင်း သတ်မှတ်နိုင်သည် သို့မဟုတ် စာကြည့်တိုက်ကို အသုံးပြုနိုင်သည်။ automaxprocs Uber က ယောက်ျားလေးတွေဆီက။

ချထားပေးပါ။

• သဘောတူညီချက်များကို စစ်ဆေးခြင်း။ သင့်ရည်ရွယ်ထားသော ပတ်ဝန်းကျင်များသို့ ဝန်ဆောင်မှုစည်းဝေးပွဲများ မစတင်မီ၊ အောက်ပါတို့ကို စစ်ဆေးရန် လိုအပ်သည်-
- API အဆုံးမှတ်များ။
— schema နှင့် API အဆုံးမှတ်များ တုံ့ပြန်မှုများကို လိုက်နာခြင်း။
- မှတ်တမ်းပုံစံ။
- ဝန်ဆောင်မှုအတွက် တောင်းဆိုမှုများအတွက် ခေါင်းစီးများ သတ်မှတ်ခြင်း (လောလောဆယ် ၎င်းကို netramesh ဖြင့် လုပ်ဆောင်သည်)
— ပွဲဘတ်စ်သို့ မက်ဆေ့ချ်များပို့သည့်အခါ ပိုင်ရှင်တိုကင်ကို သတ်မှတ်ခြင်း။ ဘတ်စ်ကားတစ်လျှောက် ဝန်ဆောင်မှုများ၏ ချိတ်ဆက်မှုကို ခြေရာခံရန် ၎င်းမှာ လိုအပ်ပါသည်။ ဝန်ဆောင်မှုများ၏ ချိတ်ဆက်မှုကို မတိုးစေဘဲ (ကောင်းသည်) နှင့် ဝန်ဆောင်မှုများ၏ ချိတ်ဆက်မှုကို အားကောင်းစေသည့် လုပ်ငန်းဒေတာ (အလွန်ဆိုးရွားပါသည်။) ဤချိတ်ဆက်မှုမှာ ပြဿနာတစ်ခုဖြစ်လာသောအခါတွင် ဘတ်စ်ကားကို မည်သူရေးသည်နှင့် ဖတ်သည်ကို နားလည်ခြင်းသည် ဝန်ဆောင်မှုများကို ကောင်းစွာခွဲခြားရန် ကူညီပေးသည်။

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

ဒြပ် benchmark

• ကွင်းပိတ်စမ်းသပ်ခြင်း။ ယင်းအတွက် ကျွန်ုပ်တို့သည် ယခု open source ကို အသုံးပြုနေပါသည်။ Hoverfly.io. ပထမဦးစွာ၊ ၎င်းသည် ဝန်ဆောင်မှုပေါ်ရှိ အစစ်အမှန်ဝန်ကို မှတ်တမ်းတင်ပြီး - အပိတ်ကွင်းတစ်ခုတွင်သာ - ၎င်းကို အတုယူသည်။

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

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

က) စုစုပေါင်းဝန်ကိုကြည့်သည်။
- အလွန်သေးငယ်သည် - ဝန်သည် အကြိမ်များစွာ ရုတ်တရက် ကျသွားပါက တစ်ခုခု လုံးဝ အလုပ်မလုပ်ပါ။
- ကြီးလွန်းသည် - ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန် လိုအပ်သည်။

b) RPS အရ ဖြတ်တောက်မှုကို ကျွန်ုပ်တို့ ကြည့်ရှုသည်။
ဤတွင် ကျွန်ုပ်တို့သည် လက်ရှိဗားရှင်းနှင့် ယခင်ဗားရှင်းနှင့် စုစုပေါင်း ပမာဏအကြား ခြားနားချက်ကို ကြည့်ပါ။ ဥပမာအားဖြင့်၊ ဝန်ဆောင်မှုတစ်ခုသည် 100 rps ကိုထုတ်လုပ်ပါက၊ ၎င်းသည် ညံ့ဖျင်းစွာရေးသားခြင်း သို့မဟုတ် ၎င်းသည် ၎င်း၏တိကျမှုဖြစ်သည်၊ သို့သော် မည်သို့ပင်ဆိုစေ၊ ဤသည်မှာ ဝန်ဆောင်မှုကို အလွန်အနီးကပ်ကြည့်ရှုရန် အကြောင်းပြချက်တစ်ခုဖြစ်သည်။
ဆန့်ကျင်ဘက်အနေနှင့်၊ RPS များလွန်းပါက၊ ချို့ယွင်းချက်အချို့ရှိနိုင်ပြီး အချို့သော endpoints များသည် payload ကိုလုပ်ဆောင်ခြင်းမှရပ်တန့်သွားကာ အခြားတစ်ခုသည် ရိုးရိုးရှင်းရှင်းစတင်လိုက်ပါသည်။ return true;

ကိန္နရီစမ်းသပ်မှုများ

ကျွန်ုပ်တို့သည် ဓာတုစမ်းသပ်မှုများကို အောင်မြင်ပြီးနောက်၊ သုံးစွဲသူအနည်းစုတွင် microservice ကို စမ်းသပ်ပါသည်။ ဝန်ဆောင်မှု၏ ရည်ရွယ်ထားသော ပရိသတ်၏ သေးငယ်သော ဝေစုဖြင့် - 0,1% ထက်နည်းသော ဂရုတစိုက်ဖြင့် စတင်ပါသည်။ ဤအဆင့်တွင်၊ မှန်ကန်သောနည်းပညာနှင့် ထုတ်ကုန်မက်ထရစ်များကို စောင့်ကြည့်စစ်ဆေးခြင်းတွင် ထည့်သွင်းထားရန် အလွန်အရေးကြီးပြီး ၎င်းတို့သည် ဝန်ဆောင်မှုတွင် ပြဿနာကို တတ်နိုင်သမျှ မြန်မြန်ပြသနိုင်စေရန် ဖြစ်သည်။ ကိန္နရီစမ်းသပ်မှုတစ်ခုအတွက် အနိမ့်ဆုံးအချိန်သည် ၅ မိနစ်ဖြစ်ပြီး အဓိကအချိန်သည် ၂ နာရီဖြစ်သည်။ ရှုပ်ထွေးသောဝန်ဆောင်မှုများအတွက် ကျွန်ုပ်တို့သည် အချိန်ကို ကိုယ်တိုင်သတ်မှတ်ပေးပါသည်။
ခွဲခြမ်းစိတ်ဖြာကြပါစို့။
— အထူးသဖြင့်၊ အထူးသဖြင့် php-fpm အလုပ်သမားများ၊
- Sentry တွင်အမှားများ;
- တုံ့ပြန်မှုအခြေအနေများ;
- တုံ့ပြန်ချိန်၊ အတိအကျနှင့် ပျမ်းမျှ။
- ကြာချိန်;
- ခြွင်းချက်၊ စီမံဆောင်ရွက်ပြီး ကိုင်တွယ်ခြင်းမပြုဘဲ၊
- ထုတ်ကုန်တိုင်းတာမှုများ။

ညှစ်စမ်း

Squeeze Testing ကို "squeezing" test လို့လည်း ခေါ်ပါတယ်။ နည်းပညာ၏အမည်ကို Netflix တွင်မိတ်ဆက်ခဲ့သည်။ ၎င်း၏အနှစ်သာရမှာ ပထမဦးစွာ ကျွန်ုပ်တို့သည် ပျက်ကွက်သည့်နေရာအထိ အစစ်အမှန်လမ်းကြောင်းတစ်ခုဖြင့် ဥပမာတစ်ခုကို ဖြည့်သွင်းပြီး ၎င်း၏ကန့်သတ်ချက်ကို သတ်မှတ်ခြင်းဖြစ်သည်။ ထို့နောက် ကျွန်ုပ်တို့သည် အခြားဥပမာတစ်ခုကို ပေါင်းထည့်ကာ ဤအတွဲကို အမြင့်ဆုံးသို့ ထပ်မံတင်ပါ။ ပထမဆုံး "ညှစ်" ဖြင့် ၎င်းတို့၏ မျက်နှာကျက်နှင့် မြစ်ဝကျွန်းပေါ်ဒေသကို ကျွန်ုပ်တို့ မြင်တွေ့ရသည်။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် တစ်ကြိမ်လျှင် သာဓကတစ်ခုကို ချိတ်ဆက်ပြီး အပြောင်းအလဲများ၏ ပုံစံကို တွက်ချက်ပါသည်။
"ဖျစ်ညှစ်ခြင်း" မှတစ်ဆင့် စမ်းသပ်ဒေတာသည် ၎င်းတို့နှင့်အတူ အတုပြုလုပ်ထားသော ဝန်ရလဒ်များကို ဖြည့်စွမ်းပေးနိုင်သည် သို့မဟုတ် ၎င်းတို့နှင့် "ပေါင်းစပ်မှု" ကိုပင် အစားထိုးသည့် ဘုံမက်ထရစ်ဒေတာဘေ့စ်တစ်ခုသို့လည်း စီးဆင်းသွားပါသည်။

ထုတ်လုပ်မှု

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

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

ဝန်ဆောင်မှုတစ်ခုအား ချဲ့ထွင်သောအခါ၊ ကျွန်ုပ်တို့သည် ကွင်းဆက်ရှိ ပထမဝန်ဆောင်မှုကို အတိုင်းအတာမထိမိစေရန်နှင့် ၎င်းကိုဝင်ရောက်ကြည့်ရှုသည့်အရာများသည် ဝန်မပိစေရန် ၎င်း၏မှီခိုမှုကို စောင့်ကြည့်ရန်လည်း အရေးကြီးပါသည်။ ဝန်ဆောင်မှုအစုအဝေးတစ်ခုလုံးအတွက် လက်ခံနိုင်သောဝန်ကို တည်ထောင်ရန်၊ ကျွန်ုပ်တို့သည် “အနီးဆုံး” မှီခိုဝန်ဆောင်မှု၏ သမိုင်းဆိုင်ရာဒေတာ (CPU နှင့် RAM အညွှန်းကိန်းများ၊ အက်ပ်အလိုက် မက်ထရစ်များတွဲလျက်) ပေါင်းစပ်မှုအပေါ် အခြေခံ၍ ၎င်းတို့ကို သမိုင်းဒေတာနှင့် နှိုင်းယှဉ်ကြည့်ပါ စတင်ခြင်းဝန်ဆောင်မှု၏ “မှီခိုမှုကွင်းဆက်” တစ်လျှောက်လုံး၊ အပေါ်မှအောက်ခြေအထိ။

ဝန်ဆောင်မှု

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

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

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

ဒိုင်ခွက်

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

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

စုစုပေါင်း

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

HighLoad++ 2018 အတွက် ဤအကြောင်းအရာနှင့်ပတ်သက်သည့် အစီရင်ခံစာကို ကျွန်ုပ်ပေးခဲ့ပြီး၊ သင်ကြည့်ရှုနိုင်ပါသည်။ видео и တင်ပြမှု.

အဆုံးထိဖတ်သူများအတွက် Bonus တစ်ပုဒ်

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

လေ့ကျင့်မှုကို မော်စကိုမြို့တွင် သြဂုတ် ၅ ရက်မှ ၇ ရက်အထိ ကျင်းပမည်ဖြစ်သည်။ ဤရက်များသည် အပြည့်အ၀သိမ်းပိုက်မည့် အလုပ်ရက်များဖြစ်သည်။ နေ့လည်စာနှင့် သင်တန်းကို ကျွန်ုပ်တို့၏ရုံးခန်းတွင် ထားရှိမည်ဖြစ်ပြီး ရွေးချယ်ခံရသူသည် ခရီးနှင့် တည်းခိုခအတွက် ကိုယ်တိုင်ပေးချေမည်ဖြစ်သည်။

ပါဝင်ရန် လျှောက်ထားနိုင်ပါသည်။ ဒီ google form မှာ. သင်ထံမှ - သင်သင်တန်းတက်ရောက်ရန် အဘယ်ကြောင့်လိုအပ်သနည်း ဟူသောမေးခွန်း၏အဖြေနှင့် သင့်အား ဆက်သွယ်ရမည့်အချက်အလက်များ။ Chris က သင်တန်းတက်မယ့် သင်တန်းသားကို ကိုယ်တိုင်ရွေးချယ်ပေးမှာဖြစ်လို့ အင်္ဂလိပ်လို ဖြေဆိုပါ။
ဤပို့စ်အတွက် အပ်ဒိတ်တစ်ခုနှင့် ဆော့ဖ်ဝဲရေးသားသူများအတွက် Avito (AvitoTech in) မှ သင်တန်းတက်ရောက်သူ၏ အမည်ကို ကျွန်ုပ်တို့ ကြေညာပါမည်။ Facebook က, VKontakte, တွစ်တာဇူလိုင်လ ၁၉ ရက်ထက် နောက်မကျစေဘဲ။

source: www.habr.com