မီခေးလ်ဆာလိုဆင်။ Golang တွေ့ဆုံပွဲ။ Look+ အပလီကေးရှင်း၏ နောက်ကျောတွင် Go ကို အသုံးပြုခြင်း။

Mikhail Salosin (နောင် - MS): - အားလုံးမင်္ဂလာပါ! ကျွန်တော့်နာမည်က မိုက်ကယ်ပါ။ ကျွန်ုပ်သည် MC2 Software တွင် နောက်ခံဆော့ဖ်ဝဲရေးသားသူအဖြစ် လုပ်ဆောင်နေပြီး Look+ မိုဘိုင်းအက်ပ်၏ နောက်ကွယ်တွင် Go ကို အသုံးပြုခြင်းအကြောင်း ဆွေးနွေးပါမည်။

ဟော်ကီကို ကြိုက်တဲ့သူရှိလား။

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

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

ဖွံ့ဖြိုးတိုးတက်ရေးမှာ ဘာကိုသုံးခဲ့လဲ။

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

ကျွန်ုပ်တို့သည် PostgreSQL ကို ဒေတာဘေ့စ်အဖြစ် အသုံးပြုခဲ့သည်။ တည်းဖြတ်သူ အင်တာဖေ့စ်ကို ActiveAdmin ကျောက်မျက်ကို အသုံးပြု၍ Ruby on Rails တွင် ရေးသားထားသည်။ စာရင်းဇယားပံ့ပိုးပေးသူထံမှ စာရင်းဇယားတင်သွင်းခြင်းကို Ruby တွင်လည်း ရေးသားထားသည်။

စနစ် API စမ်းသပ်မှုများအတွက် Python unittest ကို အသုံးပြုခဲ့သည်။ Memcached ကို API ငွေပေးချေမှုခေါ်ဆိုမှုများကို အရှိန်မြှင့်ရန် အသုံးပြုသည်၊ "စားဖိုမှူး" သည် ဖွဲ့စည်းမှုပုံစံကို ထိန်းချုပ်ရန် အသုံးပြုသည်၊ Zabbix သည် အတွင်းပိုင်းစနစ်စာရင်းအင်းများကို စုဆောင်းရန်နှင့် စောင့်ကြည့်ရန် အသုံးပြုသည်။ Graylog2 သည် မှတ်တမ်းများ စုဆောင်းရန်အတွက်ဖြစ်ပြီး၊ Slate သည် သုံးစွဲသူများအတွက် API စာရွက်စာတမ်းဖြစ်သည်။

ပရိုတိုကော ရွေးချယ်မှု

ကျွန်ုပ်တို့ကြုံတွေ့ရသည့် ပထမဆုံးပြဿနာ- အောက်ပါအချက်များအပေါ် အခြေခံ၍ backend နှင့် mobile clients များကြား အပြန်အလှန်အကျိုးသက်ရောက်မှုအတွက် ပရိုတိုကောကို ရွေးချယ်ရန် လိုအပ်ပါသည်...

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

၎င်းကိုအခြေခံ၍ ကျွန်ုပ်တို့တွင် ပရိုတိုကော ရွေးချယ်စရာနှစ်ခုရှိသည်။

1. ဝက်ဘ်ဆိုဒ်များ သို့သော် ကျွန်ုပ်တို့သည် သုံးစွဲသူထံမှ ဆာဗာသို့ ချန်နယ်များ မလိုအပ်ပါ။ ကျွန်ုပ်တို့သည် ဆာဗာမှ အပ်ဒိတ်များကို ကလိုင်းယင့်ထံသို့ ပေးပို့ရန်သာ လိုအပ်သောကြောင့် websocket သည် မလိုအပ်သော ရွေးချယ်မှုတစ်ခုဖြစ်သည်။
2. Server-Sent Events (SSE) ပေါ်လာသည် ။ ၎င်းသည် အလွန်ရိုးရှင်းပြီး အခြေခံအားဖြင့် ကျွန်ုပ်တို့လိုအပ်သမျှကို ဖြည့်ဆည်းပေးသည်။

ဆာဗာ- ပေးပို့သည့် အစီအစဉ်များ

ဤအရာသည် မည်သို့လုပ်ဆောင်သည်နှင့် ပတ်သက်၍ စကားအနည်းငယ် ...

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

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

