🥇Service mesh အသုံးပြုမှုကိစ္စများ

မှတ်ချက်။ ဘာသာပြန်: ဤဆောင်းပါး၏စာရေးသူ (Luc Perkins) သည် Linkerd၊ SMI (Service Mesh Interface) နှင့် Kuma ကဲ့သို့သော open source ပရောဂျက်များဖြစ်သည့် CNCF မှ developer ရှေ့နေတစ်ဦးဖြစ်သည် (စကားအားဖြင့်၊ Istio သည် ဤစာရင်းတွင် အဘယ်ကြောင့်မပါဝင်သနည်း?..)။ DevOps အသိုက်အဝန်းထံ “ဝန်ဆောင်မှု mesh” ဟုခေါ်သော ခေတ်မီခေတ်မီသော ဖောင်းပွမှုအကြောင်းကို ပိုမိုကောင်းမွန်စွာ နားလည်သဘောပေါက်စေရန် နောက်ထပ်ကြိုးပမ်းမှုတွင်၊ ၎င်းက အဆိုပါဖြေရှင်းချက်ပေးစွမ်းနိုင်သည့် လက္ခဏာ 16 ခုကို စာရင်းပြုစုထားသည်။

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

* ဘာသာပြန်သူ၏မှတ်ချက်- ဤဆောင်းပါးတွင် ဤနေရာမှနေ၍ ဤဘာသာပြန်ဆိုချက် ("service mesh") ကို သက်တမ်းအသစ်ရှိသေးသော ဝန်ဆောင်မှုကွက်အတွက် အသုံးပြုပါမည်။

ဒါပေမယ့် ပထမဆုံး ကျွန်တော် မှတ်ချက် အနည်းငယ် ပေးချင်ပါတယ်။

ကျွန်ုပ်သည် ကျွန်ုပ်၏ကိုယ်ပိုင်ပညာရေးအတွက် ဆောင်ရွက်သည့် ပရောဂျက်များအပြင် ဝန်ဆောင်မှုပေးသည့်ကွက်များနှင့် မည်သည့်အခါမျှ အသုံးမပြုဖူးပါ။ အခြားတစ်ဖက်တွင်၊ ကျွန်ုပ်သည် 2015 ခုနှစ်တွင် Twitter ၏ internal service mesh အတွက် စာရွက်စာတမ်းများစွာကို ရေးသားခဲ့ပြီး (ထိုစဉ်က ၎င်းကို "service mesh" ဟုပင်မခေါ်ဆိုခဲ့) နှင့် site နှင့် documentation အတွက် ပံ့ပိုးပေးခဲ့ပါသည်။ Linkerdဒါကြောင့် တစ်ခုခုကို ဆိုလိုတာပါ။
ကျွန်ုပ်၏စာရင်းသည် တွေဝေနေပြီး မပြည့်စုံပါ။ ကျွန်ုပ်သတိမပြုမိသော အသုံးပြုမှုကိစ္စများ ဖြစ်နိုင်ခြေရှိပြီး နည်းပညာများ တိုးတက်ပြောင်းလဲလာသည်နှင့်အမျှ လူကြိုက်များလာသည်နှင့်အမျှ အသစ်များသည် အချိန်နှင့်အမျှ ထွက်ပေါ်လာနိုင်ဖွယ်ရှိသည်။
တစ်ချိန်တည်းမှာပင်၊ ရှိပြီးသား ဝန်ဆောင်မှု mesh အကောင်အထည်ဖော်မှုတိုင်းသည် ဖော်ပြထားသော အသုံးပြုမှုကိစ္စများအားလုံးကို ပံ့ပိုးပေးမည်မဟုတ်ပါ။ ထို့ကြောင့် “service mesh can…” ကဲ့သို့သော ကျွန်ုပ်၏ထုတ်ပြန်ချက်များကို “အချို့၊ နှင့် အားလုံးလိုလို၊ နာမည်ကြီး service mesh အကောင်အထည်ဖော်မှုများသည်…” အဖြစ် ဖတ်သင့်သည်။
သာဓကများ၏ အစီအစဥ်သည် အရေးမကြီးပါ။

အတိုချုံးစာရင်း-

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

1. ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှု

TL;DR- ရိုးရှင်းသောအမည်များဖြင့် ကွန်ရက်ပေါ်ရှိ အခြားဝန်ဆောင်မှုများသို့ ချိတ်ဆက်ပါ။

ဝန်ဆောင်မှုများသည် သင့်လျော်သောအမည်များကို အသုံးပြု၍ အချင်းချင်း အလိုအလျောက် "ရှာ" နိုင်စေသင့်သည် - ဥပမာ၊ service.api.production, pets/staging သို့မဟုတ် cassandra. Cloud ပတ်၀န်းကျင်များသည် ၎င်းတို့၏ ပျော့ပျောင်းမှုဖြင့် သွင်ပြင်လက္ခဏာရှိပြီး အမည်တစ်ခုသည် ဝန်ဆောင်မှုများစွာကို ဖုံးကွယ်ထားနိုင်သည်။ ထိုသို့သောအခြေအနေမျိုးတွင် IP လိပ်စာအားလုံးကို hardcode လုပ်ရန် မဖြစ်နိုင်ကြောင်း ထင်ရှားပါသည်။

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

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

2. ကုဒ်ဝှက်ခြင်း

TL;DR- ဝန်ဆောင်မှုများကြားတွင် ကုဒ်မထားသော အသွားအလာများကို ဖယ်ရှားပြီး ဤလုပ်ငန်းစဉ်ကို အလိုအလျောက် ချဲ့ထွင်နိုင်စေပါသည်။

