Kafka ရှိ asynchronous API ဖြင့် ပြန်အမ်းငွေတူးလ် ဝန်ဆောင်မှုကို ဖန်တီးရာတွင် အတွေ့အကြုံ

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

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

မသက်ဆိုင်ကြောင်းရှင်းလင်းချက်- ဤဆောင်းပါးသည် HighLoad++ တွင် 2018 ခုနှစ် နိုဝင်ဘာလတွင် Sergey ကျင်းပခဲ့သော အစည်းအဝေးမှ အကြောင်းအရာများကို အခြေခံထားသည်။ Kafka နှင့် အလုပ်လုပ်သည့် Lamoda ၏ တိုက်ရိုက်အတွေ့အကြုံသည် အချိန်ဇယားရှိ အခြားအစီရင်ခံစာများထက် နားထောင်သူများကို ဆွဲဆောင်ခဲ့သည်။ ဤအရာသည် သင်စိတ်တူကိုယ်တူလူများကို အမြဲရှာဖွေနိုင်ပြီး HighLoad++ ၏စီစဉ်သူများသည် ၎င်းအတွက် သင့်လျော်သောလေထုကိုဖန်တီးရန် ဆက်လက်ကြိုးစားသွားမည့်အချက်၏ အကောင်းဆုံးဥပမာတစ်ခုဖြစ်သည်။

ဖြစ်စဉ်အကြောင်း

Lamoda သည် ၎င်း၏ကိုယ်ပိုင်အဆက်အသွယ်စင်တာ၊ ပေးပို့ခြင်းဝန်ဆောင်မှု (လုပ်ငန်းခွဲများစွာ)၊ ဓာတ်ပုံစတူဒီယို၊ ဂိုဒေါင်ကျယ်ကြီးတစ်ခုနှင့် ၎င်း၏ကိုယ်ပိုင်ဆော့ဖ်ဝဲလ်ပေါ်တွင် လုပ်ဆောင်သည့် ကြီးမားသော e-commerce ပလပ်ဖောင်းတစ်ခုဖြစ်သည်။ ငွေပေးချေမှုနည်းလမ်း ဒါဇင်များစွာရှိပါတယ်၊ b2b ပါတနာများသည် ဤဝန်ဆောင်မှုအချို့ သို့မဟုတ် အားလုံးကို အသုံးပြုပြီး ၎င်းတို့၏ထုတ်ကုန်များနှင့်ပတ်သက်သော နောက်ဆုံးပေါ်အချက်အလက်များကို သိရှိလိုသော bXNUMXb ပါတနာများဖြစ်သည်။ ထို့အပြင် Lamoda သည် ရုရှားဖက်ဒရေးရှင်းမှလွဲ၍ နိုင်ငံသုံးနိုင်ငံ၌ လည်ပတ်နေပြီး အရာအားလုံးမှာ အနည်းငယ်ကွဲပြားသည်။ စုစုပေါင်း၊ အမှာစာအသစ်ကို စီစဉ်သတ်မှတ်ရန် နည်းလမ်းပေါင်း တစ်ရာကျော်ရှိနိုင်သည်၊ ၎င်းကို ၎င်း၏ကိုယ်ပိုင်နည်းလမ်းဖြင့် လုပ်ဆောင်ရမည်ဖြစ်သည်။ ဤအရာအားလုံးသည် တစ်ခါတစ်ရံတွင် ထင်ထင်ရှားရှားမဟုတ်သော နည်းလမ်းများဖြင့် ဆက်သွယ်နိုင်သည့် ဒါဇင်ပေါင်းများစွာသော ဝန်ဆောင်မှုများ၏အကူအညီဖြင့် လုပ်ဆောင်သည်။ အဓိကတာဝန်ရှိမှုမှာ အမိန့်အဆင့်အတန်းများရှိသည့် ဗဟိုစနစ်လည်း ရှိပါသည်။ ငါတို့သူမကို BOB လို့ခေါ်တယ်၊ ငါသူမနဲ့အလုပ်လုပ်တယ်။

ဖြစ်ရပ်များ-မောင်းနှင်သော API ဖြင့် ပြန်အမ်းသည့်ကိရိယာ

Events-driven ဟူသော စကားလုံးသည် အတော်လေး hackneyed ဖြစ်သည်၊ ၎င်းကို ဆိုလိုသည့် အဓိပ္ပါယ်ကို နောက်ထပ်အသေးစိတ် ထပ်မံဖော်ပြပါမည်။ Kafka ရှိ ဖြစ်ရပ်များ မောင်းနှင်သည့် API ချဉ်းကပ်မှုကို စမ်းကြည့်ရန် ဆုံးဖြတ်ခဲ့သည့် အကြောင်းအရာနှင့် စတင်ပါမည်။

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

ဒါပေမယ့် ဥပဒေအပြောင်းအလဲတွေကြောင့် ပြန်ရတာ ပိုရှုပ်ထွေးလာပြီး အဲဒါအတွက် သီးခြား microservice တစ်ခုကို အကောင်အထည်ဖော်ခဲ့ရပါတယ်။

ကျွန်ုပ်တို့၏လှုံ့ဆော်မှု-

1. ဥပဒေ FZ-54 - အတိုချုပ်ပြောရလျှင် ဥပဒေသည် မိနစ်အနည်းငယ်အတွင်း SLA တိုတောင်းသော SLA တစ်ခုအတွင်း ငွေကြေးလွှဲပြောင်းမှုတိုင်း၊ ပြေစာဖြစ်စေ၊ ပြေစာဖြစ်စေ အခွန်ရုံးသို့ အစီရင်ခံရန် လိုအပ်သည်။ ကျွန်ုပ်တို့သည် e-commerce ကုမ္ပဏီတစ်ခုအနေဖြင့် လုပ်ငန်းဆောင်ရွက်မှုများစွာကို ဆောင်ရွက်ပါသည်။ နည်းပညာအရ၊ ၎င်းသည် တာဝန်သစ် (ထို့ကြောင့် ဝန်ဆောင်မှုအသစ်) နှင့် ပတ်သက်သည့် စနစ်များအားလုံးတွင် တိုးတက်မှုများကို ဆိုလိုသည်။
2. BOB ကွဲသွားတယ်။ BOB ၏ အဓိကမဟုတ်သောတာဝန်ဝတ္တရားများမှ ကင်းလွတ်စေရန်နှင့် ၎င်း၏ အလုံးစုံရှုပ်ထွေးမှုကို လျှော့ချရန် ကုမ္ပဏီတွင်း ပရောဂျက်တစ်ခုဖြစ်သည်။

