QCon ညီလာခံ။ ပရမ်းပတာကျွမ်းကျင်ခြင်း- Microservices အတွက် Netflix လမ်းညွှန်။ အပိုင်း ၄

Josh Evans သည် အခြေခံအချက်များ - အသေးစားဝန်ဆောင်မှုများ၏ ခန္ဓာဗေဒ၊ ဖြန့်ဝေမှုစနစ်များနှင့် သက်ဆိုင်သည့် စိန်ခေါ်မှုများနှင့် ၎င်းတို့၏ အကျိုးကျေးဇူးများကို စတင်ခြင်းဖြင့် Netflix microservices ၏ ဖရိုဖရဲနှင့် အရောင်အသွေးစုံလင်သော ကမ္ဘာအကြောင်း ဆွေးနွေးသည်။ ဤအခြေခံအုတ်မြစ်ကို တည်ဆောက်ခြင်းဖြင့် အသေးစားဝန်ဆောင်မှုကို ကျွမ်းကျင်ပိုင်နိုင်စွာ ဦးဆောင်နိုင်စေမည့် ယဉ်ကျေးမှု၊ ဗိသုကာနှင့် လုပ်ငန်းလည်ပတ်မှုဆိုင်ရာ အလေ့အကျင့်များကို စူးစမ်းလေ့လာသည်။

QCon ညီလာခံ။ ပရမ်းပတာကျွမ်းကျင်ခြင်း- Microservices အတွက် Netflix လမ်းညွှန်။ အပိုင်း ၄
QCon ညီလာခံ။ ပရမ်းပတာကျွမ်းကျင်ခြင်း- Microservices အတွက် Netflix လမ်းညွှန်။ အပိုင်း ၄
QCon ညီလာခံ။ ပရမ်းပတာကျွမ်းကျင်ခြင်း- Microservices အတွက် Netflix လမ်းညွှန်။ အပိုင်း ၄

လုပ်ငန်းလည်ပတ်မှု ပျံ့လွင့်ခြင်းနှင့်မတူဘဲ၊ ဝန်ဆောင်မှုဆိုင်ရာ နိုင်ငံတကာအသွင်ကူးပြောင်းမှုအတွက် ဘာသာစကားအသစ်များနှင့် ကွန်တိန်နာများကဲ့သို့သော နည်းပညာအသစ်များကို မိတ်ဆက်ခြင်းသည် ပတ်ဝန်းကျင်အတွက် ရှုပ်ထွေးမှုအသစ်များကို ပေါင်းထည့်ရန် သတိရှိရှိ ဆုံးဖြတ်ချက်များဖြစ်သည်။ Java နှင့် EC2 ကိုအခြေခံ၍ ကြိုတင်သတ်မှတ်ထားသော အကောင်းဆုံးအလေ့အကျင့်များအဖြစ် Netflix အတွက် အကောင်းဆုံးနည်းပညာလမ်းပြမြေပုံတွင် ကျွန်ုပ်၏လုပ်ငန်းဆောင်ရွက်မှုအဖွဲ့သည် စံပြုသတ်မှတ်ထားသော်လည်း လုပ်ငန်းကြီးထွားလာသည်နှင့်အမျှ developer များသည် Python၊ Ruby၊ Node-JS နှင့် Docker ကဲ့သို့သော အစိတ်အပိုင်းအသစ်များကို စတင်ထည့်သွင်းလာကြသည်။