အခု အပြန်အလှန် ဆက်သွယ်မှု သူ့ဟာသူ ဘယ်လို အလုပ်လုပ်လဲ ဆိုတာ ပြောကြည့်ရအောင်။

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

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

တိုက်ရိုက်ချိတ်ဆက်မှုကို မည်သို့ဝန်ဆောင်မှုပေးသနည်း။

• ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် ကြားခံအပ်ဒိတ်များကို လက်ခံရရှိမည့် ချန်နယ်တစ်ခုကို ဖန်တီးပါသည်။
• ထို့နောက် အပ်ဒိတ်များရရှိရန် ဤချန်နယ်ကို စာရင်းသွင်းပါ။
• အားလုံးအဆင်ပြေကြောင်း client မှသိစေရန် မှန်ကန်သော header ကို သတ်မှတ်ပေးထားပါသည်။
• ပထမဆုံး ping ကို ပို့ပါ။ ကျွန်ုပ်တို့သည် လက်ရှိချိတ်ဆက်မှုအချိန်တံဆိပ်ကို ရိုးရှင်းစွာမှတ်တမ်းတင်ပါသည်။
• ၎င်းနောက်၊ အပ်ဒိတ်ချန်နယ်ကို မပိတ်မချင်း ချန်နယ်ကို အကွက်တစ်ကွင်းမှ ဖတ်ပါသည်။ ချန်နယ်သည် ချိတ်ဆက်မှုများကို ဖွင့်ရန်အတွက် လက်ရှိအချိန်တံဆိပ် သို့မဟုတ် အပြောင်းအလဲများကို အခါအားလျော်စွာ လက်ခံရရှိပါသည်။

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

ထို့ကြောင့်၊ ယခု ကျွန်ုပ်တို့၏ ping သည် အပ်ဒိတ်မှလာသော တူညီသောချန်နယ်မှ လာပါသည်။

ထို့ကြောင့်၊ 15 စက္ကန့်တိုင်းတစ်ကြိမ် အမှတ်ခြစ်သည့် timer တစ်ခုသာရှိသည်။

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

အပ်ဒိတ်များ ပေးပို့ခြင်းအတွက် ယန္တရား

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

CMS ကို အသုံးပြု၍ ဒေတာသည် ဒေတာဘေ့စ်ထဲသို့ ဝင်ရောက်သည်။ ၎င်းပြီးနောက်၊ ဒေတာဘေ့စ်သည် Listen/Notify ယန္တရားကို အသုံးပြု၍ ၎င်းအကြောင်း API ဆာဗာများကို အသိပေးသည်။ API ဆာဗာများသည် ဤအချက်အလက်ကို သုံးစွဲသူများထံ ပေးပို့ထားပြီးဖြစ်သည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့တွင် အခြေခံအားဖြင့် ဒေတာဘေ့စ်သို့ ချိတ်ဆက်ထားသော ဆာဗာအနည်းငယ်မျှသာ ရှိပြီး ဒေတာဘေ့စ်တွင် အထူးဝန်ဆောင်မှု မရှိပါ။ အဘယ်ကြောင့်ဆိုသော် သုံးစွဲသူသည် မည်သည့်နည်းဖြင့်မျှ ဒေတာဘေ့စ်နှင့် တိုက်ရိုက်မတုံ့ပြန်နိုင်သောကြောင့်၊

PostgreSQL- နားထောင်/အကြောင်းကြားပါ။

Postgres ရှိ Listen/Notify ယန္တရားသည် သင့်အား ဖြစ်ရပ်အချို့ ပြောင်းလဲသွားကြောင်း ဖြစ်ရပ်စာရင်းသွင်းသူများကို အကြောင်းကြားနိုင်သည် - အချို့သောမှတ်တမ်းကို ဒေတာဘေ့စ်တွင် ဖန်တီးထားသည်။ ဒါကိုလုပ်ဖို့၊ ရိုးရှင်းတဲ့ အစပျိုးနဲ့ လုပ်ဆောင်ချက်ကို ရေးခဲ့ပါတယ်။

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

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

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

