monolith မှ microservices သို့ ကူးပြောင်းခြင်း- သမိုင်းနှင့် လက်တွေ့

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

ပရောဂျက်သည် 2000 ခုနှစ်အစတွင် ၎င်း၏သမိုင်းကြောင်းကို ကြာမြင့်စွာကတည်းက စတင်ခဲ့သည်။ ပထမဗားရှင်းများကို Visual Basic 6 တွင် ရေးသားခဲ့သည်။ အချိန်ကြာလာသည်နှင့်အမျှ IDE သည် အနာဂတ်တွင် ဤဘာသာစကားကို ပံ့ပိုးရန် ခက်ခဲလိမ့်မည်ဖြစ်ကြောင်း ထင်ရှားလာသည်။ ပြီးတော့ ဘာသာစကား ကိုယ်တိုင်က ဖွံ့ဖြိုးမှု အားနည်းတယ်။ 2000 နှောင်းပိုင်းတွင် ၎င်းသည် ပိုမိုအလားအလာရှိသော C# သို့ပြောင်းရန် ဆုံးဖြတ်ခဲ့သည်။ ဗားရှင်းအသစ်သည် အဟောင်း၏ပြန်လည်ပြင်ဆင်မှုနှင့်အတူ အပြိုင်ရေးသားခဲ့ပြီး၊ ကုဒ်ကို .NET တွင် တဖြည်းဖြည်းနှင့် ပိုများလာစေသည်။ C# တွင် Backend သည် ဝန်ဆောင်မှုတည်ဆောက်မှုပုံစံကို အစပိုင်းတွင် အာရုံစိုက်ခဲ့သော်လည်း ဖွံ့ဖြိုးတိုးတက်မှုအတွင်း၊ ယုတ္တိရှိသော ဘုံစာကြည့်တိုက်များကို အသုံးပြုခဲ့ပြီး ဝန်ဆောင်မှုများကို လုပ်ငန်းစဉ်တစ်ခုတည်းတွင် စတင်ခဲ့သည်။ ရလဒ်မှာ "ဝန်ဆောင်မှု monolith" ဟုခေါ်သော အက်ပလီကေးရှင်းတစ်ခုဖြစ်သည်။

ဤပေါင်းစပ်မှု၏ အားသာချက်အနည်းငယ်ထဲမှတစ်ခုမှာ ပြင်ပ API မှတစ်ဆင့် ဝန်ဆောင်မှုများအချင်းချင်းခေါ်ဆိုနိုင်သည့်စွမ်းရည်ဖြစ်သည်။ ပိုမိုမှန်ကန်သောဝန်ဆောင်မှုသို့ကူးပြောင်းခြင်းအတွက် ရှင်းလင်းပြတ်သားသောကြိုတင်လိုအပ်ချက်များနှင့် အနာဂတ်တွင် microservice ဗိသုကာလက်ရာများရှိပါသည်။

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

အကြောင်းအရာ

• ဗိသုကာပညာနှင့် ပြဿနာများ တည်ရှိနေသော ဖြေရှင်းနည်း
• မိုက်ခရိုဝန်ဆောင်မှုများမှ မျှော်လင့်ချက်များ
• အသွင်ကူးပြောင်းရေးပြဿနာများ
• monolith မှ microservices သို့ဘယ်လိုပြောင်းမလဲ။
  • ပထမဦးဆုံးနည်းလမ်း
  • ဒုတိယလမ်း
  • တတိယလမ်း
  • စတုတ္ထလမ်း
• ဒေတာဘေ့စ်နှင့်အတူအလုပ်လုပ်
  • ရှိပြီးသားဇယားများကို ပိုင်းခြားခြင်း။
  • ဆောင်ရွက်နေသည့်ဌာန
• အရင်းအမြစ်ကုဒ်နှင့်အတူအလုပ်လုပ်
• အခြေခံအဆောက်အအုံဆိုင်ရာ ပြဿနာများ
  • ပတ်ဝန်းကျင်တွင် လူကိုယ်တိုင်တပ်ဆင်ခြင်း။
  • သီးခြား သစ်ခုတ်ခြင်း။
  • ဆက်စပ်ဝန်ဆောင်မှုများကို စမ်းသပ်ခြင်းနှင့် အမှားပြင်ဆင်ခြင်း