ဤပုံကြမ်းသည် အဓိက Lamoda စနစ်များကို ပြသထားသည်။ အခု အများစုက ပိုများတယ်။ ကျုံ့နေသော monolith ပတ်လည်တွင် 5-10 microservices ကြယ်စုတစ်ခု. ၎င်းတို့သည် တဖြည်းဖြည်းကြီးထွားလာသော်လည်း အလယ်တွင်ရွေးချယ်ထားသောအပိုင်းအစကို ဖြန့်ကျက်ချထားခြင်းသည် ကြောက်စရာကောင်းသောကြောင့် ၎င်းတို့ကို သေးငယ်အောင်ပြုလုပ်ရန် ကျွန်ုပ်တို့ကြိုးစားနေပါသည်။ ကျွန်ုပ်တို့သည် လဲလှယ်မှုအားလုံး (မြှားများ) ကို သီးသန့်ထားရန် ခိုင်းစေကာ ၎င်းတို့ထဲမှ တစ်ခုမှ မရရှိနိုင်တော့ကြောင်း ထည့်သွင်းစဉ်းစားပါသည်။

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

နည်းပညာအရ BOB သည်-

• ကုဒ်၏ ~ 150k လိုင်းများ + စမ်းသပ်မှု ~ 100k လိုင်းများ။
• php7.2 + Zend 1 & Symfony Components 3;
• > 100 APIs & ~50 အပြင်ထွက်ပေါင်းစည်းမှုများ။
• ၄င်းတို့သည် ကိုယ်ပိုင်စီးပွားရေး ယုတ္တိရှိသော နိုင်ငံဖြစ်သည်။

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

Return Process

ကနဦးတွင်၊ BOB နှင့် ငွေပေးချေမှု လုပ်ငန်းစဉ်တွင် စနစ်နှစ်ခု ပါဝင်ပါသည်။ ယခု နောက်ထပ် နှစ်ခုပေါ်လာသည်-

• ပြင်ပဝန်ဆောင်မှုများနှင့် ဆက်သွယ်မှုဆိုင်ရာ ပြဿနာများကို ဂရုစိုက်ပေးမည့် Fiscalization Service။
• BOB ကို မဖောင်းပွစေရန် ရိုးရှင်းစွာ လဲလှယ်မှုအသစ်များပါရှိသော ငွေပြန်အမ်းသည့်ကိရိယာ။

ယခု လုပ်ငန်းစဉ်သည် ဤကဲ့သို့ ဖြစ်ပုံရသည်။

1. BOB သည် ပြန်အမ်းငွေအတွက် တောင်းဆိုချက်ကို လက်ခံရရှိသည် ။
2. BOB က ဒီ Refund Tool အကြောင်း ဆွေးနွေးထားပါတယ်။
3. ပြန်အမ်းငွေတူးလ်က ငွေပေးချေမှုကို ပြောသည်- “ငွေပြန်ပေး”။
4. ငွေပေးချေမှုက ငွေကို ပြန်ပေးပါတယ်။
5. ပြန်အမ်းငွေတူးလ်နှင့် BOB သည် လက်ရှိအခြေအနေများကို ၎င်းတို့နှစ်ဦးစလုံး လိုအပ်သောကြောင့် အချင်းချင်း ထပ်တူပြုပါသည်။ BOB တွင် UI ရှိပြီး စာရင်းကိုင်ဆိုင်ရာ အစီရင်ခံစာများနှင့် ယေဘုယျအားဖြင့် အလွယ်တကူ လွှဲပြောင်းမရနိုင်သည့် ဒေတာအများအပြားရှိသောကြောင့် ပြန်အမ်းငွေတူးလ်သို့ လုံးလုံးပြောင်းရန် ကျွန်ုပ်တို့ အဆင်သင့်မဖြစ်သေးပါ။ ကုလားထိုင်နှစ်လုံးပေါ်ထိုင်ရမယ်။
6. ဘဏ္ဍာငွေတောင်းခံမှု မရှိတော့ပါ။

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် အရာအားလုံးစတင်ခဲ့သည့် Kafka - event-bus တွင် event bus တစ်မျိုးကို ပြုလုပ်ခဲ့သည်။ ဟားရေ၊ အခု ကျွန်တော်တို့မှာ ကျရှုံးမှု (sarcasm) တစ်ခုတည်းရှိတယ်။

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

Event-driven API ဆိုတာဘာလဲ

ဤမေးခွန်းအတွက် အဖြေကောင်းတစ်ခုသည် Martin Fowler (GOTO 2017) ၏ အစီရင်ခံစာတွင် ရှိသည်။ "ဖြစ်ရပ်-မောင်းနှင်သော ဗိသုကာ၏ အဓိပ္ပါယ်များစွာ".

အတိုချုံးပြီး ကျွန်တော်တို့ လုပ်ခဲ့တာတွေ၊

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

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

ပြန်အမ်းငွေ တူးလ် ဝန်ဆောင်မှု မတင်ပါ။ထို့ကြောင့် Kafka သည် လိုအပ်သည်ထက် ဘောပင်၏အရသာက ပိုမှန်သည်။ ပြန်အမ်းငွေဝန်ဆောင်မှုသည် မြင့်မားသောပရောဂျက်တစ်ခုဖြစ်လာပါက လုပ်ငန်းသည် ပျော်ရွှင်မည်ဟု မထင်ပါ။

Async လဲလှယ်မှု AS IS