ဤနေရာတွင် ဒေတာဘေ့စ်သို့ ချိတ်ဆက်ပြီး ချန်နယ် (data_updates) ကို နားထောင်လိုသည်ဟု ပြောသော စံ pq စာကြည့်တိုက်သည် ချိတ်ဆက်မှုဖွင့်ထားပြီး အရာအားလုံး အဆင်ပြေကြောင်း စစ်ဆေးပါ။ နေရာချွေတာရန် အမှားစစ်ဆေးခြင်းကို ချန်လှပ်ထားပါသည် (စစ်ဆေးခြင်းသည် အန္တရာယ်မရှိပါ)။

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

Fan-out အလုပ်က ဘယ်လိုလဲ။

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

Go တွင် ၎င်းကို အကောင်အထည်ဖော်ပုံ-

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

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

ချန်နယ်ကို "နားဆင်သူများ" သို့ ပေါင်းထည့်သည့် စာရင်းသွင်းနည်းလမ်းလည်း ရှိပါသည်-

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

ဆိုတဲ့မေးခွန်းကို: - ဤချန်နယ်မှတဆင့် အဘယ်အရာ ထုတ်လွှင့်သနည်း။

ဒေါ်: - ပြောင်းလဲထားသော သို့မဟုတ် ping မော်ဒယ်ကို ပို့လွှတ်သည် (အဓိကအားဖြင့် ဂဏန်း၊ ကိန်းပြည့်)။

ဒေါ်: - သင်သည် မည်သည့်အရာကိုမဆို ပေးပို့နိုင်သည်၊ မည်သည့်ဖွဲ့စည်းပုံအားမဆို ပေးပို့နိုင်သည်၊ ၎င်းကို ထုတ်ဝေနိုင်သည် - ၎င်းသည် JSON အဖြစ်သို့ ပြောင်းလဲသွားပြီး ဒါပင်ဖြစ်ပါသည်။

ဒေါ်: - ကျွန်ုပ်တို့သည် Postgres ထံမှ အကြောင်းကြားချက်တစ်ခု လက်ခံရရှိသည် - ၎င်းတွင် ဇယားအမည်နှင့် သတ်မှတ်ပုံပါရှိသည်။ ဇယားအမည်နှင့် သတ်မှတ်ဖော်ပြမှုအပေါ် အခြေခံ၍ ကျွန်ုပ်တို့ လိုအပ်သော မှတ်တမ်းကို ရယူပြီးနောက် ဤဖွဲ့စည်းပုံကို ထုတ်ဝေရန်အတွက် ကျွန်ုပ်တို့ထံ ပေးပို့ပါသည်။

အခြေခံအဆောက်အဦများ

အခြေခံအဆောက်အအုံဆိုင်ရာ ရှုထောင့်ကနေ ဘယ်လိုမြင်လဲ။ ကျွန်ုပ်တို့တွင် ဟာ့ဒ်ဝဲဆာဗာ ၇ ခု ရှိသည်- ၎င်းတို့ထဲမှ တစ်ခုသည် ဒေတာဘေ့စ်အတွက် လုံးလုံးလျားလျား အပ်နှံထားပြီး၊ အခြား ခြောက်ခုသည် လည်ပတ်နေသည့် virtual machines ဖြစ်သည်။ API ၏ မိတ္တူ 7 ခု ရှိသည်- API ပါသည့် virtual machine တစ်ခုစီသည် သီးခြား hardware server တစ်ခုပေါ်တွင် အလုပ်လုပ်သည် - ၎င်းသည် ယုံကြည်စိတ်ချရမှုအတွက်ဖြစ်သည်။

အသုံးပြုနိုင်မှု ပိုကောင်းလာစေရန် Keepalived တပ်ဆင်ထားသော ရှေ့တန်းနှစ်ခုရှိသည်၊ ထို့ကြောင့် တစ်ခုခုဖြစ်သွားပါက ရှေ့တန်းတစ်ခုသည် အခြားတစ်ခုကို အစားထိုးနိုင်မည်ဖြစ်သည်။ ထို့အပြင် - CMS မိတ္တူနှစ်စောင်။

