ဆောင်းပါး၏ဘာသာပြန်: သံတမန်ကြိုးချည်ခြင်း မော်ဒယ် - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

ဒီဆောင်းပါးကို အတော်လေး စိတ်ဝင်စားဖို့ကောင်းတာကို တွေ့ခဲ့ရပြီး Envoy ကို "istio" ရဲ့ တစ်စိတ်တစ်ပိုင်းအဖြစ် မကြာခဏ အသုံးပြုလေ့ရှိတဲ့အတွက် kubernetes ရဲ့ "ingress controller" အဖြစ်၊ လူအများစုဟာ ဥပမာအားဖြင့်၊ ဥပမာအားဖြင့်၊ ပုံမှန်အားဖြင့် တူညီတဲ့ တုံ့ပြန်မှုမျိုး မရှိကြပါဘူး။ Nginx သို့မဟုတ် Haproxy ထည့်သွင်းမှုများ။ သို့သော် တစ်ခုခု ကွဲသွားပါက အတွင်းမှ မည်သို့ အလုပ်လုပ်သည်ကို နားလည်ရန် ကောင်းပါသည်။ အထူးစကားလုံးများအပါအဝင် စာသားအများစုကို ရုရှားဘာသာသို့ တတ်နိုင်သမျှ ဘာသာပြန်ရန် ကြိုးစားခဲ့သည်၊ ဒါကိုကြည့်ရတာ နာကျင်ခံစားရသူတွေအတွက် မူရင်းကို ကွင်းစဥ်မှာ ချန်ထားခဲ့တယ်။ ကြောင်မှကြိုဆိုပါတယ်။

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

Envoy နှင့်ပတ်သက်သော ကျွန်ုပ်ရရှိသည့် အတွေ့ရအများဆုံး နည်းပညာဆိုင်ရာမေးခွန်းများထဲမှတစ်ခုမှာ ၎င်းအသုံးပြုသော threading model ၏ အဆင့်နိမ့်ဖော်ပြချက်တစ်ခုတောင်းဆိုခြင်းဖြစ်သည်။ ဤပို့စ်တွင်၊ Envoy သည် ကုဒ်များကို အပြိုင်အဆိုင်နှင့် စွမ်းဆောင်ရည်မြင့်မားစေရန်အတွက် အတွင်းပိုင်း၌ အသုံးပြုထားသည့် Thread Local Storage စနစ်အပြင် Envoy မှ ချိတ်ဆက်မှုများကို မည်သို့မြေပုံဆွဲမည်ကို ဖော်ပြပါမည်။

Threading ခြုံငုံသုံးသပ်ချက်

Envoy သည် မတူညီသော stream အမျိုးအစားသုံးမျိုးကို အသုံးပြုသည်-