တိုက်ခိုက်သူများသည် သင့်အတွင်းပိုင်းကွန်ရက်သို့ မဝင်ရောက်နိုင်သည်ကို သိရှိရခြင်းမှာ ဝမ်းသာပါသည်။ Firewall များသည် ၎င်းကို တားဆီးရန် ကောင်းမွန်သော အလုပ်ဖြစ်သည်။ ဒါပေမယ့် ဟက်ကာတစ်ယောက်ဝင်လာရင် ဘာဖြစ်မလဲ။ ဝန်ဆောင်မှုအတွင်း အသွားအလာဖြင့် သူတို့အလိုရှိသမျှကို လုပ်ဆောင်နိုင်ပါမည်လား။ မဖြစ်ဘူးလို့ မျှော်လင့်ရအောင်။ ထိုသို့သော အခြေအနေမျိုးကို ကာကွယ်ရန်၊ ဝန်ဆောင်မှုများကြားရှိ သွားလာမှုအားလုံးကို ကုဒ်ဝှက်ထားသည့် သုည-ယုံကြည်မှုကွန်ရက်ကို အကောင်အထည်ဖော်သင့်သည်။ ခေတ်မီဝန်ဆောင်မှု အများစုသည် အပြန်အလှန်အားဖြင့် ၎င်းကို အောင်မြင်သည်။ TLS (အပြန်အလှန် TLS၊ mTLS)။ အချို့ကိစ္စများတွင်၊ mTLS သည် cloud များနှင့် အစုအဝေးများအားလုံးတွင် အလုပ်လုပ်သည် (တစ်နေ့နေ့တွင် interplanetary communications ကိုလည်း အလားတူ စီစဉ်ပေးမည်ဟု ထင်ပါသည်)။

ဟုတ်ပါတယ်၊ mTLS ဝန်ဆောင်မှု mesh အတွက် ရွေးချယ်ခွင့်. ဝန်ဆောင်မှုတစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင် TLS ကို ဂရုစိုက်နိုင်သည်၊ သို့သော် ဆိုလိုသည်မှာ လက်မှတ်များထုတ်လုပ်ရန် နည်းလမ်းရှာဖွေခြင်း၊ ဝန်ဆောင်မှုလက်ခံဆောင်ရွက်ပေးသည့်နေရာများတစ်လျှောက် ဖြန့်ဝေရန်၊ ဤလက်မှတ်များကို ဖိုင်များမှတင်မည့် အပလီကေးရှင်းတွင် ကုဒ်များပါရှိသည်။ အိုး၊ ပုံမှန်ကြားကာလတွင် ဤလက်မှတ်များကို သက်တမ်းတိုးရန် မမေ့ပါနှင့်။ Service meshes သည် mTLS ကဲ့သို့သော စနစ်များဖြင့် အလိုအလျောက်လုပ်သည်။ SPIFFEလက်မှတ်များထုတ်ပေးခြင်းနှင့် အလှည့်ကျလုပ်ဆောင်ခြင်းလုပ်ငန်းစဉ်ကို အလိုအလျောက်လုပ်ဆောင်ပေးပါသည်။

3. စစ်မှန်ကြောင်းအထောက်အထားနှင့်ခွင့်ပြုချက်

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

ဝန်ဆောင်မှုများကို မကြာခဏ သိချင်၊ အဘယ်သူသည် တောင်းဆိုချက် (အထောက်အထားစိစစ်ခြင်း) ပြုလုပ်ပြီး ဤအချက်အလက်ကို အသုံးပြု၍ ဆုံးဖြတ်သည်။ ထို ဒီဘာသာရပ်ကို လုပ်ပိုင်ခွင့် (authorization) ရှိတယ်။ ဤကိစ္စတွင်၊ နာမ်စား "သူ" သည် ဖုံးကွယ်နိုင်သည်-

အခြားဝန်ဆောင်မှုများ။ ဒါကို “စစ်မှန်ကြောင်း သက်သေပြခြင်း” ဟုခေါ်သည်။ ရွယ်တူ"ဥပမာ၊ ဝန်ဆောင်မှု web ဝန်ဆောင်မှုကို ရယူလိုသည်။ dbဝန်ဆောင်မှု meshes များသည် များသောအားဖြင့် mTLS ကို အသုံးပြု၍ ထိုပြဿနာများကို ဖြေရှင်းနိုင်သည်- ဤကိစ္စတွင် လက်မှတ်များကို လိုအပ်သော သတ်မှတ်သူအဖြစ် လုပ်ဆောင်သည်။
အချို့သောလူ့အသုံးပြုသူများ။ ဒါကို “စစ်မှန်ကြောင်း သက်သေပြခြင်း” ဟုခေါ်သည်။ တောင်းဆိုချက်များ"ဥပမာ၊ အသုံးပြုသူ haxor69 မီးခွက်အသစ်ဝယ်ချင်တယ်။ ဝန်ဆောင်မှုဂရစ်များကဲ့သို့သော အမျိုးမျိုးသော ယန္တရားများကို ပံ့ပိုးပေးသည်။ JSON ဝဘ်တိုကင်များ.
ကျွန်ုပ်တို့အများအပြားသည် ကျွန်ုပ်တို့၏ လျှောက်လွှာကုဒ်တွင် ဤအရာကို လုပ်ဆောင်ခဲ့ကြပါသည်။ တောင်းဆိုချက်တစ်ခုဝင်လာပြီး စားပွဲတစ်လုံးကို ကြည့်သည်။ usersအသုံးပြုသူကို ရှာပြီး စကားဝှက်ကို နှိုင်းယှဉ်ပါ၊ ထို့နောက် ကော်လံကို စစ်ဆေးပါ။ permissions စသည်တို့သည် ဝန်ဆောင်မှု mesh တစ်ခုတွင်၊ တောင်းဆိုချက်သည် ဝန်ဆောင်မှုသို့ မရောက်ရှိမီတွင်ပင် ၎င်းသည် ဖြစ်ပေါ်ပါသည်။