စာရင်းဇယားတင်သွင်းသူလည်း ရှိပါတယ်။ အရန်များကို အခါအားလျော်စွာ ပြုလုပ်သည့် DB Slave တစ်ခုရှိသည်။ Pigeon Pusher သည် ဖောက်သည်များထံ တွန်းအားပေးအကြောင်းကြားစာများ ပေးပို့သည့် အက်ပလီကေးရှင်းတစ်ခုဖြစ်ပြီး Zabbix၊ Graylog2 နှင့် Chef။

အမှန်မှာ၊ ဤအခြေခံအဆောက်အအုံသည် မလိုအပ်တော့ပါ၊ အဘယ်ကြောင့်ဆိုသော် 100,ဝဝဝ ကို ဆာဗာအနည်းငယ်ဖြင့် ဆောင်ရွက်ပေးနိုင်သည်။ ဒါပေမယ့် သံရှိတယ် - ငါတို့သုံးတယ် ( ဖြစ်နိုင်တယ် လို့ ပြောကြတယ် ၊ ဘာဖြစ်လို့လဲ ) ။

Go ၏အားသာချက်များ

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

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

ကျွန်ုပ်တို့သည် developer များကို ရှာဖွေနေပါသည်။ လိုချင်တာရှိရင် ကျေးဇူးပြုပြီး

မေးခွန်းများကို

ပရိသတ်ထံမှမေးခွန်း (နောင်တွင် – B): – Fan-out နှင့်ပတ်သက်သော အရေးကြီးသောအချက်တစ်ချက်ကို သင်လွတ်သွားသည်ဟု ယူဆပါသည်။ ဖောက်သည်တစ်ဦးထံ တုံ့ပြန်မှုကို ပေးပို့သည့်အခါ၊ ကလိုင်းယင့် မဖတ်လိုပါက ပိတ်ဆို့ကြောင်း နားလည်သဘောပေါက်ခြင်းမှာ မှန်ကန်ပါသလား။

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

IN: - Listen/Notify သို့ မှတ်တမ်းတစ်ခု ချက်ခြင်းပေးပို့နိုင်ပြီး identifier table မဟုတ်ပါလား။

ဒေါ်: - Listen/Notify သည် ၎င်းပေးပို့သည့်ကြိုတင်တင်တွင် ဘိုက် ၈ဝဝဝ ကန့်သတ်ချက်ရှိသည်။ မူအရ၊ အကယ်၍ ကျွန်ုပ်တို့သည် ဒေတာပမာဏအနည်းငယ်ကို ကိုင်တွယ်ဖြေရှင်းပါက ပေးပို့ရန်ဖြစ်နိုင်သည်၊ သို့သော် ဤနည်း [ကျွန်ုပ်တို့ပြုလုပ်ပုံ] သည် ရိုးရိုးရှင်းရှင်းသာ၍ ယုံကြည်စိတ်ချရသည်ဟု ကျွန်ုပ်ထင်ပါသည်။ ကန့်သတ်ချက်များသည် Postgres ကိုယ်တိုင်ဖြစ်သည်။

IN: - ဖောက်သည်များသည် ၎င်းတို့စိတ်မဝင်စားသော ပွဲများအကြောင်း အပ်ဒိတ်များ လက်ခံရရှိပါသလား။

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

IN: - မင်းဘာလို့ မင်းကိုယ်ပိုင် ORM လုပ်တာလဲ။

Alexey (Look+ ၏ developer များထဲမှတစ်ဦး)။ - ထိုအချိန်က (လွန်ခဲ့သည့်တစ်နှစ်ခန့်) တွင် ORM များ အများအပြားရှိသောအခါ ယခုထက်နည်းသည်။ ORM အများစုနဲ့ပတ်သက်တဲ့ အကြိုက်ဆုံးအချက်ကတော့ အများစုဟာ ဗလာကျင်းထားတဲ့ အင်တာဖေ့စ်ပေါ်မှာ အလုပ်လုပ်နေတာပါပဲ။ ဆိုလိုသည်မှာ၊ ဤ ORMs များရှိ နည်းလမ်းများသည် မည်သည့်အရာကိုမဆို ယူဆောင်ရန် အဆင်သင့်ဖြစ်သည်- ဖွဲ့စည်းပုံတစ်ခု၊ ဖွဲ့စည်းပုံညွှန်ပြချက်တစ်ခု၊ နံပါတ်တစ်ခု၊ လုံးဝမသက်ဆိုင်သောအရာ...

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