ဗိသုကာပညာနှင့် ပြဿနာများ တည်ရှိနေသော ဖြေရှင်းနည်း

အစပိုင်းတွင်၊ ဗိသုကာလက်ရာသည် ဤကဲ့သို့ပုံပေါက်သည်- UI သည် သီးခြားအပလီကေးရှင်းတစ်ခုဖြစ်ပြီး၊ monolithic အပိုင်းကို Visual Basic 6 တွင် ရေးသားထားသည်။ NET အပလီကေးရှင်းသည် အလွန်ကြီးမားသောဒေတာဘေ့စ်တစ်ခုနှင့် အလုပ်လုပ်သော ဆက်စပ်ဝန်ဆောင်မှုအစုတစ်ခုဖြစ်သည်။

ယခင်ဖြေရှင်းချက်၏အားနည်းချက်များ

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

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

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

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

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

မိုက်ခရိုဝန်ဆောင်မှုများမှ မျှော်လင့်ချက်များ

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

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

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

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

နည်းပညာအသစ်များကိုအသုံးပြုခြင်း။ ဒါက ပရိုဂရမ်မာတိုင်းအတွက် စိတ်ဝင်စားစရာပါပဲ။

အသွင်ကူးပြောင်းရေးပြဿနာများ

ဟုတ်ပါတယ်၊ အကယ်၍ monolith ကို microservices များအဖြစ်သို့ အလွယ်တကူ ချိုးဖျက်နိုင်လျှင် ကွန်ဖရင့်များတွင် ၎င်းအကြောင်းကို ဆွေးနွေးပြီး ဆောင်းပါးများရေးရန် မလိုအပ်ပါ။ ဤလုပ်ငန်းစဉ်တွင် အမှားအယွင်းများစွာရှိပါသည်၊ ကျွန်ုပ်တို့ကို အဟန့်အတားဖြစ်စေသော အဓိကအချက်များကို ကျွန်ုပ်ဖော်ပြပါမည်။

ပထမပြသနာ monoliths အများစုအတွက် ပုံမှန်- လုပ်ငန်းဆိုင်ရာ ယုတ္တိဗေဒ ပေါင်းစပ်မှု။ monolith ရေးတဲ့အခါ မလိုအပ်တဲ့ code မရေးမိအောင် အတန်းတွေကို ပြန်သုံးလိုပါတယ်။ microservices သို့ပြောင်းသောအခါ၊ ၎င်းသည် ပြဿနာတစ်ခုဖြစ်လာသည်- ကုဒ်အားလုံးသည် အတော်လေး တင်းကျပ်စွာ ပေါင်းစပ်ထားပြီး၊ ဝန်ဆောင်မှုများကို ခွဲခြားရန် ခက်ခဲသည်။

အလုပ်စတင်ချိန်၌၊ သိုလှောင်ရုံတွင် ပရောဂျက်ပေါင်း ၅၀၀ ကျော်နှင့် ကုဒ်လိုင်းပေါင်း ၇၀၀,ဝဝဝ ကျော်ရှိသည်။ ဒါဟာ အတော်လေး ကြီးမားတဲ့ ဆုံးဖြတ်ချက်တစ်ခုပါ။ ဒုတိယပြဿနာ. ၎င်းကို ရိုးရိုးရှင်းရှင်းယူ၍ မိုက်ခရိုဝန်ဆောင်မှုများအဖြစ် ခွဲရန် မဖြစ်နိုင်ပါ။

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

monolith မှ microservices သို့ဘယ်လိုပြောင်းမလဲ။

မိုက်ခရိုဝန်ဆောင်မှုများ စီမံဆောင်ရွက်ပေးခြင်း။

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

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