တောင်းဆိုချက်သည် မည်သူထံမှ လာကြောင်းကို ကျွန်ုပ်တို့ သတ်မှတ်ပြီးသည်နှင့်၊ ကျွန်ုပ်တို့သည် ထိုအကြောင်းအရာကို လုပ်ဆောင်ခွင့်ကို ဆုံးဖြတ်ရန် လိုအပ်ပါသည်။ ဝန်ဆောင်မှု meshes အချို့သည် သင့်အား YAML ဖိုင်များ သို့မဟုတ် command line တွင် အခြေခံပေါ်လစီများ (မည်သူလုပ်ဆောင်နိုင်သည်ဆိုသည်) ကို သတ်မှတ်ခွင့်ပြုထားပြီး အချို့ကမူဘောင်များနှင့် ပေါင်းစည်းမှုကို ပံ့ပိုးပေးပါသည်။ မူဝါဒအေးဂျင့်ဖွင့်ပါ။အဆုံးပန်းတိုင်မှာ သင့်ဝန်ဆောင်မှုများသည် ယုံကြည်စိတ်ချရသော အရင်းအမြစ်မှလာကြောင်း ယုံကြည်ပြီး မည်သည့်တောင်းဆိုမှုကိုမဆို လက်ခံစေရန်ဖြစ်သည်။ и ဤလုပ်ဆောင်ချက်ကို ခွင့်ပြုထားသည်။

4. Load ချိန်ခွင်လျှာညှိခြင်း။

TL;DR- သီးခြားပုံစံတစ်ခုအရ ဝန်ဆောင်မှုဖြစ်ရပ်များတစ်လျှောက် ဝန်ကို ဖြန့်ဝေပါ။

ဝန်ဆောင်မှုကဏ္ဍရှိ "ဝန်ဆောင်မှု" တွင် တူညီသော မိတ္တူများစွာ ပါဝင်ပါသည်။ ဥပမာ-ယနေ့ဝန်ဆောင်မှု cache မိတ္တူ ၅ စောင် ပါဝင်ပြီး မနက်ဖြန်တွင် ၎င်းတို့၏ အရေအတွက်သည် ၁၁ အထိ တိုးလာနိုင်သည်။ တောင်းဆိုမှုများကို ပေးပို့ထားသည်။ cacheသတ်မှတ်ထားသော ရည်မှန်းချက်အတိုင်း ဖြန့်ဝေသင့်သည်။ ဥပမာအားဖြင့်၊ latency ကို လျှော့ချရန် သို့မဟုတ် အလုပ်လုပ်သည့် သာဓကတစ်ခုသို့ ရောက်ရှိနိုင်ခြေကို အများဆုံးဖြစ်စေရန်။ အသုံးအများဆုံး algorithm သည် Round-robin service algorithm ဖြစ်သည်၊ သို့သော် weighted ကဲ့သို့သော အခြားအရာများစွာရှိပါသည်။ (အလေးချိန်) စုံစမ်းမေးမြန်းချက်များ (သင်နှစ်သက်သောပစ်မှတ်များကို ရွေးချယ်နိုင်သည်)၊ အသံမြည်ပါ။ (လက်စွပ်) hashing (အထက်စီးကြောင်းအိမ်ရှင်များအတွက် တသမတ်တည်း hashing ကိုသုံးပါ) သို့မဟုတ် စုံစမ်းမှုအနည်းဆုံးနည်းလမ်း (မေးလိုးချက်အနည်းဆုံးဖြင့် ဥပမာအား ဦးစားပေးသည်)။

Classic load balancers တွင် HTTP caching နှင့် DDoS protection ကဲ့သို့သော အခြားသော အင်္ဂါရပ်များ ရှိသည်၊ သို့သော် ၎င်းတို့သည် အရှေ့အနောက် လမ်းကြောင်း (ဝန်ဆောင်မှု mesh ၏ ပုံမှန် အပလီကေးရှင်း) အတွက် အလွန်သက်ဆိုင်မှု မရှိပါ။ ဟုတ်ပါတယ်၊ သင်သည် load balancing အတွက် service mesh ကိုအသုံးပြုရန်မလိုအပ်ပါ၊ သို့သော်၎င်းသည်သင့်အား ဗဟိုချုပ်ကိုင်မှုထိန်းချုပ်မှုလေယာဉ်မှဝန်ဆောင်မှုတစ်ခုစီအတွက် load Balancing မူဝါဒများကိုသတ်မှတ်ပြီး ထိန်းချုပ်နိုင်စေခြင်းဖြင့် network stack တွင်သီးခြား load balancers များကို run ရန်နှင့် configure လုပ်ရန်မလိုအပ်ပါ။

5. ပတ်လမ်းဖောက်ထွင်းခြင်း။

TL;DR- ပြဿနာရှိသော ဝန်ဆောင်မှုသို့ အသွားအလာ ရပ်တန့်ပြီး အဆိုးဆုံး အခြေအနေများတွင် ပျက်စီးမှုများကို ထိန်းချုပ်ပါ။