ဖောက်သည်များ၏ တိုင်ကြားချက်များကို မစောင့်ဘဲ ကျွန်ုပ်တို့၏ထုတ်ကုန်ကို ကောင်းမွန်စွာလုပ်ဆောင်နိုင်စေရန်အတွက် ကျွန်ုပ်တို့သည် ပထမဆုံး ထောက်ခံအားပေးခဲ့ခြင်းအတွက် အလွန်ဂုဏ်ယူဝမ်းမြောက်မိပါသည်။ အားလုံးက ရိုးရှင်းလောက်ပါပြီ - ကျွန်ုပ်တို့တွင် Python နှင့် Ruby တွင် back-office application အချို့ရှိပါသည်၊ သို့သော် ကျွန်ုပ်တို့၏ဝဘ်ဆော့ဖ်ဝဲရေးသားသူများသည် JVM ကို စွန့်ပစ်ပြီး ဝဘ်ကို ရွှေ့တော့မည်ဟု ကြေညာသောအခါတွင် ပိုမိုစိတ်ဝင်စားစရာကောင်းလာသည်။ Node ဆော့ဖ်ဝဲလ်ပလပ်ဖောင်းသို့ အပလီကေးရှင်း။ js. Docker ကို မိတ်ဆက်ပြီးနောက်၊ အရာများသည် ပိုမိုရှုပ်ထွေးလာသည်။ ကျွန်ုပ်တို့သည် ယုတ္တိဗေဒကို လိုက်နာကြပြီး ၎င်းတို့သည် ဖောက်သည်များအတွက် အဓိပ္ပာယ်များစွာရှိသောကြောင့် ၎င်းတို့ကို ဖောက်သည်များအတွက် အကောင်အထည်ဖော်သောအခါတွင် ကျွန်ုပ်တို့ရရှိလာသော နည်းပညာများသည် လက်တွေ့ဖြစ်လာပါသည်။ ဘာကြောင့်ဒီလိုဖြစ်တာလဲ ပြောပြမယ်။

API Gateway သည် UI developer များအတွက် အဆုံးမှတ်များအဖြစ် လုပ်ဆောင်နိုင်သည့် ကောင်းမွန်သော script များကို ပေါင်းစပ်နိုင်စွမ်းရှိသည်။ ၎င်းတို့သည် အပြောင်းအလဲများပြုလုပ်ပြီးနောက် ၎င်းတို့ကို ထုတ်လုပ်ပြီးနောက် အသုံးပြုသူစက်ပစ္စည်းများသို့ အသုံးချနိုင်စေရန် ဤကဲ့သို့သောနည်းဖြင့် ဤစခရစ်တစ်ခုစီကို ပြောင်းခဲ့ပြီး၊ ဤပြောင်းလဲမှုအားလုံးကို API ဂိတ်ဝတွင် လုပ်ဆောင်သည့် အဆုံးမှတ်များနှင့် ထပ်တူပြုပါသည်။

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

ဤအဆုံးမှတ်များကို API ဝန်ဆောင်မှုမှ ဆွဲထုတ်ခြင်းသည် ယုတ္တိတန်ပါသည်။ ဒါကိုလုပ်ဖို့၊ Docker containers မှာ သေးငယ်တဲ့ အပလီကေးရှင်းတွေအဖြစ် အလုပ်လုပ်တဲ့ Node.js အစိတ်အပိုင်းတွေကို ဖန်တီးခဲ့ပါတယ်။ ၎င်းသည် ဤ node အပလီကေးရှင်းများကြောင့် ဖြစ်ပေါ်လာသော ပြဿနာများနှင့် ပျက်စီးမှုများကို ခွဲထုတ်နိုင်စေခဲ့သည်။

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

• ကုန်ထုတ်ကိရိယာများ။ နည်းပညာအသစ်များကို စီမံခန့်ခွဲရာတွင် UI အဖွဲ့သည် ထိရောက်သောပုံစံတစ်ခုဖန်တီးရန် အလွန်ကောင်းမွန်သော scripts များကိုအသုံးပြုကာ အခြေခံအဆောက်အအုံကို စီမံခန့်ခွဲရန် အချိန်များစွာမလိုအပ်ဘဲ scripts များရေးသားပြီး ၎င်းတို့၏လုပ်ဆောင်နိုင်စွမ်းကို စစ်ဆေးရန်သာရှိသောကြောင့် နည်းပညာအသစ်များကို စီမံခန့်ခွဲရာတွင် ကိရိယာအသစ်များလိုအပ်ပါသည်။
  Opportunity Insight and Sorting - အဓိကဥပမာတစ်ခုမှာ စွမ်းဆောင်ရည်ယာဉ်မောင်းအချက်အလက်ကို ဖော်ထုတ်ရန် လိုအပ်သော ကိရိယာအသစ်များဖြစ်သည်။ ပရိုဆက်ဆာကို မည်မျှသိမ်းပိုက်ထားသနည်း၊ မန်မိုရီကိုအသုံးပြုပုံနှင့် ဤအချက်အလက်များကို စုဆောင်းရာတွင် မတူညီသောကိရိယာများ လိုအပ်ကြောင်း သိရန် လိုအပ်သည်။
