"ငါ့ဖိနပ်နဲ့ လမ်းလျှောက်နေတာ" - ခဏနေ၊ အမှတ်အသားပြုထားသလား။

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

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

တကယ့် HighLoad

“Marcus” သည် ပြဿနာများစွာကို ဖြေရှင်းပေးသည်၊ အဓိကမှာ X5 သတင်းအချက်အလက်စနစ်များနှင့် တံဆိပ်တပ်ထားသော ထုတ်ကုန်များအတွက် နိုင်ငံပိုင်အချက်အလက်စနစ် (GIS MP) အကြား ပေါင်းစပ်အပြန်အလှန်တုံ့ပြန်မှုဖြစ်သည်။ ပလပ်ဖောင်းသည် ကျွန်ုပ်တို့ထံမှရရှိသော အညွှန်းကုဒ်များအားလုံးကို သိမ်းဆည်းထားပြီး အရာဝတ္ထုများတစ်လျှောက် ဤကုဒ်များ၏ ရွေ့လျားမှုသမိုင်းတစ်ခုလုံးကိုလည်း သိမ်းဆည်းထားပြီး အညွှန်းတပ်ထားသော ထုတ်ကုန်များကို ပြန်လည်အဆင့်သတ်မှတ်ခြင်းကို ဖယ်ရှားပေးပါသည်။ တံဆိပ်တပ်ထားသော ကုန်ပစ္စည်းအုပ်စုများတွင် ပထမဆုံးပါဝင်သည့် ဆေးရွက်ကြီးထွက်ကုန်များ၏ ဥပမာကို အသုံးပြု၍ စီးကရက်တစ်ဘူးတွင် အထုပ် 600 ခန့်ပါဝင်ပြီး ၎င်းတို့တစ်ခုစီတွင် ကိုယ်ပိုင်ကုဒ်ပါရှိသည်။ ထို့အပြင် ကျွန်ုပ်တို့၏စနစ်၏တာဝန်မှာ ဂိုဒေါင်များနှင့် စတိုးဆိုင်များကြားရှိ သိုလှောင်ရုံများနှင့် စတိုးဆိုင်များကြားရှိ အစုအဝေးတစ်ခုစီ၏ ရွေ့လျားမှုများ၏တရားဝင်မှုကို ခြေရာခံရန်နှင့် နောက်ဆုံးတွင် ဝယ်ယူသူထံ ရောင်းချနိုင်မှုကို အတည်ပြုရန်ဖြစ်သည်။ ထို့အပြင် ကျွန်ုပ်တို့သည် တစ်နာရီလျှင် ငွေသားလွှဲပြောင်းမှု 000 ခန့်ကို မှတ်တမ်းတင်ထားပြီး ထိုကဲ့သို့သော pack တစ်ခုစီသည် စတိုးဆိုင်ထဲသို့ မည်သို့ရောက်ရှိသွားသည်ကို မှတ်တမ်းတင်ရန် လိုအပ်ပါသည်။ ထို့ကြောင့် အရာဝတ္ထုများကြားရှိ ရွေ့လျားမှုအားလုံးကို ထည့်သွင်းတွက်ချက်ပြီး တစ်နှစ်လျှင် မှတ်တမ်းပေါင်း ဘီလီယံနှင့်ချီ၍ မျှော်လင့်လျက်ရှိသည်။

အသင်း အမ်၊

