ဟေး ဟာဘ! ဆောင်းပါးရဲ့ ဘာသာပြန်ချက်ကို မင်းရဲ့အာရုံကို ငါတင်ပြတယ်။ "ဝန်ဆောင်မှု mesh ဒေတာလေယာဉ် vs ထိန်းချုပ်ရေးလေယာဉ်" စာရေးသူ Matt Klein.

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

"Service mesh" ဟူသော အယူအဆသည် ပြီးခဲ့သည့် နှစ်နှစ်အတွင်း (မူရင်း ဆောင်းပါး အောက်တိုဘာလ 10 ရက်၊ 2017 ခုနှစ်) တွင် ပိုမိုရေပန်းစားလာခဲ့ပြီး နေရာလွတ်တွင် ပါဝင်သူအရေအတွက် တိုးလာသည်နှင့်အမျှ၊ ကျွန်ုပ်သည် တစ်ခုလုံးကြားတွင် ရှုပ်ထွေးမှုများ အဆမတန် တိုးလာသည်ကို တွေ့ခဲ့ရသည်။ မတူညီသော ဖြေရှင်းနည်းများကို နှိုင်းယှဉ်ပုံနှင့် ဆန့်ကျင်ဘက်ဆိုင်ရာ နည်းပညာအသိုင်းအဝိုင်း။

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

ဝန်ဆောင်မှုကွက်ရှုပ်ထွေးမှု #1- Linkerd ~ = Nginx ~ = Haproxy ~ = ကိုယ်စားလှယ်။ ၎င်းတို့အနက်မှ Istio နှင့် တန်းတူမဟုတ်ပါ။ Istio သည် လုံးဝကွဲပြားခြားနားသော အရာတစ်ခုဖြစ်သည်။ ၁/

ပထမအချက်မှာ ရိုးရိုးဒေတာလေယာဉ်များဖြစ်သည်။ သူတို့ဘာသာသူတို့ ဘာမှမလုပ်ဘူး။ သူတို့သည် နောက်ထပ် တစ်ခုခုအတွက် ခံစားချက်ရှိရမည်။ ၂/

Istio သည် အစိတ်အပိုင်းများကို ချိတ်ဆက်ထားသော ထိန်းချုပ်လေယာဉ်၏ ဥပမာတစ်ခုဖြစ်သည်။ ဒါက တခြားအလွှာပါ။ /အဆုံး

ယခင် tweets များတွင် မတူညီသောပရောဂျက်များစွာ (Linkerd၊ NGINX၊ HAProxy၊ Envoy နှင့် Istio) ကိုဖော်ပြထားသော်လည်း ပို၍အရေးကြီးသည်မှာ data plane၊ service mesh နှင့် control plane တို့၏ ယေဘုယျသဘောတရားများကို မိတ်ဆက်ပေးခြင်းဖြစ်သည်။ ဤပို့စ်တွင်၊ ကျွန်ုပ်သည် နောက်ပြန်ဆုတ်ပြီး အလွန်မြင့်မားသောအဆင့်တွင် "ဒေတာလေယာဉ်" နှင့် "ထိန်းချုပ်မှုလေယာဉ်" ဟူသော ဝေါဟာရများကို ဆိုလိုကြောင်းနှင့် တွစ်တာတွင်ဖော်ပြထားသော ပရောဂျက်များနှင့် ပတ်သက်သည့် စည်းကမ်းချက်များအကြောင်း ဆွေးနွေးပါမည်။

Service Mesh ဆိုတာ ဘာလဲ၊

ပုံ 1- ဝန်ဆောင်မှု mesh ခြုံငုံသုံးသပ်ချက်