asynchronous ဖလှယ်မှုများအတွက် PHP ဌာနသည် များသောအားဖြင့် RabbitMQ ကို အသုံးပြုသည်။ တောင်းဆိုချက်အတွက် ဒေတာကို ကျွန်ုပ်တို့ စုဆောင်းပြီး တန်းစီထားကာ တူညီသော ဝန်ဆောင်မှုကို အသုံးပြုသူက ၎င်းကို ဖတ်ပြီး ပေးပို့ခြင်း (သို့မဟုတ် မပို့ခဲ့ပါ)။ API ကိုယ်တိုင်အတွက်၊ Lamoda သည် Swagger ကိုတက်ကြွစွာအသုံးပြုသည်။ ကျွန်ုပ်တို့သည် API တစ်ခုကို ဒီဇိုင်းဆွဲကာ Swagger တွင် ဖော်ပြကာ သုံးစွဲသူနှင့် ဆာဗာကုဒ်ကို ထုတ်လုပ်ပါသည်။ ကျွန်ုပ်တို့သည် အနည်းငယ်အဆင့်မြှင့်ထားသော JSON RPC 2.0 ကိုလည်း အသုံးပြုပါသည်။

အချို့နေရာများတွင် ESB ဘတ်စ်ကားများကို အသုံးပြုကြပြီး အချို့မှာ activeMQ တွင် နေထိုင်ကြသော်လည်း ယေဘုယျအားဖြင့်၊ RabbitMQ - စံ.

Async လဲလှယ်မှု TO BE

ဖြစ်ရပ်များ-ဘတ်စ်မှတစ်ဆင့် ဖလှယ်ခြင်းကို ဒီဇိုင်းဆွဲသည့်အခါ၊ ဥပမာတစ်ခုအား ခြေရာခံနိုင်သည်။ ကျွန်ုပ်တို့သည် ဖြစ်ရပ်ဖွဲ့စည်းပုံဖော်ပြချက်များမှတစ်ဆင့် အနာဂတ်ဒေတာဖလှယ်မှုကို အလားတူဖော်ပြပါသည်။ yaml ဖော်မတ်၊ ကျွန်ုပ်တို့ကိုယ်တိုင်ကုဒ်ထုတ်လုပ်ခြင်းကိုလုပ်ဆောင်ရမည်ဖြစ်ပြီး၊ ဂျင်နရေတာသည် သတ်မှတ်ချက်များအရ DTO များကိုဖန်တီးကာ သုံးစွဲသူများနှင့်ဆာဗာများကို ၎င်းတို့နှင့်အလုပ်လုပ်ရန် သင်ကြားပေးသည်။ မျိုးဆက်သည် ဘာသာစကားနှစ်မျိုးသို့ ပြောင်းလဲသွားသည်- golang နှင့် php. ၎င်းသည် စာကြည့်တိုက်များကို တသမတ်တည်းရှိနေစေရန် ကူညီပေးသည်။ ဂျင်နရေတာအား ဂိုလန်ဖြင့် ရေးသားထားသောကြောင့် ဂေါဂီဟူသော အမည်ကို ရခဲ့သည်။

Kafka တွင် Event-sourcing သည် ပုံမှန်အရာတစ်ခုဖြစ်သည်။ Kafka Confluent ၏အဓိကလုပ်ငန်းဗားရှင်းမှအဖြေတစ်ခုရှိပါသည်။ nakadiကျွန်ုပ်တို့၏ဒိုမိန်းညီအစ်ကို Zalando မှဖြေရှင်းချက်။ ကျွန်တော်တို့ရဲ့ vanilla Kafka ဖြင့်စတင်ရန်လှုံ့ဆော်မှု - ဤသည်မှာ နေရာတိုင်းတွင် အသုံးပြုမည်လား မဆုံးဖြတ်မချင်း ဖြေရှင်းချက်အား အခမဲ့ ချန်ထားခဲ့ကာ လေ့ကျင့်မှုနှင့် တိုးတက်မှုများအတွက် မိမိကိုယ်ကို ချန်ထားခဲ့သည်- ကျွန်ုပ်တို့၏ ပံ့ပိုးကူညီမှုကို လိုချင်ပါသည်။ JSON RPC 2.0ဘာသာစကားနှစ်ခုအတွက် ဂျင်နရေတာများနှင့် အခြားဘာကို ကြည့်ကြပါစို့။

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

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

အဲ့ဒါနဲ့ ဘတ်စ်ကား

ဒါမှမဟုတ် ပွဲအတွက် ဘတ်စ်ကား။ ဤသည်မှာ ရိုးရှင်းစွာပင် နိုင်ငံမဲ့ http gateway ဖြစ်ပြီး၊ အရေးကြီးသော အခန်းကဏ္ဍများစွာကို လုပ်ဆောင်သည်-

• ထုတ်လုပ်ခြင်း Validation — ပွဲများသည် ကျွန်ုပ်တို့၏ သတ်မှတ်ချက်များနှင့် ကိုက်ညီမှုရှိမရှိ စစ်ဆေးပါ။
• ပွဲမာစတာစနစ်ဆိုလိုသည်မှာ၊ ဤသည်မှာ မည်သည့်ဖွဲ့စည်းပုံများနှင့် အကျုံးဝင်သည်ဟု ယူဆသနည်းဟူသော မေးခွန်းကို ဖြေပေးသည့် ကုမ္ပဏီရှိ အဓိကနှင့် တစ်ခုတည်းသော စနစ်ဖြစ်သည်။ မှန်ကန်ကြောင်း အတည်ပြုခြင်းသည် အကြောင်းအရာကို တိတိကျကျ သတ်မှတ်ရန် ဒေတာအမျိုးအစားများနှင့် စာရင်းများ ပါဝင်ပါသည်။
• Hash လုပ်ဆောင်ချက် sharding အတွက် - Kafka မက်ဆေ့ချ်ဖွဲ့စည်းပုံသည် သော့တန်ဖိုးဖြစ်ပြီး သော့၏ hash ကိုအသုံးပြု၍ ၎င်းကို မည်သည့်နေရာတွင် ထည့်ရမည်ကို တွက်ချက်သည်။