Marcus သည် X5 အတွင်း ပရောဂျက်တစ်ခုဟု ယူဆသော်လည်း၊ ၎င်းကို ထုတ်ကုန်ချဉ်းကပ်မှုဖြင့် အကောင်အထည်ဖော်လျက်ရှိသည်။ အဖွဲ့သည် Scrum အရအလုပ်လုပ်သည်။ ပရောဂျက်ကို ပြီးခဲ့သောနွေရာသီက စတင်ခဲ့သော်လည်း ပထမရလဒ်သည် အောက်တိုဘာလတွင်သာ ထွက်ပေါ်လာသည် - ကျွန်ုပ်တို့၏အဖွဲ့သည် အပြည့်အဝစုဝေးခဲ့ပြီး၊ စနစ်ဗိသုကာကို တီထွင်ခဲ့ပြီး စက်ပစ္စည်းများကို ဝယ်ယူခဲ့သည်။ ယခုအဖွဲ့တွင် လူ ၁၆ ဦးရှိပြီး ၎င်းတို့အနက် ခြောက်ဦးသည် backend နှင့် frontend ဖွံ့ဖြိုးတိုးတက်မှုတွင် ပါဝင်နေပြီး ၎င်းတို့ထဲမှ သုံးဦးသည် စနစ်ခွဲခြမ်းစိတ်ဖြာမှုတွင် ပါဝင်ပါသည်။ လူခြောက်ဦးသည် လူကိုယ်တိုင်၊ ဝန်၊ အလိုအလျောက် စမ်းသပ်ခြင်းနှင့် ထုတ်ကုန်ပြုပြင်ထိန်းသိမ်းခြင်းတွင် ပါဝင်ပါသည်။ ထို့အပြင် ကျွန်ုပ်တို့တွင် SRE အထူးကုတစ်ဦးရှိသည်။

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

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

အဝေးထိန်းအဖွဲ့ အစည်းအဝေး

ဝေးလံခေါင်သီသောအလုပ်တွင် အစည်းအဝေးများ

ဖြေရှင်းချက်၏နည်းပညာအစုအဝေး

X5 အတွက် standard repository နှင့် CI/CD tool သည် GitLab ဖြစ်သည်။ ကျွန်ုပ်တို့သည် ၎င်းကို ကုဒ်သိုလှောင်မှု၊ စဉ်ဆက်မပြတ် စမ်းသပ်ခြင်းနှင့် စမ်းသပ်ထုတ်လုပ်ခြင်း ဆာဗာများသို့ ဖြန့်ကျက်ခြင်းအတွက် အသုံးပြုပါသည်။ အနည်းဆုံး လုပ်ဖော်ကိုင်ဖက် 2 ဦးသည် ကုဒ်နှင့် ဆော့ဖ်ဝဲရေးသားသူမှ ပြုလုပ်သော အပြောင်းအလဲများကို အတည်ပြုရန် လိုအပ်သောအခါတွင် ကျွန်ုပ်တို့သည် ကုဒ်ပြန်လည်သုံးသပ်ခြင်းအလေ့အကျင့်ကိုလည်း အသုံးပြုပါသည်။ Static code ခွဲခြမ်းစိတ်ဖြာသူ SonarQube နှင့် JaCoCo တို့သည် ကျွန်ုပ်တို့၏ကုဒ်ကို သန့်ရှင်းစေပြီး လိုအပ်သော ယူနစ်စမ်းသပ်မှုအဆင့်ကို သေချာစေရန် ကူညီပေးပါသည်။ ကုဒ်သို့ ပြောင်းလဲမှုအားလုံးသည် ဤစစ်ဆေးမှုများမှတစ်ဆင့် လုပ်ဆောင်ရမည်ဖြစ်သည်။ ကိုယ်တိုင်လုပ်ဆောင်သော စမ်းသပ် script များအားလုံးသည် နောက်ပိုင်းတွင် အလိုအလျောက် လုပ်ဆောင်ပါသည်။

"Marcus" မှ စီးပွားရေးလုပ်ငန်းစဉ်များကို အောင်မြင်စွာ အကောင်အထည်ဖော်ရန်အတွက်၊ တစ်ခုချင်းစီအလိုက် နည်းပညာဆိုင်ရာ ပြဿနာများစွာကို ကျွန်ုပ်တို့ ဖြေရှင်းခဲ့ရသည်။

Task 1. စနစ်၏ အလျားလိုက် အတိုင်းအတာ လိုအပ်ချက်

