ကျွန်ုပ်တို့သည် monolithic အက်ပလီကေးရှင်းမှ microservices ဗိသုကာတစ်ခုသို့ ကူးပြောင်းလာသည်နှင့်အမျှ၊ ကျွန်ုပ်တို့သည် စိန်ခေါ်မှုအသစ်များနှင့် ရင်ဆိုင်ရသည်။

monolithic အပလီကေးရှင်းတစ်ခုတွင်၊ အမှားအယွင်းဖြစ်သွားသောစနစ်၏အစိတ်အပိုင်းကိုဆုံးဖြတ်ရန်အတော်လေးလွယ်ကူသည်။ အများစုမှာ ပြဿနာမှာ monolith ၏ code ထဲတွင် သို့မဟုတ် database တွင်ဖြစ်သည်။ ဒါပေမယ့် မိုက်ခရိုဝန်ဆောင်မှုဗိသုကာမှာ ပြဿနာတစ်ခုကို စရှာတဲ့အခါ၊ အရာအားလုံးက သိပ်မသိသာတော့ပါဘူး။ တောင်းဆိုမှု အစမှ အဆုံးအထိ လုပ်ဆောင်ခဲ့သည့် လမ်းကြောင်းတစ်ခုလုံးကို ရှာဖွေပြီး ရာနှင့်ချီသော microservices များမှ ၎င်းကို ရွေးချယ်ရန် လိုအပ်ပါသည်။ ထို့အပြင်၊ ၎င်းတို့အများစုတွင် ယုတ္တိအမှားများအပြင် စွမ်းဆောင်ရည်နှင့် အမှားခံနိုင်ရည်ရှိမှုဆိုင်ရာ ပြဿနာများကိုလည်း ဖြစ်စေနိုင်သည့် ၎င်းတို့၏ ကိုယ်ပိုင်သိုလှောင်မှု အဆောက်အဦများလည်း ရှိပါသည်။

ဒီလိုပြဿနာတွေကို ကိုင်တွယ်ဖြေရှင်းနိုင်မယ့် ကိရိယာတစ်ခုကို ကျွန်တော် ရှာနေတာ ကြာပါပြီ (ဒီအကြောင်းကို Habré မှာ ရေးခဲ့တယ်- 1, 2) ဒါပေမယ့် နောက်ဆုံးမှာတော့ ကျွန်တော်ဟာ ကိုယ်ပိုင် open source ဖြေရှင်းချက်ကို လုပ်ခဲ့တယ်။ ဤဆောင်းပါးတွင် ကျွန်ုပ်သည် ဝန်ဆောင်မှု mesh ချဉ်းကပ်မှု၏ အကျိုးကျေးဇူးများအကြောင်း ပြောဆိုပြီး ၎င်း၏ အကောင်အထည်ဖော်မှုအတွက် ကိရိယာအသစ်တစ်ခုကို မျှဝေပါသည်။

Distributed tracing သည် ဖြန့်ဝေမှုစနစ်များတွင် အမှားအယွင်းများကို ရှာဖွေခြင်းပြဿနာအတွက် ဘုံဖြေရှင်းချက်တစ်ခုဖြစ်သည်။ သို့သော် ကွန်ရက်အပြန်အလှန်ဆက်သွယ်မှုများအကြောင်း အချက်အလက်စုဆောင်းခြင်းနည်းလမ်းကို စနစ်တွင် အကောင်အထည်မဖော်သေးပါက၊ သို့မဟုတ် ပိုဆိုးသည်မှာ စနစ်၏တစ်စိတ်တစ်ပိုင်းတွင် ၎င်းသည် ကောင်းမွန်စွာအလုပ်လုပ်နေပြီဖြစ်သော်လည်း တစ်စိတ်တစ်ပိုင်းအားဖြင့် ၎င်းသည် ဝန်ဆောင်မှုအဟောင်းများသို့ မထည့်ရသေးသောကြောင့် ၎င်းသည် မည်သို့မျှမဖြစ်နိုင်ပါ။ ? ပြဿနာတစ်ခု၏ အရင်းခံအကြောင်းအရင်းအတိအကျကို ဆုံးဖြတ်ရန်၊ စနစ်တွင်ဖြစ်ပျက်နေသည့်အရာများကို ပြီးပြည့်စုံသောပုံရှိရန် လိုအပ်သည်။ စီးပွားရေးအတွက် အရေးကြီးသောလမ်းကြောင်းများတွင် မည်သည့် microservices များ ပါဝင်နေသည်ကို နားလည်ရန် အထူးအရေးကြီးပါသည်။

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