အဘယ်ကြောင့်

ကျွန်ုပ်တို့သည် ချောမွေ့သောလုပ်ငန်းစဉ်ဖြင့် ကုမ္ပဏီကြီးတစ်ခုတွင် အလုပ်လုပ်ပါသည်။ ဘာကြောင့် တစ်ခုခုကို ပြောင်းလဲတာလဲ။ ဒါက စမ်းသပ်မှုတစ်ခုပါ။အကျိုးအမြတ်များစွာ ရိတ်သိမ်းရန် ကျွန်ုပ်တို့ မျှော်လင့်ပါသည်။

1:n+1 ဖလှယ်မှုများ (တစ်ခုမှ အများအပြား)

Kafka သည် သုံးစွဲသူအသစ်များကို API သို့ ချိတ်ဆက်ရန် အလွန်လွယ်ကူစေသည်။

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

BOB ၏အပိုင်းအစဖြစ်သည့် ပြန်အမ်းငွေ-တူးလ်ကိစ္စတွင်၊ ၎င်းတို့ကို Kafka မှတစ်ဆင့် ထပ်တူပြုထားရန် ကျွန်ုပ်တို့အတွက် အဆင်ပြေပါသည်။ ငွေပြန်ပေးသည်ဟုဆိုသည်- BOB၊ RT သည် ဤအကြောင်းသိရှိပြီး ၎င်းတို့၏အခြေအနေများကို ပြောင်းလဲလိုက်သည်၊ ဤအကြောင်းကို Fiscalization Service မှ သိရှိပြီး ချက်လက်မှတ်တစ်ခုထုတ်ပေးပါသည်။

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

ဒေတာ - မောင်းနှင်

စနစ်များကြားရှိ သတင်းအချက်အလက်များသည် ပွင့်လင်းမြင်သာမှုဖြစ်လာသည် - သင့်တွင် မည်သည့် “သွေးစွန်းသောလုပ်ငန်း” နှင့် သင်၏ backlog မည်မျှပင် များပြားနေပါစေ။ Lamoda တွင် စနစ်များမှ ဒေတာများကို စုဆောင်းပြီး လုပ်ငန်းအတွက်ရော ဉာဏ်ရည်ထက်မြက်သော စနစ်များအတွက်ပါ ပြန်လည်အသုံးပြုနိုင်သည့် ပုံစံတစ်ခုအဖြစ် ထည့်သွင်းပေးသည့် Data Analytics ဌာနတစ်ခုရှိသည်။ Kafka သည် သင့်အား ၎င်းတို့အား ဒေတာများစွာကို လျင်မြန်စွာ ပေးစွမ်းနိုင်ပြီး ထိုအချက်အလက်များ စီးဆင်းမှုကို ခေတ်မီအောင် ထိန်းသိမ်းနိုင်စေပါသည်။

ပုံတူမှတ်တမ်း

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

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

ထို့နောက် Kafka နှင့် မရင်းနှီးသောသူများအတွက် (ပုံသည် စာရွက်စာတမ်းမှလည်းဖြစ်သည်)၊

AMQP တွင် တန်းစီများ ရှိသည်- ကျွန်ုပ်တို့သည် စားသုံးသူအတွက် တန်းစီရန် မက်ဆေ့ချ်များ ရေးပါသည်။ ပုံမှန်အားဖြင့်၊ တန်းစီခြင်းကို တူညီသောစီးပွားရေးယုတ္တိဖြင့် စနစ်တစ်ခုဖြင့် လုပ်ဆောင်သည်။ သင်သည် စနစ်များစွာကို အကြောင်းကြားရန် လိုအပ်ပါက၊ ၎င်းတို့ကို ကိုယ်တိုင်ပွားများသည့် fanout ယန္တရားဖြင့် လဲလှယ်ရန် အပလီကေးရှင်းအား တန်းစီစာများစွာတွင် စာရေးရန် သို့မဟုတ် လဲလှယ်မှုကို သင်ကြားပေးနိုင်သည်။

Kafka တွင် အလားတူ စိတ်ကူးတစ်ခုရှိသည်။ အကွောငျးသင်ရေးထားတဲ့စာတွေကို ဖတ်ပြီးရင် မပျောက်ပါဘူး။ ပုံမှန်အားဖြင့်၊ သင်သည် Kafka သို့ ချိတ်ဆက်သောအခါ၊ သင်သည် မက်ဆေ့ဂျ်များအားလုံးကို လက်ခံရရှိပြီး သင်ချန်ထားခဲ့သည့်နေရာကို သိမ်းဆည်းရန် ရွေးချယ်ခွင့်ရှိသည်။ ဆိုလိုသည်မှာ သင်သည် ဆက်တိုက်ဖတ်သည်၊ သင်သည် စာကိုဖတ်ပြီးဟု အမှတ်အသားပြုမည်မဟုတ်သော်လည်း သင်ဆက်လက်ဖတ်ရှုနိုင်သည့် id ကို သိမ်းဆည်းပါ။ သင်သတ်မှတ်ထားသော Id ကို offset ဟုခေါ်ပြီး ယန္တရားသည် commit offset ဖြစ်သည်။