အကြောင်းတစ်ခုခုကြောင့် ဝန်ဆောင်မှုသည် ယာဉ်ကြောပိတ်ဆို့မှုကို မကိုင်တွယ်နိုင်ပါက၊ ဝန်ဆောင်မှု mesh သည် ဤပြဿနာကို ဖြေရှင်းရန် ရွေးချယ်စရာများစွာကို ပေးဆောင်သည် (အခြားအရာများကို သက်ဆိုင်ရာကဏ္ဍများတွင် ဆွေးနွေးသွားပါမည်)။ circuit breaking သည် ဝန်ဆောင်မှုလမ်းကြောင်းမှ ချိတ်ဆက်မှုကို ဖြတ်တောက်ရန် အပြင်းထန်ဆုံး ရွေးချယ်မှုဖြစ်သည်။ သို့သော်၊ ၎င်းသည် ၎င်း၏ကိုယ်ပိုင်အတွက် အဓိပ္ပာယ်မရှိပါ - အရန်အစီအစဉ်တစ်ခု လိုအပ်ပါသည်။ Backpressure ပေးနိုင်သည်။ (backpressure) တောင်းဆိုမှုများပြုလုပ်သည့် ဝန်ဆောင်မှုများသို့ (၎င်းအတွက် သင့်ဝန်ဆောင်မှုကွက်ကို သတ်မှတ်ရန် မမေ့ပါနှင့်။) သို့မဟုတ် ဥပမာအားဖြင့် အခြေအနေစာမျက်နှာကို အနီရောင်ဖြင့် အရောင်ခြယ်ကာ အသုံးပြုသူများကို “ကျသွားသော ဝေလငါး” ဖြင့် စာမျက်နှာ၏ နောက်ဗားရှင်းသို့ ပြန်လည်ညွှန်းခြင်း (“Twitter ပျက်နေသည်”)။

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

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

6. အော်တိုစကေးချဲ့ခြင်း။

TL;DR- သတ်မှတ်ထားသော စံနှုန်းများအပေါ် အခြေခံ၍ ဝန်ဆောင်မှု ဖြစ်ရပ်များ အရေအတွက်ကို တိုး သို့မဟုတ် လျှော့ချပါ။

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

ဥပမာအားဖြင့်၊ Kubernetes သည် pods ၏ CPU နှင့် Memory အသုံးပြုမှုအပေါ်အခြေခံ၍ ဝန်ဆောင်မှုများကို အတိုင်းအတာများပေးသည်။ (ကျွန်ုပ်တို့၏အစီရင်ခံစာကိုကြည့်ပါ"Kubernetes ရှိ အော်တိုစကေးချဲ့ခြင်းနှင့် အရင်းအမြစ်စီမံခန့်ခွဲမှု"- အနီးစပ်ဆုံး ဘာသာပြန်။)သို့သော် သင်သည် အခြားသော မက်ထရစ် (ကျွန်ုပ်တို့၏ အခြေအနေတွင်၊ ယာဉ်ကြောအသွားအလာဆိုင်ရာ) ကို အခြေခံ၍ စကေးချရန် ဆုံးဖြတ်ပါက သင်သည် သီးခြားမက်ထရစ်တစ်ခု လိုအပ်ပါသည်။ ဤကဲ့သို့သောအရာ ၎င်းကိုမည်ကဲ့သို့ပြုလုပ်ရမည်ကိုပြသသည်။ အထူးသံတမန်, Istio и Prometheusဒါပေမယ့် လုပ်ငန်းစဉ် ကိုယ်တိုင်က အတော်လေး ရှုပ်ထွေးပါတယ်။ ကျွန်ုပ်တို့သည် ၎င်းအား ရိုးရှင်းစေရန် ဝန်ဆောင်မှုကွက်ကို ရိုးရှင်းစေလိုပြီး "ဝန်ဆောင်မှု အရေအတွက်ကို တိုးမြှင့်ခြင်းကဲ့သို့သော အခြေအနေများကို ရိုးရှင်းစွာ သတ်မှတ်ခွင့်ပြုခြင်း" authအကယ်၍ လုပ်ဆောင်ရန် စောင့်ဆိုင်းနေသည့် တောင်းဆိုချက် အရေအတွက်သည် သတ်မှတ်ချက်ထက် တစ်မိနစ် ကျော်လွန်ပါက၊"

7. Canary ထားရှိမှု

TL;DR- သုံးစွဲသူအုပ်စုခွဲတစ်ခုတွင် ဝန်ဆောင်မှုအသစ် သို့မဟုတ် ဗားရှင်းများကို စမ်းသပ်ပါ။

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

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

8. စိမ်းပြာ ဖြန့်ကျက်မှုများ

TL;DR- အမိုက်စား အင်္ဂါရပ်အသစ်ကို ထုတ်ပြသော်လည်း ၎င်းကို ချက်ချင်းပြန်ပြောင်းရန် ပြင်ဆင်ထားပါ။

အဓိပ်ပါယျ စိမ်းပြာ ဖြန့်ကျက်မှု "အပြာ" ဝန်ဆောင်မှုအသစ်ကို အဟောင်း၊ "စိမ်း" နှင့်အပြိုင် လုပ်ဆောင်ခြင်းဖြစ်သည်။ အရာအားလုံး ချောမွေ့ပြီး ဝန်ဆောင်မှုအသစ်သည် ကောင်းမွန်ကြောင်း သက်သေပြပါက၊ အဟောင်းကို ဖြည်းဖြည်းချင်း ပိတ်သွားနိုင်ပါသည်။ (ဖြစ်ချင်တော့၊ တစ်နေ့နေ့မှာတော့ ဒီ "အပြာရောင်" ဝန်ဆောင်မှုအသစ်ဟာ "အစိမ်းရောင်" နဲ့ ပျောက်ကွယ်သွားမယ့် ကံကြမ္မာကို ခံစားရပါလိမ့်မယ်...) အစိမ်းရောင် အပြာရောင် ဖြန့်ကျက်မှုများသည် အင်္ဂါရပ်အသစ်တွင် ပါဝင်သည့် ကိန္နရီများနှင့် ကွဲပြားသည် တစ်ချိန်တည်းမှာ အသုံးပြုသူများ (တစ်စိတ်တစ်ပိုင်းမဟုတ်ပါ); ဤနေရာတွင် တစ်စုံတစ်ခု မှားယွင်းနေပါက "backup port" အဆင်သင့်ရှိရန်ဖြစ်သည်။