ဤပြဿနာကိုဖြေရှင်းရန် ကျွန်ုပ်တို့သည် ဗိသုကာပညာအတွက် microservice ချဉ်းကပ်နည်းကို ရွေးချယ်ခဲ့သည်။ တစ်ချိန်တည်းမှာပင်၊ ဝန်ဆောင်မှုများ၏ တာဝန်ဝတ္တရားများကို နားလည်ရန် အလွန်အရေးကြီးပါသည်။ လုပ်ငန်းစဉ်များ၏ တိကျသောအချက်အလက်များကို ထည့်သွင်းစဉ်းစားကာ ၎င်းတို့ကို လုပ်ငန်းလည်ပတ်မှုအဖြစ်သို့ ပိုင်းခြားရန် ကျွန်ုပ်တို့ကြိုးစားခဲ့သည်။ ဥပမာအားဖြင့်၊ ဂိုဒေါင်တစ်ခုတွင် လက်ခံခြင်းသည် မကြာခဏမဟုတ်သော်လည်း အလွန်ကြီးမားသော လည်ပတ်မှုဖြစ်ပြီး၊ ထိုကာလအတွင်း ကုန်ပစ္စည်းလက်ခံသည့်ယူနစ်နှင့်ပတ်သက်သည့် ပြည်နယ်စည်းကမ်းထိန်းသိမ်းရေးအဖွဲ့ထံမှ သတင်းအချက်အလက်ကို အမြန်ရယူရန် လိုအပ်သည်၊ တစ်ကြိမ်တွင် ပေးပို့သည့်အရေအတွက်သည် 600000 အထိရောက်ရှိသွားမည်ဖြစ်သည်။ ၊ ဤထုတ်ကုန်ကို ဂိုဒေါင်ထဲသို့ လက်ခံနိုင်မှုကို စစ်ဆေးပြီး ဂိုဒေါင်အလိုအလျောက်စနစ်အတွက် လိုအပ်သော အချက်အလက်အားလုံးကို ပြန်ပို့ပေးပါ။ သို့သော် သိုလှောင်ရုံများမှ တင်ပို့မှုသည် ပိုမိုပြင်းထန်မှုရှိပြီး တစ်ချိန်တည်းတွင် သေးငယ်သောဒေတာပမာဏဖြင့် လုပ်ဆောင်သည်။

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

ပြင်ပစနစ်များနှင့် အပြန်အလှန်တုံ့ပြန်မှုအတွက် မော်ဂျူးများကို သီးခြားဝန်ဆောင်မှုများအဖြစ် ခွဲခြားရန် ဆုံးဖြတ်ခဲ့သည်။ ၎င်းသည် လုပ်ငန်းလုပ်ဆောင်နိုင်စွမ်းရှိသော ဝန်ဆောင်မှုများအပေါ် သက်ရောက်မှုမရှိသလောက် ပြင်ပစနစ်များ၏ မကြာခဏပြောင်းလဲနေသော APIs ပြဿနာကို ဖြေရှင်းနိုင်စေခဲ့သည်။

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

အလုပ် 2။ ပလက်ဖောင်းဝန်ဆောင်မှုများကြားတွင် မြင့်မားသောဝန်နှင့် အလွန်အကြိတ်အနယ် ဒေတာဖလှယ်ရန် လိုအပ်သည်- ပရောဂျက်စတင်သည့်အဆင့်တွင် တစ်စက္ကန့်လျှင် လည်ပတ်မှု 600 ခန့် လုပ်ဆောင်သည်။ လက်လီဆိုင်များသည် ကျွန်ုပ်တို့၏ပလပ်ဖောင်းနှင့်ချိတ်ဆက်ထားသောကြောင့် ဤတန်ဖိုးသည် ops/sec 5000 အထိတိုးလာမည်ဟုမျှော်လင့်ပါသည်။