ထို့ကြောင့် ကွဲပြားခြားနားသော ယုတ္တိဗေဒကို အကောင်အထည်ဖော်နိုင်သည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် မတူညီသောနိုင်ငံများအတွက် ဥပမာ 4 ခုတွင် BOB ရှိသည် - Lamoda သည် ရုရှား၊ ကာဇက်စတန်၊ ယူကရိန်း၊ Belarus တွင်ရှိသည်။ ၎င်းတို့ကို သီးခြားစီအသုံးပြုထားသောကြောင့်၊ ၎င်းတို့တွင် အနည်းငယ်ကွဲပြားသော configs နှင့် ၎င်းတို့၏ ကိုယ်ပိုင်လုပ်ငန်းဆိုင်ရာ ယုတ္တိရှိသည်။ ကျွန်ုပ်တို့သည် မည်သည့်နိုင်ငံကိုရည်ညွှန်းကြောင်း မက်ဆေ့ချ်တွင် ဖော်ပြသည်။ နိုင်ငံတစ်ခုစီရှိ BOB သုံးစွဲသူတိုင်းသည် မတူညီသော groupId ဖြင့်ဖတ်ကြပြီး မက်ဆေ့ချ်သည် ၎င်းတို့နှင့်မသက်ဆိုင်ပါက ၎င်းတို့သည် ၎င်းကို ကျော်သွားသည် ၊ ဆိုလိုသည်မှာ၊ ချက်ခြင်း offset +1 ကျူးလွန်သည်။ ကျွန်ုပ်တို့၏ငွေပေးချေမှုဝန်ဆောင်မှုမှ တူညီသောအကြောင်းအရာကို ဖတ်ပါက၊ ၎င်းသည် သီးခြားအုပ်စုတစ်ခုနှင့် ပြုလုပ်သောကြောင့်၊ အော့ဖ်ဆက်များသည် ဖြတ်တောက်မည်မဟုတ်ပါ။

ပွဲလိုအပ်ချက်များ-

• ဒေတာပြည့်စုံမှု။ ဖြစ်စဉ်ကို စီမံဆောင်ရွက်နိုင်ရန် ဒေတာအလုံအလောက်ရှိစေလိုပါသည်။

• သမာဓိ။ ကျွန်ုပ်တို့သည် Events-bus သို့ လွှဲအပ်ပေးပါသည်။
• အမိန့်က အရေးကြီးတယ်။ ပြန်လာရတဲ့ကိစ္စမှာ ကျွန်တော်တို့က သမိုင်းနဲ့ တွဲလုပ်ရတော့မယ်။ အကြောင်းကြားချက်များနှင့်အတူ၊ အမှာစာသည် အရေးမကြီးပါ၊ ၎င်းတို့သည် တစ်သားတည်းရှိနေသည့် အကြောင်းကြားချက်များဖြစ်ပါက မည်သည့်အမှာစာသည် ပထမရောက်ရှိသည်ဖြစ်စေ အီးမေးလ်သည် တူညီမည်ဖြစ်ပါသည်။ ပြန်အမ်းငွေကိစ္စတွင် ရှင်းလင်းသော လုပ်ငန်းစဉ်တစ်ခု ရှိသည်၊ ကျွန်ုပ်တို့သည် အမှာစာကို ပြောင်းလဲပါက ခြွင်းချက်များ ပေါ်ပေါက်လာမည်ဖြစ်ပြီး ပြန်အမ်းငွေကို ဖန်တီးခြင်း သို့မဟုတ် လုပ်ဆောင်မည်မဟုတ်ပါ - ကျွန်ုပ်တို့သည် မတူညီသော အခြေအနေတွင် ကုန်ဆုံးသွားပါမည်။
• ရှေ့နောက်ညီညွတ်မှု။ ကျွန်ုပ်တို့တွင် စတိုးတစ်ခုရှိပြီး ယခု ကျွန်ုပ်တို့သည် API တစ်ခုအစား ပွဲများကို ဖန်တီးပါသည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများသို့ အဖြစ်အပျက်အသစ်များနှင့် ရှိပြီးသားအရာများဆီသို့ ပြောင်းလဲမှုများအကြောင်း အချက်အလက်များကို လျင်မြန်စွာနှင့် ဈေးပေါပေါဖြင့် ပေးပို့ရန် နည်းလမ်းတစ်ခု လိုအပ်ပါသည်။ သီးခြား git repository နှင့် code generator များတွင် ဘုံသတ်မှတ်ချက်တစ်ခုအားဖြင့် ၎င်းကို အောင်မြင်သည်။ ထို့ကြောင့်၊ မတူညီသော ဝန်ဆောင်မှုများရှိ ဖောက်သည်များနှင့် ဆာဗာများကို ညှိနှိုင်းဆောင်ရွက်ပါသည်။

Lamoda ရှိ Kafka

ကျွန်ုပ်တို့တွင် Kafka တပ်ဆင်မှု သုံးခုရှိသည်။

1. မှတ်တမ်းများ;
2. R&D;
3. အဲ့ဒါနဲ့ ဘတ်စ်ကား။

ယနေ့ကျွန်ုပ်တို့သည် နောက်ဆုံးအချက်အကြောင်းကိုသာ ပြောနေကြသည်။ ပွဲစား-ဘတ်စ်ကားများတွင်၊ ကျွန်ုပ်တို့တွင် အလွန်ကြီးမားသော တပ်ဆင်မှုများ မရှိပါ။ ပွဲစား (ဆာဗာ ၃ ခု) နှင့် အကြောင်းအရာ ၂၇ ခုသာရှိသည်။ စည်းကမ်းအရ၊ အကြောင်းအရာတစ်ခုသည် လုပ်ငန်းစဉ်တစ်ခုဖြစ်သည်။ ဒါပေမယ့် ဒါက သိမ်မွေ့တဲ့အချက်ဖြစ်ပြီး အခုပဲ ကျွန်တော်တို့ ထိတွေ့လိုက်မယ်။

အပေါ်က rps ဂရပ်ပါ။ ပြန်အမ်းငွေလုပ်ငန်းစဉ်ကို စိမ်းပြာရောင်မျဉ်းဖြင့် အမှတ်အသားပြုထားပြီး (ဟုတ်ပါတယ်၊ X ဝင်ရိုးပေါ်ရှိ)၊ ပန်းရောင်လိုင်းသည် အကြောင်းအရာ အပ်ဒိတ်လုပ်ငန်းစဉ်ဖြစ်သည်။

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

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

Lamoda Events တွေမှာ သုံးပါတယ်။

အောက်ပါလုပ်ငန်းများအတွက် ကျွန်ုပ်တို့သည် တည်ဆောက်ထားသော ဗိသုကာပညာကို အသုံးပြုသည်-

