NDC လန်ဒန်ညီလာခံ။ အသေးစားဝန်ဆောင်မှု ဘေးအန္တရာယ်ကို ကာကွယ်ပေးခြင်း။ အပိုင်း 1

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

၎င်း၏ဟောပြောချက်တွင်၊ Jimmy Bogard သည် လက်တွေ့ဘဝတွင် အသေးစားဝန်ဆောင်မှုဆိုင်ရာ ဘေးဥပဒ်တစ်ခုနှင့်ပတ်သက်၍ "သေမှုသေခင်း" ကို လုပ်ဆောင်မည်ဖြစ်သည်။ သူရှာဖွေတွေ့ရှိခဲ့သော မော်ဒယ်လ်၊ ဖွံ့ဖြိုးတိုးတက်မှုနှင့် ထုတ်လုပ်ရေးဆိုင်ရာ ပြဿနာများနှင့် သူ၏အဖွဲ့သည် ဖြန့်ဝေထားသော monolith အသစ်ကို သန့်ရှင်းမှု၏ နောက်ဆုံးပုံအဖြစ်သို့ ဖြည်းညှင်းစွာ ပြောင်းလဲပုံတို့ကို ပြသမည်ဖြစ်သည်။ ဒီဇိုင်းအမှားအယွင်းများကို လုံးဝကာကွယ်ရန် မဖြစ်နိုင်သော်လည်း၊ နောက်ဆုံးထုတ်ကုန်သည် ယုံကြည်စိတ်ချရသော ဖြန့်ဝေမှုစနစ်ဖြစ်လာစေရန် သေချာစေရန် ဒီဇိုင်းလုပ်ငန်းစဉ်တွင် ပြဿနာများကို အနည်းဆုံး ဖော်ထုတ်နိုင်သည်။

အားလုံးပဲမင်္ဂလာပါ ကျွန်တော်ကတော့ Jimmy ပါ၊ ဒီနေ့ microservice တွေဆောက်တဲ့အခါ ကြီးမားတဲ့ဘေးအန္တရာယ်တွေကို ဘယ်လိုရှောင်ရှားနိုင်မလဲဆိုတာကို သင်ကြားရတော့မှာပါ။ ဒီဇာတ်လမ်းဟာ သူတို့ရဲ့ သင်္ဘောကို ရေခဲတောင်နဲ့ တိုက်မိခြင်းမှ ကာကွယ်ဖို့ တစ်နှစ်ခွဲလောက် အလုပ်လုပ်ခဲ့တဲ့ ကုမ္ပဏီတစ်ခုရဲ့ ဇာတ်လမ်းပါ။ ဤဇာတ်လမ်းကို မှန်ကန်စွာပြောပြရန်၊ ကျွန်ုပ်တို့သည် အချိန်ကိုပြန်သွားကာ ဤကုမ္ပဏီစတင်ခဲ့သည့်နေရာနှင့် ၎င်း၏ IT အခြေခံအဆောက်အအုံသည် အချိန်နှင့်အမျှ ကြီးထွားလာပုံအကြောင်း ဆွေးနွေးရမည်ဖြစ်သည်။ ဤဘေးအန္တရာယ်တွင် အပြစ်မဲ့သူများ၏အမည်များကို ကာကွယ်ရန်၊ ဤကုမ္ပဏီ၏အမည်ကို Bell Computers ဟု ပြောင်းလဲလိုက်ပါသည်။ နောက်ဆလိုက်တွင် ထိုကဲ့သို့သောကုမ္ပဏီများ၏ အိုင်တီအခြေခံအဆောက်အအုံသည် 90s အလယ်ပိုင်းတွင် မည်သို့မည်ပုံရှိသည်ကို ပြသသည်။ ၎င်းသည် ကွန်ပြူတာ ဟာ့ဒ်ဝဲစတိုးကို လည်ပတ်ရန်အတွက် ကြီးမားသော universal အမှား-ခံနိုင်ရည်ရှိသော HP Tandem Mainframe ဆာဗာ၏ ပုံမှန်ဗိသုကာတစ်ခုဖြစ်သည်။

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

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