Kafka အစုအဝေးကို အသုံးပြုပြီး ပလက်ဖောင်း၏ မိုက်ခရိုဝန်ဆောင်မှုများကြား တစ်ပြိုင်နက် အပြန်အလှန် အပြန်အလှန်တုံ့ပြန်မှုကို လုံးဝနီးပါး စွန့်လွှတ်ခြင်းဖြင့် ဤပြဿနာကို ဖြေရှင်းနိုင်ခဲ့သည်။ လုပ်ဆောင်ချက်အားလုံးသည် တပြိုင်နက်တည်းမဟုတ်သောကြောင့် စနစ်လိုအပ်ချက်များကို အလွန်ဂရုတစိုက်ခွဲခြမ်းစိတ်ဖြာရန် လိုအပ်ပါသည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည် ပွဲစားမှတစ်ဆင့် အဖြစ်အပျက်များကို ထုတ်လွှင့်ရုံသာမက လိုအပ်သည့် လုပ်ငန်းဆိုင်ရာ အချက်အလက်အားလုံးကို မက်ဆေ့ခ်ျတွင်ပါ ပေးပို့ပါသည်။ ထို့ကြောင့် မက်ဆေ့ချ်အရွယ်အစားသည် ကီလိုဘိုက်များစွာအထိ ရောက်ရှိနိုင်သည်။ Kafka ရှိ မက်ဆေ့ချ်အရွယ်အစား ကန့်သတ်ချက်သည် ကျွန်ုပ်တို့အား မက်ဆေ့ခ်ျအရွယ်အစားကို တိကျစွာ ခန့်မှန်းရန် လိုအပ်ပြီး လိုအပ်ပါက ၎င်းတို့ကို ပိုင်းခြားရန် လိုအပ်သော်လည်း ခွဲဝေမှုသည် လုပ်ငန်းဆောင်ရွက်မှုများနှင့် ဆက်စပ်နေပါသည်။
ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် ကားတစ်စီးမှရောက်ရှိလာသော ကုန်ပစ္စည်းများကို သေတ္တာများအဖြစ် ပိုင်းခြားပါ။ synchronous လုပ်ဆောင်ချက်များအတွက် သီးခြား microservices များကို ခွဲဝေပေးပြီး နှံ့နှံ့စပ်စပ် load testing ပြုလုပ်ပါသည်။ Kafka ကိုအသုံးပြုခြင်းဖြင့် ကျွန်ုပ်တို့အား နောက်ထပ်စိန်ခေါ်မှုတစ်ခုအနေဖြင့် ပေးအပ်သည် - Kafka ပေါင်းစည်းမှုကို ထည့်သွင်းစဉ်းစားခြင်းဖြင့် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုလုပ်ငန်းလည်ပတ်မှုကို စမ်းသပ်ခြင်းသည် ကျွန်ုပ်တို့၏ယူနစ်စမ်းသပ်မှုအားလုံးကို ပြိုင်တူဖြစ်စေသည်။ Embedded Kafka Broker ကို အသုံးပြု၍ ကျွန်ုပ်တို့၏ကိုယ်ပိုင် အသုံးဝင်နည်းလမ်းများကို ရေးသားခြင်းဖြင့် ဤပြဿနာကို ဖြေရှင်းနိုင်ခဲ့ပါသည်။ ၎င်းသည် တစ်ဦးချင်းနည်းလမ်းများအတွက် ယူနစ်စမ်းသပ်မှုများကို ရေးရန်မလိုအပ်သော်လည်း Kafka ကိုအသုံးပြု၍ ရှုပ်ထွေးသောကိစ္စရပ်များကို ကျွန်ုပ်တို့စမ်းသပ်လိုပါသည်။

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

Task 3. Data အများအပြား သိမ်းဆည်းရန် လိုအပ်သည်- ဆေးလိပ်တစ်ခုတည်းအတွက် တစ်နှစ်လျှင် တံဆိပ်ပေါင်း ၁ ဘီလီယံကျော်သည် X1 သို့ ရောက်လာသည်။ ၎င်းတို့သည် အဆက်မပြတ်နှင့် အမြန်ဝင်ရောက်ရန် လိုအပ်သည်။ စုစုပေါင်း၊ စနစ်သည် ဤတံဆိပ်တပ်ထားသော ကုန်ပစ္စည်းများ၏ လှုပ်ရှားမှုမှတ်တမ်း ၁၀ ဘီလီယံခန့်ကို လုပ်ဆောင်ရမည်ဖြစ်သည်။