ဆားဗစ်ကွက်တွေ များလာတယ်။

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

ဖြေရှင်းချက်

ဤချဉ်းကပ်နည်းကို အကောင်အထည်ဖော်မှုများစွာ ရှိနှင့်ပြီးဖြစ်သည်။ Istio и linkerd2. ၎င်းတို့သည် ဘောက်စ်ပြင်ပတွင် အင်္ဂါရပ်များစွာကို ပံ့ပိုးပေးသည်။ သို့သော် တစ်ချိန်တည်းတွင် အရင်းအမြစ်များပေါ်တွင် ကြီးမားသော အကျုံးဝင်မှု ရှိလာပါသည်။ ထို့အပြင်၊ ထိုသို့သောစနစ်လည်ပတ်သည့် အစုအဝေးကြီးလေ၊ အခြေခံအဆောက်အအုံသစ်ကို ထိန်းသိမ်းရန် အရင်းအမြစ်များ ပိုမိုလိုအပ်လာမည်ဖြစ်သည်။ Avito တွင်၊ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှု သာဓကများ ထောင်နှင့်ချီ ပါဝင်သော kubernetes အစုအဝေးများကို လုပ်ဆောင်သည် (၎င်းတို့၏ အရေအတွက်သည် လျင်မြန်စွာ တိုးလာသည်)။ ၎င်း၏ လက်ရှိအကောင်အထည်ဖော်မှုတွင်၊ Istio သည် ဝန်ဆောင်မှုတစ်ခုလျှင် 300Mb RAM ကိုသုံးစွဲသည်။ ဖြစ်နိုင်ခြေ အများအပြားကြောင့်၊ ပွင့်လင်းသော ချိန်ခွင်လျှာသည် ဝန်ဆောင်မှုများ၏ အလုံးစုံ တုံ့ပြန်ချိန် (10ms အထိ) ကိုလည်း သက်ရောက်မှုရှိပါသည်။

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

ထို့ကြောင့် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ ဆုံးဖြတ်ချက်ကို ချမှတ်ခဲ့သည်-  Netramesh.

Netramesh

Netramesh စနစ်အတွင်းရှိ ဝန်ဆောင်မှုအရေအတွက်ကို မခွဲခြားဘဲ အကန့်အသတ်မရှိ အတိုင်းအတာအထိ အတိုင်းအတာအထိ ပေါ့ပါးသော ဝန်ဆောင်မှု mesh ဖြေရှင်းချက်တစ်ခုဖြစ်သည်။

ဖြေရှင်းချက်အသစ်၏ အဓိကပန်းတိုင်များမှာ အရင်းအမြစ်နိမ့်ကျခြင်းနှင့် စွမ်းဆောင်ရည်မြင့်မားခြင်း တို့ဖြစ်သည်။ အဓိကအင်္ဂါရပ်များထဲတွင်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ Jaeger စနစ်သို့ ခြေရာခံခြင်းအပိုင်းများကို ပွင့်လင်းမြင်သာစွာ ချက်ချင်းပေးပို့နိုင်လိုပါသည်။

ယနေ့တွင်၊ cloud ဖြေရှင်းချက်အများစုကို Golang တွင်အကောင်အထည်ဖော်သည်။ ပြီးတော့ ဒီအတွက် အကြောင်းပြချက်တွေရှိတယ်။ Golang တွင် I/O နှင့် တပြိုင်တည်းလုပ်ဆောင်ပြီး လိုအပ်သလို cores များတစ်လျှောက် စကေးများကို အဆင်ပြေပြေနှင့် အတော်လေးရိုးရှင်းသော Golang တွင် ကွန်ရက်အက်ပ်လီကေးရှင်းများရေးသားခြင်း။ နောက်ပြီး အရမ်းအရေးကြီးတာက ဒီပြဿနာကို ဖြေရှင်းဖို့ စွမ်းဆောင်ရည်က လုံလောက်ပါတယ်။ အဲဒါကြောင့်လည်း Golang ကို ရွေးချယ်ခဲ့ပါတယ်။