အဓိက- ဒီ thread က process startup နဲ့ shutdown လုပ်တာ၊ DNS၊ health checking၊ general cluster နဲ့ runtime management၊ statistics reset၊ administration နဲ့ general process management အပါအဝင် XDS (xDiscovery Service) API processing အားလုံးကို စီမံခန့်ခွဲပါတယ်။ Linux အချက်ပြမှုများ၊ hot restart များ စသည်တို့။ ဤ thread တွင် ဖြစ်ပျက်သမျှသည် asynchronous ဖြစ်ပြီး non-blocking ဖြစ်သည်။ အလုံးစုံပြောရလျှင် main thread သည် CPU ကြီးကြီးမားမား မလိုအပ်သော အရေးကြီးသော လုပ်ငန်းစဉ်အားလုံးကို ညှိနှိုင်းပေးသည်။ ၎င်းသည် control code အများစုကို single-thread ကဲ့သို့ ရေးသားနိုင်စေသည်။
အလုပ်သမား- မူရင်းအားဖြင့်၊ Envoy သည် စနစ်အတွင်းရှိ ဟာ့ဒ်ဝဲကြိုးတစ်ခုစီအတွက် အလုပ်သမားချည်မျှင်တစ်ခုကို ဖန်တီးသည်၊ ၎င်းကို ရွေးချယ်ခွင့်ကို အသုံးပြု၍ ထိန်းချုပ်နိုင်သည်။ --concurrency. အလုပ်သမား လိုင်းတစ်ခုစီသည် နားဆင်သူတိုင်းကို နားထောင်ရန် တာဝန်ရှိသည့် “ပိတ်ဆို့ခြင်းမဟုတ်သော” ဖြစ်ရပ်ကွင်းဆက်တစ်ခုကို လုပ်ဆောင်သည်၊၊ (ဇူလိုင် 29၊ 2017) ရေးသားချိန်တွင် (ဇူလိုင် XNUMX၊ XNUMX) တွင် နားထောင်သူအား ခွဲခြမ်းစိပ်ဖြာခြင်းမရှိပါ၊ ချိတ်ဆက်မှုအသစ်များကို လက်ခံကာ စစ်ထုတ်မှုအစုတစ်ခုကို ချက်ခြင်းလုပ်ဆောင်သည်။ ချိတ်ဆက်မှု၊ ချိတ်ဆက်မှုသက်တမ်းတစ်လျှောက် အဝင်/အထွက် (IO) လည်ပတ်မှုအားလုံးကို လုပ်ဆောင်ခြင်း။ တစ်ဖန်၊ ၎င်းသည် ချိတ်ဆက်မှုဆိုင်ရာ ကုဒ်အများစုကို ကြိုးတစ်ချောင်းတည်းဖြင့် ရေးသားနိုင်စေပါသည်။
File flusher- Envoy ရေးသော ဖိုင်တစ်ခုစီတွင် အဓိကအားဖြင့် မှတ်တမ်းများကို ဝင်ရောက်ကြည့်ရှုသည့် ဖိုင်တစ်ခုစီတွင် လက်ရှိတွင် သီးခြားပိတ်ဆို့ထားသော စာတွဲတစ်ခုရှိသည်။ အဘယ်ကြောင့်ဆိုသော် အသုံးပြုနေချိန်၌ပင် ဖိုင်စနစ်မှ သိမ်းဆည်းထားသော ဖိုင်များသို့ စာရေးခြင်းကြောင့် ဖြစ်သည်။ O_NONBLOCK တစ်ခါတစ်ရံ ပိတ်ဆို့သွားနိုင်သည်။ worker threads သည် ဖိုင်တစ်ခုသို့ စာရေးရန် လိုအပ်သောအခါ၊ data သည် အမှန်တကယ်တွင် ၎င်းကို thread မှတဆင့် ရှင်းထုတ်သွားသည့် memory အတွင်းရှိ ကြားခံတစ်ခုသို့ ရွေ့သွားသည် file flush. ဤသည်မှာ နည်းပညာအရ လုပ်သားချည်မျှင်များအားလုံး မန်မိုရီကြားခံကိုဖြည့်ရန် ကြိုးစားစဉ် တူညီသောလော့ခ်ကို ပိတ်ဆို့နိုင်သည့် ကုဒ်တစ်ခုဖြစ်သည်။

ချိတ်ဆက်မှုကိုင်တွယ်ခြင်း။