ပထမဦးဆုံးနည်းလမ်း — ရှိပြီးသား module များကို ဝန်ဆောင်မှုများအဖြစ် ရွှေ့ပါ။ ဤကိစ္စနှင့်စပ်လျဉ်း၍ ကျွန်ုပ်တို့ကံကောင်းခဲ့သည်- WCF ပရိုတိုကောကို အသုံးပြု၍ လုပ်ဆောင်သည့် မှတ်ပုံတင်ပြီးသား ဝန်ဆောင်မှုများ ရှိပါသည်။ ၎င်းတို့ကို သီးခြားစည်းဝေးပွဲများအဖြစ် ခွဲထုတ်ခဲ့သည်။ ကျွန်ုပ်တို့သည် ၎င်းတို့ကို သီးခြားခွဲထုတ်ပြီး တည်ဆောက်မှုတစ်ခုစီတွင် လောင်ချာငယ်တစ်ခုကို ထည့်ထားသည်။ ၎င်းကို ဝန်ဆောင်မှုတစ်ခုအဖြစ်နှင့် ကွန်ဆိုးလ်တစ်ခုအဖြစ် အက်ပ်လီကေးရှင်းကို လုပ်ဆောင်နိုင်စေမည့် အံ့ဖွယ် Topshelf စာကြည့်တိုက်ကို အသုံးပြု၍ ရေးသားထားသည်။ ဖြေရှင်းချက်တွင် နောက်ထပ်ပရောဂျက်များမလိုအပ်သောကြောင့် အမှားရှာပြင်ခြင်းအတွက် ၎င်းသည် အဆင်ပြေသည်။

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

host နှင့် စုဝေးခြင်းသည် Program class ရှိ ကုဒ်တစ်ကြောင်းမျှသာဖြစ်သည်။ ကျွန်ုပ်တို့သည် အရန်အတန်းတွင် Topshelf နှင့် အလုပ်ကို ဝှက်ထားသည်။

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

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

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

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

UI အပိုင်း၏ ကုဒ်မှ တကယ့်ဥပမာကို ကြည့်ပါက၊ ဤဖြေရှင်းချက်အများစုတွင် UI ဖောင်တည်ဆောက်ရန်အတွက်သာမက အခြားလုပ်ငန်းစဉ်များတွင် အသုံးဝင်သော လုပ်ငန်းဆိုင်ရာ ယုတ္တိဗေဒပါ၀င်ကြောင်း သင်တွေ့နိုင်ပါသည်။

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

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

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

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

ဤနယ်နိမိတ်မျဉ်းများကို တစ်ခုနှင့်တစ်ခု ခွဲထုတ်ပြီး မိုက်ခရိုဝန်ဆောင်မှုများကို monolithic ဖြေရှင်းချက်တစ်ခုမှ ခွဲထုတ်ခြင်းလုပ်ငန်းစဉ်ကို စတင်ရန်အတွက် ကျွန်ုပ်တို့သည် အပလီကေးရှင်းအတွင်း ပြင်ပ API များကို ဖန်တီးခြင်းကဲ့သို့သော ချဉ်းကပ်နည်းကို အသုံးပြုခဲ့သည်။ အကယ်၍ အချို့သော module များသည် microservice ဖြစ်လာမည်ကို သိရှိပါက၊ လုပ်ငန်းစဉ်အတွင်း တစ်နည်းနည်းဖြင့် ပြုပြင်မွမ်းမံထားပါက၊ ပြင်ပခေါ်ဆိုမှုများမှတစ်ဆင့် အခြားသော ကန့်သတ်အကြောင်းအရာနှင့်သက်ဆိုင်သည့် ယုတ္တိဗေဒဆိုင်ရာ ခေါ်ဆိုမှုများကို ချက်ချင်းပြုလုပ်ခဲ့ပါသည်။ ဥပမာအားဖြင့်၊ REST သို့မဟုတ် WCF မှတဆင့်။

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

တိကျတဲ့ ဥပမာကို ကြည့်ရအောင်။ ကျွန်ုပ်တို့တွင် “လျှောက်လွှာ” ၏အကြောင်းအရာကို စီမံဆောင်ရွက်ပေးသော ပိုက်လိုင်းတစ်ခု၏ အယူအဆတစ်ခုရှိသည်။ သူသည် ဖောက်သည်တစ်ဦး၊ အကောင့်တစ်ခုနှင့် ဘဏ်ကတ်တစ်ခုကို တစ်ဖန်ဖန်တီးသည်။ ကလိုင်းယင့်နှင့် အကောင့်ကို အောင်မြင်စွာ ဖန်တီးထားသော်လည်း ကတ်ဖန်တီးမှု မအောင်မြင်ပါက၊ အပလီကေးရှင်းသည် "အောင်မြင်သော" အခြေအနေသို့ မရွှေ့ဘဲ "ကတ်ကို မဖန်တီးရသေးသည်" အနေအထားတွင် ရှိနေမည်ဖြစ်သည်။ အနာဂတ်တွင်၊ နောက်ခံလုပ်ဆောင်ချက်က ၎င်းကို ကောက်ယူပြီး အပြီးသတ်ပါမည်။ စနစ်သည် အချိန်အတော်ကြာအောင် ကွဲလွဲနေသည့် အခြေအနေတွင် ရှိနေသော်လည်း ယေဘုယျအားဖြင့် ၎င်းကို ကျွန်ုပ်တို့ ကျေနပ်ပါသည်။

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