ကနဦးဒီဇိုင်းသည် အလွန်ကောင်းမွန်ပြီး ထိပ်တန်းအဆင့်ဆိုက် bell.com နှင့် တစ်ဦးချင်းအပလီကေးရှင်းများအတွက် catalog.bell.com၊ accounts.bell.com၊ orders.bell.com၊ ထုတ်ကုန်ရှာဖွေမှု search.bell တို့ ပါဝင်ပါသည်။ com ။ ဒိုမိန်းခွဲတစ်ခုစီသည် ASP.Net 1.0 မူဘောင်နှင့် ၎င်း၏ကိုယ်ပိုင်ဒေတာဘေ့စ်များကို အသုံးပြုခဲ့ပြီး ၎င်းတို့အားလုံးသည် စနစ်နောက်ခံနှင့် စကားပြောဆိုခဲ့ကြသည်။ သို့သော်၊ အမှိုက်အားလုံးကျန်ရှိနေသည့် ကြီးမားသော ပင်မဘောင်တစ်ခုအတွင်းတွင် အမိန့်အားလုံးကို ဆက်လက်လုပ်ဆောင်ပြီး လုပ်ဆောင်နေသော်လည်း ရှေ့ဆုံးတွင် သီးခြားအပလီကေးရှင်းများနှင့် သီးခြားဒေတာဘေ့စ်များပါရှိသော သီးခြားဝဘ်ဆိုက်များဖြစ်သည်။

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

အစိတ်အပိုင်းအားလုံးကို တစ်ခုနှင့်တစ်ခု ခေါ်ဆိုမှုများ၊ API များကို ဝင်ရောက်အသုံးပြုသည်၊ မြှုပ်သွင်းထားသော ပြင်ပအဖွဲ့အစည်း dll များနှင့် အခြားအရာများအားလုံးကို လိပ်စာပေးထားသည်။ ဗားရှင်းထိန်းချုပ်မှုစနစ်များသည် တစ်စုံတစ်ဦး၏ကုဒ်ကို ဖမ်းယူကာ ပရောဂျက်အတွင်း တွန်းချကာ အရာအားလုံး ပျက်သွားတတ်သည်။ MS SQL Server 2005 သည် လင့်ခ်ဆာဗာများ၏ သဘောတရားကို အသုံးပြုထားပြီး၊ ဆလိုက်ပေါ်ရှိ မြှားများကို ကျွန်ုပ်မပြသော်လည်း၊ ဒေတာဘေ့စ်တစ်ခုစီသည် ဒေတာဘေ့စ်အများအပြားမှရရှိသောဒေတာကိုအခြေခံ၍ ဇယားများတည်ဆောက်ခြင်းတွင် အမှားအယွင်းမရှိသောကြောင့် ဒေတာဘေ့စ်တစ်ခုစီသည် အပြန်အလှန်ပြောဆိုခဲ့ကြသည်။

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

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

လက်ရှိအက်ပလီကေးရှင်းသည် 15 နှစ်ကြာထုတ်လုပ်ထားပြီး ASP.Net-based applications များအတွက်စံချိန်တင်ထားသည်။ ဝန်ဆောင်မှုသည် ကမ္ဘာတစ်ဝှမ်းမှ မှာယူမှုများကို လက်ခံခဲ့ပြီး ဤတစ်ခုတည်းသော အက်ပ်လီကေးရှင်းမှ နှစ်စဉ်ဝင်ငွေသည် ဒေါ်လာတစ်ဘီလီယံအထိ ရောက်ရှိခဲ့သည်။ အမြတ်၏ သိသာထင်ရှားသော အစိတ်အပိုင်းကို bell.com ဝဘ်ဆိုဒ်မှ ထုတ်ပေးခဲ့သည်။ Black Fridays တွင်၊ site မှတဆင့်မှာယူသောအရေအတွက်သည်သန်းပေါင်းများစွာရောက်ရှိခဲ့သည်။ သို့သော်၊ စနစ်ဒြပ်စင်များ၏ တင်းကျပ်သော အပြန်အလှန်ချိတ်ဆက်မှုများသည် ဝန်ဆောင်မှုအတွက် မည်သည့်ပြောင်းလဲမှုမှ ပြုလုပ်ခွင့်မပြုသောကြောင့် လက်ရှိဗိသုကာလက်ရာသည် မည်သည့်တိုးတက်မှုကိုမျှ ခွင့်မပြုခဲ့ပေ။

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