အထက်တွင် အကျဉ်းချုံး ဆွေးနွေးခဲ့သည့်အတိုင်း အလုပ်သမား လိုင်းများအားလုံးသည် ခွဲခြမ်းစိတ်ဖြာခြင်းမရှိဘဲ နားထောင်သူအားလုံးကို နားထောင်သည်။ ထို့ကြောင့်၊ kernel သည် လက်ခံထားသော sockets များကို worker thread များသို့ ချောမွေ့စွာ ပေးပို့ရန်အတွက် အသုံးပြုသည်။ ခေတ်မီ kernels များသည် ယေဘုယျအားဖြင့် အလွန်ကောင်းမွန်သည်၊ ၎င်းတို့သည် တူညီသော socket တွင် နားထောင်နေသော အခြား thread များကို အသုံးမပြုမီ thread တစ်ခုအား အလုပ်အားဖြည့်ရန် အဝင်/အထွက် (IO) ဦးစားပေး မြှင့်တင်ခြင်းကဲ့သို့သော အင်္ဂါရပ်များကို အသုံးပြု၍ ၎င်းတို့သည် round robin ကို အသုံးမပြုမီ၊ တောင်းဆိုချက်တစ်ခုစီကို လုပ်ဆောင်ရန် လော့ခ်ချခြင်း (Spinlock)။
အလုပ်သမားချည်မျှင်တွင် ချိတ်ဆက်မှုကို လက်ခံပြီးသည်နှင့် ၎င်းသည် အဆိုပါချည်မျှင်ကို ဘယ်တော့မှ မထားခဲ့ပါ။ ချိတ်ဆက်မှု၏ နောက်ထပ်လုပ်ဆောင်မှုအားလုံးကို ထပ်ဆင့်ပေးပို့ခြင်းအပြုအမူအပါအဝင် အလုပ်သမားချည်မျှင်တွင် လုံးလုံးလျားလျား ကိုင်တွယ်ပါသည်။

ဤသည်မှာ အရေးကြီးသော အကျိုးဆက်များစွာရှိသည်။

Envoy ရှိ ချိတ်ဆက်မှု ပေါင်းကူးကန်အားလုံးကို အလုပ်သမားချည်မျှင်တစ်ခုတွင် တာဝန်ပေးထားသည်။ ထို့ကြောင့် HTTP/2 ချိတ်ဆက်မှုပေါင်းစုများသည် တစ်ကြိမ်လျှင် အထက်စီးကြောင်းရှိ host တစ်ခုစီသို့ ချိတ်ဆက်မှုတစ်ခုသာ ပြုလုပ်သော်လည်း၊ အလုပ်သမားလိုင်း လေးခုရှိပါက၊ တည်ငြိမ်သောအခြေအနေတွင် အထက်စီးကြောင်းရှိ host တစ်ခုလျှင် HTTP/2 ချိတ်ဆက်မှု လေးခုရှိမည်ဖြစ်သည်။
Envoy သည် ဤနည်းလမ်းဖြင့် လုပ်ဆောင်ရခြင်း၏ အကြောင်းရင်းမှာ လုပ်သားချည်မျှင်တစ်ခုတည်းတွင် အရာအားလုံးကို သိမ်းဆည်းထားခြင်းဖြင့်၊ ကုဒ်အားလုံးနီးပါးကို ပိတ်ဆို့ခြင်းမရှိဘဲ ရေးမှတ်နိုင်ပြီး ၎င်းသည် တစ်ခုတည်းသောချည်မျှင်ကဲ့သို့ ဖြစ်နေခြင်းကြောင့်ဖြစ်သည်။ ဤဒီဇိုင်းသည် ကုဒ်များစွာရေးရန် လွယ်ကူစေပြီး အကန့်အသတ်မရှိနီးပါးရှိသော အလုပ်သမားစာကြောင်းများဆီသို့ မယုံနိုင်လောက်အောင် ကောင်းမွန်စွာ ချိန်ညှိပေးသည်။
သို့သော်လည်း၊ အဓိက မှတ်သားစရာများထဲမှ တစ်ခုမှာ memory pool နှင့် connection efficiency ရှုထောင့်မှ၊ ၎င်းကို configure လုပ်ရန် အမှန်တကယ် အရေးကြီးပါသည်။ --concurrency. အလုပ်သမား လိုင်းများ လိုအပ်သည်ထက် ပိုများနေခြင်းသည် မှတ်ဉာဏ်ကို ဖြုန်းတီးမည်ဖြစ်ပြီး၊ ရပ်နားထားသော ချိတ်ဆက်မှုများ ပိုမိုဖန်တီးနိုင်ကာ ချိတ်ဆက်မှုပေါင်းစည်းမှုနှုန်းကို လျှော့ချပေးမည်ဖြစ်သည်။ Lyft တွင်၊ ကျွန်ုပ်တို့၏ အထူးသံတမန် ဆိုက်ကားကွန်တိန်နာများသည် အလွန်နိမ့်ကျသော တူညီသောငွေကြေးဖြင့် လည်ပတ်နေသောကြောင့် စွမ်းဆောင်ရည်သည် ၎င်းတို့ဘေးတွင်ရှိသော ဝန်ဆောင်မှုများနှင့် အကြမ်းအားဖြင့် ကိုက်ညီပါသည်။ ကျွန်ုပ်တို့သည် Envoy ကို အများဆုံး တူညီသော ငွေကြေးဖြင့်သာ edge proxy အဖြစ် လုပ်ဆောင်ပါသည်။

