Та өөрийн цул загвараа бичил үйлчилгээ болгон дахин зохион бүтээхэд хэдэн сар зарцуулсан бөгөөд эцэст нь бүгд нэг дор цугларч, шилжүүлэгчийг эргүүлэв. Та эхний вэб хуудас руу ороход... юу ч болохгүй. Та үүнийг дахин ачаална уу - дахин сайн зүйл байхгүй, сайт маш удаан байгаа тул хэдэн минутын турш хариу өгөхгүй байна. Юу болсон бэ?
Жимми Богард илтгэлдээ бодит амьдрал дээр тохиолдсон микро үйлчилгээний гамшгийн талаар "цаашид" шинжилгээ хийх болно. Тэрээр загварчлал, хөгжүүлэлт, үйлдвэрлэлийн асуудлуудыг нээсэн, түүний баг шинэ тархсан цул чулууг хэрхэн аажмаар эрүүл саруул байдлын эцсийн дүр зураг болгон хувиргасныг харуулах болно. Загварын алдаанаас бүрэн урьдчилан сэргийлэх боломжгүй ч гэсэн та эцсийн бүтээгдэхүүнийг найдвартай түгээх систем болгохын тулд дизайны үйл явцын эхэн үед асуудлыг тодорхойлж чадна.
Сайн байцгаана уу, намайг Жимми гэдэг бөгөөд өнөөдөр та бичил үйлчилгээ байгуулахдаа мега гамшгаас хэрхэн зайлсхийх талаар сонсох болно. Энэ бол миний хөлөг онгоцыг мөсөн уултай мөргөлдөхөөс урьдчилан сэргийлэхийн тулд жил хагасын турш ажилласан компаний түүх юм. Энэ түүхийг зөв ярихын тулд бид өнгөрсөн үе рүү буцаж, энэ компани хаанаас эхэлсэн, мэдээллийн технологийн дэд бүтэц нь цаг хугацааны явцад хэрхэн өссөн талаар ярих хэрэгтэй болно. Энэ гамшигт нэрвэгдээгүй хүмүүсийн нэрийг хамгаалахын тулд би энэ компанийн нэрийг Bell Computers болгон өөрчилсөн. Дараагийн слайд нь 90-ээд оны дундуур ийм компаниудын мэдээллийн технологийн дэд бүтэц ямар байсныг харуулж байна. Энэ бол компьютерийн техник хангамжийн дэлгүүр ажиллуулахад зориулагдсан том хэмжээний гэмтэлд тэсвэртэй HP Tandem Mainframe серверийн ердийн архитектур юм.
Тэд бүх захиалга, борлуулалт, өгөөж, бүтээгдэхүүний каталог, хэрэглэгчийн баазыг удирдах системийг бий болгох шаардлагатай байсан тул тухайн үеийн хамгийн түгээмэл үндсэн фрэймийн шийдлийг сонгосон. Энэхүү аварга систем нь компанийн талаархи бүх мэдээлэл, боломжтой бүх зүйлийг агуулж, гүйлгээ бүрийг энэхүү үндсэн фрэймээр дамжуулан гүйцэтгэдэг. Тэд бүх өндгөө нэг сагсанд хадгалсан бөгөөд энэ нь хэвийн зүйл гэж бодсон. Энд ороогүй цорын ганц зүйл бол шуудангийн захиалгын каталог, утсаар захиалга өгөх явдал юм.
Цаг хугацаа өнгөрөх тусам систем улам бүр томорч, асар их хэмжээний хог хаягдал хуримтлагдсан. Түүнчлэн, COBOL бол дэлхийн хамгийн илэрхийлэлтэй хэл биш тул систем нь том, цул хог хаягдал болж хувирсан. 2000 он гэхэд тэд олон компаниуд өөрсдийн бүх бизнесээ явуулдаг вэб сайттай болохыг олж мэдээд анхны арилжааны цэг-ком вэб сайтаа байгуулахаар шийджээ.
Анхны загвар нь маш сайхан харагдаж байсан бөгөөд дээд түвшний bell.com сайт болон тусдаа програмуудад зориулсан хэд хэдэн дэд домайнуудаас бүрдсэн байв: catalog.bell.com, accounts.bell.com, orders.bell.com, бүтээгдэхүүн хайх search.bell. com. Дэд домайн бүр ASP.Net 1.0 хүрээ болон өөрийн мэдээллийн баазыг ашигласан бөгөөд тэд бүгд системийн backend-тэй ярилцсан. Гэсэн хэдий ч бүх захиалгыг нэг том том фрэймийн хүрээнд боловсруулж, гүйцэтгэсэн бөгөөд бүх хог хаягдал үлдсэн боловч урд тал нь тусдаа програмууд, тусдаа мэдээллийн сан бүхий тусдаа вэбсайтууд байв.
Тиймээс системийн загвар нь эмх цэгцтэй, логиктой харагдаж байсан ч бодит систем нь дараагийн слайдад үзүүлсэн шиг байв.
Бүх элементүүд бие бие рүүгээ дуудлага хийх, API руу хандах, гуравдагч талын суулгасан dll гэх мэт. Хувилбарын хяналтын системүүд хэн нэгний кодыг шүүрч аваад, төсөл дотор оруулаад бүх зүйл эвдэрдэг. MS SQL Server 2005 нь холбоос серверийн тухай ойлголтыг ашигласан бөгөөд би слайд дээрх сумыг харуулаагүй ч мэдээллийн сан бүр өөр хоорондоо ярилцдаг байсан, учир нь хэд хэдэн мэдээллийн сангаас олж авсан өгөгдөл дээр үндэслэн хүснэгт байгуулахад буруу зүйл байхгүй.
Тэд одоо системийн өөр өөр логик хэсгүүдийн хооронд бага зэрэг тусгаарлагдсан тул энэ нь тархсан шороо болж, хамгийн том хог хаягдал нь үндсэн фрэймийн арын хэсэгт үлдсэн хэвээр байна.
Хамгийн инээдтэй нь энэ том фрэймийг Bell Computers-ын өрсөлдөгчид бүтээж, техникийн зөвлөхүүд нь засварлаж байсан. Хэрэглээний гүйцэтгэл хангалтгүй байгаа гэдэгт итгэлтэй байсан компани тэдгээрээс салж, системийг дахин зохион бүтээхээр шийджээ.
Одоо байгаа программыг 15 жилийн турш үйлдвэрлэсэн бөгөөд энэ нь ASP.Net-д суурилсан програмуудын хувьд дээд амжилт юм. Энэхүү үйлчилгээ нь дэлхийн өнцөг булан бүрээс захиалгыг хүлээн авдаг байсан бөгөөд энэ ганц програмаас жилийн орлого нь тэрбум долларт хүрсэн. Ашгийн нэлээд хэсгийг bell.com вэб сайт бүрдүүлжээ. Хар баасан гаригт тус сайтаар дамжуулан захиалсан хүмүүсийн тоо хэдэн саяд хүрсэн байна. Гэсэн хэдий ч системийн элементүүдийн хатуу холболт нь үйлчилгээнд ямар ч өөрчлөлт оруулахыг бараг зөвшөөрдөггүй тул одоо байгаа архитектур нь ямар ч хөгжлийг зөвшөөрөөгүй.
Хамгийн ноцтой асуудал бол дэлхийн компаниудад ийм арилжааны схем маш түгээмэл байдаг ч нэг улсаас захиалга өгч, өөр улсад төлбөрөө төлж, гуравдагч руу илгээх боломжгүй байсан. Одоо байгаа вэбсайт нь иймэрхүү зүйлийг хийхийг зөвшөөрдөггүй байсан тул тэд эдгээр захиалгыг утсаар хүлээн авч, өгөх ёстой байв. Энэ нь компанийг архитектураа өөрчлөх, ялангуяа микро үйлчилгээнд шилжих талаар бодоход хүргэсэн.
Тэд бусад компаниудтай ижил төстэй асуудлыг хэрхэн шийдсэнийг харахын тулд ухаалаг зүйлийг хийсэн. Эдгээр шийдлүүдийн нэг нь API болон гадаад мэдээллийн баазаар холбогдсон микро үйлчилгээнүүдээс бүрдэх Netflix үйлчилгээний архитектур байв.
Bell Computers-ийн удирдлага тодорхой үндсэн зарчмуудыг баримтлан яг ийм архитектур барихаар шийджээ. Нэгдүгээрт, тэд хуваалцсан мэдээллийн сангийн аргыг ашиглан өгөгдлийн давхардлыг арилгасан. Мэдээлэл илгээгээгүй, харин эсрэгээрээ шаардлагатай хүн бүр төвлөрсөн эх сурвалж руу хандах ёстой байв. Үүний дараа тусгаарлалт, бие даасан байдал бий болсон - үйлчилгээ бүр бусдаас хараат бус байв. Тэд Вэб API-г бүх зүйлд ашиглахаар шийдсэн - хэрэв та өгөгдөл авах эсвэл өөр системд өөрчлөлт оруулахыг хүсвэл энэ бүгдийг Web API-ээр хийсэн. Сүүлчийн том зүйл бол өрсөлдөгчдийн техник хангамж дээр суурилсан "Хонх" үндсэн фрэймийн эсрэг "Хонх дээр хонх" нэртэй шинэ үндсэн фрэйм байв.
Тиймээс, 18 сарын хугацаанд тэд эдгээр үндсэн зарчмуудын дагуу системийг барьж, үйлдвэрлэлийн өмнөх үе шатанд авчирсан. Амралтын өдрүүдийн дараа ажилдаа буцаж ирэхэд хөгжүүлэгчид цугларч, шинэ систем холбогдсон бүх серверүүдийг асаав. 18 сарын ажил, олон зуун хөгжүүлэгчид, хамгийн орчин үеийн Bell техник хангамж - эерэг үр дүн байхгүй! Энэ нь олон хүний урмыг хугалсан, учир нь тэд энэ системийг зөөврийн компьютер дээрээ олон удаа ажиллуулж байсан бөгөөд бүх зүйл хэвийн байсан.
Тэд энэ асуудлыг шийдэхийн тулд бүх мөнгөө хаях ухаантай байсан. Тэд унтраалга бүхий хамгийн орчин үеийн серверийн тавиуруудыг суулгаж, гигабит оптик шилэн, галзуу хэмжээний RAM бүхий хамгийн хүчирхэг серверийн техник хангамжийг ашиглаж, бүгдийг нь холбож, тохируулсан - дахиад юу ч биш! Дараа нь тэд шалтгаан нь хугацаа хэтэрсэн байж магадгүй гэж сэжиглэж эхэлсэн тул бүх вэб тохиргоо, бүх API тохиргоо руу орж, завсарлагааны тохиргоог бүхэлд нь дээд утгаар нь шинэчилсэн бөгөөд ингэснээр тэдний хийж чадах зүйл бол зүгээр суугаад ямар нэгэн зүйл болохыг хүлээх явдал байв. сайт руу. Тэд вэбсайтыг ачаалах хүртэл 9 минут хагасын турш хүлээж, хүлээсэн.
Үүний дараа өнөөгийн нөхцөл байдалд нарийн дүн шинжилгээ хийх шаардлагатай байгаа нь тэдэнд мэдрэгдэж, биднийг урьсан. Бидний олж мэдсэн хамгийн эхний зүйл бол хөгжлийн 18 сарын туршид нэг ч жинхэнэ "бичил" бүтээгдээгүй - бүх зүйл улам бүр томорсон. Үүний дараа бид гамшгийн шалтгааныг ойлгохын тулд "тархины шуурга"-тай төстэй "харамсал" эсвэл "гунигтай эргэн харах", мөн "гэмт шуурга" гэгддэг "тархины шуурга"-г бичиж эхэлсэн.
Бидэнд хэд хэдэн сэжүүр байсан бөгөөд тэдгээрийн нэг нь API дуудлага хийх үед замын хөдөлгөөний бүрэн ханасан байдал байв. Та цул үйлчилгээний архитектурыг ашиглахдаа ямар алдаа гарсныг шууд ойлгох боломжтой, учир нь танд бүтэлгүйтэлд хүргэж болзошгүй бүх зүйлийг мэдээлэх ганц стекийн ул мөр байдаг. Хэд хэдэн үйлчилгээнүүд ижил API-д нэгэн зэрэг нэвтэрч байгаа тохиолдолд WireShark гэх мэт сүлжээний хяналтын нэмэлт хэрэгслийг ашиглахаас өөр зам мөрийг хянах боломжгүй бөгөөд үүний ачаар та нэг хүсэлтийг шалгаж, хэрэгжүүлэх явцад юу болсныг олж мэдэх боломжтой. Тиймээс бид нэг вэб хуудас авч, бараг 2 долоо хоног оньсогоны хэсгүүдийг нэгтгэж, янз бүрийн дуудлага хийж, тэдгээр нь юунд хүргэсэн талаар дүн шинжилгээ хийсэн.
Энэ зургийг хар. Энэ нь нэг гадаад хүсэлт нь буцаж буцаж ирдэг олон дотоод дуудлага хийхийг үйлчилгээнд уриалж байгааг харуулж байна. Дотоод дуудлага бүр энэ хүсэлтийг бие даан гүйцэтгэх боломжтой байхын тулд нэмэлт үсрэлт хийдэг тул шаардлагатай мэдээллийг авахын тулд өөр хаанаас ч эргэж чадахгүй байна. Гадны хүсэлт нь бусад нэмэлт үйлчилгээг дууддаг нэмэлт үйлчилгээ гэх мэт бараг л хязгааргүй дууддаг тул энэ зураг утгагүй дуудлагын цуваа мэт харагдаж байна.
Энэ диаграмм дахь ногоон өнгө нь үйлчилгээнүүд бие биенээ дууддаг хагас тойргийг харуулж байна - А үйлчилгээ В үйлчилгээ рүү, В үйлчилгээ C үйлчилгээ рүү залгаж, А үйлчилгээг дахин дуудна. Үүний үр дүнд бид "тархсан мухардлыг" авдаг. Ганц хүсэлт нь мянган сүлжээний API дуудлагыг үүсгэсэн бөгөөд систем нь алдааг тэсвэрлэх чадвар болон давталтын хамгаалалтгүй байсан тул эдгээр API дуудлагын аль нэг нь ч амжилтгүй болсон тохиолдолд хүсэлт амжилтгүй болно.
Бид бага зэрэг математик хийсэн. API дуудлага бүр нь 150 мс-ээс ихгүй SLA, 99,9% ажиллах хугацаатай байсан. Нэг хүсэлт нь 200 өөр дуудлагад хүргэсэн бөгөөд хамгийн сайн тохиолдолд хуудсыг 200 x 150 мс = 30 секундын дотор харуулах боломжтой. Мэдээжийн хэрэг, энэ нь сайн зүйл биш байсан. 99,9% ажиллах хугацааг 200-аар үржүүлснээр бид 0% хүртээмжтэй болсон. Энэ архитектур нь анхнаасаа бүтэлгүйтэх магадлалтай байсан нь харагдаж байна.
Бид хөгжүүлэгчдээс 18 сар ажилласны дараа энэ асуудлыг хэрхэн анзаарч чадаагүй вэ? Тэд зөвхөн өөрсдийн ажиллуулсан кодын SLA-г тоолдог байсан ч хэрэв тэдний үйлчилгээ өөр үйлчилгээ дуудсан бол SLA-даа тэр хугацааг тооцдоггүй нь тогтоогдсон. Нэг процессын хүрээнд эхлүүлсэн бүх зүйл 150 мс-ийн утгыг дагаж мөрддөг байсан ч бусад үйлчилгээний процессуудад хандах нь нийт саатлыг хэд дахин нэмэгдүүлсэн. Анхны сургамж нь: "Та SLA-аа хянаж байна уу, эсвэл SLA таныг хянаж байна уу?" Манай тохиолдолд энэ нь сүүлчийнх байсан.
Бидний олж мэдсэн дараагийн зүйл бол тэд Питер Дейч, Жеймс Гослинг нарын боловсруулсан тархсан тооцооллын буруу ойлголтын тухай мэддэг байсан ч эхний хэсгийг үл тоомсорлосон явдал байв. Энэ нь "сүлжээ найдвартай", "тэг хоцролт", "хязгааргүй нэвтрүүлэх чадвар" гэсэн мэдэгдлүүд нь ташаа ойлголт юм. Бусад буруу ташаа ойлголтуудад “сүлжээ аюулгүй”, “топологи хэзээ ч өөрчлөгддөггүй”, “зөвхөн нэг администратор байдаг”, “мэдээлэл дамжуулах зардал тэг”, “сүлжээ нь нэгэн төрлийн” гэсэн үг юм.
Тэд үйлчилгээгээ орон нутгийн машинууд дээр туршиж үзээд гадны үйлчилгээтэй хэзээ ч холбогдоогүй тул алдаа гаргасан. Орон нутгийн хэмжээнд хөгжүүлж, локал кэш ашиглах үед тэд хэзээ ч сүлжээний хоптой тулгараагүй. Хөгжлийн 18 сарын турш тэд гадны үйлчилгээнд нөлөөлвөл юу болох талаар нэг ч удаа бодож байгаагүй.
Өмнөх зурган дээрх үйлчилгээний хил хязгаарыг харвал бүгд буруу байгааг харж болно. Үйлчилгээний хил хязгаарыг хэрхэн тодорхойлох талаар зөвлөгөө өгөх олон эх сурвалж байдаг бөгөөд ихэнх нь дараагийн слайд дээрх Microsoft шиг үүнийг буруу хийдэг.
Энэ зураг нь "Бичил үйлчилгээг хэрхэн бүтээх вэ" сэдвээр MS блогоос авсан болно. Энэ нь энгийн вэб програм, бизнесийн логикийн блок, мэдээллийн санг харуулж байна. Хүсэлт шууд ирдэг, магадгүй вэбэд зориулсан нэг сервер, бизнесийн нэг сервер, мэдээллийн санд зориулсан нэг сервер байдаг. Хэрэв та замын хөдөлгөөнийг нэмэгдүүлбэл зураг бага зэрэг өөрчлөгдөнө.
Хоёр вэб серверийн хооронд урсгалыг хуваарилах ачааллын тэнцвэржүүлэгч, вэб үйлчилгээ болон бизнесийн логик хооронд байрлах кэш, бизнесийн логик болон мэдээллийн сангийн хооронд өөр нэг кэш ирдэг. Энэ бол 2000-аад оны дундуур ачааллын тэнцвэржүүлэх, цэнхэр/ногоон байршуулах программдаа ашигласан Bell архитектур юм. Хэсэг хугацааны дараа бүх зүйл сайн ажилласан, учир нь энэ схем нь цул бүтцэд зориулагдсан байв.
Дараах зураг нь үндсэн үйлчилгээ тус бүрийг тусдаа микро үйлчилгээ болгон хуваахад MS нь цул үйлчилгээнээс микро үйлчилгээ рүү шилжихийг хэрхэн зөвлөж байгааг харуулж байна. Энэ схемийг хэрэгжүүлэх явцад Белл алдаа гаргасан.
Тэд бүх үйлчилгээгээ өөр өөр түвшинд хуваасан бөгөөд тус бүр нь олон тусдаа үйлчилгээнээс бүрддэг. Жишээлбэл, вэб үйлчилгээнд контент үзүүлэх, баталгаажуулах микро үйлчилгээ, бизнесийн логик үйлчилгээ нь захиалга, дансны мэдээллийг боловсруулах микро үйлчилгээ, мэдээллийн сан нь тусгай өгөгдөл бүхий олон тооны микро үйлчилгээнд хуваагдсан. Вэб, бизнесийн логик, мэдээллийн сан хоёулаа харьяалалгүй үйлчилгээ байсан.
Гэсэн хэдий ч, энэ зураг нь компанийн мэдээллийн технологийн кластераас гадуур ямар ч бизнесийн нэгжийг зураглаагүй тул бүрэн буруу байсан. Энэхүү схем нь гадаад ертөнцтэй ямар ч холбоогүй байсан тул жишээлбэл, гуравдагч этгээдийн бизнесийн аналитикийг хэрхэн олж авах нь тодорхойгүй байв. Тэд илүү их мөнгө олж авахын тулд аль болох олон хүнийг удирдахыг эрэлхийлж байсан ажилчдын карьерыг хөгжүүлэхийн тулд хэд хэдэн үйлчилгээг зохион бүтээсэн гэдгийг би тэмдэглэж байна.
Тэд бичил үйлчилгээ рүү шилжих нь дотоод N түвшний физик давхаргын дэд бүтцээ авч, Докерыг түүн дээр наахтай адил хялбар гэж үзсэн. Уламжлалт N түвшний архитектур ямар байхыг харцгаая.
Энэ нь UI хэрэглэгчийн интерфэйсийн түвшин, бизнесийн логик түвшин, өгөгдлийн хандалтын түвшин, мэдээллийн сан гэсэн 4 түвшнээс бүрдэнэ. Илүү дэвшилтэт зүйл бол DDD (Домайнд тулгуурласан дизайн) эсвэл програм хангамжид суурилсан архитектур бөгөөд хоёр дунд түвшин нь домэйн объект ба репозитор юм.
Би энэ архитектурт өөрчлөлтийн өөр өөр талбар, хариуцлагын өөр өөр талбаруудыг харахыг хичээсэн. Ердийн N түвшний хэрэглээнд бүтэц дээр дээрээс доошоо босоо нэвчсэн өөрчлөлтийн өөр өөр хэсгүүдийг ангилдаг. Эдгээр нь Каталог, хувь хүний компьютер дээр хийгдсэн тохиргооны тохиргоо, миний багийн хийсэн Checkout шалгалтууд юм.
Энэхүү схемийн онцлог нь эдгээр өөрчлөлтүүдийн хил хязгаар нь зөвхөн бизнесийн логик түвшинд төдийгүй мэдээллийн санд нөлөөлдөг.
Үйлчилгээ гэж юу гэсэн үг болохыг харцгаая. Үйлчилгээний тодорхойлолтын 6 шинж чанар байдаг - энэ нь програм хангамж юм:
- тодорхой байгууллага бий болгож ашигласан;
- систем доторх тодорхой төрлийн мэдээллийн агуулга, боловсруулалт ба/эсвэл хангах үүрэгтэй;
- үйл ажиллагааны тодорхой хэрэгцээг хангахын тулд бие даан барьж, байрлуулж, ажиллуулж болно;
- хэрэглэгчид болон бусад үйлчилгээтэй харилцах, гэрээ эсвэл гэрээний баталгаанд үндэслэн мэдээллээр хангах;
- зөвшөөрөлгүй нэвтрэхээс өөрийгөө хамгаалж, мэдээллийг алдагдахаас хамгаалдаг;
- бүтэлгүйтлийг мэдээллийн эвдрэлд хүргэхгүй байхаар зохицуулдаг.
Эдгээр бүх шинж чанарыг "автономи" гэсэн нэг үгээр илэрхийлж болно. Үйлчилгээнүүд нь бие биенээсээ хамааралгүй үйл ажиллагаа явуулж, тодорхой хязгаарлалтуудыг хангадаг бөгөөд үүний үндсэн дээр хүмүүс өөрт хэрэгтэй мэдээллээ авч болох гэрээг тодорхойлдог. Би тодорхой технологиудыг дурдаагүй бөгөөд үүнийг ашиглах нь өөрөө ойлгомжтой юм.
Одоо микро үйлчилгээний тодорхойлолтыг харцгаая.
- бичил үйлчилгээ нь жижиг хэмжээтэй бөгөөд тодорхой нэг асуудлыг шийдвэрлэхэд зориулагдсан;
- Микро үйлчилгээ нь бие даасан;
- Микро үйлчилгээний архитектурыг бий болгохдоо хот төлөвлөлтийн зүйрлэлийг ашигладаг. Энэ бол Сэм Ньюманы "Бичил үйлчилгээ байгуулах" номноос гаргасан тодорхойлолт юм.
"Хязгаарлагдмал контекст"-ийн тодорхойлолтыг Эрик Эвансын "Domain-Driven Design" номноос авсан болно. Энэ нь архитектурын дизайны төв болох DDD-ийн үндсэн загвар бөгөөд эзэлхүүнтэй архитектурын загваруудтай ажиллаж, тэдгээрийг өөр өөр Хязгаарлагдмал контекстэд хувааж, тэдгээрийн хоорондын харилцан үйлчлэлийг тодорхой тодорхойлдог.
Энгийнээр хэлбэл, Хязгаарлагдмал контекст нь тухайн модулийг ашиглаж болох хамрах хүрээг илэрхийлдэг. Энэ хүрээнд жишээ нь, таны бизнесийн домэйн дээр харж болох логик нэгдсэн загвар юм. Захиалгад оролцож буй ажилтнуудаас “үйлчлүүлэгч гэж хэн бэ” гэж асуувал нэг тодорхойлолт, борлуулалттай холбоотой хүмүүсээс асуувал өөр тодорхойлолт, гүйцэтгэгчид гурав дахь тодорхойлолтыг өгнө.
Тиймээс, "Хязгаарлагдмал контекст"-д хэрэв бид үйлчилгээнийхээ хэрэглэгч гэж юу болох талаар тодорхой тодорхойлолт өгч чадахгүй бол энэ нэр томъёоны утгын талаар ярьж болох хил хязгаарыг тодорхойлж, дараа нь эдгээр өөр өөр тодорхойлолтуудын хоорондох шилжилтийн цэгүүдийг тодорхойлъё гэж хэлсэн. Өөрөөр хэлбэл, хэрэв бид захиалга өгөх үүднээс үйлчлүүлэгчийн тухай ярьж байгаа бол энэ нь энэ, тэр гэсэн үг, хэрэв борлуулалтын үүднээс авч үзвэл энэ нь энэ, тэр гэсэн үг юм.
Микро үйлчилгээний дараагийн тодорхойлолт нь ажлын процессын бүрэлдэхүүн хэсгүүдийг хүрээлэн буй орчинд "нэвчих" -ээс урьдчилан сэргийлэх аливаа төрлийн дотоод үйлдлүүдийг багтаах явдал юм. Дараа нь "гадны харилцан үйлчлэлийн тодорхой гэрээний тодорхойлолт буюу гадаад харилцааны тодорхойлолт" гарч ирдэг бөгөөд энэ нь SLA-аас буцаж ирэх гэрээний санаагаар илэрхийлэгддэг. Сүүлчийн тодорхойлолт нь эс буюу эсийн зүйрлэл бөгөөд энэ нь микро үйлчилгээний доторх үйл ажиллагааны багцыг бүрэн бүрхэж, гадаад ертөнцтэй харилцах рецепторуудыг агуулдаг гэсэн үг юм.
Тиймээс бид Bell Computers-ийн залууст хандан, "Та нарын үүсгэсэн эмх замбараагүй байдлыг бид засах боломжгүй, учир нь та үүнийг хийх мөнгөгүй, гэхдээ бид үүнийг бүгдийг нь болгохын тулд зөвхөн нэг үйлчилгээг засах болно. мэдрэмж." Энэ үед би өөрийн цорын ганц үйлчилгээгээ хэрхэн засч, хүсэлтэд 9 минут хагасаас илүү хурдан хариу өгсөн талаар ярьж эхэлье.
22:30 минут
Үргэлжлэл тун удахгүй...
Бага зэрэг сурталчилгаа
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com