သူတို့သည် အလားတူပြဿနာကို မည်သို့ဖြေရှင်းခဲ့သည်ကို သိရှိရန် အခြားကုမ္ပဏီများကို ကြည့်ရှုခြင်းဖြင့် စမတ်ကျသောအရာကို လုပ်ဆောင်ခဲ့သည်။ ဤဖြေရှင်းနည်းများထဲမှတစ်ခုမှာ API တစ်ခုနှင့် ပြင်ပဒေတာဘေ့စ်မှတစ်ဆင့် ချိတ်ဆက်ထားသော microservices များပါ၀င်သော Netflix ဝန်ဆောင်မှုတည်ဆောက်ပုံဖြစ်သည်။

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

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

သူတို့ဟာ ဒီပြဿနာကို ဖြေရှင်းရာမှာ သူတို့ရဲ့ ပိုက်ဆံအားလုံးကို ပစ်ချဖို့ ထက်မြက်ပါတယ်။ ၎င်းတို့သည် ခလုတ်များဖြင့် ခေတ်အမီဆုံး ဆာဗာများကို တပ်ဆင်ခဲ့သည်၊ gigabit optical fiber သုံးထားသော၊ အားအပြင်းဆုံး RAM ပမာဏရှိသော ဆာဗာ ဟာ့ဒ်ဝဲကို တပ်ဆင်ထားပြီး၊ ၎င်းအားလုံးကို ချိတ်ဆက်ထားပြီး၊ ၎င်းကို ပြုပြင်ပေးသည် - နှင့် ထပ်ပြီး ဘာမှ မဖြစ်ပါ။ ထို့နောက်တွင် အကြောင်းအရင်းသည် အချိန်ကုန်သွားခြင်းဖြစ်နိုင်သည်ဟု သံသယရှိလာကြသည်၊ ထို့ကြောင့် ၎င်းတို့သည် ဝဘ်ဆက်တင်များအားလုံးကို၊ API ဆက်တင်များအားလုံးကို ဝင်ရောက်ကာ အမြင့်ဆုံးတန်ဖိုးများအဖြစ် အချိန်ကုန်သတ်မှတ်မှုကို အပ်ဒိတ်လုပ်ကာ တစ်ခုခုဖြစ်မလာစေရန် ထိုင်စောင့်နေလိုက်ကြသည်။ site သို့။ ဝဘ်ဆိုဒ်ကို နောက်ဆုံးတင်မပြီးမချင်း ၉ မိနစ်ခွဲလောက် စောင့်ပြီး စောင့်နေကြတယ်။

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