ပိတ်ဆို့ခြင်းမပြုခြင်းဟူသည် အဘယ်နည်း။

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

သံတမန်သည် ရှည်လျားသော လုပ်ငန်းစဉ်လော့ခ်များစွာကို အသုံးပြုသည်-

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

ချည်မျှင်စက်တွင်းသိုလှောင်မှု

Envoy သည် ပင်မချည်မျှင်၏ တာဝန်များကို အလုပ်သမားချည်မျှင်၏ တာဝန်များနှင့် ခွဲထုတ်ပုံကြောင့်၊ ရှုပ်ထွေးသော လုပ်ငန်းစဉ်ကို ပင်မချည်မျှင်တွင် လုပ်ဆောင်နိုင်ပြီး အလုပ်သမားချည်မျှင်တစ်ခုစီအား အလွန်တပြိုင်နက်တည်း ပံ့ပိုးပေးရန် လိုအပ်ပါသည်။ ဤကဏ္ဍတွင် Envoy Thread Local Storage (TLS) ကို မြင့်မားသောအဆင့်တွင် ဖော်ပြထားပါသည်။ နောက်အပိုင်းတွင် အစုအဖွဲ့တစ်ခုကို စီမံခန့်ခွဲရန် ၎င်းကိုအသုံးပြုပုံကို ဖော်ပြပါမည်။

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

Envoy ၏ TLS (Thread local storage) စနစ်သည် အောက်ပါအတိုင်း အလုပ်လုပ်ပါသည်။

ပင်မစာတွဲတွင် လုပ်ဆောင်နေသော ကုဒ်သည် လုပ်ငန်းစဉ်တစ်ခုလုံးအတွက် TLS အပေါက်တစ်ခုကို ခွဲဝေပေးနိုင်ပါသည်။ ၎င်းသည် abstract ဖြစ်သော်လည်း လက်တွေ့တွင် ၎င်းသည် O(1) ဝင်ရောက်မှုကို ပံ့ပိုးပေးသည့် vector တစ်ခုသို့ အညွှန်းတစ်ခုဖြစ်သည်။
ပင်မချည်မျှင်သည် ၎င်း၏အထိုင်တွင် မတရားသောဒေတာကို ထည့်သွင်းနိုင်သည်။ ၎င်းကို ပြီးသောအခါ၊ ဒေတာကို ပုံမှန်ဖြစ်ရပ် ကွင်းဆက်ဖြစ်ရပ်အဖြစ် အလုပ်သမားချည်မျှင်တစ်ခုစီထံ လွှင့်တင်မည်ဖြစ်သည်။
အလုပ်သမား စာတွဲများကို ၎င်းတို့၏ TLS အပေါက်မှ ဖတ်နိုင်ပြီး ထိုနေရာတွင် ရရှိနိုင်သည့် မည်သည့် thread-local data ကိုမဆို ထုတ်ယူနိုင်သည်။

