Microservices - ဗားရှင်းများ၏ပေါင်းစပ်ပေါက်ကွဲမှု

မင်္ဂလာပါ Habr။ မင်းရဲ့အာရုံကို ငါတင်ပြတယ်။ ဆောင်းပါး၏စာရေးဆရာ၏ဘာသာပြန် Microservices - ဗားရှင်းများ၏ ပေါင်းစပ်ပေါက်ကွဲမှု.

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

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

နားလည်မှုလွဲမှားနေသေးရင် သင်္ချာကို ခွဲပါရစေ။ ထို့ကြောင့် ကျွန်ုပ်တို့တွင် အသေးစားဝန်ဆောင်မှု ၁၀ ​​ခုရှိပြီး တစ်ခုစီတွင် အပ်ဒိတ်တစ်ခုစီ ရရှိသည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် microservice တစ်ခုစီအတွက် ဖြစ်နိုင်ချေ ဗားရှင်း 10 ခု (အဟောင်းဖြစ်စေ၊ အသစ်ဖြစ်စေ)။ ယခု၊ ထုတ်ကုန်အစိတ်အပိုင်းတစ်ခုစီအတွက်၊ ကျွန်ုပ်တို့သည် ဤဗားရှင်းနှစ်မျိုးထဲမှ တစ်ခုခုကို အသုံးပြုနိုင်သည်။ သင်္ချာနည်းအားဖြင့်၊ ကျွန်ုပ်တို့တွင် ဂဏန်း 2 လုံးရှိ ဒွိစုံဂဏန်းများ နှင့် တူညီပါသည်။ ဥပမာအားဖြင့်၊ 10 သည် ဗားရှင်းအသစ်ဖြစ်ပြီး 1 သည် ဗားရှင်းဟောင်းဖြစ်သည်ဆိုပါစို့ - ထို့နောက် ဖြစ်နိုင်ချေရှိသော ပြောင်းလဲမှုတစ်ခုကို 0 ဟု ရည်ညွှန်းနိုင်သည် - 1001000000st နှင့် 1th အစိတ်အပိုင်းများကို အပ်ဒိတ်လုပ်ထားပြီး အခြားအရာအားလုံးမဟုတ်သည့်နေရာဖြစ်သည်။ ဂဏန်း 4 လုံး ဒွိစုံဂဏန်းတစ်ခုတွင် 10^2 သို့မဟုတ် 10 တန်ဖိုးများ ရှိနိုင်သည်ကို သင်္ချာပညာမှ သိရှိပါသည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့နှင့် ဆက်ဆံနေသော အရေအတွက်၏ အတိုင်းအတာကို အတည်ပြုပြီးဖြစ်သည်။

ကျွန်ုပ်တို့၏ ကျိုးကြောင်းဆင်ခြင်မှုကို ဆက်လက်လုပ်ဆောင်ကြပါစို့ - ကျွန်ုပ်တို့တွင် မိုက်ခရိုဝန်ဆောင်မှု 100 ရှိပြီး တစ်ခုချင်းစီတွင် ဖြစ်နိုင်သည့် ဗားရှင်း 10 ခုရှိလျှင် ဘာဖြစ်နိုင်မည်နည်း။ အခြေအနေတစ်ခုလုံးသည် အဆင်မပြေဖြစ်လာသည် - ယခု ကျွန်ုပ်တို့တွင် 10^100 ပြောင်းလဲမှုများရှိသည် - များပြားလှသောအရေအတွက်ဖြစ်သည်။ သို့သော်လည်း၊ ယခု ကျွန်ုပ်တို့သည် "kubernetes" ကဲ့သို့သော စကားလုံးများ၏ နောက်ကွယ်တွင် ပုန်းအောင်းမနေတော့ဘဲ ပြဿနာကို ရင်ဆိုင်နေရသောကြောင့် ဤအခြေအနေကို ဤနည်းဖြင့် တံဆိပ်ကပ်ရန် ကျွန်ုပ်နှစ်သက်ပါသည်။