ပုံ 1 အခြေခံအကျဆုံးအဆင့်တွင် ဝန်ဆောင်မှုကွက်တစ်ခု၏ သဘောတရားကို သရုပ်ဖော်သည်။ ဝန်ဆောင်မှုအစု (AD) လေးခုရှိသည်။ ဝန်ဆောင်မှုတစ်ခုစီသည် ဒေသတွင်း ပရောက်စီဆာဗာတစ်ခုနှင့် ဆက်စပ်နေသည်။ အပလီကေးရှင်းတစ်ခုတည်းမှ ကွန်ရက်အသွားအလာအားလုံးကို (HTTP၊ REST၊ gRPC၊ Redis စသည်ဖြင့်) သည် ဒေသန္တရပရောက်စီမှတဆင့် သင့်လျော်သော ပြင်ပဝန်ဆောင်မှုအစုအဝေးများသို့ ပေးပို့သည်။ ဤနည်းအားဖြင့်၊ အပလီကေးရှင်းဥပမာသည် ကွန်ရက်တစ်ခုလုံးကို သတိမထားမိဘဲ ၎င်း၏ပြည်တွင်းပရောက်စီကိုသာ သိရှိသည်။ အမှန်တကယ်အားဖြင့်၊ ဖြန့်ဝေမှုစနစ်ကွန်ရက်ကို ဝန်ဆောင်မှုမှ ဖယ်ရှားခဲ့သည်။

အပါယ်ဒေ

ဝန်ဆောင်မှု mesh တွင်၊ အပလီကေးရှင်းအတွက် စက်တွင်းရှိ ပရောက်စီဆာဗာသည် အောက်ပါလုပ်ငန်းများကို လုပ်ဆောင်သည်-

• ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှု. သင့်လျှောက်လွှာအတွက် မည်သည့်ဝန်ဆောင်မှုများ/လျှောက်လွှာများကို ရနိုင်သနည်း။
• ကျန်းမာရေးစစ်ဆေးခြင်း။. ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုမှ ပြန်လာသော ဝန်ဆောင်မှုဖြစ်ရပ်များသည် ကောင်းမွန်ပြီး ကွန်ရက်အသွားအလာကို လက်ခံရန် အဆင်သင့်ဖြစ်ပြီလား။ ၎င်းတွင် လုပ်ဆောင်နေသော (ဥပမာ- တုံ့ပြန်မှု/ကျန်းမာရေးစစ်ဆေးခြင်း) နှင့် passive (ဥပမာ- ကျန်းမာရေးနှင့်မညီညွတ်သောဝန်ဆောင်မှုအခြေအနေ၏ညွှန်ပြချက်အဖြစ် 3 ဆက်တိုက် 5xx အမှားများကိုအသုံးပြုခြင်း) ကျန်းမာရေးစစ်ဆေးမှုများ နှစ်ခုလုံးပါဝင်နိုင်သည်။
• လမ်းကြောင်းပေး. REST ဝန်ဆောင်မှုတစ်ခုမှ "/foo" သို့ တောင်းဆိုချက်ကို လက်ခံရရှိသောအခါ၊ မည်သည့်ဝန်ဆောင်မှုအစုအဝေးထံသို့ တောင်းဆိုချက်ကို ပေးပို့သင့်သနည်း။
• Load ချိန်ခွင်လျှာ. လမ်းကြောင်းပြနေစဉ်တွင် ဝန်ဆောင်မှုအစုအဝေးကို ရွေးချယ်ပြီးသည်နှင့်၊ မည်သည့်ဝန်ဆောင်မှုဥပမာထံ တောင်းဆိုချက်ကို ပေးပို့သင့်သနည်း။ ဘယ်အချိန်ကုန်သွားလဲ။ ဘယ် circuit breaking settings နဲ့လဲ။ တောင်းဆိုမှု မအောင်မြင်ပါက ၎င်းကို ပြန်စမ်းသင့်ပါသလား။
• အထောက်အထားပြခြင်းနှင့် ခွင့်ပြုချက်. ဝင်လာသောတောင်းဆိုမှုများအတွက်၊ ခေါ်ဆိုမှုဝန်ဆောင်မှုကို mTLS သို့မဟုတ် အခြားယန္တရားအချို့ကို အသုံးပြု၍ လျှို့ဝှက်သင်္ကေတဖြင့် ဖော်ထုတ်နိုင်/ခွင့်ပြုနိုင်ပါသလား။ ၎င်းကို အသိအမှတ်ပြု/ခွင့်ပြုပါက၊ ဝန်ဆောင်မှုတွင် တောင်းဆိုထားသော လည်ပတ်မှု (အဆုံးမှတ်) ကို ခေါ်ဆိုခွင့် သို့မဟုတ် အထောက်အထားမခိုင်လုံသော တုံ့ပြန်မှုကို ပြန်ပေးသင့်ပါသလား။
• မြင်နိုင်စွမ်း. တောင်းဆိုချက်တစ်ခုစီအတွက် အသေးစိတ်စာရင်းဇယားများ၊ မှတ်တမ်းများ/မှတ်တမ်းများနှင့် ဖြန့်ဝေထားသော ခြေရာခံဒေတာကို အော်ပရေတာများ ပေါ်ပေါက်လာသောအခါတွင် ဖြန့်ဝေထားသော လမ်းကြောင်းစီးဆင်းမှုနှင့် အမှားရှာပြင်ခြင်းဆိုင်ရာ ပြဿနာများကို နားလည်နိုင်စေရန် ထုတ်ပေးသင့်ပါသည်။

