ဗိသုကာလက်ရာရွေးချယ်မှုအပိုင်း (၃)

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

နိဒါန်း

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

အနည်းငယ်သောသမိုင်း

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

အတိုချုပ်အားဖြင့်၊ ကျွန်ုပ်တို့၏လက်ရှိနားလည်မှုရှိသည့် microservices များသည် အောက်ပါအတိုင်း ပေါ်ပေါက်လာသည်- 2011 ခုနှစ်တွင် James Lewis သည် ကုမ္ပဏီအသီးသီး၏ လုပ်ငန်းများကို ခွဲခြမ်းစိတ်ဖြာခြင်းဖြင့် SOA ၏ဖြန့်ကျက်မှုကို အရှိန်မြှင့်တင်ပေးသည့် “မိုက်ခရိုအက်ပ်” ပုံစံအသစ်တစ်ခု ပေါ်ပေါက်လာစေရန် အာရုံစိုက်ခဲ့သည်။ ဝန်ဆောင်မှုများ။ အတန်ငယ်ကြာပြီးနောက် 2012 ခုနှစ်တွင် ဗိသုကာဆိုင်ရာ ထိပ်သီးအစည်းအဝေးတွင် ပုံစံကို microservice ဟု အမည်ပြောင်းခဲ့သည်။ ထို့ကြောင့်၊ microservices များကို မိတ်ဆက်ခြင်း၏ ကနဦးပန်းတိုင်မှာ နာမည်ဆိုးဖြင့် ကျော်ကြားစေရန်ဖြစ်သည်။ စျေးကွက်ဖို့အချိန်.

Microservices များသည် 2015 ခုနှစ်တွင် hype wave တွင်ရှိခဲ့သည်။ အချို့သောလေ့လာမှုများအရ၊ microservices ခေါင်းစဉ်နှင့်ပတ်သက်သောအစီရင်ခံစာမပါဘဲညီလာခံတစ်ခုမျှမပြီးမြောက်ပါ။ ထို့အပြင်၊ အချို့သော ညီလာခံများသည် မိုက်ခရိုဝန်ဆောင်မှုများအတွက် သီးသန့်ဖြစ်သည်။ ယခုအချိန်တွင်၊ ပရောဂျက်များစွာသည် ဤဗိသုကာပုံစံကို စတင်အသုံးပြုပြီး ပရောဂျက်တွင် အမွေအနှစ်ကုဒ်များစွာပါရှိပါက၊ မိုက်ခရိုဝန်ဆောင်မှုများသို့ ရွှေ့ပြောင်းခြင်းကို တက်ကြွစွာလုပ်ဆောင်နေဖွယ်ရှိသည်။

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

Monolith

မိုက်ခရိုဝန်ဆောင်မှုများနှင့် ဆန့်ကျင်ဘက်ဖြစ်သော ဗိသုကာပုံစံမှာ monolith (သို့မဟုတ် all-in-one) ဖြစ်သည်။ monolith ဆိုသည်မှာ အဓိပ္ပါယ်မရှိနိုင်သောကြောင့် ဗိသုကာပုံစံများ၏ နောက်ထပ်ဖွံ့ဖြိုးတိုးတက်မှုကို အစပြုခဲ့သည့် ဤဗိသုကာပုံစံ၏ အားနည်းချက်များကို ချက်ချင်းဖော်ပြလိုက်ပါမည်။ အောက်တွင် ချို့ယွင်းချက်တစ်ခုစီကို သီးခြားစီကြည့်ရန် အဆိုပြုပါသည်။

အရွယ်

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

ချိတ်ဆက်မှု

Monolith သည် "ရွှံ့ဘောလုံးကြီး" ဖြစ်ပြီး၊ အပြောင်းအလဲများသည် ကြိုတင်မှန်းဆ၍မရသော အကျိုးဆက်များကို ဖြစ်ပေါ်စေနိုင်သည်။ တစ်နေရာတည်းတွင် အပြောင်းအလဲပြုလုပ်ခြင်းဖြင့်၊ အခြားတစ်ခုတွင် monolith ကို ထိခိုက်စေနိုင်သည် (တူညီသော "မင်းနားရွက်ကိုကုတ်လိုက်၊ *@ ပြုတ်ကျသည်")။ ဤသည်မှာ monolith ရှိ အစိတ်အပိုင်းများသည် အလွန်ရှုပ်ထွေးပြီး အရေးအကြီးဆုံးမှာ၊ ထင်ရှားသော ဆက်ဆံရေးများ ရှိနေခြင်းကြောင့် ဖြစ်သည်။

ဖြန့်ကျက်

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

အပေါ်ယံ

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

အခြားဥပမာ (ပိုမိုဂန္ထဝင်)- ဝန်ဆောင်မှု A သည် ဝန်ဆောင်မှု B ထက် များစွာပို၍ ရေပန်းစားသည်၊ ထို့ကြောင့် သင်သည် ဝန်ဆောင်မှု A နှင့် ဝန်ဆောင်မှု 100 B တို့ကို လိုချင်ပါသည်။ တဖန်၊ ရွေးချယ်စရာ နှစ်ခု- ကျွန်ုပ်တို့သည် 10 လုံးလုံးလျားလျား အပြည့်ကို ဖြန့်ချထားသည်ဖြစ်စေ သို့မဟုတ် အချို့သောအချိန်တွင်၊ ဝန်ဆောင်မှု B ကို ကိုယ်တိုင် ပိတ်ရပါမည်။

ယုံကြည်စိတ်ချရမှု

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

Inertia

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

ကောက်ချက်

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

ပိုပြီးဖတ်ပါ:

• အဘယ်ကြောင့် SQL Server သည် ORDER BY မပါဘဲရလဒ်များကိုစီရန်အာမမခံနိုင်ပါ။
• ဆော့ဖ်ဝဲရေးသားသူများနှင့် စီမံခန့်ခွဲသူများအတွက် ဗိသုကာပညာ- မည်သူသည် အဘယ်အရည်အချင်းများ လိုအပ်သနည်း။

source: www.habr.com