• အခြေအနေကို ခြေရာခံပါ။: ပါဝင်ပတ်သက်သည့် စနစ်အားလုံးမှ ခေါ်ဆိုမှုလုပ်ဆောင်ရန်နှင့် အခြေအနေခြေရာခံခြင်း။ ငွေပေးချေမှု၊ အခြေအနေများ၊ ငွေစာရင်းရှင်းတမ်းများ၊ အသိပေးချက်များ။ ဤတွင် ကျွန်ုပ်တို့သည် ချဉ်းကပ်နည်းကို စမ်းသပ်ခဲ့ပြီး၊ ကိရိယာများပြုလုပ်ကာ၊ ချို့ယွင်းချက်အားလုံးကို စုဆောင်းကာ စာရွက်စာတမ်းများကို ရေးသားကာ ၎င်းကိုအသုံးပြုပုံကို ကျွန်ုပ်တို့၏လုပ်ဖော်ကိုင်ဖက်များအား ပြောပြခဲ့သည်။
• ထုတ်ကုန်ကတ်များကို အပ်ဒိတ်လုပ်နေသည်- ဖွဲ့စည်းမှုပုံစံ၊ မက်တာဒေတာ၊ ဝိသေသလက္ခဏာများ။ စနစ်တစ်ခုသည် (ပြသသည့်) ကိုဖတ်သည်နှင့်အများအပြားရေးသည်။
• အီးမေးလ်၊ push နှင့် sms: အော်ဒါ စုဆောင်းပြီးပြီ၊ အော်ဒါရောက်ပြီ၊ ပြန်လက်ခံပြီးပြီ စသဖြင့် အများကြီးရှိတယ်။
• စတော့၊ ဂိုဒေါင် သက်တမ်းတိုးခြင်း။ — ပစ္စည်းများ၏ အရေအတွက် အပ်ဒိတ်၊ နံပါတ်များသာ- ဂိုဒေါင်သို့ ရောက်ရှိ၊ ပြန်လာ။ ကုန်ပစ္စည်းကြိုတင်စာရင်းသွင်းခြင်းဆိုင်ရာ စနစ်အားလုံးသည် လက်ရှိဒေတာဖြင့် လုပ်ဆောင်ရန် လိုအပ်ပါသည်။ လက်ရှိတွင်၊ စတော့ခ်အပ်ဒိတ်စနစ်သည် အတော်လေးရှုပ်ထွေးသည်၊ Kafka သည် ၎င်းကိုရိုးရှင်းစေသည်။
• ဒေတာများကိုခွဲခြမ်းစိတ်ဖြာခြင်း (R&D ဌာန)၊ ML ကိရိယာများ၊ ခွဲခြမ်းစိတ်ဖြာမှု၊ စာရင်းအင်းများ။ ကျွန်ုပ်တို့သည် အချက်အလက်များကို ပွင့်လင်းမြင်သာစေရန် လိုလားသည် - Kafka သည် ဤအရာအတွက် ကောင်းမွန်သင့်လျော်ပါသည်။

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

ဒီဇိုင်းပြဿနာများ

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

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

ဒေတာစီးကြောင်း

Kafka ၏ကိစ္စတွင်၊ data flow ကိုစီစဉ်ရန်မေးခွန်းပေါ်လာသည်။ ဤတာဝန်တွင် အချက်များစွာကို အခြေခံ၍ ဗျူဟာရွေးချယ်ခြင်း ပါ၀င်သည်၊ ၎င်းတို့အားလုံးကို ကျော်ဖြတ်ကြပါစို့။

ခေါင်းစဉ်တစ်ခုတွင် သို့မဟုတ် မတူညီသော အကြောင်းအရာတစ်ခုတွင် ရှိပါသလား။

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

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

နယ်ပယ်အသစ် သို့မဟုတ် ပွဲအသစ်လား။

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

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

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

ပြန်အမ်းငွေကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် တစ်နှစ်ခွဲအတွင်း အဖြစ်အပျက်များကို ရောက်ရှိလာပါသည်။ ငွေပြန်အမ်းမွမ်းမံမှုဟုခေါ်သော မက်တာဖြစ်ရပ်တစ်ခုရှိပါသည်၊ ဤအပ်ဒိတ်အမှန်တကယ်မည်သို့ဖြစ်သည်ကိုဖော်ပြသည့် အမျိုးအစားအကွက်ပါရှိသည်။ ထို့အတွက်ကြောင့်၊ ဤအမျိုးအစားဖြင့် ဤဖြစ်ရပ်ကို မည်သို့အတည်ပြုရမည်ကို ကျွန်ုပ်တို့အား ပြောပြသော မှန်ကန်သည့်စနစ်ဖြင့် “အံ့ဖွယ်ကောင်းသော” ခလုတ်များရှိသည်။

ပွဲပုံစံဗားရှင်း

Kafka တွင် မက်ဆေ့ချ်များကို တရားဝင်အောင်ပြုလုပ်ရန် သင်သုံးနိုင်သည်။ Avroဒါပေမယ့် အဲဒါကို ချက်ချင်းတင်ပြီး Confluent ကိုသုံးဖို့ လိုအပ်တယ်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ကျွန်ုပ်တို့သည်ဗားရှင်းကိုသတိထားပါ။ မော်ဒယ်သည် “ဝဲ” ဖြစ်သောကြောင့် ကူးယူမှုမှတ်တမ်းမှ မက်ဆေ့ဂျ်များကို အမြဲပြန်ဖတ်ရန် မဖြစ်နိုင်ပါ။ အခြေခံအားဖြင့်၊ မော်ဒယ်သည် နောက်ပြန်သဟဇာတဖြစ်စေရန် ဗားရှင်းများတည်ဆောက်ရန် ထွက်လာသည်- ဥပမာ၊ အကွက်တစ်ခုကို ယာယီရွေးချယ်ခွင့်ပြုလုပ်ပါ။ ကွဲလွဲမှုများ အားကောင်းလွန်းပါက၊ ကျွန်ုပ်တို့သည် အကြောင်းအရာအသစ်တစ်ခုကို စတင်ရေးသားပြီး အဟောင်းကို ဖတ်ရှုပြီးသည့်အခါ သုံးစွဲသူများကို လွှဲပြောင်းပါ။