ဒေတာလေယာဉ်သည် service mesh ရှိ ယခင်အချက်များအားလုံးအတွက် တာဝန်ရှိသည်။ တကယ်တော့၊ proxy local to the service (sidecar) သည် data plane ဖြစ်သည်။ တစ်နည်းဆိုရသော် ဒေတာလေယာဉ်သည် ဝန်ဆောင်မှုတစ်ခုထံ သို့မဟုတ် ပေးပို့သည့် ကွန်ရက်ပက်ကေ့ခ်ျတိုင်းကို အခြေအနေအရ ထုတ်လွှင့်ခြင်း၊ ထပ်ဆင့်ခြင်းနှင့် စောင့်ကြည့်ခြင်းအတွက် တာဝန်ရှိသည်။

ထိန်းချုပ်ရေးလေယာဉ်

ဒေသန္တရ ပရောက်စီတစ်ခုမှ ဒေတာယာဉ်တွင် ပေးဆောင်သော ကွန်ရက် abstraction သည် မှော်ဆန်သည်(?)။ သို့သော်၊ ဝန်ဆောင်မှု B သို့ "/foo" လမ်းကြောင်းအကြောင်း ပရောက်စီက မည်သို့သိသနည်း။ ပရောက်စီတောင်းဆိုမှုများဖြင့် ပြည့်နှက်နေသော ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိသည့်ဒေတာကို မည်သို့အသုံးပြုနိုင်မည်နည်း။ ဝန်ချိန်ခွင်လျှာချိန်ညှိခြင်း၊ အချိန်ကုန်ခြင်း၊ ပတ်လမ်းဖောက်ခြင်းစသည်ဖြင့် ဘောင်များကို မည်သို့ပြင်ဆင်သတ်မှတ်ထားသနည်း။ အပြာ/အစိမ်းနည်းလမ်း သို့မဟုတ် သာယာလှပသော အသွားအလာအကူးအပြောင်းနည်းလမ်းကို အသုံးပြု၍ အပလီကေးရှင်းကို သင်မည်သို့ ဖြန့်ကျက်အသုံးပြုသနည်း။ စနစ်တစ်ခုလုံး အထောက်အထားစိစစ်ခြင်းနှင့် ခွင့်ပြုချက်ဆက်တင်များကို မည်သူက စီစဉ်သတ်မှတ်ပေးသနည်း။

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

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

ပုံ 2: လူသားထိန်းချုပ်မှုလေယာဉ်

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