၎င်းသည် အလွန်ရိုးရှင်းပြီး မယုံနိုင်လောက်အောင် အားကောင်းသည့် ပါရာဒိုင်းတစ်ခုဖြစ်သော်လည်း၊ ၎င်းသည် RCU (Read-Copy-Update) ပိတ်ဆို့ခြင်းသဘောတရားနှင့် အလွန်ဆင်တူသည်။ အခြေခံအားဖြင့်၊ အလုပ်လုပ်ကိုင်နေစဉ် TLS အပေါက်များရှိ ဒေတာပြောင်းလဲမှုများကို အလုပ်သမား လိုင်းများမှ မည်သည့်အခါမျှ မတွေ့ရ။ အလုပ်ကိစ္စများကြားတွင် ကျန်အချိန်အတွင်းသာ အပြောင်းအလဲ ဖြစ်ပေါ်ပါသည်။

Envoy သည် ၎င်းကို မတူညီသောနည်းလမ်းနှစ်ခုဖြင့် အသုံးပြုသည်-

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

Cluster update threading

ဤကဏ္ဍတွင်၊ အစုအဖွဲ့တစ်ခုကို စီမံခန့်ခွဲရန် TLS (Thread local storage) ကို မည်သို့အသုံးပြုကြောင်း ဖော်ပြပါမည်။ အစုအဝေးစီမံခန့်ခွဲမှုတွင် xDS API နှင့်/သို့မဟုတ် DNS လုပ်ဆောင်ခြင်းအပြင် ကျန်းမာရေးစစ်ဆေးခြင်းလည်း ပါဝင်သည်။

Cluster flow Management တွင် အောက်ပါ အစိတ်အပိုင်းများနှင့် အဆင့်များ ပါဝင်သည်-

Cluster Manager သည် Envoy အတွင်းရှိ အစိတ်အပိုင်းတစ်ခုဖြစ်ပြီး လူသိများသော အစုအဝေးအထက်ပိုင်းများ၊ Cluster Discovery Service (CDS) API၊ Secret Discovery Service (SDS) နှင့် Endpoint Discovery Service (EDS) APIs၊ DNS နှင့် လုပ်ဆောင်နေသော ပြင်ပစစ်ဆေးမှုများ။ ကျန်းမာရေးစစ်ဆေးခြင်း။ ရှာဖွေတွေ့ရှိထားသော hosts များအပြင် ကျန်းမာရေးအခြေအနေများပါ၀င်သော upstream cluster တစ်ခုစီ၏ "နောက်ဆုံးတွင် တသမတ်တည်း" မြင်ကွင်းဖန်တီးရန် တာဝန်ရှိပါသည်။
ကျန်းမာရေးစစ်ဆေးသူသည် တက်ကြွသောကျန်းမာရေးစစ်ဆေးမှုကို လုပ်ဆောင်ပြီး ကျန်းမာရေးအခြေအနေပြောင်းလဲမှုများကို အစုအဖွဲ့မန်နေဂျာထံ အစီရင်ခံသည်။
CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS ကို အစုအဖွဲ့အဖွဲ့ဝင်အဖြစ် ဆုံးဖြတ်ရန် လုပ်ဆောင်ပါသည်။ အခြေအနေပြောင်းလဲမှုကို အစုအဖွဲ့မန်နေဂျာထံ ပြန်ပေးသည်။
အလုပ်သမားချည်မျှင်တစ်ခုစီသည် ဖြစ်ရပ်ကွင်းဆက်တစ်ခုကို စဉ်ဆက်မပြတ်လုပ်ဆောင်သည်။
အစုအဖွဲ့မန်နေဂျာသည် အစုအဝေးတစ်ခုအတွက် အခြေအနေ ပြောင်းလဲသွားကြောင်း ဆုံးဖြတ်သောအခါ၊ ၎င်းသည် အစုအဝေး၏ အခြေအနေ၏ ဖတ်သာမြင်သာသော လျှပ်တစ်ပြက်အသစ်တစ်ခုကို ဖန်တီးပြီး ၎င်းအား အလုပ်သမားတိုင်းသို့ ပေးပို့သည်။
လာမည့်တိတ်ဆိတ်သောကာလတွင်၊ အလုပ်သမားချည်မျှင်သည် ခွဲဝေချထားပေးသည့် TLS အပေါက်တွင် လျှပ်တစ်ပြက်ရိုက်ချက်အား အပ်ဒိတ်လုပ်မည်ဖြစ်သည်။
လက်ခံသူအား ချိန်ခွင်လျှာတင်ရန်အတွက် လက်ခံဆောင်ရွက်ပေးမည့် I/O ပွဲတစ်ခုအတွင်း၊ ဝန်ချိန်ခွင်လျှာသည် host နှင့်ပတ်သက်သည့် အချက်အလက်ကိုရယူရန် TLS (Thread local storage) slot တစ်ခု တောင်းဆိုမည်ဖြစ်သည်။ ဒါကသော့ခလောက်မလိုအပ်ပါဘူး။ TLS သည် ချိန်ခွင်လျှာတင်သည့် ချိန်ခွင်လျှာများနှင့် အခြားအစိတ်အပိုင်းများကို ကက်ရှ်များ၊ ဒေတာတည်ဆောက်ပုံများ စသည်တို့ကို ပြန်လည်တွက်ချက်နိုင်စေရန် အပ်ဒိတ်ဖြစ်ရပ်များကို အစပျိုးနိုင်သည်ကို သတိပြုပါ။ ၎င်းသည် ဤပို့စ်၏ ဘောင်ကျော်လွန်သော်လည်း ကုဒ်ရှိ နေရာအမျိုးမျိုးတွင် အသုံးပြုသည်။