ဒီပြဿနာကို ငါဘာလို့ စွဲလန်းနေတာလဲ။ တစ်စိတ်တစ်ပိုင်းအားဖြင့် NLP နှင့် AI လောကတွင် ယခင်က လုပ်ဆောင်ခဲ့သောကြောင့် ပေါင်းစပ်ပေါက်ကွဲခြင်းပြဿနာကို လွန်ခဲ့သော 5-6 နှစ်ခန့်က ဆွေးနွေးခဲ့ကြပါသည်။ ဗားရှင်းများအစား ကျွန်ုပ်တို့တွင် တစ်ဦးချင်းစကားလုံးများပါရှိပြီး ထုတ်ကုန်များအစား စာကြောင်းများနှင့် စာပိုဒ်များပါရှိသည်။ NLP နှင့် AI ၏ပြဿနာများသည် ကြီးမားစွာမဖြေရှင်းနိုင်သေးသော်လည်း လွန်ခဲ့သည့်နှစ်အနည်းငယ်အတွင်း သိသာထင်ရှားသောတိုးတက်မှုများရရှိခဲ့ကြောင်း ဝန်ခံရပါမည်။ (ကျနော့်အမြင်အရတော့ တိုးတက်မှုတွေ ရှိလာနိုင်ပါတယ်။оလုပ်ငန်းတွင်းရှိလူများသည် စက်သင်ယူမှုနှင့် အခြားနည်းပညာများကို အနည်းငယ်ပိုအာရုံစိုက်ထားလျှင် ပိုကောင်းမည်၊ သို့သော် ၎င်းသည် အကြောင်းအရာမဟုတ်ပါ)။

DevOps နှင့် microservices ၏ကမ္ဘာသို့ ပြန်သွားကြပါစို့။ Kunstkamera တွင် ဆင်တစ်ကောင်ကဲ့သို့ ဟန်ဆောင်ကာ ကြီးမားသောပြဿနာတစ်ခုနှင့် ကျွန်ုပ်တို့ရင်ဆိုင်နေကြရသည် - ကျွန်ုပ်မကြာခဏကြားနေရသောအရာမှာ "ကူဘာနက်နှင့် ပဲ့စင်ကို ယူလိုက်ပါ၊ အားလုံးအဆင်ပြေသွားမှာပါ!" ဒါပေမယ့် မဟုတ်ဘူး၊ အရာအားလုံးဟာ အရင်အတိုင်းပဲ ကျန်ခဲ့မယ်ဆိုရင် အရာအားလုံးက အဆင်ပြေမှာ မဟုတ်ပါဘူး။ ထို့အပြင်၊ ဤပြဿနာအတွက် ခွဲခြမ်းစိတ်ဖြာသည့် အဖြေတစ်ခုသည် ၎င်း၏ ရှုပ်ထွေးမှုကြောင့် လက်ခံနိုင်ပုံမပေါ်ပေ။ NLP တွင်ကဲ့သို့ပင်၊ ကျွန်ုပ်တို့သည် ရှာဖွေမှုနယ်ပယ်ကို ကျဉ်းမြောင်းစေခြင်းဖြင့် ဤပြဿနာကို ဦးစွာချဉ်းကပ်သင့်သည်—ဤကိစ္စတွင်၊ ခေတ်မမီတော့သော ပြောင်းလဲမှုများကို ဖယ်ရှားခြင်းဖြင့်၊

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

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

ထိုသို့သောစမ်းသပ်မှုစနစ်သည် ဤကဲ့သို့ဖြစ်နိုင်သည်-

