လွယ်လွယ်ပြောရရင် Service Discovery ဆိုတာ Microservices တွေက တစ်ယောက်နဲ့တစ်ယောက် လိပ်စာရှာတဲ့ စနစ်ပါ။ App တစ်ခုက အပိုင်းအသေးလေးတွေ အများကြီးနဲ့ ဖွဲ့ထားတဲ့အခါ အပိုင်းတစ်ခုက တခြား အပိုင်းတစ်ခုကို ခေါ်ဖို့ သူ့ လိပ်စာကို သိဖို့ လိုပါတယ်။ ဒါပေမယ့် Cloud ပေါ်မှာ Service တွေက အမြဲ ရွေ့နေတယ်၊ ပွားနေတယ်၊ ကျလိုက် ပြန်တက်လိုက် ဖြစ်နေတယ်။ ဒါကြောင့် လိပ်စာကို စာရွက်ပေါ်မှာ အသေရေးထားလို့ မရပါဘူး။ Service Discovery က အဲဒီလိပ်စာတွေကို အချိန်နဲ့တပြေးညီ ရှာပေးတဲ့ စနစ်ပါ။
ကျွန်တော် ဒါကို နားလည်သွားတာက ဟိုတယ်ကောင်တာနဲ့ ယှဉ်ကြည့်မှပါ။ ဟိုတယ်ကြီးတစ်ခုမှာ ဧည့်သည် အခန်းတွေ ရာချီရှိတယ်။ ဧည့်သည် တစ်ယောက်က တခြားတစ်ယောက်ကို ရှာချင်ရင် အခန်းနံပါတ်ကို အလွတ်မှတ်ထားစရာ မလိုပါဘူး။ ကောင်တာကို သွားမေးလိုက်ရင် ကောင်တာက အခုလက်ရှိ အခန်းနံပါတ်ကို ပြောပေးပါတယ်။ ဧည့်သည် အခန်းပြောင်းသွားရင်တောင် ကောင်တာမှာ စာရင်းက အသစ်ဖြစ်နေမှာပါ။ Service Discovery လည်း ဒီလိုပါပဲ။ Service တစ်ခုချင်းစီက စတင်တဲ့အခါ Registry ဆိုတဲ့ ကောင်တာကြီးမှာ “ကျွန်တော် ဒီမှာ ရှိနေတယ်” လို့ စာရင်းသွင်းပါတယ်။ တခြား Service က ခေါ်ချင်ရင် Registry ကို မေးပြီး လက်ရှိလိပ်စာကို ယူသုံးပါတယ်။
ဥပမာ Food Delivery App တစ်ခုကို ကြည့်ရအောင်။ Order Service၊ Payment Service၊ Restaurant Service၊ Rider Service ဆိုပြီး အပိုင်းတွေ ခွဲထားတယ်ဆိုပါစို့။ ကိုယ်က အစားအစာ မှာလိုက်တဲ့အခါ Order Service က Payment Service ကို ခေါ်ရမယ်။ Payment Service က Server ဘယ်နှစ်လုံးမှာ run နေလဲ၊ IP တွေက ဘာလဲဆိုတာ Order Service က အလွတ်မှတ်ထားစရာ မလိုပါဘူး။ Service Discovery ကနေ မေးယူလိုက်ရုံပါပဲ။ Payment Service အသစ်တစ်လုံး တိုးလာရင်လည်း Registry မှာ အလိုလို စာရင်းဝင်သွားတာမို့ ချက်ချင်း အသုံးပြုလို့ ရပါတယ်။
Service Discovery ဘယ်လို အလုပ်လုပ်လဲ?
စာရင်းသွင်းခြင်း — Service တစ်ခုက စတင်တဲ့အခါ သူ့နာမည်၊ IP၊ Port တို့ကို Registry မှာ သွင်းပါတယ်။ Consul၊ etcd၊ Eureka တို့လို Tool တွေက ဒီ Registry အလုပ်ကို လုပ်ပေးပါတယ်။ Kubernetes သုံးရင် Kubernetes ကိုယ်တိုင်က Service Discovery ပါပြီးသားပါ။
ကျန်းမာရေး စစ်ခြင်း — Registry က Service တွေကို ခဏခဏ “အသက်ရှင်သေးလား” လို့ မေးပါတယ်။ Health Check လို့ ခေါ်ပါတယ်။ ပြန်မဖြေတဲ့ Service ကို စာရင်းကနေ ဖယ်လိုက်ပါတယ်။ ဒါကြောင့် ကျသွားတဲ့ Server ဆီကို ဘယ်သူမှ လမ်းမလွဲတော့ပါဘူး။
ရှာဖွေခြင်း — ခေါ်ချင်တဲ့ Service က Registry ကို မေးပြီး လက်ရှိလိပ်စာစာရင်းကို ရပါတယ်။ ပြီးရင် Load Balancer ပုံစံနဲ့ တစ်လုံးချင်း အလှည့်ကျ ခေါ်ပါတယ်။ Load Balancer အကြောင်း အရင်က ရေးခဲ့ဖူးပါတယ်။
Client-side နဲ့ Server-side — ရှာတဲ့ အလုပ်ကို ခေါ်တဲ့သူဘက်က လုပ်ရင် Client-side၊ ကြားမှာ Router တစ်ခု ခံပြီး သူက ရှာပေးရင် Server-side လို့ ခေါ်ပါတယ်။ အရင်က ရေးခဲ့ဖူးတဲ့ API Gateway က Server-side ပုံစံနဲ့ နီးစပ်ပါတယ်။
ဘာလို့ လိပ်စာအသေ ရေးထားလို့ မရတာလဲ?
Container တွေနဲ့ Cloud မှာ Service တွေက အကြိမ်ကြိမ် ပြန်စတတ်ပါတယ်။ ပြန်စတိုင်း IP အသစ် ရတတ်ပါတယ်။ Auto Scaling ကြောင့် Server အရေအတွက်ကလည်း အချိန်နဲ့အမျှ ပြောင်းနေပါတယ်။ လိပ်စာကို Code ထဲမှာ အသေရေးထားရင် Service ပြန်စတာနဲ့ App ပျက်သွားမှာပါ။ Service Discovery ရှိမှ ဒီလို ရွေ့နေတဲ့ ကမ္ဘာမှာ Service တွေ တစ်ယောက်ကို တစ်ယောက် ရှာတွေ့နေမှာပါ။
ကိုယ်တိုင် နားလည်အောင် စမ်းကြည့်ဖို့
Docker Compose နဲ့ Service နှစ်ခု run ကြည့်ပါ။ တစ်ခုကို Service Name နဲ့ ခေါ်ကြည့်ပါ။ IP အသေမလိုဘဲ Name နဲ့ ချိတ်လို့ရတာကို မြင်ရပါလိမ့်မယ်။
Kubernetes မှာ Service တစ်ခု ဆောက်ကြည့်ပါ။ Pod တွေ ဖျက်ပြီး အသစ်ပေါ်လာလည်း Service Name က မပြောင်းဘူးဆိုတာ စမ်းကြည့်ပါ။
ကိုယ့် App မှာ API URL တွေ အသေရေးထားမိလား ပြန်စစ်ပါ။ Environment Variable နဲ့ ခွဲထားရင် နောက်ပိုင်း Service Discovery ထည့်ဖို့ လွယ်သွားပါလိမ့်မယ်။
Service Discovery က ဘာမှ ခမ်းနားတဲ့ နည်းပညာ မဟုတ်ပါဘူး။ ဖုန်းစာအုပ်ကြီးတစ်အုပ်နဲ့ တူပါတယ်။ ဒါပေမယ့် Microservices တွေ အများကြီးနဲ့ ဖွဲ့ထားတဲ့ App တစ်ခု ရှင်သန်ဖို့ဆိုရင် အဲဒီဖုန်းစာအုပ်လေးက မရှိမဖြစ် လိုအပ်ပါတယ်။ Service တွေ ရှာတွေ့နေသ၍ App က ဆက်အလုပ်လုပ်နေမှာပါ။ 🙂