Service meshes သည် "အပြာရောင်" ဝန်ဆောင်မှုကိုစမ်းသပ်ရန်အလွန်အဆင်ပြေသောနည်းလမ်းကိုပေးဆောင်ပြီးပြဿနာများရှိပါကအလုပ်လုပ် "အစိမ်းရောင်" တစ်ခုသို့ချက်ချင်းပြောင်းပါ။ ၎င်းတို့သည် အပြည့်အဝလည်ပတ်ရန် အဆင်သင့်ဖြစ်မဖြစ်ကို နားလည်စေရန် ကူညီပေးသည့် "အပြာရောင်" ဝန်ဆောင်မှု၏ လည်ပတ်မှုနှင့်ပတ်သက်သည့် အချက်အလက်များစွာ (အောက်တွင် "Telemetry" ကို ကြည့်ပါ) ကိုလည်း ပေးဆောင်သည်ဟု မဆိုလိုပါ။

မှတ်ချက်။ ဘာသာပြန်− Kubernetes (ဖော်ပြထားသော ကိန္နရီ၊ အပြာ/အစိမ်းနှင့် အခြားအရာများ အပါအဝင်) တွင် မတူညီသော အသုံးချနည်းဗျူဟာများအကြောင်း ပိုမိုဖတ်ရှုနိုင်ပါသည် ဤဆောင်းပါးတွင်.

9. ကျန်းမာရေးစစ်ဆေးပါ။

TL;DR- မည်သည့်ဝန်ဆောင်မှုအခြေအနေများသည် ကျန်းမာရေးနှင့်ညီညွတ်သည်ကို စောင့်ကြည့်ပြီး မကျန်းမာတော့သောသူများကို တုံ့ပြန်ပါ။

ကျန်းမာရေးစစ်ဆေးမှု (ကျန်းမာရေးစစ်ဆေးမှု) ဝန်ဆောင်မှု သာဓကများကို လက်ခံရန်နှင့် အသွားအလာကို လုပ်ဆောင်ရန် အဆင်သင့်ဖြစ်မဖြစ် ဆုံးဖြတ်ရန် ကူညီပေးသည်။ ဥပမာအားဖြင့်၊ HTTP ဝန်ဆောင်မှုများတွင်၊ ကျန်းမာရေးစစ်ဆေးမှုသည် အဆုံးမှတ်တစ်ခုသို့ GET တောင်းဆိုချက်နှင့်တူနိုင်သည်။ /health. ဖြေ 200 OK ဥပမာသည် ကျန်းမာသည် ဟု ဆိုလိုသည် - လမ်းကြောင်းကို လက်ခံရန် အဆင်သင့်မဖြစ်သေးပါ။ Service Meshes သည် သင့်အား ကျန်းမာရေးစစ်ဆေးသည့်နည်းလမ်းနှင့် ဤစစ်ဆေးမှုပြုလုပ်သည့်အကြိမ်ရေ နှစ်မျိုးလုံးကို သတ်မှတ်နိုင်စေပါသည်။ ထို့နောက် ဤအချက်အလက်ကို အခြားရည်ရွယ်ချက်များအတွက် အသုံးပြုနိုင်သည် - ဥပမာအားဖြင့်၊ load balancing နှင့် circuit breaking အတွက်။

ထို့ကြောင့် ကျန်းမာရေးစစ်ဆေးမှုများသည် သီးသန့်အသုံးပြုမှုကိစ္စမဟုတ်သော်လည်း အများအားဖြင့် အခြားပန်းတိုင်များအောင်မြင်ရန် အသုံးပြုကြသည်။ ထို့အပြင်၊ ကျန်းမာရေးစစ်ဆေးမှုများ၏ရလဒ်များပေါ်မူတည်၍ ပြင်ပ (အခြားဝန်ဆောင်မှုပေးသည့်နေရာပန်းတိုင်များနှင့်ဆက်စပ်သော) လုပ်ဆောင်ချက်များကို လိုအပ်နိုင်ပါသည်- ဥပမာ၊ အခြေအနေစာမျက်နှာကို အပ်ဒိတ်လုပ်ခြင်း၊ GitHub တွင် ပြဿနာဖန်တီးခြင်း သို့မဟုတ် JIRA လက်မှတ်ကို ဖြည့်သွင်းခြင်း။ ဝန်ဆောင်မှု mesh သည် ဤအရာအားလုံးကို အလိုအလျောက်လုပ်ဆောင်ရန်အတွက် အဆင်ပြေသော ယန္တရားကို ပေးဆောင်သည်။

10. သွန်းလောင်းခြင်း။

TL;DR- အသုံးပြုမှု ယာယီမြင့်တက်မှုကို တုံ့ပြန်သည့်အနေဖြင့် အသွားအလာလမ်းကြောင်းပြန်ပေးပါ။

ဝန်ဆောင်မှုတစ်ခုသည် အသွားအလာများပြားနေပါက၊ အဆိုပါလမ်းကြောင်းအချို့ကို အခြားနေရာသို့ ခေတ္တပြန်ညွှန်းနိုင်သည် (ဆိုလိုသည်မှာ "ချ" သို့မဟုတ် "လောင်း" သည်) (သွန်း) အဲဒီမှာ)။ ဥပမာအားဖြင့်၊ အရန်ဝန်ဆောင်မှု သို့မဟုတ် ဒေတာစင်တာသို့ သို့မဟုတ် အမြဲတမ်းတစ်ခုသို့ Pulsar အကြောင်းအရာ ရလဒ်အနေဖြင့်၊ ဝန်ဆောင်မှုသည် ရပ်တန့်နေပြီး မည်သည့်အရာကိုမျှ လုပ်ဆောင်ခြင်းမပြုဘဲ အချို့သောတောင်းဆိုမှုများကို ဆက်လက်လုပ်ဆောင်သွားမည်ဖြစ်သည်။ Load shedding သည် chain breaking ကို ပိုကောင်းသည်၊ သို့သော် ၎င်းကို အလွန်အကျွံသုံးရန် မအကြံပြုနိုင်သေးပါ။ ၎င်းသည် ရေအောက်ဝန်ဆောင်မှုများကို ပျက်စီးသွားစေသည့် Cascading ကျရှုံးမှုများကို ကာကွယ်ပေးသည်။