တတိယပြဿနာကိုဖြေရှင်းရန် NoSQL ဒေတာဘေ့စ် MongoDB ကိုရွေးချယ်ခဲ့သည်။ ကျွန်ုပ်တို့သည် node 5 ခုကိုတည်ဆောက်ထားပြီး node တစ်ခုစီတွင် ဆာဗာ 3 ခု၏ပုံတူအစုတစ်ခုရှိသည်။ ၎င်းသည် သင့်အား စနစ်အား အလျားလိုက် အတိုင်းအတာ၊ ဆာဗာအသစ်များကို အစုအဝေးသို့ ပေါင်းထည့်ရန်နှင့် ၎င်း၏ အမှားအယွင်းကို ခံနိုင်ရည်ရှိစေရန် သေချာစေသည်။ ဤနေရာတွင် ကျွန်ုပ်တို့သည် နောက်ထပ်ပြဿနာတစ်ခု ကြုံတွေ့ရသည် - အလျားလိုက် အရွယ်စားနိုင်သော မိုက်ခရိုဝန်ဆောင်မှုများကို အသုံးပြုခြင်းကို ထည့်သွင်းစဉ်းစားကာ mongo အစုအဝေးတွင် အရောင်းအ၀ယ်ပြုလုပ်ခြင်းကို သေချာစေပါသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့၏စနစ်၏တာဝန်တစ်ခုမှာ တူညီသောတံဆိပ်ကပ်ထားသောကုဒ်များဖြင့် ထုတ်ကုန်များကို ပြန်လည်ရောင်းချရန် ကြိုးပမ်းမှုများကို ဖော်ထုတ်ရန်ဖြစ်သည်။ ဤတွင်၊ ထပ်ဆင့်များသည် မှားယွင်းသော စကန်ဖတ်ခြင်း သို့မဟုတ် ငွေကိုင်သမားများ၏ မှားယွင်းသော လုပ်ဆောင်မှုများဖြင့် ပေါ်လာပါသည်။ ထိုသို့သော ထပ်တူများကို Kafka batch တစ်ခုတွင် စီမံဆောင်ရွက်နေပြီး နှစ်ခုလုံးတွင် အပြိုင်လုပ်ဆောင်နေမှုများကို တွေ့ရှိရပါသည်။ ထို့ကြောင့်၊ ဒေတာဘေ့စ်ကို မေးမြန်းခြင်းဖြင့် ထပ်တူဖြစ်နေခြင်းအတွက် စစ်ဆေးခြင်းမှာ ဘာတစ်ခုမှ မပေးခဲ့ပါ။ မိုက်ခရိုဝန်ဆောင်မှုတစ်ခုစီအတွက်၊ ဤဝန်ဆောင်မှု၏ လုပ်ငန်းဆိုင်ရာ ယုတ္တိကိုအခြေခံ၍ ပြဿနာကို သီးခြားဖြေရှင်းခဲ့သည်။ ဥပမာအားဖြင့်၊ စစ်ဆေးမှုများအတွက်၊ ကျွန်ုပ်တို့သည် အတွဲအတွင်းတွင် ချက်လက်မှတ်တစ်ခုကို ထည့်သွင်းပြီး ထည့်သွင်းသည့်အခါ ထပ်နေသည့်ပုံသဏ္ဍာန်အတွက် သီးခြားလုပ်ဆောင်ခြင်း။

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

Task 4- တန်းစီခြင်းကို ပြန်လည်လုပ်ဆောင်ခြင်းနှင့် စောင့်ကြည့်ခြင်း-

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