IN: - လူဘယ်နှစ်ယောက် ပါဝင်ခဲ့လဲ။

ဒေါ်: - ကနဦးအဆင့်တွင် လူနှစ်ဦး ပါဝင်ခဲ့သည်။ ကျွန်ုပ်တို့သည် ဇွန်လတွင် တစ်နေရာတွင် စတင်ခဲ့ပြီး သြဂုတ်လတွင် အဓိကအပိုင်းသည် အဆင်သင့်ဖြစ်နေပြီ (ပထမဗားရှင်း)။ စက်တင်ဘာလတွင် ထွက်ရှိခဲ့သည်။

IN: - SSE ကို သင်ဖော်ပြသည့်နေရာတွင် သင်သည် အချိန်ကုန်ခြင်းကို အသုံးမပြုပါ။ အဲဒီလို့ဘာဖြစ်လို့?

ဒေါ်: - ရိုးရိုးသားသားပြောရလျှင် SSE သည် html5 ပရိုတိုကောအဖြစ်ရှိနေဆဲဖြစ်သည်- SSE စံသည် ကျွန်ုပ်နားလည်သလောက် ဘရောက်ဆာများနှင့် ဆက်သွယ်ရန်အတွက် ဒီဇိုင်းထုတ်ထားသည်။ ၎င်းတွင် ဘရောက်ဆာများ ပြန်လည်ချိတ်ဆက်နိုင်စေရန် (ထို့ကြောင့်) ထပ်လောင်းဝန်ဆောင်မှုများပါရှိသည်၊ သို့သော် ကျွန်ုပ်တို့တွင် အချက်အလက်ချိတ်ဆက်ခြင်းနှင့် လက်ခံခြင်းအတွက် မည်သည့်ယုတ္တိကိုမဆို အကောင်အထည်ဖော်နိုင်သည့် client များရှိသောကြောင့် ၎င်းတို့ကို ကျွန်ုပ်တို့တွင် မလိုအပ်ပါ။ ကျွန်ုပ်တို့သည် SSE ကိုမဖန်တီးခဲ့ဘဲ SSE နှင့်ဆင်တူသောအရာတစ်ခုဖြစ်သည်။ ဤသည်မှာ ပရိုတိုကော ကိုယ်တိုင်မဟုတ်ပါ။
မလိုအပ်ဘူး။ ကျွန်ုပ်နားလည်သလောက်၊ ဖောက်သည်များသည် ချိတ်ဆက်မှုယန္တရားကို အစမှအဆုံးနီးပါး အကောင်အထည်ဖေါ်ခဲ့သည်။ သူတို့ တကယ် ဂရုမစိုက်ဘူး။

IN: - မည်သည့် အပို အသုံးအဆောင်များကို သင်အသုံးပြုခဲ့သနည်း။

ဒေါ်: - စတိုင်လ်နှင့် gofmt တို့ကို တစ်စုတစ်စည်းတည်းဖြစ်စေရန်အတွက် govet နှင့် golint ကို ကျွန်ုပ်တို့ အတက်ကြွဆုံးအသုံးပြုခဲ့သည်။ အခြားမည်သည့်အရာမှ အသုံးမပြုခဲ့ပါ။

IN: - အမှားရှာရန် သင်ဘာကိုအသုံးပြုခဲ့သနည်း။

ဒေါ်: - စမ်းသပ်မှုများအသုံးပြု၍ အမှားရှာပြင်ခြင်းကို အကြီးအကျယ်လုပ်ဆောင်ခဲ့သည်။ ကျွန်ုပ်တို့သည် မည်သည့်အမှားရှာဂ် သို့မဟုတ် GOP ကိုမျှ အသုံးမပြုခဲ့ပါ။

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

ဒေါ်: - မရှိပါ။ ၎င်းတို့တွင် မြင်နိုင်စွမ်း "ကျဉ်းမြောင်းသော" နယ်ပယ်ရှိသည်။ ၎င်းတို့ကို ဤနေရာတွင်မှလွဲ၍ အခြားမည်သည့်နေရာတွင်မှ အသုံးမပြုပါ (ဤအတန်း၏အတွင်းပိုင်းမှလွဲ၍) ၎င်းသည် အလွန်ကျစ်လစ်သိပ်သည်းသည် - ၎င်းသည် 7 လိုင်းသာကြာသည်။