အပေါ် ပုံ ၃ "လူသားထိန်းချုပ်မှုလေယာဉ်" ဟုခေါ်သည်ကိုပြသသည်။ ဤအသုံးချမှု အမျိုးအစားတွင်၊ အလွန်အသုံးများဆဲဖြစ်သော၊ ဆိုးရွားသော လူသားအော်ပရေတာသည် scripts များမှတစ်ဆင့် ဖြစ်နိုင်ချေရှိသော ပုံစံများကို ဖန်တီးပေးပြီး proxy အားလုံးသို့ အထူးလုပ်ငန်းစဉ်အချို့မှတဆင့် ဖြန့်ကျက်ချထားပါသည်။ ထို့နောက် ပရောက်စီများသည် ဤဖွဲ့စည်းပုံကို စတင်အသုံးပြုပြီး မွမ်းမံထားသော ဆက်တင်များကို အသုံးပြု၍ ဒေတာလေယာဉ်ကို စတင်လုပ်ဆောင်သည်။

ပုံ 3- အဆင့်မြင့်ဝန်ဆောင်မှုကွက်ထိန်းချုပ်ရေးလေယာဉ်

အပေါ် ပုံ ၃ ဝန်ဆောင်မှု mesh ၏ "တိုးချဲ့" ထိန်းချုပ်မှုလေယာဉ်ကို ပြသသည်။ ၎င်းတွင် အောက်ပါ အစိတ်အပိုင်းများ ပါဝင်ပါသည်။

• လူသား: စနစ်တစ်ခုလုံးနှင့်ပတ်သက်ပြီး အဆင့်မြင့်မားသော ဆုံးဖြတ်ချက်များချသော (စိတ်ဆိုးနည်းမည်ဟု မျှော်လင့်သော) ပုဂ္ဂိုလ်တစ်ဦးရှိနေသေးသည်။
• လေယာဉ် UI ကို ထိန်းချုပ်ပါ။: လူတစ်ဦးသည် စနစ်အား ထိန်းချုပ်ရန်အတွက် အသုံးပြုသူ၏ အင်တာဖေ့စ် အမျိုးအစားအချို့နှင့် အပြန်အလှန် တုံ့ပြန်သည်။ ၎င်းသည် ဝဘ်ပေါ်တယ်၊ အမိန့်ပေးစာကြောင်း အပလီကေးရှင်း (CLI) သို့မဟုတ် အခြားသော အင်တာဖေ့စ်အချို့ ဖြစ်နိုင်သည်။ အသုံးပြုသူကြားခံကို အသုံးပြု၍ အော်ပရေတာသည် ကမ္ဘာလုံးဆိုင်ရာ စနစ်ဖွဲ့စည်းပုံဆိုင်ရာ ကန့်သတ်ဘောင်များကို ဝင်ရောက်ခွင့်ရှိသည်-
  • ဖြန့်ကျက်ထိန်းချုပ်မှု၊ အပြာ/အစိမ်း နှင့်/သို့မဟုတ် တဖြည်းဖြည်း လမ်းကြောင်းပြောင်းခြင်း။
  • အထောက်အထားစိစစ်ခြင်းနှင့် ခွင့်ပြုချက်ရွေးချယ်စရာများ
  • ဥပမာအားဖြင့် အပလီကေးရှင်း A က "/foo" နှင့်ပတ်သက်သည့် အချက်အလက်ကို တောင်းဆိုသည့်အခါ လမ်းကြောင်းသတ်မှတ်ခြင်း ဇယားသတ်မှတ်ချက်များ
  • အချိန်ကုန်ခြင်း၊ ထပ်စမ်းခြင်း၊ circuit breaking ဆက်တင်များ စသည်တို့ကဲ့သို့သော ချိန်ခွင်လျှာဆက်တင်များကို ဆွဲချပါ။