ကျွန်ုပ်တို့တွင် သဲလွန်စများစွာရှိခဲ့ပြီး ၎င်းတို့ထဲမှတစ်ခုမှာ API ခေါ်ဆိုချိန်တွင် လမ်းကြောင်းများပြည့်နှက်နေပါသည်။ သင် monolithic ဝန်ဆောင်မှုဗိသုကာကိုအသုံးပြုသောအခါ၊ သင့်တွင်ပျက်ကွက်မှုဖြစ်စေနိုင်သည့်အရာအားလုံးကိုအစီရင်ခံသည့်တစ်ခုတည်းသောခြေရာတစ်ခုရှိသောကြောင့်သင်ချက်ချင်းနားလည်နိုင်သည် ။ ဝန်ဆောင်မှုများစွာသည် တူညီသော API ကိုတစ်ပြိုင်နက်ဝင်ရောက်သည့်အခါတွင်၊ WireShark ကဲ့သို့သော ကွန်ရက်စောင့်ကြည့်ရေးကိရိယာများကို အသုံးပြုရန်မှလွဲ၍ သဲလွန်စကို ခြေရာခံရန် နည်းလမ်းမရှိပေ။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် ဝဘ်စာမျက်နှာတစ်ခုကိုယူ၍ ပဟေဠိအပိုင်းအစများကို ပေါင်းထည့်ကာ အမျိုးမျိုးသောဖုန်းခေါ်ဆိုမှုများပြုလုပ်ကာ ၎င်းတို့တစ်ဦးစီဖြစ်ပေါ်လာပုံကို ခွဲခြမ်းစိတ်ဖြာကာ ၂ ပတ်နီးပါးကြာအောင် အချိန်ယူခဲ့ရသည်။
ဒီပုံကိုကြည့်ပါ။ ပြင်ပတောင်းဆိုချက်တစ်ခုက ဝန်ဆောင်မှုကို ပြန်ပို့သည့်အတွင်းပိုင်းခေါ်ဆိုမှုများစွာကို ပြုလုပ်ရန် အချက်ပြသည်။ လိုအပ်သောအချက်အလက်များကိုရယူရန် အခြားမည်သည့်နေရာမှ မလှည့်နိုင်သောကြောင့် ဤတောင်းဆိုချက်ကို လွတ်လပ်စွာ ဝန်ဆောင်မှုပေးနိုင်စေရန် အတွင်းပိုင်းခေါ်ဆိုမှုတစ်ခုစီသည် ထပ်လောင်း hops များပြုလုပ်ပေးကြောင်း တွေ့ရှိရပါသည်။ ပြင်ပတောင်းဆိုချက်သည် အပိုဝန်ဆောင်မှုများကိုခေါ်ဆိုသည်၊ အခြားအပိုဝန်ဆောင်မှုများကိုခေါ်ဆိုသော၊ အစရှိသည်ဖြင့် ကြော်ငြာအကန့်အသတ်မရှိနီးပါးခေါ်ဆိုသောကြောင့် ဤပုံသည် အဓိပ္ပါယ်မဲ့ခေါ်ဆိုမှုများနှင့်တူပါသည်။

ဤပုံတွင်ရှိသော အစိမ်းရောင်သည် ဝန်ဆောင်မှုများ တစ်ခုနှင့်တစ်ခု ခေါ်ဆိုသည့် စက်ဝိုင်းခြမ်းတစ်ခုကို ပြသသည် - ဝန်ဆောင်မှု A ခေါ်ဆိုမှု ဝန်ဆောင်မှု B၊ ဝန်ဆောင်မှု B က ဝန်ဆောင်မှု C နှင့် ၎င်းသည် ဝန်ဆောင်မှု A ကို ထပ်မံခေါ်ဆိုပါသည်။ ရလဒ်အနေဖြင့် ကျွန်ုပ်တို့သည် “ဖြန့်ဝေသော မသေမချာ” ကို ရရှိပါသည်။ တောင်းဆိုချက်တစ်ခုသည် ကွန်ရက် API ခေါ်ဆိုမှုပေါင်း ထောင်ဂဏန်းကို ဖန်တီးခဲ့ပြီး စနစ်တွင် တပ်ဆင်ထားသော အမှားအယွင်းခံနိုင်ရည်နှင့် လှည့်ပတ်ကာကွယ်မှု မရှိသောကြောင့်၊ ဤ API ခေါ်ဆိုမှုတစ်ခုမှပင် မအောင်မြင်ပါက တောင်းဆိုချက်သည် ကျရှုံးမည်ဖြစ်သည်။

ကျွန်တော်တို့ သင်္ချာတချို့ လုပ်ခဲ့တယ်။ API ခေါ်ဆိုမှုတစ်ခုစီတွင် 150 ms ထက်မပိုသော SLA နှင့် 99,9% ဖွင့်ချိန်ရှိသည်။ တောင်းဆိုချက်တစ်ခုသည် မတူညီသောခေါ်ဆိုမှုပေါင်း 200 ကိုဖြစ်ပေါ်စေပြီး အကောင်းဆုံးအခြေအနေတွင်၊ စာမျက်နှာကို 200 x 150 ms = 30 စက္ကန့်အတွင်း ပြသနိုင်သည်။ ထုံးစံအတိုင်း၊ ဒါက မကောင်းဘူး။ 99,9% အလုပ်ချိန်ကို 200 ဖြင့် မြှောက်ခြင်းဖြင့် ကျွန်ုပ်တို့ 0% ရရှိနိုင်မှုကို ရရှိပါသည်။ ဤဗိသုကာလက်ရာသည် အစကတည်းက ကျရှုံးခြင်းသို့ ရောက်သွားကြောင်း တွေ့ရှိရပေသည်။