• အခြေခံပုံများကို အပိုင်းပိုင်းခွဲခြင်း - ရိုးရှင်းသော အခြေခံ AMI သည် ပိုမိုကွဲကွဲပြီး အထူးပြုလာသည်။
• Node စီမံခန့်ခွဲမှု။ cloud ရှိ node များကို စီမံခန့်ခွဲရန် ခွင့်ပြုသည့် ပြင်ပဗိသုကာ သို့မဟုတ် နည်းပညာများ မရရှိနိုင်သောကြောင့် ကျွန်ုပ်တို့သည် အတိုင်းအတာနှင့် ယုံကြည်စိတ်ချရသော ကွန်တိန်နာအသုံးပြုမှုနှင့် Amazon AWS နှင့် cloud ပေါင်းစပ်မှုကို ပံ့ပိုးပေးသည့် Titus ကို တည်ဆောက်ခဲ့သည်။
• စာကြည့်တိုက် သို့မဟုတ် ပလပ်ဖောင်းတစ်ခု၏ မိတ္တူ။ ပလက်ဖောင်း၏ တူညီသော အဓိကလုပ်ဆောင်နိုင်စွမ်းဖြင့် နည်းပညာအသစ်များကို ပံ့ပိုးပေးခြင်းဖြင့် ၎င်းကို cloud-based Node.js developer tools များအဖြစ် ပွားရန်လိုအပ်သည်။
• သင်ယူမှုမျဉ်းကွေးနှင့် စက်မှုအတွေ့အကြုံ။ နည်းပညာအသစ်များကို မိတ်ဆက်ခြင်းသည် ကျော်လွှားရမည့် စိန်ခေါ်မှုအသစ်များကို မလွဲမသွေ ဖန်တီးပေးပါသည်။

ထို့ကြောင့် ကျွန်ုပ်တို့သည် “ခင်းထားသောလမ်း” တစ်ခုတည်းကို ကန့်သတ်မထားနိုင်ဘဲ ကျွန်ုပ်တို့၏နည်းပညာများကို တိုးတက်စေမည့် နည်းလမ်းသစ်များကို အဆက်မပြတ်တည်ဆောက်နေရမည်ဖြစ်သည်။ ကုန်ကျစရိတ်များကို လျှော့ချရန်အတွက် ကျွန်ုပ်တို့သည် ဗဟိုမှပံ့ပိုးမှုကို ကန့်သတ်ထားပြီး JVM၊ node အသစ်များနှင့် Docker တို့ကို အာရုံစိုက်ထားပါသည်။ ကျွန်ုပ်တို့သည် ထိရောက်သောအကျိုးသက်ရောက်မှုကို ဦးစားပေးလုပ်ဆောင်ပြီး၊ ၎င်းတို့၏ဆုံးဖြတ်ချက်များအတွက် ကုန်ကျစရိတ်များအကြောင်း အဖွဲ့များအား အသိပေးထားပြီး၊ ၎င်းတို့ထုတ်လုပ်ထားပြီးဖြစ်သည့် အကျိုးသက်ရောက်မှုမြင့်မားသောဖြေရှင်းချက်များကို ပြန်လည်အသုံးပြုရန် နည်းလမ်းများကို ရှာဖွေရန် ၎င်းတို့အား တိုက်တွန်းထားသည်။ ထုတ်ကုန်ကို နိုင်ငံတကာဖောက်သည်များထံ အရောက်ပို့ပေးရန် ဝန်ဆောင်မှုကို နိုင်ငံခြားဘာသာစကားသို့ ဘာသာပြန်သောအခါတွင် ကျွန်ုပ်တို့သည် ဤချဉ်းကပ်မှုကို အသုံးပြုပါသည်။ ဥပမာများတွင် Python ဗားရှင်း၊ Ruby ဗားရှင်း၊ Java ဗားရှင်း စသည်ဖြင့် ဖန်တီးရန် အလွန်လွယ်ကူစေရန်အတွက် ရိုးရှင်းသော ကလိုင်းယင့်စာကြည့်တိုက်များ ပါဝင်ပါသည်။

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

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