• အလုပ်ချိန်ဇယားရေးဆွဲသူ: ဝန်ဆောင်မှုများကို Kubernetes သို့မဟုတ် Nomad ကဲ့သို့သော အချိန်ဇယားဆွဲခြင်း/စုစည်းမှုစနစ် အမျိုးအစားအချို့မှတစ်ဆင့် အခြေခံအဆောက်အအုံပေါ်တွင် လုပ်ဆောင်ပါသည်။ အစီအစဉ်ဆွဲသူသည် ၎င်း၏ဒေသခံ ပရောက်စီနှင့်အတူ ဝန်ဆောင်မှုကို တင်ရန် တာဝန်ရှိသည်။
• ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှု. အစီအစဉ်ဆွဲသူသည် ဝန်ဆောင်မှုဖြစ်ရပ်များကို စတင်ပြီး ရပ်တန့်သည့်အခါ၊ ၎င်းသည် ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုစနစ်သို့ ကျန်းမာရေးအခြေအနေကို အစီရင်ခံသည်။
• Sidecar proxy configuration APIs - ဒေသန္တရ ပရောက်စီများသည် အော်ပရေတာကြားဝင်စွက်ဖက်မှုမရှိဘဲ နောက်ဆုံးတွင် တသမတ်တည်းဖြစ်သော မော်ဒယ်ကို အသုံးပြု၍ အမျိုးမျိုးသော စနစ်အစိတ်အပိုင်းများမှ အခြေအနေကို တက်ကြွစွာ ထုတ်ယူသည်။ လက်ရှိလည်ပတ်နေသည့် ဝန်ဆောင်မှုဖြစ်ရပ်များနှင့် ဒေသဆိုင်ရာ ပရောက်စီဆာဗာများ ပါဝင်သော စနစ်တစ်ခုလုံးသည် နောက်ဆုံးတွင် ဂေဟစနစ်တစ်ခုအဖြစ် ပေါင်းစပ်သွားပါသည်။ Envoy ၏ universal data plane API သည် လက်တွေ့တွင် မည်သို့အလုပ်လုပ်ကြောင်း ဥပမာတစ်ခုဖြစ်သည်။

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

ဒေတာလေယာဉ်နှင့် ထိန်းချုပ်ရေးလေယာဉ်။ ဒေတာလေယာဉ်နှင့် ထိန်းချုပ်မှုလေယာဉ် အနှစ်ချုပ်

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

လက်ရှိ ပရောဂျက်ရှုခင်း

အထက်ဖော်ပြပါ ရှင်းလင်းချက်ကို နားလည်ပြီး၊ ဝန်ဆောင်မှု mesh ပရောဂျက်၏ လက်ရှိအခြေအနေကို ကြည့်ကြပါစို့။

• ဒေတာလေယာဉ်တွေLinkerd၊ NGINX၊ HAProxy၊ Envoy၊ Traefik
• လေယာဉ်များကို ထိန်းချုပ်ပါ။: Istio၊ Nelson၊ SmartStack

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

Linkerd သည် 2016 အစောပိုင်းတွင် service mesh အတွက် ပထမဆုံး data plane proxy servers များထဲမှ တစ်ခုဖြစ်ပြီး service mesh design model ကို သတိပြုမိစေရန် ကောင်းသောအလုပ်တစ်ခု လုပ်ဆောင်ခဲ့သည်။ ထို့နောက် 6 လခန့်အကြာတွင် Envoy သည် Linkerd နှင့်ပူးပေါင်းခဲ့သည် (2015 ခုနှစ်နှောင်းပိုင်းကတည်းက Lyft နှင့် အတူရှိခဲ့သော်လည်း)။ Linkerd နှင့် Envoy တို့သည် service meshes များကို ဆွေးနွေးရာတွင် အများဆုံးဖော်ပြလေ့ရှိသော ပရောဂျက်နှစ်ခုဖြစ်သည်။