ထွက်နိုင်ရေး

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

ဘယ်လိုရလဒ်တွေ ရခဲ့လဲ ကြည့်ရအောင်။

ရမ်

Netramesh သည် အသွားအလာမရှိဘဲ ~10Mb စားသုံးပြီး 50Mb အများဆုံး 10000Mb ကို ဥပမာတစ်ခုလျှင် XNUMX RPS အထိ သုံးစွဲသည်။

Istio အထူးကိုယ်စားလှယ်ပရောက်စီသည် သာဓကပေါင်းထောင်ပေါင်းများစွာရှိသော ကျွန်ုပ်တို့၏အစုအဝေးများတွင် ~300Mb အမြဲစားသုံးသည်။ ၎င်းသည် ၎င်းအား အစုအဝေးတစ်ခုလုံးသို့ ချိန်ညှိရန် ခွင့်မပြုပါ။

Netramesh ဖြင့် ကျွန်ုပ်တို့သည် မှတ်ဉာဏ်သုံးစွဲမှု ~ 10 ဆ လျှော့ချနိုင်ခဲ့သည်။

စီပီယူ

CPU အသုံးပြုမှုသည် Load အောက်တွင် အတော်လေး တူညီပါသည်။ ဆိုက်ကားဆီသို့ အချိန်ယူနစ်တစ်ခုအတွက် တောင်းဆိုမှုအရေအတွက်ပေါ်တွင် မူတည်သည်။ အမြင့်ဆုံးတွင် တစ်စက္ကန့်လျှင် တောင်းဆိုမှု 3000 တွင် တန်ဖိုးများ-

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

ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုများကြား ဆက်သွယ်ရေးအတွက် HTTP/1 ကို အသုံးပြုပါသည်။ သံတမန်မှတစ်ဆင့် proxying လုပ်သည့်အခါ Istio အတွက် တုံ့ပြန်ချိန်တိုးလာမှုသည် 5-10ms အထိရှိပြီး၊ ၎င်းသည် မီလီစက္ကန့်အတွင်း တုံ့ပြန်ရန်အဆင်သင့်ဖြစ်နေသော ဝန်ဆောင်မှုများအတွက် အလွန်များပြားပါသည်။ Netramesh ဖြင့် ဤအချိန်သည် 0.5-2ms သို့ လျော့ကျသွားသည်။

အပေါ်ယံ

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

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

Netramesh သည် ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုအတွက် နောက်ထပ်ယန္တရားများကို မထည့်ပါ။ ယာဉ်အသွားအလာအားလုံးကို netra sidecar မှတဆင့် ပွင့်လင်းမြင်သာစွာ ပို့ဆောင်ပေးပါသည်။

Netramesh သည် HTTP/1 အပလီကေးရှင်းပရိုတိုကောကို ပံ့ပိုးပေးသည်။ ၎င်းကို သတ်မှတ်ရန်၊ ပြင်ဆင်နိုင်သော ဆိပ်ကမ်းများစာရင်းကို အသုံးပြုသည်။ ပုံမှန်အားဖြင့်၊ စနစ်တွင် HTTP ဆက်သွယ်မှုဖြစ်ပေါ်သည့် port အများအပြားရှိသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုများနှင့် ပြင်ပတောင်းဆိုမှုများကြား အပြန်အလှန်အကျိုးသက်ရောက်မှုအတွက် 80၊ 8890၊ 8080 ကိုအသုံးပြုပါသည်။ ဤကိစ္စတွင်၊ ၎င်းတို့ကို ပတ်ဝန်းကျင်ပြောင်းလဲမှုတစ်ခုအသုံးပြု၍ သတ်မှတ်နိုင်သည်။ NETRA_HTTP_PORTS.