မိုက်ခရိုဝန်ဆောင်မှုကို ခွဲဝေသတ်မှတ်ခြင်း၏ ဥပမာကို ကြည့်ကြပါစို့။ အန္တရာယ်ကင်းစွာ ထုတ်လုပ်နိုင်စေရန် သင်မည်ကဲ့သို့ ဆောင်ကြဉ်းနိုင်မည်နည်း။ ဤဥပမာတွင်၊ ကျွန်ုပ်တို့တွင် microservice ပြုလုပ်လိုသည့် ကုဒ်ကဏ္ဍများထဲမှ တစ်ခုဖြစ်သော လစာငွေပေးချေမှု ဝန်ဆောင်မှု module တစ်ခု၊ စနစ်၏ သီးခြားအစိတ်အပိုင်းတစ်ခုရှိသည်။

ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် ကုဒ်ကို ပြန်လည်ရေးသားခြင်းဖြင့် microservice တစ်ခုကို ဖန်တီးပါသည်။ ကျွန်ုပ်တို့ မကျေနပ်သော ရှုထောင့်အချို့ကို မြှင့်တင်နေပါသည်။ ကျွန်ုပ်တို့သည် ဖောက်သည်ထံမှ လုပ်ငန်းလိုအပ်ချက်အသစ်များကို အကောင်အထည်ဖော်ပါသည်။ ခေါ်ဆိုမှု ထပ်ဆင့်ပို့ခြင်းကို ပံ့ပိုးပေးမည့် UI နှင့် backend အကြား ချိတ်ဆက်မှုတွင် API Gateway တစ်ခုကို ပေါင်းထည့်ပါသည်။

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

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

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

ဒေတာဘေ့စ်နှင့်အတူအလုပ်လုပ်

ဒေတာဘေ့စ်သည် လက်ရှိ schema တစ်ခုတည်းသာမက စုဆောင်းထားသော သမိုင်းဆိုင်ရာ အချက်အလက်ပါ ပါဝင်သောကြောင့် အရင်းအမြစ်ကုဒ်ထက် ပိုဆိုးသည်ဟု ပိုင်းခြားနိုင်ပါသည်။

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

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

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

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

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

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

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

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

နောက်တစ်ဆင့်အနေနဲ့ကတော့ သီးခြားဇယားတွေနဲ့ အလုပ်လုပ်တဲ့ ကုဒ်အပိုင်းကို သီးခြား microservice တစ်ခုအဖြစ် ခွဲထုတ်ပြီး သီးခြား process တစ်ခုဖြစ်တဲ့ container မှာ run နိုင်ပါတယ်။ ၎င်းသည် monolith ဒေတာဘေ့စ်နှင့် တိုက်ရိုက်မသက်ဆိုင်သော ဇယားများနှင့် ချိတ်ဆက်မှုရှိသော သီးခြားဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ Monolith သည် ဖြုတ်တပ်နိုင်သော အပိုင်းနှင့် စာဖတ်ရန်အတွက် အပြန်အလှန် တုံ့ပြန်ဆဲဖြစ်သည်။

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

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

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

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

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

အဲဒီအခါမှာ ဖြစ်နိုင်တဲ့ ချဉ်းကပ်နည်း နှစ်ခုရှိတယ်။