ကျွန်ုပ်တို့သည် ဆော့ဖ်ဝဲအင်ဂျင်နီယာများကို 18 လကြာအလုပ်လုပ်ပြီးနောက်ဤပြဿနာကိုမည်သို့အသိအမှတ်ပြုရန်ပျက်ကွက်သနည်းဟုမေးသည်။ ၎င်းတို့သည် ၎င်းတို့လည်ပတ်သည့်ကုဒ်အတွက် SLA ကိုသာ ရေတွက်ခဲ့သော်လည်း ၎င်းတို့၏ဝန်ဆောင်မှုကို အခြားဝန်ဆောင်မှုဟု ခေါ်ပါက၊ ၎င်းတို့၏ SLA တွင် ထိုအချိန်ကို ထည့်သွင်းမတွက်ခဲ့ပေ။ လုပ်ငန်းစဉ်တစ်ခုအတွင်း စတင်လုပ်ဆောင်သည့်အရာအားလုံးသည် 150 ms တန်ဖိုးနှင့် ကိုက်ညီသော်လည်း အခြားဝန်ဆောင်မှုလုပ်ငန်းစဉ်များသို့ ဝင်ရောက်ခွင့်သည် စုစုပေါင်းနှောင့်နှေးမှုကို အဆများစွာ တိုးမြင့်စေသည်။ ပထမသင်ခန်းစာမှာ- "မင်းရဲ့ SLA ကို ထိန်းချုပ်ထားသလား၊ ဒါမှမဟုတ် SLA က မင်းကို ထိန်းချုပ်ထားတာလား။" ငါတို့ကိစ္စမှာ၊ အဲဒါက နောက်ဆုံးပဲ။

ကျွန်ုပ်တို့ရှာဖွေတွေ့ရှိခဲ့သည့်နောက်တစ်ခုမှာ Peter Deitch နှင့် James Gosling တို့က ပုံဖော်ထားသည့် ဖြန့်ဝေထားသော တွက်ချက်မှုဆိုင်ရာ အယူအဆလွဲမှားမှုများကို ၎င်းတို့ သိရှိခဲ့ကြသော်လည်း ပထမပိုင်းကို လျစ်လျူရှုခဲ့ကြသည်။ ထုတ်ပြန်ချက်များသည် "ကွန်ရက်သည် ယုံကြည်စိတ်ချရသော၊" "သုည latency" နှင့် "infinite throughput" တို့သည် အထင်အမြင်လွဲမှားမှုများဖြစ်ကြောင်း ၎င်းကဆိုသည်။ အခြားအထင်အမြင်လွဲမှားမှုများတွင် "ကွန်ရက်သည် လုံခြုံသည်၊၊" "ထိပ်ပိုင်းဗေဒသည် ဘယ်သောအခါမှမပြောင်းလဲ၊" "စီမံခန့်ခွဲသူတဦးတည်းသာရှိပါသည်"၊ "ဒေတာလွှဲပြောင်းမှုကုန်ကျစရိတ်သည် သုညဖြစ်သည်" နှင့် "ကွန်ရက်သည် တစ်သားတည်းဖြစ်နေပါသည်။"
၎င်းတို့သည် ပြည်တွင်းစက်များတွင် ၎င်းတို့၏ဝန်ဆောင်မှုကို စမ်းသပ်ပြီး ပြင်ပဝန်ဆောင်မှုများနှင့် ဘယ်သောအခါမှ မချိတ်ဆက်နိုင်သောကြောင့် အမှားအယွင်းရှိခဲ့သည်။ ပြည်တွင်း၌ ဖွံ့ဖြိုးတိုးတက်ပြီး ဒေသဆိုင်ရာ ကက်ရှ်တစ်ခုကို အသုံးပြုသောအခါတွင် ၎င်းတို့သည် ကွန်ရက်ဟော့စ်များကို ဘယ်သောအခါမှ မကြုံတွေ့ခဲ့ကြပေ။ ဖွံ့ဖြိုးတိုးတက်မှု 18 လလုံးတွင် ပြင်ပဝန်ဆောင်မှုများ ထိခိုက်ပါက ဘာဖြစ်နိုင်သည်ကို ၎င်းတို့ တစ်ခါမျှ မတွေးဖူးပါ။

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

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

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

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

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

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