ဆော့ဖ်ဝဲလ်တီထွင်ဆန်းသစ်မှုများကို အကောင်အထည်ဖော်ရာတွင် အရှိန်အဟုန်မြင့်မားစွာရရှိစေရန်၊ ဆိုလိုသည်မှာ ဝန်ဆောင်မှုပေးပို့ရာတွင် အနှောင့်အယှက်မဖြစ်စေဘဲ၊ ကျွန်ုပ်တို့၏ဖောက်သည်များအတွက် အဆင်မပြေမှုမဖြစ်စေဘဲ စနစ်သို့ အပြောင်းအလဲအသစ်များကို အဆက်မပြတ်ပြုလုပ်ခြင်းတို့ကို မည်သို့အောင်မြင်နိုင်မည်နည်း။ Netflix သည် ကမ္ဘာလုံးဆိုင်ရာ cloud-based စီမံခန့်ခွဲမှုနှင့် စဉ်ဆက်မပြတ် ပေးပို့ခြင်း (CD) ပလပ်ဖောင်းအသစ်ဖြစ်သော Spinnaker ကိုအသုံးပြုခြင်းဖြင့် ၎င်းကိုအောင်မြင်ခဲ့သည်။

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

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

တုန်လှုပ်ချောက်ချားစွာ ဖြန့်ချိခြင်းဆိုသည်မှာ ဒေသတစ်ခုတွင် ဖြန့်ချိမှုတစ်ခုတွင် ပြဿနာများရှိပါက၊ ကျွန်ုပ်တို့သည် အခြားဒေသတစ်ခုသို့ ပြောင်းရွှေ့ခြင်းကို ဆိုလိုပါသည်။ ဤကိစ္စတွင်၊ အထက်ဖော်ပြပါ စစ်ဆေးစာရင်းကို ထုတ်လုပ်မှုပိုက်လိုင်းတွင် ထည့်သွင်းရပါမည်။ ငါ မင်းကို အချိန်နည်းနည်း သက်သာစေပြီး ဒီအကြောင်းအရာကို နက်နက်နဲနဲ နက်နက်နဲနဲ တွေးကြည့်ချင်တယ်ဆိုရင် ငါ့ရဲ့ ယခင်ဟောပြောချက်ဖြစ်တဲ့ Engineering Global Netflix Operations in the Cloud ကို ကြည့်ဖို့ အကြံပြုလိုပါတယ်။ မိန့်ခွန်း၏ ဗီဒီယိုရိုက်ကူးမှုကို ဆလိုက်အောက်ခြေရှိ လင့်ခ်ကို လိုက်နာခြင်းဖြင့် ကြည့်ရှုနိုင်ပါသည်။