1. ဆော့ဖ်ဝဲရေးသားသူများသည် စာမေးပွဲများရေးသည် (၎င်းသည် အရေးကြီးသောအဆင့်ဖြစ်သည် - မဟုတ်ပါက ကျွန်ုပ်တို့တွင် အကဲဖြတ်မှုစံနှုန်းမရှိသောကြောင့် - ၎င်းသည် စက်သင်ယူမှုတွင် ဒေတာတံဆိပ်တပ်ခြင်းနှင့်တူသည်)။
2. အစိတ်အပိုင်းတစ်ခုစီ (ပရောဂျက်) သည် ၎င်း၏ကိုယ်ပိုင် CI စနစ်ကို လက်ခံရရှိသည် - ဤလုပ်ငန်းစဉ်သည် ယခုအခါ ကောင်းမွန်စွာ ဖွံ့ဖြိုးလာခဲ့ပြီး အစိတ်အပိုင်းတစ်ခုအတွက် CI စနစ်တစ်ခု ဖန်တီးခြင်းဆိုင်ရာ ပြဿနာကို ကြီးမားစွာ ဖြေရှင်းပြီးဖြစ်သည်။
3. "စမတ်ပေါင်းစပ်မှုစနစ်" သည် အမျိုးမျိုးသော CI စနစ်များ၏ ရလဒ်များကို စုဆောင်းပြီး နောက်ဆုံးထုတ်ကုန်အဖြစ် အစိတ်အပိုင်းပရောဂျက်များကို စုစည်းကာ စမ်းသပ်မှုကို လုပ်ဆောင်ကာ နောက်ဆုံးတွင် ရှိပြီးသားအစိတ်အပိုင်းများနှင့် အန္တရာယ်အချက်များအပေါ် အခြေခံ၍ အလိုရှိသောထုတ်ကုန်လုပ်ဆောင်နိုင်စွမ်းရရှိရန် အတိုဆုံးလမ်းကြောင်းကို တွက်ချက်ပေးပါသည်။ အပ်ဒိတ်တစ်ခုမဖြစ်နိုင်ပါက၊ ဤစနစ်သည် ရှိပြီးသားအစိတ်အပိုင်းများနှင့် မည်သည့်အရာက အမှားအယွင်းဖြစ်စေကြောင်း ဆော့ဖ်ဝဲအင်ဂျင်နီယာများအား အသိပေးသည်။ တစ်ဖန်၊ ပေါင်းစည်းမှုစနစ်သည် စာမေးပွဲများကို အကဲဖြတ်မှုစံနှုန်းတစ်ခုအဖြစ် အသုံးပြုသောကြောင့် ဤနေရာတွင် စမ်းသပ်မှုစနစ်သည် အလွန်အရေးကြီးပါသည်။
4. ထို့နောက် Smart Integration System မှ ဒေတာများကို လက်ခံရရှိပြီး အပ်ဒိတ်ကို တိုက်ရိုက်လုပ်ဆောင်ပေးသည့် CD စနစ်။ ဤအဆင့်သည် သံသရာကို အဆုံးသတ်သည်။

အကျဉ်းချုပ်ပြောရလျှင် ကျွန်ုပ်အတွက် ယခုအကြီးမားဆုံးပြဿနာတစ်ခုမှာ ထုတ်ကုန်တစ်ခုသို့ အစိတ်အပိုင်းအမျိုးမျိုးကို ချိတ်ဆက်ပေးမည့် "Smart Integration System" မရှိခြင်းကြောင့် ထုတ်ကုန်တစ်ခုလုံးကို မည်သို့ပေါင်းစပ်ထားသည်ကို ခြေရာခံနိုင်မည်ဖြစ်သည်။ ဒီအပေါ် အသိုင်းအဝိုင်းရဲ့ အတွေးအမြင်တွေကို ကျွန်တော် စိတ်ဝင်စားမယ် (spoiler - ကျွန်တော် လက်ရှိ ပရောဂျက်တစ်ခု လုပ်နေပါတယ် Relizaထိုကဲ့သို့ စမတ်ကျသော ပေါင်းစည်းမှုစနစ် ဖြစ်လာနိုင်သည်)။

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

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

source: www.habr.com