မိုက်ခရိုဝန်ဆောင်မှုများသို့ ပြောင်းရွှေ့ခြင်းသည် ၎င်းတို့၏ အတွင်းပိုင်း N-tier ရုပ်ပိုင်းဆိုင်ရာ အလွှာ အခြေခံအဆောက်အအုံကို ယူပြီး ၎င်းတွင် Docker ကို ကပ်ထားသကဲ့သို့ လွယ်ကူသည်ဟု ၎င်းတို့က ယုံကြည်ခဲ့သည်။ ရိုးရာ N-tier ဗိသုကာပုံသဏ္ဌာန်ကို လေ့လာကြည့်ရအောင်။

၎င်းတွင် အဆင့် 4 ဆင့် ပါ၀င်သည်- UI အသုံးပြုသူ အင်တာဖေ့စ်အဆင့်၊ လုပ်ငန်းယုတ္တိအဆင့်၊ ဒေတာဝင်ရောက်ခွင့်အဆင့်နှင့် ဒေတာဘေ့စ်။ ပိုမိုတိုးတက်ကောင်းမွန်သည်မှာ DDD (Domain-Driven Design) သို့မဟုတ် အလယ်အလတ်အဆင့်နှစ်ခုမှာ domain objects နှင့် repository တစ်ခုဖြစ်သည့် software-oriented architecture ဖြစ်သည်။

အပြောင်းအလဲရဲ့ မတူညီတဲ့ နယ်ပယ်တွေ၊ ဒီဗိသုကာမှာ တာဝန်ရှိတဲ့ နယ်ပယ်အသီးသီးကို ကြည့်ဖို့ ကြိုးစားခဲ့တယ်။ ပုံမှန် N-tier အပလီကေးရှင်းတစ်ခုတွင်၊ တည်ဆောက်ပုံအား အပေါ်မှအောက်ခြေအထိ ဒေါင်လိုက်စိမ့်ဝင်စေသော ပြောင်းလဲမှု၏ မတူညီသော နယ်ပယ်များကို အမျိုးအစားခွဲခြားထားသည်။ ၎င်းတို့သည် ကွန်ပျူတာတစ်လုံးချင်းစီတွင် လုပ်ဆောင်ခဲ့သော Catalog၊ Config ဆက်တင်များနှင့် ကျွန်ုပ်၏အဖွဲ့မှ ကိုင်တွယ်သည့် Checkout စစ်ဆေးမှုများဖြစ်သည်။

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

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

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

ဤဂုဏ်သတ္တိများအားလုံးကို “ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်” ဟူသော စကားလုံးတစ်လုံးတည်းဖြင့် ဖော်ပြနိုင်သည်။ ဝန်ဆောင်မှုများသည် တစ်ခုနှင့်တစ်ခု အမှီအခိုကင်းစွာ လုပ်ကိုင်ကြပြီး အချို့သော ကန့်သတ်ချက်များကို ကျေနပ်စေကာ ၎င်းတို့လိုအပ်သော အချက်အလက်များကို လူများရရှိနိုင်သည့် အခြေခံဖြင့် စာချုပ်များကို သတ်မှတ်ပေးသည်။ တိကျတဲ့နည်းပညာတွေကို မသုံးတတ်ဘူးဆိုတာ ထင်ရှားပါတယ်။

အခု microservices တွေရဲ့ အဓိပ္ပါယ်ဖွင့်ဆိုချက်ကို ကြည့်ရအောင်။