11. ယာဉ်ကြောအသွားအလာကို မျဉ်းပြိုင်ခြင်း/ပုံမဖော်ခြင်း။

TL;DR- တောင်းဆိုချက်တစ်ခုကို နေရာများစွာသို့ တစ်ပြိုင်နက် ပေးပို့ပါ။

တစ်ခါတစ်ရံတွင် ဝန်ဆောင်မှုများစွာထံသို့ တောင်းဆိုချက်တစ်ခု (သို့မဟုတ် အချို့သောတောင်းဆိုမှုများ) ကို တစ်ပြိုင်နက် ပေးပို့ရန် လိုအပ်ပါသည်။ ပုံမှန်ဥပမာတစ်ခုသည် ထုတ်လုပ်မှုလမ်းကြောင်း၏တစ်စိတ်တစ်ပိုင်းကို အဆင့်မြှင့်တင်ခြင်းဝန်ဆောင်မှုတစ်ခုထံ ပေးပို့ခြင်းဖြစ်သည်။ ပင်မထုတ်လုပ်ရေးဝဘ်ဆာဗာသည် ရေအောက်ပိုင်းဝန်ဆောင်မှုသို့ တောင်းဆိုချက်တစ်ခု ပေးပို့သည်။ products.production နှင့်သာ။ ဝန်ဆောင်မှု mesh သည် ဤတောင်းဆိုချက်ကို ထက်မြက်စွာ မိတ္တူကူးပြီး ၎င်းထံသို့ ပေးပို့ပါသည်။ products.stagingဝဘ်ဆာဗာကတောင် မသိတဲ့၊

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

12. လျှပ်ကာ

TL;DR- သင့်ဝန်ဆောင်မှု mesh ကို အသေးစားကွန်ရက်များအဖြစ် ခွဲလိုက်ပါ။

အဖြစ်လူသိများသည်။ ပိုင်းခြားခြင်း။အထီးကျန်ခြင်းသည် ဝန်ဆောင်မှုကွက်တစ်ခုအား တစ်ခုနှင့်တစ်ခုအကြောင်းမသိသော ယုတ္တိနည်းကျကျ သီးခြားအပိုင်းများအဖြစ် ပိုင်းခြားခြင်းအနုပညာဖြစ်သည်။ Isolation သည် virtual private networks များဖန်တီးခြင်းနှင့် ခပ်ဆင်ဆင်တူသည်။ အဓိကခြားနားချက်မှာ သင်သည် ဝန်ဆောင်မှု mesh (ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုကဲ့သို့) အကျိုးကျေးဇူးအားလုံးကို ဆက်လက်ရရှိနေသေးသော်လည်း လုံခြုံရေးကို ထပ်လောင်းထည့်သွင်းထားသည်။ ဥပမာအားဖြင့်၊ အကယ်၍ တိုက်ခိုက်သူသည် ကွန်ရက်တစ်ခုရှိ ဝန်ဆောင်မှုတစ်ခုအား ထိုးဖောက်ဝင်ရောက်ရန် စီမံပါက၊ ၎င်းတို့သည် အခြားသော ကွန်ရက်ခွဲများတွင် မည်သည့်ဝန်ဆောင်မှုများ လုပ်ဆောင်နေသည်များကို မြင်နိုင်မည်မဟုတ်ပါ သို့မဟုတ် ၎င်းတို့၏ လမ်းကြောင်းကို ကြားဖြတ်တားဆီးနိုင်မည်မဟုတ်ပေ။

အဖွဲ့အစည်းဆိုင်ရာ အကျိုးကျေးဇူးများလည်း ရှိနိုင်ပါသည်။ သင့်ကုမ္ပဏီဖွဲ့စည်းပုံအပေါ် အခြေခံ၍ ဝန်ဆောင်မှုများကို subnets များအဖြစ် ခွဲခြမ်းပြီး ဝန်ဆောင်မှု mesh တစ်ခုလုံးကို ခြေရာခံရန် လိုအပ်သည့် သိမြင်နားလည်မှုဆိုင်ရာ ဝန်ထုပ်ဝန်ပိုးမှ developer များအား ကင်းလွတ်စေနိုင်သည်။

13. နှုန်းကန့်သတ်ချက်၊ ထပ်စမ်းခြင်းနှင့် အချိန်ကုန်ခြင်းများကို တောင်းဆိုပါ။

TL;DR- သင့်ကုဒ်ဘေ့စ်တွင် အချိန်ကုန်တောင်းဆိုမှု စီမံခန့်ခွဲခြင်းလုပ်ငန်းများကို ထည့်သွင်းရန် မလိုအပ်တော့ပါ။