အပိုင်းပိုင်းအစီအစဥ်များကိုဖတ်ရှုရန်အာမခံပါသည်။

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

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

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

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

ဖြစ်ရပ်များနှင့် အမိန့်များ

ဒါက ကျွန်တော်တို့ ကြုံတွေ့ရတဲ့ နောက်ထပ်ပြဿနာတစ်ခုပါ။ ဖြစ်ရပ်သည် အချို့သောဖြစ်ရပ်တစ်ခုဖြစ်သည်- ကျွန်ုပ်တို့သည် တစ်နေရာရာတွင် တစ်ခုခုဖြစ်ခဲ့သည် (တစ်စုံတစ်ခု_ဖြစ်ပွားခဲ့သည်)၊ ဥပမာ၊ ပစ္စည်းတစ်ခုကို ပယ်ဖျက်လိုက်သည် သို့မဟုတ် ပြန်အမ်းငွေဖြစ်သွားသည်ဟု ကျွန်ုပ်တို့ပြောပါသည်။ အကယ်၍ တစ်စုံတစ်ယောက်သည် ဤဖြစ်ရပ်များကို နားထောင်ပါက၊ "ပစ္စည်းကို ပယ်ဖျက်လိုက်သည်" အရ၊ ပြန်အမ်းငွေယူနစ်ကို ဖန်တီးမည်ဖြစ်ပြီး၊ "ပြန်အမ်းငွေဖြစ်သွားသည်" ကို စနစ်ထည့်သွင်းမှုတွင် တစ်နေရာရာမှာ ရေးထားမည်ဖြစ်သည်။

သို့သော် အများအားဖြင့်၊ သင်သည် အဖြစ်အပျက်များကို ဒီဇိုင်းဆွဲသည့်အခါ ၎င်းတို့ကို အချည်းနှီးမရေးချင်ပါ - တစ်စုံတစ်ဦးသည် ၎င်းတို့ကို ဖတ်မည်ဟူသောအချက်ကို သင်အားကိုးပါသည်။ something_happened (item_canced၊ refund_refunded) တွင် တစ်ခုခု_should_be_done ကိုရေးရန် ပြင်းထန်သောသွေးဆောင်မှုရှိပါသည်။ ဥပမာ၊ ပစ္စည်းပြန်ပို့ရန် အသင့်ဖြစ်နေပါပြီ။

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

RabbitMQ ရှိ asynchronous လဲလှယ်မှုတွင်၊ သင်သည် မက်ဆေ့ချ်ကို ဖတ်သည့်အခါ http သို့သွားပါ၊ အနည်းဆုံး မက်ဆေ့ချ်ကို လက်ခံရရှိကြောင်း သင့်တွင် တုံ့ပြန်မှုတစ်ခုရှိသည်။ သင် Kafka သို့ စာရေးသောအခါတွင် သင်သည် Kafka သို့ ရေးခဲ့သည့် မက်ဆေ့ချ်တစ်ခု ရှိသော်လည်း ၎င်းကို မည်ကဲ့သို့ လုပ်ဆောင်ခဲ့သည်ကို သင်မသိပါ။

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

တစ်ခုလုံးကိုပြည့်ပြည့်စုံစုံ

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

အဲဒါကို ငါတို့သိတယ်၊ အဲဒါကို အားကိုးတယ်၊ ဒါတောင် ဖြစ်သွားတာ။ Event-bus ၏ရှုထောင့်မှ အဖြစ်အပျက်သည် မှန်ကန်သောကြောင့် ဖြစ်ခဲ့သည်၊ အဖြစ်အပျက်သည် အပလီကေးရှင်းစစ်ဆေးသူ၏ ရှုထောင့်မှ မှန်ကန်သော်လည်း PostgreSQL ၏ ရှုထောင့်မှ မမှန်ကန်သောကြောင့် ကျွန်ုပ်တို့၏စနစ် MySQL၊ လက်မှတ်မထိုးထားသော INT ဖြင့် စနစ်တွင် PostgreSQL သည် INT ဖြင့်သာရှိသည်။ သူ့အရွယ်အစားက နည်းနည်းသေးပြီး Id က အဆင်မပြေဘူး။ Symfony သည် ချွင်းချက်ဖြင့် သေဆုံးသွားခဲ့သည်။ ကျွန်ုပ်တို့သည် ၎င်းကို မှီခိုအားထားသောကြောင့် ခြွင်းချက်အား ဖမ်းမိခဲ့ပြီး ဤနှိမ်နှင်းမှုကို ကျူးလွန်တော့မည်ဖြစ်သော်လည်း မက်ဆေ့ချ်ကို မအောင်မြင်သောကြောင့် ပြဿနာကောင်တာကို တိုးမြှင့်လိုခြင်းမပြုမီတွင်၊ ဤပရောဂျက်ရှိ ကောင်တာများသည် ဒေတာဘေ့စ်ထဲတွင်လည်း ရှိပြီး Symfony သည် ဒေတာဘေ့စ်နှင့် ဆက်သွယ်မှုကို ပိတ်ထားပြီးဖြစ်ပြီး၊ ဒုတိယခြွင်းချက်သည် နှိမ်ချရန်အခွင့်အရေးမရှိဘဲ လုပ်ငန်းစဉ်တစ်ခုလုံးကို သတ်ပစ်လိုက်ပါသည်။

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

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

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

