လွယ်လွယ်ပြောရရင် service mesh ဆိုတာ microservices အများကြီး တစ်ခုနဲ့တစ်ခု စကားပြောတဲ့အခါ ကြားကနေ လမ်းညွှန်၊ ထိန်းချုပ်၊ လုံခြုံရေးပေးတဲ့ “ဆက်သွယ်ရေး အလွှာ” တစ်ခု။ Service တိုင်းရဲ့ ဘေးမှာ “sidecar” လို့ခေါ်တဲ့ အကူ program လေး တစ်ခု ကပ်ထားပြီး၊ အဲဒီ sidecar တွေအားလုံးကို ဗဟိုကနေ စည်းမျဉ်းချပေးတာ။
မြို့ကြီးတစ်မြို့ရဲ့ ယာဉ်ထိန်းစနစ်နဲ့ ဥပမာ ပြောရအောင်။ ကားအစီးရေ ထောင်ချီ ပြေးနေတဲ့ မြို့မှာ ကားတစ်စီးချင်းစီက “လမ်းပိတ်ရင် ဘယ်လို ပတ်မောင်းမလဲ၊ မီးပွိုင့်မှာ ဘယ်လို ရပ်မလဲ” ကို ကိုယ့်ဟာကိုယ် ဆုံးဖြတ်နေရရင် ပျားတုပ်သလို ရှုပ်မယ်။ ဒါကြောင့် မီးပွိုင့်၊ လမ်းညွှန်ဆိုင်းဘုတ်၊ ယာဉ်ထိန်းရဲ ဆိုတာ ရှိတာ။ Service mesh ကလည်း ဒီအတိုင်းပဲ — service တွေ (ကားတွေ) အချင်းချင်း စကားပြောတဲ့ request တွေ (လမ်းပေါ်က ကားတွေ) ကို ကြားကနေ ထိန်းပေးတဲ့ စနစ်။
ဘာလို့ လိုလာတာလဲဆိုတော့ microservices များလာတဲ့အခါ ပြဿနာတက်လို့ပဲ။ Service ၃၀ လောက်ရှိတဲ့ system မှာ “A က B ကို ခေါ်တာ မရရင် ၃ ခါ ပြန်ကြိုးစား၊ ၅ စက္ကန့်အတွင်း မရရင် လက်လျှော့” ဆိုတဲ့ logic ကို service ၃၀ လုံးမှာ တစ်ပုံစံတည်း ရေးရတယ်။ တစ်နေ့ စည်းမျဉ်းပြောင်းချင်ရင် code ၃၀ ခု ပြန်ပြင်ရတယ်။ Service mesh ရှိရင် ဒီ logic တွေ အားလုံးကို code ထဲက ထုတ်ပြီး mesh အလွှာမှာ တစ်နေရာတည်း ရေးထားလိုက်တယ်။ Service တွေက business logic ပဲ ရေးရတယ် — “လမ်းပေါ်မှာ ဘယ်လို မောင်းရမယ်” ဆိုတာကို စိတ်မပူရတော့ဘူး။
အလုပ်လုပ်ပုံက ဒီလို။ Service တိုင်းရဲ့ pod ဒါမှမဟုတ် container ဘေးမှာ Envoy လို့ခေါ်တဲ့ sidecar proxy လေး တစ်ခု အလိုလို ကပ်ပါလာတယ်။ Service A က B ကို စကားပြောချင်ရင် တိုက်ရိုက် မပြောဘူး — ကိုယ့်ဘေးက sidecar ကို ပြောတယ်၊ sidecar က B ရဲ့ sidecar ဆီ ပို့တယ်။ ကြားထဲမှာ retry လုပ်၊ timeout ကိုင်၊ လုံခြုံရေး စစ် — အကုန် sidecar က လုပ်ပေးတယ်။ ပြီးတော့ Istio (ဒါမှမဟုတ် Linkerd) ဆိုတဲ့ control plane က “ဘယ် service က ဘယ်ဟာကို ခေါ်လို့ရတယ်၊ ဘယ်လောက် မြန်ရမယ်” ဆိုတဲ့ စည်းမျဉ်းတွေကို sidecar အားလုံးဆီ တစ်ပြိုင်နက် ချပေးတယ်။
ရလာတဲ့ အကျိုးကျေးဇူးတွေ —
Retry, timeout, circuit breaker — service ကျရင် အလိုလို ပတ်လမ်း ရှာပေးတယ်
mTLS — service အချင်းချင်း စကားပြောတာ အလိုလို encrypt ဖြစ်သွားတယ်
Traffic split — version အသစ်ကို လူ ၁၀% ဆီ အရင်လွှတ်တဲ့ canary လုပ်ရလွယ်တယ်
Observability — request တွေ ဘယ်လမ်းသွား၊ ဘယ်မှာ နှေးနေလဲ အလိုလို မြင်ရတယ်
Policy — “payment service ကို checkout service ပဲ ခေါ်လို့ရတယ်” လို စည်းမျဉ်းချလို့ရတယ်
ဒါပေမယ့် သတိထားရမှာက service mesh က “အရွယ်ရောက်ပြီးသား” system တွေအတွက်ပဲ။ Service ၃-၅ ခုလောက်နဲ့ ရနေတဲ့ app မှာ Istio တပ်လိုက်ရင် ဆင်ကြီးကို ရွက်ဖျင်တဲ ဆောက်ပေးသလို ဖြစ်မယ် — ထိန်းရခက်၊ resource စား၊ debug ရခက်။ Service ဆယ်ဂဏန်းကျော်လာမှ၊ “အချင်းချင်း စကားပြောတာ ထိန်းရခက်လာပြီ” လို့ ခံစားရမှ စဉ်းစားပါ။
Microservices က “အပိုင်းပိုင်းခွဲထား” တဲ့ အနုပညာဆိုရင် service mesh က အဲဒီအပိုင်းတွေကြား “စာပို့စနစ်” ကို စနစ်တကျ ထိန်းပေးတဲ့ စာတိုက်ကြီးလို့ မှတ်ထားလိုက်ပါ။ 🙂