ပဌမ: ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်အသစ်နှင့် အဟောင်းများတွင် ဒေတာအားလုံးကို မိတ္တူပွားပါသည်။ ဤကိစ္စတွင်ခုနှစ်, ကျွန်ုပ်တို့သည် data redundancy နှင့် synchronization ပြဿနာများ ဖြစ်ပေါ်လာနိုင်ပါသည်။ ဒါပေမယ့် မတူညီတဲ့ client နှစ်ခုကို ယူနိုင်ပါတယ်။ တစ်မျိုးက ဗားရှင်းအသစ်နဲ့ အလုပ်လုပ်မှာဖြစ်ပြီး နောက်တစ်ခုက ဗားရှင်းအဟောင်းနဲ့ အလုပ်လုပ်မှာပါ။

ဒုတိယ: အချို့သော လုပ်ငန်းသတ်မှတ်ချက်များအရ ကျွန်ုပ်တို့သည် ဒေတာကို ပိုင်းခြားပါသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် ဒေတာဘေ့စ်အဟောင်းတွင် သိမ်းဆည်းထားသည့် စနစ်တွင် ထုတ်ကုန် ၅ ခုရှိသည်။ ကျွန်ုပ်တို့သည် လုပ်ငန်းတာဝန်အသစ်တွင် ဒေတာဘေ့စ်အသစ်တွင် ဆဋ္ဌမမြောက်ကို ထားရှိသည်။ သို့သော် ဤဒေတာကို တစ်ပြိုင်တည်းလုပ်ဆောင်ပြီး ကလိုင်းယင့်ထံမှ မည်သည့်နေရာနှင့် မည်သည့်အရာမှ ရယူရမည်ကို ပြသမည့် API Gateway တစ်ခု လိုအပ်ပါမည်။

ချဉ်းကပ်မှုနှစ်ခုလုံးသည် အလုပ်အခြေအနေပေါ်မူတည်၍ ရွေးချယ်ပါ။

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

နောက်ဆုံးအဆင့်မှာ ဒေတာတည်ဆောက်ပုံဟောင်းများကို ဖယ်ရှားရန်ဖြစ်သည်။

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

အရင်းအမြစ်ကုဒ်နှင့်အတူအလုပ်လုပ်

ဤသည်မှာ monolithic ပရောဂျက်ကို ခွဲခြမ်းစိတ်ဖြာခြင်းစသောအခါတွင် အရင်းအမြစ်ကုဒ်ပုံသည် ပုံသဏ္ဌာန်ဖြစ်သည်။

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

သီးခြားသုံးလို့ရတဲ့ အခြေခံအဆောက်အဦစာကြည့်တိုက်တွေ ရှိလို့ ကံကောင်းလိုက်တာ။

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

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

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