အကယ်၍ သင်သည် Kubernetes ကို တီးမှုတ်သူနှင့် ဝန်ဆောင်မှုများကြား အစုအဝေးအတွင်း ဆက်သွယ်မှု အတွက် ၎င်း၏ ဝန်ဆောင်မှု အဖွဲ့အစည်း ယန္တရားကို အသုံးပြုပါက၊ ယန္တရားသည် အတူတူပင် ဖြစ်သည်။ ပထမဦးစွာ၊ microservice သည် kube-dns ကို အသုံးပြု၍ ဝန်ဆောင်မှု IP လိပ်စာကို ရယူပြီး ၎င်းနှင့်ချိတ်ဆက်မှုအသစ်ကို ဖွင့်ပေးသည်။ ဤချိတ်ဆက်မှုကို ဒေသခံ netra-sidecar ဖြင့် ပထမဆုံးတည်ဆောက်ထားပြီး TCP ပက်ကေ့ခ်ျအားလုံးသည် ကနဦးတွင် netra သို့ ရောက်ရှိသည်။ ထို့နောက်၊ netra-sidecar သည် မူလဦးတည်ရာနှင့် ချိတ်ဆက်မှုတစ်ခုကို တည်ဆောက်သည်။ node ပေါ်ရှိ pod IP ပေါ်ရှိ NAT သည် netra မပါဘဲနှင့် အတိအကျတူညီနေပါသည်။

ဖြန့်ဝေထားသော ခြေရာခံခြင်းနှင့် အကြောင်းအရာ ထပ်ဆင့်ပို့ခြင်း။

Netramesh သည် HTTP အပြန်အလှန်တုံ့ပြန်မှုများအကြောင်း ခြေရာခံခြင်းအပိုင်းများကို ပေးပို့ရန် လိုအပ်သောလုပ်ဆောင်နိုင်စွမ်းကို ပေးသည်။ Netra-sidecar သည် HTTP ပရိုတိုကောကို ခွဲခြမ်းစိတ်ဖြာပြီး၊ တောင်းဆိုမှုနှောင့်နှေးမှုများကို တိုင်းတာပြီး HTTP ခေါင်းစီးများမှ လိုအပ်သော အချက်အလက်များကို ထုတ်ယူသည်။ နောက်ဆုံးတွင်၊ Jaeger စနစ်တစ်ခုတည်းတွင် ခြေရာများအားလုံးကို ကျွန်ုပ်တို့ရရှိမည်ဖြစ်သည်။ အနုစိတ်ဖွဲ့စည်းပုံအတွက်၊ တရားဝင်စာကြည့်တိုက်မှ ပံ့ပိုးပေးထားသော ပတ်ဝန်းကျင်ပြောင်းလွဲချက်များကိုလည်း အသုံးပြုနိုင်သည်။ jaeger စာကြည့်တိုက်သွားပါ။.

ဒါပေမယ့် ပြဿနာတစ်ခုရှိတယ်။ ဝန်ဆောင်မှုများသည် အထူး uber ခေါင်းစီးကို ထုတ်ပေးပြီး ပေးပို့ခြင်းမပြုမချင်း၊ စနစ်တွင် ချိတ်ဆက်ထားသော ခြေရာခံခြင်းအပိုင်းများကို ကျွန်ုပ်တို့ တွေ့ရမည်မဟုတ်ပါ။ ပြီးတော့ ဒါက ပြဿနာတွေရဲ့ အကြောင်းရင်းကို မြန်မြန်ရှာဖို့ လိုတယ်။ ဤတွင် Netramesh တွင်အဖြေတစ်ခုရှိသည်။ Proxies များသည် HTTP ခေါင်းစီးများကိုဖတ်ပြီး၊ ၎င်းတို့တွင် uber ခြေရာကောက် ID မပါဝင်ပါက၊ တစ်ခုထုတ်ပေးပါ။ Netramesh သည် sidecar တွင် အဝင်အထွက်တောင်းဆိုမှုများအကြောင်း အချက်အလက်များကို သိမ်းဆည်းထားပြီး လိုအပ်သော အထွက်တောင်းဆိုမှု ခေါင်းစီးများဖြင့် ၎င်းတို့အား ဖြည့်စည်းပေးခြင်းဖြင့် ၎င်းတို့နှင့် ကိုက်ညီပါသည်။ ဝန်ဆောင်မှုများတွင် သင်လုပ်ဆောင်ရန်မှာ ခေါင်းစီးတစ်ခုသာ ပေးပို့ရန်ဖြစ်သည်။ X-Request-Idပတ်ဝန်းကျင် ကိန်းရှင်ကို အသုံးပြု၍ ပြင်ဆင်သတ်မှတ်နိုင်သည်။ NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh ရှိ အကြောင်းအရာ၏ အရွယ်အစားကို ထိန်းချုပ်ရန်၊ သင်သည် အောက်ပါ ပတ်ဝန်းကျင် ကိန်းရှင်များကို သတ်မှတ်နိုင်သည်။ NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (အကြောင်းအရာကို သိမ်းဆည်းမည့်အချိန်) နှင့် NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (အကြောင်းအရာရှင်းလင်းမှုအကြိမ်ရေ)။