ဟောပြောချက်အဆုံးတွင်၊ Netflix ၏အဖွဲ့အစည်းနှင့် တည်ဆောက်ပုံအကြောင်း အတိုချုပ်ပြောပါမည်။ အစပိုင်းတွင် ကျွန်ုပ်တို့တွင် NRDP 1.x media streaming ၏ ပထမဆုံးဗားရှင်းဖြစ်သည့် Electronic Delivery ဟုခေါ်သော အစီအစဉ်တစ်ခုရှိသည်။ အသုံးပြုသူသည် နောက်ပိုင်းတွင် စက်ပေါ်တွင် ပြန်ဖွင့်ရန်အတွက်သာ အကြောင်းအရာများကို ဒေါင်းလုဒ်လုပ်နိုင်သောကြောင့် "backstream" ဟူသော အသုံးအနှုန်းကို ဤနေရာတွင် အသုံးပြုနိုင်ပါသည်။ Netflix ၏ ပထမဆုံး ဒစ်ဂျစ်တယ် ပို့ဆောင်မှု ပလပ်ဖောင်းသည် 2009 ခုနှစ် တွင် ဤကဲ့သို့ ဖြစ်သည် ။

အသုံးပြုသူစက်ပစ္စည်းတွင် NRDP ပလပ်ဖောင်း - Netflix Ready Device Platform ကိုအခြေခံ၍ UI အင်တာဖေ့စ်၊ လုံခြုံရေးမော်ဂျူးများ၊ ဝန်ဆောင်မှုအသက်သွင်းခြင်းနှင့် ပြန်ဖွင့်ခြင်းတို့ပါရှိသော Netflix အပလီကေးရှင်းပါရှိသည်။

ထိုအချိန်က user interface သည် အလွန်ရိုးရှင်းပါသည်။ ၎င်းတွင် Queque Reader ဟုခေါ်သည့်အရာပါ၀င်ပြီး အသုံးပြုသူသည် Queque တွင် တစ်ခုခုထည့်ပြီးနောက် ၎င်းတို့၏စက်ပေါ်ရှိ ပေါင်းထည့်ထားသည့်အကြောင်းအရာကို ကြည့်ရှုရန် ဝဘ်ဆိုက်သို့သွားမည်ဖြစ်သည်။ အပြုသဘောဆောင်သည့်အချက်မှာ ရှေ့ဆုံးအသင်းနှင့် နောက်တန်းအဖွဲ့သည် တူညီသော အီလက်ထရွန်းနစ် ပို့ဆောင်ရေးအဖွဲ့အစည်းနှင့် ရင်းနှီးစွာ အလုပ်လုပ်သော ဆက်ဆံရေးရှိခြင်းကြောင့်ဖြစ်သည်။ ပေးဆောင်မှုအား XML ကို အခြေခံ၍ ဖန်တီးထားသည်။ တစ်ချိန်တည်းမှာပင်၊ DVD လုပ်ငန်းအတွက် Netflix API ကို ဖန်တီးခဲ့ပြီး၊ ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုသို့ ပြင်ပအပလီကေးရှင်းများကို လမ်းကြောင်းပြရန် တွန်းအားပေးခဲ့သည်။

သို့သော်၊ Netflix API သည် အကြောင်းအရာအားလုံး၏ မက်တာဒေတာ၊ ရရှိနိုင်သည့်ရုပ်ရှင်များအကြောင်း အချက်အလက်များပါရှိသော ဆန်းသစ်သောအသုံးပြုသူမျက်နှာပြင်ကို ကူညီပေးရန်အတွက် ကောင်းမွန်စွာပြင်ဆင်ထားပြီး ကြည့်ရှုစာရင်းများကို ဖန်တီးနိုင်စေပါသည်။ ၎င်းတွင် JSON schema၊ HTTP Response Code၊ ခေတ်မီဗိသုကာတွင်အသုံးပြုသည့်တူညီသောပုံစံနှင့် Front-end အပလီကေးရှင်းအတွက် ထိုအချိန်က လိုအပ်သည့်အရာဖြစ်သည့် OAuth လုံခြုံရေးစံနမူနာကို အခြေခံ၍ ၎င်းတွင် ယေဘူယျ REST API တစ်ခုရှိသည်။ ၎င်းသည် အများသူငှာ တိုက်ရိုက်ထုတ်လွှင့်သည့် အကြောင်းအရာ ပေးပို့မှုပုံစံမှ သီးသန့်တစ်ခုသို့ ရွှေ့ရန် ဖြစ်နိုင်ချေရှိသည်။