• microservice သည် သေးငယ်ပြီး သီးခြားပြဿနာတစ်ခုကို ဖြေရှင်းရန် ဒီဇိုင်းထုတ်ထားသည်။
• အသေးစားဝန်ဆောင်မှုသည် ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရှိသည်။
• မိုက်ခရိုဆားဗစ်ဗိသုကာကို ဖန်တီးသောအခါ၊ မြို့ပြစီမံကိန်းအလင်္ကာကို အသုံးပြုသည်။ ဤသည်မှာ Sam Newman ၏ Building Microservices စာအုပ်မှ အဓိပ္ပါယ်ဖွင့်ဆိုချက်ဖြစ်သည်။

Bounded Context ၏ အဓိပ္ပါယ်ဖွင့်ဆိုချက်ကို Eric Evans ၏ Domain-Driven Design စာအုပ်မှ ကောက်နှုတ်ထားပါသည်။ ၎င်းသည် ထုထည်ကြီးမားသော ဗိသုကာပုံစံများနှင့်အတူ လုပ်ဆောင်သည့် ဗိသုကာဒီဇိုင်းစင်တာ DDD ရှိ ပင်မပုံစံတစ်ခုဖြစ်ပြီး ၎င်းတို့ကို မတူညီသောစည်းနှောင်ထားသော အကြောင်းအရာများအဖြစ် ပိုင်းခြားကာ ၎င်းတို့ကြားရှိ အပြန်အလှန်ဆက်သွယ်မှုများကို ပြတ်သားစွာသတ်မှတ်ထားသည်။

ရိုးရိုးရှင်းရှင်းပြောရလျှင်၊ Bounded Context သည် သီးခြား module တစ်ခုကို အသုံးပြုနိုင်သည့် နယ်ပယ်ကို ရည်ညွှန်းသည်။ ဤအကြောင်းအရာအတွင်းတွင်၊ ဥပမာ၊ သင့်လုပ်ငန်းဒိုမိန်းတွင် မြင်နိုင်သော ယုတ္တိနည်းကျကျ ပေါင်းစပ်ထားသော မော်ဒယ်တစ်ခုဖြစ်သည်။ အမှာစာများတွင်ပါ၀င်သော ဝန်ထမ်းများအား "မည်သူသည် ဖောက်သည်ဖြစ်သနည်း" ဟု မေးပါက၊ အရောင်းတွင် ပါ၀င်သူများကို မေးပါက၊ နောက်တစ်ခုရမည်ဖြစ်ပြီး၊ ဖျော်ဖြေသူများသည် သင့်အား တတိယအဓိပ္ပါယ်ကို ပေးမည်ဖြစ်သည်။

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

Microservice ၏နောက်ထပ်အဓိပ္ပါယ်မှာ အလုပ်လုပ်ငန်းစဉ်၏ အစိတ်အပိုင်းများ ပတ်ဝန်းကျင်သို့ “ယိုစိမ့်မှု” ကို ဟန့်တားသည့် မည်သည့်အတွင်းပိုင်း လည်ပတ်ဆောင်ရွက်မှုမျိုးမဆို ကုပ်ကုပ်ထည့်ထားခြင်း ဖြစ်ပါသည်။ ထို့နောက်တွင် SLAs မှပြန်လာသော စာချုပ်များ၏ စိတ်ကူးဖြင့် ကိုယ်စားပြုသည့် "ပြင်ပဆက်သွယ်မှုများ သို့မဟုတ် ပြင်ပဆက်သွယ်ရေးများအတွက် တိကျပြတ်သားသော စာချုပ်များ၏ အဓိပ္ပါယ်ဖွင့်ဆိုချက်" ဖြစ်သည်။ နောက်ဆုံး အဓိပ္ပါယ်ဖွင့်ဆိုချက်မှာ ဆဲလ်တစ်ခု သို့မဟုတ် ဆဲလ်တစ်ခုဖြစ်ပြီး၊ ဆိုလိုသည်မှာ microservice တစ်ခုအတွင်း လည်ပတ်မှုအစုအဝေးတစ်ခု၏ ပြီးပြည့်စုံသော encapsulation နှင့် ပြင်ပကမ္ဘာနှင့် ဆက်သွယ်ရန်အတွက် receptors များရှိနေခြင်းတို့ကို ဆိုလိုသည်။

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

၀၆း၀၀ မိနစ်

မကြာမီ ဆက်လက်ဖော်ပြပါမည်...

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

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