အထက်ဖော်ပြပါလုပ်ထုံးလုပ်နည်းကိုအသုံးပြုခြင်းဖြင့် Envoy သည် တောင်းဆိုမှုတိုင်းကို ပိတ်ဆို့ခြင်းမရှိဘဲ (ယခင်ဖော်ပြခဲ့သည့်အတိုင်း) ဆောင်ရွက်ပေးနိုင်သည်။ TLS ကုဒ်ကိုယ်တိုင်၏ ရှုပ်ထွေးမှုအပြင်၊ ကုဒ်အများစုသည် multithreading အလုပ်လုပ်ပုံနှင့် single-threaded ရေးသားနိုင်သည်ကို နားလည်ရန်မလိုအပ်ပါ။ ၎င်းသည် ပိုမိုကောင်းမွန်သောစွမ်းဆောင်ရည်အပြင် ကုဒ်အများစုကို ရေးရန်ပိုမိုလွယ်ကူစေသည်။

TLS ကိုအသုံးပြုသည့် အခြားစနစ်ခွဲများ

TLS (Thread local storage) နှင့် RCU (Read Copy Update) ကို Envoy တွင် တွင်ကျယ်စွာ အသုံးပြုပါသည်။

အသုံးပြုမှုဥပမာ:

လုပ်ဆောင်နေစဉ်အတွင်း လုပ်ဆောင်နိုင်စွမ်းကို ပြောင်းလဲရန်အတွက် ယန္တရား- လက်ရှိဖွင့်ထားသည့် လုပ်ဆောင်နိုင်စွမ်းစာရင်းကို ပင်မစာတွဲတွင် တွက်ချက်ထားသည်။ ထို့နောက် RCU ဝေါဟာရကို အသုံးပြု၍ အလုပ်သမားစာတွဲတစ်ခုစီကို ဖတ်ရန်-သပ်သပ်လျှပ်တစ်ပြက်ရိုက်ချက်တစ်ခု ပေးသည်။
လမ်းကြောင်းဇယားများကို အစားထိုးခြင်း။RDS (Route Discovery Service) မှ ပံ့ပိုးပေးသော လမ်းကြောင်းဇယားများအတွက်) လမ်းကြောင်းဇယားများကို ပင်မစာတွဲတွင် ဖန်တီးထားသည်။ RCU (Read Copy Update) ဟူသော ဝေါဟာရကို အသုံးပြု၍ လုပ်သားလိုင်းတစ်ခုစီသို့ ဖတ်ရန်သီးသန့် လျှပ်တစ်ပြက်ရိုက်ချက်အား နောက်ပိုင်းတွင် ပေးအပ်သွားပါမည်။ ၎င်းသည် လမ်းကြောင်းဇယားများကို အက်တမ်ပြောင်းလဲခြင်းအား ထိရောက်စွာလုပ်ဆောင်စေသည်။
HTTP ခေါင်းစီး သိမ်းဆည်းခြင်း- ထွက်ပေါ်လာသည့်အတိုင်း၊ တောင်းဆိုချက်တစ်ခုစီအတွက် HTTP ခေါင်းစီးကို တွက်ချက်ခြင်း (core တစ်ခုလျှင် ~25K+ RPS RPS ကို အသုံးပြုနေစဉ်) သည် အလွန်စျေးကြီးသည်။ အထူးကိုယ်စားလှယ်သည် စက္ကန့်ဝက်တိုင်း ခေါင်းစီးအား ဗဟိုမှတွက်ချက်ပြီး TLS နှင့် RCU မှတစ်ဆင့် အလုပ်သမားတစ်ဦးစီအား ပေးသည်။