ဤအရာအားလုံးကို သီးခြားအသုံးပြုမှုကိစ္စများဟု ယူဆနိုင်သော်လည်း ၎င်းတို့တွင် တူညီသည့်အချက်တစ်ချက်ကြောင့် ၎င်းတို့ကို စုစည်းရန် ဆုံးဖြတ်ခဲ့သည်- ၎င်းတို့သည် ပုံမှန်အားဖြင့် အပလီကေးရှင်းစာကြည့်တိုက်များမှ ကိုင်တွယ်သည့် တောင်းဆိုမှုဘဝသံသရာစီမံခန့်ခွဲမှုတာဝန်များကို ဖယ်ရှားလိုက်ပါသည်။ အကယ်၍ သင်သည် Ruby on Rails ဝဘ်ဆာဗာကို တည်ဆောက်နေပါက (ဝန်ဆောင်မှု mesh နှင့် ပေါင်းစည်းမထားပါ) မှတဆင့် ဝန်ဆောင်မှုများကို နောက်ခံပြုရန် တောင်းဆိုမှုများ ပြုလုပ်နေပါက၊ gRPCN တောင်းဆိုမှုများ မအောင်မြင်ပါက အပလီကေးရှင်းသည် ဘာလုပ်ရမည်ကို ကိုယ်တိုင်ဆုံးဖြတ်ရမည်ဖြစ်သည်။ ၎င်းသည် ဤဝန်ဆောင်မှုများ မည်မျှ အသွားအလာ မည်မျှ ကိုင်တွယ်နိုင်ပြီး အထူးစာကြည့်တိုက်ကို အသုံးပြု၍ ဤကန့်သတ်ချက်များကို hardcode လုပ်နိုင်သည်ကိုလည်း တွက်ဆရမည်ဖြစ်သည်။ ထို့အပြင်၊ လျှောက်လွှာသည် မည်သည့်အချိန်တွင် စွန့်လွှတ်ရမည်ကို ဆုံးဖြတ်ရမည်ဖြစ်ပြီး တောင်းဆိုမှုအား ဆိုးရွားသွားစေမည် (အချိန်ကုန်သွားသည်)။ အထက်ဖော်ပြပါ ကန့်သတ်ချက်များအားလုံးကို ပြောင်းလဲရန်အတွက် ဝဘ်ဆာဗာကို ရပ်တန့်ရန်၊ ပြန်လည်ပြင်ဆင်ပြီး ပြန်လည်စတင်ရမည်ဖြစ်သည်။

ဤတာဝန်များကို service mesh သို့လွှဲအပ်ခြင်းသည် ဝန်ဆောင်မှု developer များသည် ၎င်းတို့အကြောင်း စဉ်းစားရန်မလိုအပ်ဘဲ ၎င်းတို့ကို ကမ္ဘာလုံးဆိုင်ရာနည်းလမ်းဖြင့် ထည့်သွင်းစဉ်းစားနိုင်စေခြင်းကိုလည်း ဆိုလိုသည်။ သင့်တွင် ရှုပ်ထွေးသော ဝန်ဆောင်မှုကွင်းဆက်တစ်ခုရှိပါက A –> B –> C –> D –> E ဟု ပြောပါ၊ သင်သည် တောင်းဆိုချက်တစ်ခု၏ ဘဝသံသရာတစ်ခုလုံးကို ထည့်သွင်းစဉ်းစားရန် လိုအပ်ပါသည်။ ဝန်ဆောင်မှု C တွင် အချိန်ကုန်ဆုံးရန် လိုအပ်ပါက၊ အနည်းငယ်မျှသာမဟုတ်ဘဲ၊ ဝန်ဆောင်မှုကုဒ်ကို အပ်ဒိတ်လုပ်ခြင်းနှင့် ဆွဲထုတ်ခြင်းတောင်းဆိုချက်ကို စောင့်ဆိုင်းခြင်းနှင့် ပြုပြင်မွမ်းမံထားသော ဝန်ဆောင်မှုကို အသုံးပြုရန် CI စနစ်က တစ်ကြိမ်တည်းလုပ်ဆောင်ရန် အဓိပ္ပာယ်ရှိပါသည်။

14. Telemetry

TL;DR- ဝန်ဆောင်မှုများမှ လိုအပ်သော (မလိုအပ်သော) အချက်အလက်အားလုံးကို စုဆောင်းပါ။

Telemetry သည် မက်ထရစ်များ၊ ဖြန့်ဝေထားသော ခြေရာခံခြင်းနှင့် မှတ်တမ်းများပါ၀င်သည့် ထီးအသုံးအနှုန်းတစ်ခုဖြစ်သည်။ Service meshes သည် data အမျိုးအစားသုံးမျိုးလုံးကို စုဆောင်းခြင်းနှင့် စီမံဆောင်ရွက်ခြင်းအတွက် ယန္တရားများကို ပေးဆောင်သည်။ ဖြစ်နိုင်ချေရှိသော ရွေးချယ်စရာ အရေအတွက် များလွန်းသဖြင့် အရာများ အနည်းငယ် မှုန်ဝါးသွားသော နေရာဖြစ်သည်။ တိုင်းတာမှုများအတွက်၊ Prometheus နှင့် မှတ်တမ်းများကို စုဆောင်းရန် အခြားကိရိယာများကို အသုံးပြုနိုင်သည်။ ကျွမ်းကျင်စွာ, Loki, အကျုံးဝင်သည်။ နှင့်အခြားသူများ။ (ဥပမာ၊ ကျွန်ုပ်တို့နှင့်အတူ ClickHouse သစ်လုံးအိမ် K8s အတွက် — ဘာသာပြန်သူ၏မှတ်စု)ဖြန့်ဝေခြင်းအတွက် ခြေရာခံခြင်းလည်း ရှိပါသည်။ မုဆိုး စသည်တို့။ ဝန်ဆောင်မှု mesh တစ်ခုစီသည် အချို့သောကိရိယာများကိုသာမက အခြားအရာများကိုပါ ပံ့ပိုးပေးနိုင်ပါသည်။ ပရောဂျက် လုပ်နိုင်မလားဆိုတာ စောင့်ကြည့်ရဦးမှာပါ။ Telemetry ကိုဖွင့်ပါ။ ပေါင်းစည်းမှုကို ပေးစွမ်းသည်။

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

CLI ရှိ ဝန်ဆောင်မှုတစ်ခုမှ အမြီးမှတ်တမ်းများ၊
ဝန်ဆောင်မှု mesh ဒက်ရှ်ဘုတ်မှ တောင်းဆိုမှုပမာဏကို ခြေရာခံပါ။
ဖြန့်ဝေထားသော ခြေရာများကို စုဆောင်းပြီး Jaeger ကဲ့သို့သော စနစ်တစ်ခုသို့ ပေးပို့ပါ။