အသွင်ကူးပြောင်းမှု၏ပြဿနာမှာ အကွဲကွဲအပြားပြားဖြစ်နေခြင်းဖြစ်သည်၊ ယခု ကျွန်ုပ်တို့၏စနစ်သည် လုံးဝကွဲပြားခြားနားသောလည်ပတ်မှုဆိုင်ရာမူများကိုအခြေခံ၍ ဝန်ဆောင်မှုနှစ်ခုကိုလုပ်ဆောင်ခဲ့သည် - တစ်ခုမှာ Rest၊ JSON နှင့် OAuth တွင်၊ နောက်တစ်ခုသည် RPC၊ XML နှင့် NTBA တိုကင်စနစ်ကိုအခြေခံသည့်အသုံးပြုသူလုံခြုံရေးယန္တရားတစ်ခုတို့ဖြစ်သည်။ ၎င်းသည် ပထမဆုံး ပေါင်းစပ်တည်ဆောက်မှုဖြစ်သည်။

API သည် ကနဦးတွင် NCCP နှင့် ကောင်းစွာ အတိုင်းအတာမရှိသောကြောင့် ကျွန်ုပ်တို့၏အဖွဲ့နှစ်ဖွဲ့ကြားတွင် firewall တစ်ခုရှိ၍ ၎င်းသည် အဖွဲ့များကြားတွင် ကွဲလွဲမှုများဖြစ်စေသည်။ ခြားနားချက်များမှာ ဝန်ဆောင်မှုများ၊ ပရိုတိုကောများ၊ ဆားကစ်များ၊ လုံခြုံရေး မော်ဂျူးများနှင့် ဆော့ဖ်ဝဲရေးဆွဲသူများသည် လုံးဝကွဲပြားခြားနားသော အကြောင်းအရာများကြားတွင် မကြာခဏ ပြောင်းရလေ့ရှိသည်။

ဒီကိစ္စနဲ့ ပတ်သက်ပြီးတော့ ကုမ္ပဏီရဲ့ အကြီးတန်း အင်ဂျင်နီယာတစ်ယောက်နဲ့ စကားစမြည်ပြောခဲ့ပြီး၊ “မှန်ကန်တဲ့ ရေရှည်တည်ဆောက်မှုပုံစံက ဘာဖြစ်သင့်သလဲ” လို့ မေးတဲ့ မေးခွန်းကို သူက တန်ပြန်မေးခွန်းကို မေးခဲ့တယ်- “မင်း ပိုစိုးရိမ်တာ ဖြစ်နိုင်တယ်။ အဖွဲ့အစည်းဆိုင်ရာ အကျိုးဆက်များအကြောင်း - ကျွန်ုပ်တို့သည် ဤအရာများကို ပေါင်းစည်းပြီး ကျွန်ုပ်တို့ ကောင်းစွာလုပ်ဆောင်ရန် သင်ယူထားသည့်အရာများကို ချိုးဖျက်ပါက မည်သို့ဖြစ်မည်နည်း။ ဤချဉ်းကပ်မှုသည် Conway's Law နှင့် အလွန်သက်ဆိုင်သည်- "အဖွဲ့အစည်း၏ ဆက်သွယ်ရေးဖွဲ့စည်းပုံကို ပုံတူကူးထားသည့် ဒီဇိုင်းပုံစံဖြင့် ဒီဇိုင်းစနစ်များကို ကန့်သတ်ထားသည်။" ဤသည်မှာ အလွန်နက်နဲသော အဓိပ္ပါယ်ဖွင့်ဆိုချက်ဖြစ်သည်၊ ထို့ကြောင့် ကျွန်ုပ်သည် ပိုမိုတိကျသောတစ်ခုကို နှစ်သက်ပါသည်- "ဆော့ဖ်ဝဲလ်၏ မည်သည့်အပိုင်းမဆို ၎င်းကို ဖန်တီးထားသည့် အဖွဲ့အစည်းဖွဲ့စည်းပုံကို ထင်ဟပ်စေပါသည်။" ဤသည်မှာ Eric Raymond ၏ အကြိုက်ဆုံးကိုးကားချက်ဖြစ်သည်- "သင့်တွင် compiler တစ်ခုတွင် developer လေးယောက်ရှိလျှင်၊ သင်သည် four-pass compiler ဖြင့်အဆုံးသတ်မည်ဖြစ်သည်။" ကောင်းပြီ၊ Netflix တွင် four-pass compiler ရှိပြီး၊ ၎င်းသည်ကျွန်ုပ်တို့အလုပ်လုပ်ပုံဖြစ်သည်။