partitions များနှင့်အလုပ်လုပ်ခြင်း၏အသေးစိတ်အချက်အလက်များကိုပြန်သွားသောအခါ၎င်းကိုစာရွက်စာတမ်းတွင်မှန်ကန်စွာရေးထားသည်။ စားသုံးသူ >= ခေါင်းစဉ်ခွဲများ. ဒါပေမယ့် ဒီအကြောင်းကို ကြိုက်တာထက် အများကြီးနောက်ကျမှ သိခဲ့ရတယ်။ အကယ်၍ သင်သည် အတိုင်းအတာနှင့် စားသုံးသူနှစ်ဦးရှိလိုပါက၊ အနည်းဆုံး အပိုင်းနှစ်ခု လိုအပ်သည်။ ဆိုလိုသည်မှာ သင့်တွင် မက်ဆေ့ချ်ပေါင်း 20 စုဆောင်းထားပြီး အသစ်တစ်ခုပြုလုပ်ပါက၊ မက်ဆေ့ချ်အရေအတွက်သည် မကြာမီ ညီမျှမည်မဟုတ်ပါ။ ထို့ကြောင့်၊ အပြိုင်စားသုံးသူနှစ်ဦးရှိရန်၊ သင်သည် partitions များကိုကိုင်တွယ်ရန်လိုအပ်သည်။

စောင့်ကြည့်လေ့လာခြင်း

အဲဒါကို စောင့်ကြည့်တဲ့နည်းလမ်းက လက်ရှိချဉ်းကပ်မှုမှာ ဘယ်လိုပြဿနာတွေရှိနေလဲဆိုတာ ပိုရှင်းမယ်ထင်တယ်။

ဥပမာအားဖြင့်၊ ဒေတာဘေ့စ်ရှိ ထုတ်ကုန်မည်မျှကို မကြာသေးမီကမှ ၎င်းတို့၏ အခြေအနေကို ပြောင်းလဲလိုက်သည်ကို ကျွန်ုပ်တို့ တွက်ချက်ပြီး ယင်းပြောင်းလဲမှုများအပေါ် အခြေခံ၍ ဖြစ်ရပ်များ ဖြစ်ပေါ်သင့်ပြီး ဤနံပါတ်ကို ကျွန်ုပ်တို့၏ စောင့်ကြည့်ရေးစနစ်သို့ ပေးပို့ပါသည်။ ထို့နောက် Kafka မှ ကျွန်ုပ်တို့သည် ဒုတိယ နံပါတ်ကို ရရှိသည်၊ အမှန်တကယ် ဖြစ်ရပ်မည်မျှ မှတ်တမ်းတင်ခဲ့သည် ။ ထင်ရှားသည်မှာ ဤဂဏန်းနှစ်လုံးကြား ခြားနားချက်သည် အမြဲတမ်း သုညဖြစ်သင့်သည်။

ထို့အပြင်၊ ထုတ်လုပ်သူမည်သို့လုပ်ဆောင်နေသည်၊ ပွဲများ-ဘတ်စ်ကားများလက်ခံရရှိခြင်းရှိမရှိ၊ နှင့်စားသုံးသူမည်သို့လုပ်ဆောင်နေသည်ဖြစ်စေသင်စောင့်ကြည့်ရန်လိုအပ်သည်။ ဥပမာအားဖြင့်၊ အောက်ဖော်ပြပါဇယားများတွင် Refund Tool သည် ကောင်းမွန်နေသော်လည်း BOB တွင် ပြဿနာအချို့ (အပြာရောင်အတက်အကျများ) ရှိနေသည်မှာ ထင်ရှားသည်။

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

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

ဤသည်မှာ API တုံ့ပြန်မှုပုံစံဖြစ်သည်။ ဤတွင် group bob-live-fifa၊ partition refund.update.v1၊ status OK, lag 0 - နောက်ဆုံးနောက်ဆုံး offset စသည်တို့ဖြစ်သည်။

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

အကျဉ်းချုပ်ပြောရလျှင် ပွဲများကို အသုံးပြုသည့်အခါ အဆင်ပြေသည်။:

• စနစ်များစွာအတွက် အချက်အလက်များ လိုအပ်ပါသည်။
• လုပ်ဆောင်ခြင်း၏ရလဒ်သည် အရေးမကြီးပါ။
• ပွဲအနည်းအကျဉ်း သို့မဟုတ် အသေးအမွှားဖြစ်ရပ်များ ရှိပါသည်။

ဆောင်းပါးတွင် Kafka တွင် အလွန်တိကျသောအကြောင်းအရာတစ်ခုရှိသည် - ဟုထင်ရသော်လည်း ၎င်းနှင့်ဆက်စပ်၍ အကြောင်းအရာများစွာကို တစ်ပြိုင်နက်တည်း အကြံပြုလိုပါသည်။
ပထမ၊ နောက် HighLoad++ ကျွန်ုပ်တို့သည် နိုဝင်ဘာလအထိ စောင့်ရမည်ဖြစ်ပြီး၊ ဧပြီလတွင် စိန့်ပီတာစဘတ်ဗားရှင်းရှိမည်ဖြစ်ပြီး ဇွန်လတွင် Novosibirsk ရှိ မြင့်မားသောပစ္စည်းများအကြောင်း ဆွေးနွေးမည်ဖြစ်သည်။
ဒုတိယအနေနှင့်၊ အစီရင်ခံစာရေးသားသူ Sergei Zaika သည် ကျွန်ုပ်တို့၏ အသိပညာစီမံခန့်ခွဲမှုဆိုင်ရာ ညီလာခံအသစ်၏ အစီအစဉ်ကော်မတီ၏ အဖွဲ့ဝင်ဖြစ်သည်။ KnowledgeConf. ညီလာခံသည် တစ်ရက်တာ ဧပြီလ ၂၆ ရက်နေ့တွင် ကျင်းပမည်ဖြစ်သော်လည်း ၎င်း၏ အစီအစဉ်မှာ အလွန်ပြင်းထန်သည်။
မေလတွင်ဖြစ်လိမ့်မည်။ PHP ရုရှား и RIT++ (DevOpsConf ပါ၀င်သည်) - ထိုနေရာတွင် သင့်အကြောင်းအရာကို အကြံပြုနိုင်သည်၊ သင့်အတွေ့အကြုံအကြောင်း ပြောဆိုကာ သင့်ကျပ်ပြားများအကြောင်း တိုင်ကြားနိုင်ပါသည်။

source: www.habr.com