IN: - ဘယ်လိုမှ အလိုလိုသိနေသေးတာမဟုတ်ဘူး...

ဒေါ်: - မဟုတ်ဘူး၊ ဒါက တကယ့်ကုဒ်ပါ။ စတိုင်နဲ့ မပတ်သက်ပါဘူး။ အလွန်သေးငယ်သော လူတန်းစားမျှသာဖြစ်ပြီး စာသင်ခန်းအတွင်း၌ နယ်ပယ် ၃ ခုသာရှိသည်။

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

IN: – ပြင်ပအဖွဲ့အစည်း မှီခိုမှုစီမံခန့်ခွဲမှု ပက်ကေ့ခ်ျများ ရှိပါသလား။

ဒေါ်: - ငါတို့က go dep သုံးတယ်။

IN: - အစီရင်ခံစာ၏ခေါင်းစဉ်တွင် ဗီဒီယိုအကြောင်း တစ်စုံတစ်ရာရှိသော်လည်း ဗီဒီယိုနှင့်ပတ်သက်သည့် အစီရင်ခံစာတွင် ဘာမှမရှိပါ။

ဒေါ်: - မဟုတ်ပါ၊ ဗီဒီယိုနှင့်ပတ်သက်သည့် အကြောင်းအရာတွင် ကျွန်ုပ်တွင် ဘာမှမရှိပါ။ ၎င်းကို "Look+" ဟုခေါ်သည် - ၎င်းသည် အပလီကေးရှင်း၏အမည်ဖြစ်သည်။

IN: - အဲဒါကို ဖောက်သည်တွေဆီ လွှင့်နေတယ်လို့ မင်းပြောခဲ့တာလား။

ဒေါ်: - ကျွန်ုပ်တို့သည် ဗီဒီယိုကြည့်ရှုခြင်းတွင် မပါဝင်ပါ။ ဒါကို Megafon က လုံးဝလုပ်ဆောင်ခဲ့တာပါ။ ဟုတ်ကဲ့၊ လျှောက်လွှာကို MegaFon လို့ မပြောခဲ့ပါဘူး။

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

ကြော်ငြာအချို့ 🙂

ကျွန်ုပ်တို့နှင့်အတူရှိနေသည့်အတွက် ကျေးဇူးတင်ပါသည်။ ကျွန်ုပ်တို့၏ဆောင်းပါးများကို သင်နှစ်သက်ပါသလား။ ပိုစိတ်ဝင်စားစရာကောင်းတဲ့ အကြောင်းအရာတွေကို ကြည့်ချင်ပါသလား။ မှာယူမှုတစ်ခုပြုလုပ်ခြင်း သို့မဟုတ် သူငယ်ချင်းများကို အကြံပြုခြင်းဖြင့် ကျွန်ုပ်တို့အား ပံ့ပိုးကူညီပါ၊ $4.99 မှ developer များအတွက် cloud VPS, မင်းအတွက် ငါတို့က တီထွင်ထားတဲ့ entry-level server တွေရဲ့ ထူးခြားတဲ့ analogue တစ်ခု။ VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps သို့မဟုတ် $19 မှ ဆာဗာတစ်ခုမျှဝေပုံနှင့်ပတ်သက်သော အမှန်တရားတစ်ခုလုံး။ (RAID1 နှင့် RAID10၊ 24 cores အထိနှင့် 40GB DDR4 အထိ)။

အမ်စတာဒမ်ရှိ Equinix Tier IV ဒေတာစင်တာတွင် Dell R730xd သည် ၂ ဆ စျေးသက်သာသည်။ ဒီမှာသာ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ကို $199 မှ နယ်သာလန်မှာ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 မှ။ အကြောင်းဖတ်ပါ။ Infrastructure Corp ကို ဘယ်လိုတည်ဆောက်မလဲ။ တစ်ပြားတစ်ချပ်အတွက် ယူရို ၉၀၀၀ တန် Dell R730xd E5-2650 v4 ဆာဗာများကို အသုံးပြုခြင်း။

source: www.habr.com