အခြားကိစ္စများရှိပါသည်၊ သို့သော်ယခင်နမူနာများသည် TLS ကိုဘာအတွက်အသုံးပြုသည်ကို ကောင်းစွာနားလည်သဘောပေါက်သင့်သည်။

စွမ်းဆောင်ရည် ချို့ယွင်းချက်များကို သိရှိသည်။

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

ဤဆောင်းပါးတွင် ဖော်ပြထားသည့်အတိုင်း၊ လက်ရှိတွင် အလုပ်သမား လိုင်းများအားလုံးသည် access log memory buffer သို့ စာရေးသည့်အခါ လော့ခ်တစ်ခု ရရှိပါသည်။ မြင့်မားသော ပေါင်းစပ်ငွေကြေးနှင့် မြင့်မားသော သွင်းအားစုတွင်၊ သင်သည် နောက်ဆုံးဖိုင်သို့ စာရေးသောအခါတွင် အမိန့်ပြင်ပသို့ ပေးပို့ခြင်းအတွက် အသုံးစရိတ်ဖြင့် အလုပ်သမားချည်စာတစ်ခုစီအတွက် ဝင်ရောက်ခွင့်မှတ်တမ်းများကို အစုလိုက်ပြုလုပ်ရန် လိုအပ်ပါသည်။ တနည်းအားဖြင့် သင်သည် အလုပ်သမားချည်နှောင်မှုတစ်ခုစီအတွက် သီးခြားဝင်ရောက်ခွင့်မှတ်တမ်းတစ်ခုကို ဖန်တီးနိုင်သည်။
စာရင်းအင်းများကို အလွန်ကောင်းမွန်အောင်ပြုလုပ်ထားသော်လည်း၊ အလွန်မြင့်မားသော တူညီသောငွေကြေးနှင့် ဖြတ်သန်းမှုတွင် တစ်ဦးချင်းစာရင်းဇယားများအပေါ် အဏုမြူအငြင်းပွားမှုဖြစ်နိုင်ဖွယ်ရှိသည်။ ဤပြဿနာအတွက် ဖြေရှင်းချက်မှာ ဗဟိုကောင်တာများကို အချိန်အခါအလိုက် ပြန်လည်သတ်မှတ်ခြင်းနှင့်အတူ အလုပ်သမားချည်နှောင်မှုတစ်ခုစီဖြစ်သည်။ ဒါကို နောက်ပို့စ်တစ်ခုမှာ ဆွေးနွေးပါမယ်။
သိသာထင်ရှားသော လုပ်ဆောင်ခြင်းဆိုင်ရာ အရင်းအမြစ်များ လိုအပ်သည့် ချိတ်ဆက်မှု အလွန်နည်းသည့် အခြေအနေတွင် Envoy ကို အသုံးပြုပါက လက်ရှိ ဗိသုကာလက်ရာသည် ကောင်းစွာ အလုပ်မဖြစ်ပါ။ ချိတ်ဆက်မှုများကို အလုပ်သမား လိုင်းများကြားတွင် အညီအမျှ ခွဲဝေပေးမည်ဟု အာမခံချက် မရှိပါ။ အလုပ်သမားအသိုင်းအ၀ိုင်းများကြား ချိတ်ဆက်မှုများကို ဖလှယ်နိုင်စေမည့် လုပ်သားချိတ်ဆက်မှု ချိန်ခွင်လျှာကို အကောင်အထည်ဖော်ခြင်းဖြင့် ၎င်းကို ဖြေရှင်းနိုင်ပါသည်။