အထူး session token ဖြင့် အမှတ်အသားပြုခြင်းဖြင့် သင့်စနစ်ရှိ လမ်းကြောင်းများစွာကို ပေါင်းစပ်နိုင်သည်။ Netra သည်သင့်အားတပ်ဆင်ရန်ခွင့်ပြုသည်။ HTTP_HEADER_TAG_MAP HTTP ခေါင်းစီးများကို သက်ဆိုင်ရာ tracing span တဂ်များအဖြစ် ပြောင်းလဲရန်။ ၎င်းသည် စမ်းသပ်ခြင်းအတွက် အထူးအသုံးဝင်နိုင်သည်။ လုပ်ဆောင်ချက်ဆိုင်ရာ စမ်းသပ်မှုအောင်မြင်ပြီးနောက်၊ သက်ဆိုင်ရာ စက်ရှင်သော့ဖြင့် စစ်ထုတ်ခြင်းဖြင့် စနစ်၏ မည်သည့်အစိတ်အပိုင်းကို ထိခိုက်ခဲ့ကြောင်း သင်တွေ့မြင်နိုင်ပါသည်။

Request Source ကို သတ်မှတ်ခြင်း။

တောင်းဆိုချက်သည် မည်သည့်နေရာမှ လာသည်ကို ဆုံးဖြတ်ရန်၊ အရင်းအမြစ်နှင့် ခေါင်းစီးကို အလိုအလျောက် ထည့်ခြင်း၏ လုပ်ဆောင်ချက်ကို သင်အသုံးပြုနိုင်ပါသည်။ ပတ်ဝန်းကျင် ကိန်းရှင်ကို အသုံးပြုခြင်း။ NETRA_HTTP_X_SOURCE_HEADER_NAME အလိုအလျောက် ထည့်သွင်းမည့် ခေါင်းစီးအမည်ကို သင် သတ်မှတ်နိုင်သည်။ အသုံးပြုခြင်းဖြင့် NETRA_HTTP_X_SOURCE_VALUE အထွက်တောင်းဆိုမှုအားလုံးအတွက် X-Source ခေါင်းစီးကို သတ်မှတ်ပေးမည့် တန်ဖိုးကို သင်သတ်မှတ်နိုင်သည်။

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

အသွားအလာလမ်းကြောင်းနှင့် Netramesh အတွင်းပိုင်း

Netramesh တွင် အဓိက အစိတ်အပိုင်း နှစ်ခု ပါဝင်သည်။ ပထမဆုံး၊ netra-init သည် traffic ကိုကြားဖြတ်ရန် ကွန်ရက်စည်းမျဉ်းများကို သတ်မှတ်သည်။ သူသုံးလိုက်သည် iptables စည်းမျဉ်းများကို ပြန်ညွှန်းသည်။ Netramesh ၏ဒုတိယအဓိကအစိတ်အပိုင်းဖြစ်သည့် sidecar ပေါ်ရှိအသွားအလာအားလုံးသို့မဟုတ်တစ်စိတ်တစ်ပိုင်းကိုကြားဖြတ်ရန်။ အဝင်နှင့်အထွက် TCP ဆက်ရှင်များအတွက် ကြားဖြတ်ဟန့်တားရမည့် port များကို သင် configure လုပ်နိုင်ပါသည်။ INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