ပဌမ: ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုများ၊ လုပ်ဆောင်ချက်များနှင့် ပလပ်အင်များကြားတွင် စီးပွားရေးဆိုင်ရာ ယုတ္တိကို မမျှဝေလိုတော့ပါ။ ကျွန်ုပ်တို့သည် မိုက်ခရိုဝန်ဆောင်မှုများအတွင်း စီးပွားရေးဆိုင်ရာ ယုတ္တိဗေဒကို သီးခြားပြုလုပ်လိုပါသည်။ အခြားတစ်ဖက်တွင်မူ Microservices သည် လုံးဝအမှီအခိုကင်းစွာတည်ရှိနေသော ၀န်ဆောင်မှုများအဖြစ် စံနမူနာယူပါသည်။ ဤချဉ်းကပ်နည်းသည် အနည်းငယ်ဖြုန်းတီးသည်ဟု ကျွန်ုပ်ယုံကြည်သည်၊ အကြောင်းမှာ၊ ဥပမာ၊ C# ရှိ ဝန်ဆောင်မှုများသည် မည်သည့်အခြေအနေတွင်မဆို စံစာကြည့်တိုက်တစ်ခုနှင့် ချိတ်ဆက်ထားသောကြောင့် အောင်မြင်ရန်ခက်ခဲပါသည်။ ကျွန်ုပ်တို့၏စနစ်အား C# ဖြင့် ရေးသားထားပြီး၊ ကျွန်ုပ်တို့သည် အခြားနည်းပညာများကို အသုံးမပြုရသေးပါ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ဘုံနည်းပညာဆိုင်ရာ စည်းဝေးပွဲများကို အသုံးပြုရန် တတ်နိုင်မည်ဟု ဆုံးဖြတ်ခဲ့သည်။ အဓိကကတော့ သူတို့မှာ စီးပွားရေးဆိုင်ရာ ယုတ္တိဗေဒအပိုင်းအစတွေ မပါဝင်လို့ပါပဲ။ သင်အသုံးပြုနေသော ORM တွင် အဆင်ပြေသော ထုပ်ပိုးမှုတစ်ခုရှိလျှင် ၎င်းကို ဝန်ဆောင်မှုတစ်ခုမှ ဝန်ဆောင်မှုတစ်ခုသို့ ကူးယူခြင်းသည် အလွန်စျေးကြီးပါသည်။

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

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

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

ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများသည် အတွင်းပိုင်းအခြေခံအဆောက်အအုံဆိုင်ရာ ပက်ကေ့ချ်များကို ပြင်ပပုံစံများကဲ့သို့ပင် ရည်ညွှန်းစပြုလာသည်။ ကျွန်ုပ်တို့သည် Nuget မှပြင်ပစာကြည့်တိုက်များကိုဒေါင်းလုဒ်လုပ်ပါ။ ကျွန်ုပ်တို့ ဤပက်ကေ့ဂျ်များထားရှိရာ Artifactory နှင့်အလုပ်လုပ်ရန် ပက်ကေ့ဂျ်မန်နေဂျာနှစ်ဦးကို အသုံးပြုခဲ့သည်။ သိုလှောင်ရုံငယ်များတွင် Nuget ကိုလည်း အသုံးပြုခဲ့သည်။ ဝန်ဆောင်မှုများစွာရှိသော သိုလှောင်ရုံများတွင် ကျွန်ုပ်တို့သည် မော်ဂျူးများကြားတွင် ဗားရှင်းပိုမိုညီညွတ်မှုကိုပေးသည့် Paket ကို အသုံးပြုခဲ့သည်။

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

အခြေခံအဆောက်အအုံဆိုင်ရာ ပြဿနာများ

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

ပတ်ဝန်းကျင်တွင် လူကိုယ်တိုင်တပ်ဆင်ခြင်း။

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

ကျွန်ုပ်တို့သည် အရင်းအမြစ်ကုဒ် သိုလှောင်မှုအတွက် Atlassian၊ Bitbucket နှင့် တည်ဆောက်ရန်အတွက် Bamboo ကို အသုံးပြုပါသည်။ C# နှင့် တူညီသောကြောင့် Cake တွင် build scripts များကို ရေးလိုပါသည်။ အဆင်သင့်လုပ်ထားသော ပက်ကေ့ဂျ်များသည် Artifactory သို့ရောက်ရှိလာပြီး Ansible သည် စမ်းသပ်ဆာဗာများသို့ အလိုအလျောက်ရောက်ရှိပြီး ၎င်းတို့ကို ချက်ချင်းစမ်းသပ်နိုင်မည်ဖြစ်သည်။

သီးခြား သစ်ခုတ်ခြင်း။

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

Filebeat ဖြင့် ကျွန်ုပ်တို့၏ မှတ်တမ်းများကို စုဆောင်းနိုင်သည်- ဆာဗာများထို့နောက် ၎င်းတို့ကို ပြောင်းလဲပါ၊ UI တွင် query များတည်ဆောက်ရန် Kibana ကို အသုံးပြုပါ၊ ထို့နောက် ဝန်ဆောင်မှုများအကြား ခေါ်ဆိုမှုကို မည်သို့လမ်းကြောင်းပြောင်းခဲ့သည်ကို ကြည့်ပါ။ Trace ID များသည် ဤအတွက် အလွန်အထောက်အကူဖြစ်စေပါသည်။

ဆက်စပ်ဝန်ဆောင်မှုများကို စမ်းသပ်ခြင်းနှင့် အမှားပြင်ဆင်ခြင်း

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

ဝန်ဆောင်မှုများ၏ ထုတ်လုပ်မှုဗားရှင်းများကိုသာ လုပ်ဆောင်သည့် ဆာဗာများ ရှိပါသည်။ အသုံးမပြုမီနှင့် အတွင်းပိုင်း လေ့ကျင့်မှုများအတွက် ပေးပို့မှုကို စစ်ဆေးရန်အတွက် ဤဆာဗာများ လိုအပ်ပါသည်။