Istio ကို မေလ 2017 တွင်ကြေငြာခဲ့သည်။ Istio ပရောဂျက်၏ ရည်မှန်းချက်များသည် ပြသထားသည့် တိုးချဲ့ထိန်းချုပ်မှုလေယာဉ်နှင့် အလွန်ဆင်တူသည်။ ပုံ ၃. Istio အတွက် အထူးကိုယ်စားလှယ်သည် မူရင်းပရောက်စီဖြစ်သည်။ ထို့ကြောင့် Istio သည် ထိန်းချုပ်ရေးလေယာဉ်ဖြစ်ပြီး Envoy သည် ဒေတာလေယာဉ်ဖြစ်သည်။ အချိန်တိုအတွင်း Istio သည် စိတ်လှုပ်ရှားမှုများစွာကို ထုတ်ပေးခဲ့ပြီး အခြားသော ဒေတာလေယာဉ်များသည် Envoy (Linkerd နှင့် NGINX နှစ်ခုစလုံးသည် Istio နှင့် ပေါင်းစည်းမှုကို သရုပ်ပြခဲ့သည်) အတွက် အခြားဒေတာလေယာဉ်များ စတင်ပေါင်းစပ်ခဲ့သည်။ တူညီသောထိန်းချုပ်မှုလေယာဉ်အတွင်း မတူညီသောဒေတာလေယာဉ်များကို အသုံးပြုနိုင်သည့်အချက်မှာ ထိန်းချုပ်မှုလေယာဉ်နှင့် ဒေတာလေယာဉ်တို့သည် တင်းတင်းကြပ်ကြပ် တွဲနေမည်မဟုတ်ကြောင်း ဆိုလိုခြင်းဖြစ်သည်။ Envoy ၏ ယေဘူယျဒေတာလေယာဉ် API ကဲ့သို့သော API တစ်ခုသည် စနစ်၏ အစိတ်အပိုင်းနှစ်ခုကြားတွင် ပေါင်းကူးဖွဲ့စည်းနိုင်သည်။

Nelson နှင့် SmartStack တို့သည် ထိန်းချုပ်မှုလေယာဉ်နှင့် ဒေတာလေယာဉ်ကို ပိုင်းခြားပုံပြရန် ကူညီပေးပါသည်။ Nelson သည် Envoy ကို ၎င်း၏ proxy အဖြစ် အသုံးပြုကာ HashiCorp stack ကို အခြေခံ၍ service mesh အတွက် ယုံကြည်စိတ်ချရသော ထိန်းချုပ်မှုလေယာဉ်ကို တည်ဆောက်သည်။ ခြေသလုံး စတာတွေ၊ SmartStack သည် ဝန်ဆောင်မှု meshes လှိုင်းသစ်တစ်ခု၏ ပထမဆုံးဖြစ်ကောင်းဖြစ်နိုင်သည်။ SmartStack သည် HAProxy သို့မဟုတ် NGINX အနီးတစ်ဝိုက်တွင် ထိန်းချုပ်မှုလေယာဉ်ကို တည်ဆောက်ပြီး ဒေတာလေယာဉ်မှ ဝန်ဆောင်မှု mesh မှ ထိန်းချုပ်မှုလေယာဉ်ကို ပိုင်းဖြတ်နိုင်စွမ်းကို သရုပ်ပြသည်။

ဝန်ဆောင်မှု mesh ပါသော မိုက်ခရိုဆားဗစ်ဗိသုကာသည် အာရုံစူးစိုက်မှု ပိုများလာနေသည် (မှန်လှပါ!)၊ ပရောဂျက်များနှင့် ရောင်းချသူများသည် ဤဦးတည်ချက်တွင် လုပ်ဆောင်ရန် ပိုများလာပါသည်။ လာမယ့်နှစ်အနည်းငယ်အတွင်းမှာ data plane နဲ့ control plane နှစ်ခုစလုံးမှာ ဆန်းသစ်တီထွင်မှုတွေ အများကြီးတွေ့လာရပြီး မတူညီတဲ့ အစိတ်အပိုင်းတွေကို ထပ်လောင်းပေါင်းစပ်ထားပါတယ်။ အဆုံးစွန်အားဖြင့်၊ အော်ပရေတာအတွက် microservice ဗိသုကာလက်ရာသည် ပိုမိုပွင့်လင်းပြီး မှော်ဆန်သော (?) ဖြစ်လာသင့်သည်။
စိတ်တိုတာတွေ လျှော့နည်းလာမယ်လို့ မျှော်လင့်ပါတယ်။

သော့ယူမှုများ

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

source: www.habr.com