ဤကိစ္စတွင် အမြီးသည် ခွေးကို လှုပ်ယမ်းနေသည်ဟု ဆိုနိုင်သည်။ ကျွန်ုပ်တို့၏ ပထမဦးစားပေးသည် ဖြေရှင်းချက်မဟုတ်ဘဲ အဖွဲ့အစည်းဖြစ်သည်၊ ကျွန်ုပ်တို့တွင်ရှိသော ဗိသုကာလက်ရာကို တွန်းအားပေးသည့် အဖွဲ့အစည်းဖြစ်သည်။ တဖြည်းဖြည်း၊ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုများထဲမှ Blade Runner ဟုခေါ်သော ဗိသုကာတစ်ခုသို့ ပြောင်းရွှေ့သွားသည်၊ အကြောင်းမှာ ဤနေရာတွင် ကျွန်ုပ်တို့သည် edge services နှင့် NCCP ၏စွမ်းရည်များကို Zuul proxy၊ API gateway နှင့် သက်ဆိုင်ရာ functional သို့ တိုက်ရိုက်ပေါင်းစည်းနိုင်သည့်စွမ်းရည်အကြောင်းပြောနေသောကြောင့်ဖြစ်သည်။ “အပိုင်းအစများ” ကို ပိုမိုအဆင့်မြင့်သော လုံခြုံရေး၊ ပြန်ဖွင့်ခြင်း၊ ဒေတာစီခြင်း စသည်တို့ပါရှိသော ဝန်ဆောင်မှုအသစ်များအဖြစ် ပြောင်းလဲထားပါသည်။

ထို့ကြောင့် ဌာနဆိုင်ရာဖွဲ့စည်းပုံများနှင့် ကုမ္ပဏီ၏ ဒိုင်းနမစ်များသည် စနစ်ဒီဇိုင်းပုံဖော်ရာတွင် အရေးပါသောအခန်းကဏ္ဍမှ ပါဝင်နေပြီး အပြောင်းအလဲကို အားပေးအားမြှောက်ပြုခြင်း သို့မဟုတ် ဟန့်တားသည့်အချက်ဖြစ်သည်ဟု ဆိုနိုင်ပါသည်။ Microservices ဗိသုကာလက်ရာသည် ရှုပ်ထွေးပြီး အော်ဂဲနစ်ဖြစ်ပြီး ၎င်း၏ကျန်းမာရေးသည် စည်းကမ်းနှင့် ပရမ်းပတာမိတ်ဆက်မှုအပေါ် အခြေခံထားသည်။

ကြော်ငြာနည်းနည်း

ကျွန်ုပ်တို့နှင့်အတူရှိနေသည့်အတွက် ကျေးဇူးတင်ပါသည်။ ကျွန်ုပ်တို့၏ဆောင်းပါးများကို သင်နှစ်သက်ပါသလား။ ပိုစိတ်ဝင်စားစရာကောင်းတဲ့ အကြောင်းအရာတွေကို ကြည့်ချင်ပါသလား။ မှာယူမှုတစ်ခုပြုလုပ်ခြင်း သို့မဟုတ် သူငယ်ချင်းများကို အကြံပြုခြင်းဖြင့် ကျွန်ုပ်တို့အား ပံ့ပိုးကူညီပါ၊ $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