ထိုကဲ့သို့သော အစီအစဉ်ကို အကောင်အထည်ဖော်ရန်၊ ကျွန်ုပ်တို့သည် အောက်ပါတို့ကို လိုအပ်သည်- ဤဖြေရှင်းချက်ကို Spring နှင့် ပေါင်းစပ်ကာ ကုဒ်ပွားခြင်းကို ရှောင်ရှားရန်။ ဝဘ်ကို စီးနင်းနေစဉ် Spring BeanPostProccessor ကိုအခြေခံ၍ အလားတူဖြေရှင်းချက်ကို တွေ့ရှိခဲ့သော်လည်း ကျွန်ုပ်တို့အတွက် မလိုအပ်ဘဲ ခက်ခဲနေပုံရသည်။ ကျွန်ုပ်တို့၏အဖွဲ့သည် သုံးစွဲသူများဖန်တီးရန်အတွက် နွေဦးစက်ဝန်းတွင် ပေါင်းစည်းနိုင်စေမည့် ရိုးရှင်းသောဖြေရှင်းချက်တစ်ခုကို ပြုလုပ်ထားပြီး ထပ်မံ၍ကြိုးစားအသုံးပြုသူများကိုလည်း ထည့်သွင်းထားပါသည်။ Spring team ကို ကျွန်ုပ်တို့၏ဖြေရှင်းချက်၏ ရှေ့ပြေးပုံစံကို ကမ်းလှမ်းခဲ့သည်၊ သင်မြင်နိုင်သည်။ ဒီမှာ. Retry Consumer အရေအတွက်နှင့် စားသုံးသူတစ်ဦးစီအတွက် ကြိုးပမ်းမှုအရေအတွက်သည် လုပ်ငန်းလုပ်ငန်းစဉ်၏လိုအပ်ချက်များပေါ်မူတည်၍ ကန့်သတ်ချက်များဖြင့် စီစဉ်သတ်မှတ်ထားပြီး အရာအားလုံးလုပ်ဆောင်နိုင်စေရန်အတွက် ကျန်ရှိသည့်အရာအားလုံးမှာ org.springframework.kafka.annotation.KafkaListener ကို မှတ်ချက်ထည့်သွင်းရန်ဖြစ်သည်။ Spring developer အားလုံးနှင့်ရင်းနှီးသော၊

ပြန်လည်ကြိုးစားမှုအားလုံးပြီးနောက် မက်ဆေ့ချ်ကို မဆောင်ရွက်နိုင်ပါက Spring DeadLetterPublishingRecoverer ကို အသုံးပြု၍ DLT (စာသေခေါင်းစဉ်) သို့သွားပါမည်။ ပံ့ပိုးကူညီမှုတောင်းဆိုချက်အရ၊ ကျွန်ုပ်တို့သည် ဤလုပ်ဆောင်နိုင်စွမ်းကို တိုးချဲ့ပြီး DLT၊ stackTrace၊ traceId နှင့် ၎င်းတို့နှင့်ပတ်သက်သော အခြားအသုံးဝင်သော အချက်အလက်များတွင် ပါဝင်သော မက်ဆေ့ချ်များကို ကြည့်ရှုနိုင်စေမည့် သီးခြားဝန်ဆောင်မှုတစ်ခုကို ဖန်တီးခဲ့သည်။ ထို့အပြင်၊ စောင့်ကြည့်ခြင်းနှင့်သတိပေးချက်များကို DLT ခေါင်းစဉ်များအားလုံးတွင် ပေါင်းထည့်ခဲ့ပြီး ယခုအခါ၊ တကယ်တော့၊ DLT ခေါင်းစဉ်ရှိ မက်ဆေ့ချ်တစ်ခု၏ အသွင်အပြင်သည် ချို့ယွင်းချက်တစ်ခုကို ခွဲခြမ်းစိတ်ဖြာပြီး ပြုပြင်ရန် အကြောင်းပြချက်တစ်ခုဖြစ်သည်။ ၎င်းသည် အလွန်အဆင်ပြေသည် - ခေါင်းစဉ်အမည်ဖြင့်၊ ပြဿနာ၏ အရင်းခံအကြောင်းတရားရှာဖွေမှုကို သိသိသာသာ အရှိန်မြှင့်ပေးသည့် လုပ်ငန်းစဉ်၏ မည်သည့်အဆင့်တွင် ကျွန်ုပ်တို့ ချက်ချင်းနားလည်ပါသည်။

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

ပလပ်ဖောင်းလည်ပတ်မှု

ပလက်ဖောင်းသည် အကျိုးဖြစ်ထွန်းသော လည်ပတ်မှုတွင်ရှိပြီး၊ ကျွန်ုပ်တို့ နေ့စဉ် ပို့ဆောင်မှုနှင့် ပို့ဆောင်မှုများ လုပ်ဆောင်ကာ ဖြန့်ဖြူးရေးစင်တာများနှင့် စတိုးဆိုင်အသစ်များကို ချိတ်ဆက်ပါ။ လေယာဉ်မှူး၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့်၊ စနစ်သည် "Tobacco" နှင့် "Shoes" ထုတ်ကုန်အုပ်စုများနှင့် အလုပ်လုပ်ပါသည်။

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

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

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

source: www.habr.com