လူကြိုက်များသော Specflow ဒစ်ဂျစ်တိုက်ကို အသုံးပြု၍ အလိုအလျောက်စမ်းသပ်ခြင်းလုပ်ငန်းစဉ်ကို ကျွန်ုပ်တို့ထည့်သွင်းထားပါသည်။ Ansible မှ ဖြန့်ကျက်ပြီးနောက် ချက်ချင်းဆိုသလို NUnit ကို အသုံးပြု၍ စမ်းသပ်မှုများ အလိုအလျောက် လုပ်ဆောင်ပါသည်။ လုပ်ဆောင်စရာ လွှမ်းခြုံမှု အပြည့်အဝ အလိုအလျောက် ဖြစ်နေပါက၊ လက်ဖြင့် စမ်းသပ်ခြင်း ပြုလုပ်ရန် မလိုအပ်ပါ။ တခါတရံတွင် နောက်ထပ် manual testing လိုအပ်သေးသော်လည်း၊ သီးခြားပြဿနာတစ်ခုအတွက် မည်သည့်စမ်းသပ်မှုများကို လုပ်ဆောင်ရမည်ကို ဆုံးဖြတ်ရန် Jira တွင် တဂ်များကို အသုံးပြုပါသည်။

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

ငါတို့ ဘာအောင်မြင်ခဲ့လဲ။

ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် "လွတ်မြောက်ခြင်း" ဟူသောအယူအဆကိုဖယ်ရှားခဲ့သည်။ ဤ colossus ကို ထုတ်လုပ်မှုပတ်ဝန်းကျင်တွင် အသုံးချပြီး လုပ်ငန်းလုပ်ငန်းစဉ်များကို ယာယီအနှောင့်အယှက်ဖြစ်စေသည့် နှစ်လကြာ ကြီးမားသောထုတ်ဝေမှုများ မရှိတော့ပါ။ ယခု ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုများကို 1,5 ရက်တိုင်းတွင် ပျမ်းမျှအားဖြင့် ဖြန့်ကျက်ထားပြီး ခွင့်ပြုချက်ရပြီးပါက ၎င်းတို့ကို အုပ်စုဖွဲ့ကာ လုပ်ဆောင်သွားမည်ဖြစ်သည်။

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

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

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

အကျဉ်းချုပ်

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

  သတိပေးချက်လေးတစ်ခု မိုက်ခရိုဝန်ဆောင်မှုများသို့ ပြောင်းရွှေ့ခြင်းအတွက် ကုန်ကျစရိတ်များသည် အလွန်အရေးကြီးပါသည်။ အခြေခံအဆောက်အအုံပြဿနာကို တစ်ယောက်တည်းဖြေရှင်းဖို့ အချိန်အတော်ကြာပါတယ်။ ထို့ကြောင့် သင့်တွင် တိကျသောအတိုင်းအတာမလိုအပ်သော အပလီကေးရှင်းငယ်တစ်ခုရှိပါက သင့်တွင် သင့်အဖွဲ့၏အာရုံစိုက်မှုနှင့်အချိန်အတွက် အပြိုင်ဖောက်သည်အများအပြားမရှိပါက၊ microservices များသည် ယနေ့သင်လိုအပ်သောအရာမဟုတ်ပေ။ တော်တော်စျေးကြီးတယ်။ အကယ်၍ သင်သည် microservices ဖြင့် လုပ်ငန်းစဉ်ကို စတင်ပါက၊ monolith တီထွင်မှုဖြင့် တူညီသော ပရောဂျက်ကို စတင်ပါက ကုန်ကျစရိတ်က အစပိုင်းတွင် ပိုများမည်ဖြစ်သည်။

  PS သည် ပို၍ စိတ်ခံစားမှုဆိုင်ရာ ဇာတ်လမ်းတစ်ပုဒ် (နှင့် သင့်အတွက် ပုဂ္ဂိုလ်ရေးအရကဲ့သို့) - အဆိုအရ link ကို.
  ဤသည်မှာ အစီရင်ခံစာ၏ ဗားရှင်းအပြည့်အစုံဖြစ်သည်။

source: www.habr.com