အာရုံစူးစိုက်မှု ၊ ပုဂ္ဂလဓိဋ္ဌာန်တရား ၊ ယေဘူယျအားဖြင့် ပြောရလျှင် တယ်လီမီတာသည် ဝန်ဆောင်မှု mesh အနှောင့်အယှက်များစွာကို မလိုချင်သော ဧရိယာတစ်ခုဖြစ်သည်။ အောင်မြင်မှုနှုန်းနှင့် latency ကဲ့သို့ အခြေခံအချက်အလက်များကို စုဆောင်းပြီး အချို့သော "ရွှေမက်ထရစ်များ" ကို ခြေရာခံခြင်းသည် ကောင်းမွန်သော်လည်း၊ အချို့သော အထူးပြုစနစ်များကို ကောင်းစွာနားလည်ထားပြီးဖြစ်သော Frankenstein stacks များ ထွက်ပေါ်လာသည်ကို မတွေ့ရတော့ဟု မျှော်လင့်ကြပါစို့။

15. စာရင်းစစ်

TL;DR- သမိုင်းသင်ခန်းစာများကို မေ့သွားသူများသည် ၎င်းတို့ကို ထပ်ခါတလဲလဲလုပ်ရန် ဆုံးခန်းတိုင်မည်ဖြစ်သည်။

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

စာရင်းစစ်သည် telemetry နှင့် အလွန်နီးကပ်စွာ ဆက်စပ်နေကြောင်း ထင်ရှားပါသည်။ ခြားနားချက်မှာ တယ်လီမီတာသည် အများအားဖြင့် စွမ်းဆောင်ရည်နှင့် နည်းပညာပိုင်းဆိုင်ရာ ကြံ့ခိုင်မှုကဲ့သို့သော အရာများနှင့် ဆက်စပ်နေသော်လည်း စာရင်းစစ်သည် တင်းကြပ်သော နည်းပညာနယ်ပယ်ပြင်ပတွင် ကျရောက်နေသည့် ဥပဒေနှင့် အခြားပြဿနာများနှင့် ဆက်စပ်နိုင်သည် (ဥပမာ၊ EU အထွေထွေဒေတာ ကာကွယ်ရေး စည်းမျဉ်းကို လိုက်နာခြင်း)။

16. စိတ်ကူးပုံဖော်ခြင်း။

TL;DR- React.js၊ ထူးဆန်းသော အင်တာဖေ့စ်စမ်းရေတွင်း။

ပိုကောင်းတဲ့အသုံးအနှုန်းတစ်ခုရှိနိုင်ပေမယ့် အဲဒါကို ကျွန်တော်မသိဘူး။ ဝန်ဆောင်မှု mesh သို့မဟုတ် ၎င်း၏ အစိတ်အပိုင်းအချို့၏ ဂရပ်ဖစ်ကိုယ်စားပြုမှုကို ဆိုလိုပါသည်။ ဤမြင်ယောင်ချက်များတွင် ပျမ်းမျှ latencies၊ sidecar container configuration အချက်အလက်၊ ကျန်းမာရေးစစ်ဆေးမှုရလဒ်များနှင့် သတိပေးချက်များကဲ့သို့သော ညွှန်းကိန်းများ ပါဝင်နိုင်သည်။

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

စာရင်းတွင်မပါဝင်ပါ။

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

Multi-ဒေတာစင်တာကျွန်ုပ်စိတ်ထဲတွင်၊ ဤသည်မှာ ကျဉ်းမြောင်းပြီး တိကျသော ဝန်ဆောင်မှုကွက်များ သို့မဟုတ် ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုကဲ့သို့သော အင်္ဂါရပ်အစုံအလင်ကဲ့သို့ အသုံးပြုမှုကိစ္စမျိုးမဟုတ်ပါ။
အဝင်အထွက်. ဤအရာသည် ဆက်စပ်ဧရိယာဖြစ်သည်၊ သို့သော် ကျွန်ုပ်သည် "အရှေ့-အနောက် လမ်းကြောင်း" အသုံးပြုမှုကိစ္စတွင် ကျွန်ုပ်ကိုယ်တိုင် (ဖြစ်ကောင်းဖြစ်နိုင်သည်) ကို ကန့်သတ်ထားသည်။ Ingress နှင့် egress သည် သီးခြားဆောင်းပါးတစ်ခုနှင့် ထိုက်တန်သည်။

ကောက်ချက်

လောလောဆယ်တော့ ဒီလောက်ပါပဲ။ တဖန် ဤစာရင်းသည် အလွန်အခြေအနေအရဖြစ်ပြီး မပြည့်စုံနိုင်ဆုံးဖြစ်နိုင်သည်။ တစ်ခုခု လွဲချော်သွားတယ်လို့ ထင်ရင် ဒါမှမဟုတ် အမှားလုပ်မိရင် Twitter မှာ ဆက်သွယ်ပါ (@lucperkins) စည်းမျဥ်းစည်းကမ်းများကို လိုက်နာပါ။

PS ဘာသာပြန်မှ

ဆောင်းပါးအတွက် အဓိက သရုပ်ဖော်ပုံသည် ဆောင်းပါးမှ ပုံတစ်ပုံကို အခြေခံပြီး “Service Mesh ဆိုတာ ဘာလဲ (နဲ့ တစ်ခုကို ဘယ်အချိန်မှာ သုံးရမလဲ)။" (Gregory MacKinnon မှ) ၎င်းသည် အပလီကေးရှင်းများမှ လုပ်ဆောင်နိုင်စွမ်းအချို့ (အစိမ်းဖြင့်) ၎င်းတို့ကြားချိတ်ဆက်မှုများကို ပံ့ပိုးပေးသည့် service mesh သို့ ရွှေ့ပြောင်းသွားသည်ကို ပြသသည်။

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

source: www.habr.com