ကိရိယာတွင် စိတ်ဝင်စားဖွယ်ကောင်းသော အင်္ဂါရပ်တစ်ခုလည်း ပါရှိသည်။ ခြေရာခံခြင်းအပိုင်းများကို စုဆောင်းရန်အတွက် သီးသန့် Netramesh ကို အသုံးပြုပါက၊ ထုတ်လုပ်မှုပတ်ဝန်းကျင်တွင် သင်သည် အရင်းအမြစ်များကို ချွေတာနိုင်ပြီး ကိန်းရှင်များကို အသုံးပြု၍ ဖြစ်နိုင်ခြေရှိသောလမ်းကြောင်းကို ဖွင့်နိုင်သည် NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 မှ 1)။ မူရင်းတန်ဖိုးသည် 1 (အသွားအလာအားလုံးကို ကြားဖြတ်ထားသည်)။

အောင်မြင်စွာ ကြားဖြတ်နားထောင်ပြီးနောက်၊ netra sidecar သည် ချိတ်ဆက်မှုအသစ်ကို လက်ခံပြီး အသုံးပြုသည်။ SO_ORIGINAL_DST မူရင်းဦးတည်ရာကိုရယူရန် socket ရွေးချယ်မှု။ ထို့နောက် Netra သည် မူလ IP လိပ်စာသို့ ချိတ်ဆက်မှုအသစ်တစ်ခုဖွင့်ပြီး ပါတီများကြား ဖြတ်သန်းသွားသော အသွားအလာအားလုံးကို နားထောင်ကာ နှစ်လမ်းသွား TCP ဆက်သွယ်ရေးကို ထူထောင်သည်။ ဆိပ်ကမ်းကို HTTP အဖြစ် သတ်မှတ်ပါက၊ Netra သည် ၎င်းကို ခွဲခြမ်းစိပ်ဖြာရန် ကြိုးစားသည်။ HTTP ခွဲခြမ်းစိတ်ဖြာမှု မအောင်မြင်ပါက၊ Netra သည် TCP သို့ ပြန်ကျသွားပြီး bytes များကို ပွင့်လင်းမြင်သာစွာ proxy လုပ်ပေးသည်။

မှီခိုဂရပ်ကိုတည်ဆောက်ခြင်း။

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

အကယ်၍ သင်သည် ခြေရာခံခြင်းအပိုင်းများကို သိမ်းဆည်းရန် Elasticsearch ကိုအသုံးပြုနေပါက၊ သင်သည် အသုံးပြုနိုင်သည်။ ရိုးရှင်းသော Golang အသုံးဝင်မှုElasticsearch ၏ အင်္ဂါရပ်များနှင့် လုပ်ဆောင်နိုင်စွမ်းများကို အသုံးပြု၍ မိနစ်ပိုင်းအတွင်း တူညီသောဂရပ်ကို တည်ဆောက်ပေးမည်ဖြစ်သည်။

Netramesh အသုံးပြုနည်း

Netra ကို သံစုံတီးဝိုင်းလုပ်သည့် မည်သည့်ဝန်ဆောင်မှုတွင်မဆို အလွယ်တကူ ထည့်သွင်းနိုင်သည်။ ဥပမာတစ်ခုကြည့်နိုင်ပါတယ်။ ဒီမှာ.

လောလောဆယ်တွင်၊ Netra သည် ဝန်ဆောင်မှုများအတွက် ဆိုက်ကားများကို အလိုအလျောက်အကောင်အထည်ဖော်နိုင်စွမ်းမရှိသော်လည်း အကောင်အထည်ဖော်ရန် အစီအစဉ်များရှိပါသည်။

Netramesh ၏အနာဂတ်

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

အနာဂတ်တွင်၊ Netramesh သည် HTTP မှလွဲ၍ အခြားသော အပလီကေးရှင်းအလွှာပရိုတိုကောများကို ပံ့ပိုးပေးမည်ဖြစ်သည်။ L7 လမ်းကြောင်းကို မကြာမီကာလအတွင်း ရနိုင်ပါမည်။

အလားတူပြဿနာများကြုံတွေ့ပါက Netramesh ကိုအသုံးပြုပြီး မေးခွန်းများနှင့် အကြံပြုချက်များဖြင့် ကျွန်ုပ်တို့ထံ စာရေးပါ။

source: www.habr.com