နိဂုံး

Envoy ၏ threading model ကို မှန်ကန်စွာ မပြင်ဆင်ပါက ဖြုန်းတီးနိုင်သည့် memory နှင့် connections များကို အသုံးစရိတ်ဖြင့် ပရိုဂရမ်ရေးဆွဲရာတွင် လွယ်ကူပြီး ကြီးမားသော ပြိုင်တူပြိုင်ဖက်များကို ပံ့ပိုးပေးရန် ဒီဇိုင်းထုတ်ထားသည်။ ဤပုံစံသည် အလွန်မြင့်မားသော thread count နှင့် throughput တွင် ကောင်းမွန်စွာလုပ်ဆောင်နိုင်စေပါသည်။
Twitter တွင် ကျွန်ုပ်အကျဉ်းချုံးပြောခဲ့သည့်အတိုင်း၊ ဒီဇိုင်းသည် DPDK (Data Plane Development Kit) ကဲ့သို့သော သုံးစွဲသူမုဒ် ကွန်ရက်ချိတ်ဆက်မှုအစုစု၏ထိပ်တွင် ဒီဇိုင်းကို လုပ်ဆောင်နိုင်ပြီး သမားရိုးကျဆာဗာများသည် L7 လုပ်ဆောင်ချက်အပြည့်ဖြင့် တစ်စက္ကန့်လျှင် တောင်းဆိုချက်သန်းပေါင်းများစွာကို ကိုင်တွယ်နိုင်စေပါသည်။ လာမည့်နှစ်အနည်းငယ်အတွင်း မည်သည့်အရာများ ဆောက်လုပ်မည်ကို ကြည့်ရှုရန် အလွန်စိတ်ဝင်စားဖွယ်ကောင်းပါသည်။
နောက်ဆုံး အမြန်မှတ်ချက်တစ်ခု- Envoy အတွက် C++ ကို ဘာကြောင့် ရွေးချယ်ခဲ့တာလဲ အကြိမ်ကြိမ် မေးဖူးပါတယ်။ ဤပို့စ်တွင် ဖော်ပြထားသော ဗိသုကာလက်ရာကို တည်ဆောက်နိုင်သည့် တစ်ခုတည်းသော အသုံးများသည့် စက်မှုအဆင့်ဘာသာစကားဖြစ်နေဆဲ အကြောင်းရင်းမှာ ကျန်ရှိနေပါသည်။ C++ သည် ပရောဂျက်အားလုံး သို့မဟုတ် အများအပြားအတွက် မသင့်လျော်သော်လည်း အချို့သောအသုံးပြုမှုကိစ္စများတွင် ၎င်းသည် အလုပ်ပြီးမြောက်ရန် တစ်ခုတည်းသောကိရိယာဖြစ်နေဆဲဖြစ်သည်။