Siz o'zingizning monolitingizni mikroservislarga qayta loyihalash uchun bir necha oy sarfladingiz va nihoyat hamma kalitni almashtirish uchun yig'ildi. Siz birinchi veb-sahifaga kirasiz ... va hech narsa sodir bo'lmaydi. Siz uni qayta yuklaysiz - va yana yaxshi narsa yo'q, sayt shunchalik sekinki, u bir necha daqiqa davomida javob bermaydi. Nima bo'ldi?
Jimmi Bogard o'z nutqida real hayotdagi mikroservis halokati bo'yicha "o'limdan keyingi tekshiruv" o'tkazadi. U kashf etgan modellashtirish, ishlab chiqish va ishlab chiqarish muammolarini va uning jamoasi asta-sekin yangi taqsimlangan monolitni aqlning yakuniy rasmiga aylantirganini ko'rsatib beradi. Dizayn xatolarining to'liq oldini olishning iloji bo'lmasa-da, yakuniy mahsulot ishonchli taqsimlangan tizimga aylanishini ta'minlash uchun hech bo'lmaganda dizayn jarayonining boshida muammolarni aniqlashingiz mumkin.
Hammaga salom, men Jimmiman va bugun siz mikroservislarni yaratishda qanday qilib mega ofatlardan qochishingiz mumkinligini eshitasiz. Bu men bir yarim yil davomida ularning kemasi aysberg bilan to'qnashib ketishining oldini olish uchun ishlagan kompaniyaning hikoyasidir. Bu voqeani to‘g‘ri bayon qilish uchun biz o‘tmishga qaytib, bu kompaniya qayerdan boshlangani va vaqt o‘tishi bilan uning IT infratuzilmasi qanday rivojlangani haqida gapirishimiz kerak bo‘ladi. Ushbu falokatda begunohlarning ismlarini himoya qilish uchun men ushbu kompaniya nomini Bell Computers deb o'zgartirdim. Keyingi slaydda 90-yillarning o'rtalarida bunday kompaniyalarning IT infratuzilmasi qanday ko'rinishga ega bo'lganligi ko'rsatilgan. Bu kompyuter jihozlari do'konini boshqarish uchun katta universal nosozliklarga chidamli HP Tandem Mainframe serverining odatiy arxitekturasidir.
Ular barcha buyurtmalar, sotuvlar, daromadlar, mahsulot kataloglari va mijozlar bazasini boshqarish uchun tizim yaratishlari kerak edi, shuning uchun ular o'sha paytdagi eng keng tarqalgan asosiy kompyuter echimini tanladilar. Bu gigant tizim kompaniya haqidagi barcha ma'lumotlarni, mumkin bo'lgan barcha narsalarni o'z ichiga olgan va har bir tranzaksiya shu meynfreym orqali amalga oshirilgan. Ular barcha tuxumlarini bitta savatda saqlashdi va bu normal holat deb o'ylashdi. Bu erda kiritilmagan yagona narsa - pochta orqali buyurtmalar kataloglari va telefon orqali buyurtma berish.
Vaqt o'tishi bilan tizim kengayib bordi va unda juda katta miqdordagi axlat to'planib qoldi. Bundan tashqari, COBOL dunyodagi eng ifodali til emas, shuning uchun tizim katta, monolit axlat bo'lagiga aylandi. 2000 yilga kelib, ular ko'pgina kompaniyalar o'zlarining barcha bizneslarini amalga oshiradigan veb-saytlari borligini ko'rdilar va birinchi tijorat dot-com veb-saytini yaratishga qaror qilishdi.
Dastlabki dizayn juda chiroyli ko'rindi va yuqori darajadagi bell.com sayti va individual ilovalar uchun bir qator subdomenlardan iborat edi: catalog.bell.com, accounts.bell.com, orders.bell.com, mahsulot qidirish search.bell. com. Har bir subdomen ASP.Net 1.0 ramkasidan va o'z ma'lumotlar bazalaridan foydalangan va ularning barchasi tizimning backend bilan gaplashgan. Biroq, barcha buyurtmalarni qayta ishlash va bajarishda barcha axlatlar qolgan yagona yirik meynfreymda davom etdi, lekin oldingi qismi alohida ilovalar va alohida ma'lumotlar bazalari bo'lgan alohida veb-saytlar edi.
Shunday qilib, tizimning dizayni tartibli va mantiqiy ko'rinardi, ammo haqiqiy tizim keyingi slaydda ko'rsatilganidek edi.
Barcha elementlar bir-biriga qo'ng'iroqlarga yo'naltirilgan, API-larga kirish, o'rnatilgan uchinchi tomon DLL-lari va boshqalar. Ko'pincha versiyalarni boshqarish tizimlari boshqa birovning kodini ushlab, uni loyiha ichiga suradi va keyin hamma narsa buziladi. MS SQL Server 2005 havola serverlari kontseptsiyasidan foydalangan va men slaydda o'qlarni ko'rsatmagan bo'lsam ham, ma'lumotlar bazalarining har biri ham bir-biri bilan gaplashdi, chunki bir nechta ma'lumotlar bazalaridan olingan ma'lumotlar asosida jadvallar tuzishda hech qanday yomon narsa yo'q.
Ular endi tizimning turli mantiqiy sohalari o'rtasida bir oz bo'linishga ega bo'lganligi sababli, bu taqsimlangan axloqsizlik bo'laklariga aylandi, eng katta axlat bo'lagi hamon asosiy kompyuterning orqa qismida qolmoqda.
Qizig'i shundaki, bu meynfreym Bell Computers kompaniyasining raqobatchilari tomonidan qurilgan va hali ham ularning texnik maslahatchilari tomonidan saqlanmoqda. Ilovalarining qoniqarsiz ishlashiga ishonch hosil qilgan kompaniya ulardan xalos bo'lishga va tizimni qayta ishlab chiqishga qaror qildi.
Mavjud dastur 15 yil davomida ishlab chiqarilgan, bu ASP.Net-ga asoslangan ilovalar uchun rekorddir. Xizmat butun dunyo bo'ylab buyurtmalarni qabul qildi va ushbu yagona dasturdan yillik daromad milliard dollarga etdi. Daromadning muhim qismi bell.com sayti tomonidan yaratilgan. Qora juma kunlari sayt orqali berilgan buyurtmalar soni bir necha millionga yetdi. Biroq, mavjud arxitektura hech qanday rivojlanishga yo'l qo'ymadi, chunki tizim elementlarining qattiq o'zaro bog'liqligi deyarli xizmatga hech qanday o'zgartirish kiritishga imkon bermadi.
Eng jiddiy muammo, bunday savdo sxemasi global kompaniyalarda juda keng tarqalgan bo'lishiga qaramay, bir mamlakatdan buyurtma berish, boshqasida to'lash va uchinchisiga jo'natishning mumkin emasligi edi. Mavjud veb-sayt bunga o'xshash narsaga ruxsat bermadi, shuning uchun ular bu buyurtmalarni telefon orqali qabul qilishlari va joylashtirishlari kerak edi. Bu kompaniyaning arxitekturani o'zgartirish, xususan, mikroservislarga o'tish haqida ko'proq o'ylashiga olib keldi.
Ular shunga o'xshash muammoni qanday hal qilganliklarini ko'rish uchun boshqa kompaniyalarga qarab aqlli ish qildilar. Ushbu echimlardan biri API va tashqi ma'lumotlar bazasi orqali ulangan mikroservislardan iborat Netflix xizmat arxitekturasi edi.
Bell Computers rahbariyati ma'lum bir asosiy tamoyillarga rioya qilgan holda aynan shunday arxitekturani qurishga qaror qildi. Birinchidan, ular umumiy ma'lumotlar bazasi yondashuvidan foydalangan holda ma'lumotlarning takrorlanishini bartaraf etdilar. Hech qanday ma'lumot yuborilmadi, aksincha, unga muhtoj bo'lgan har bir kishi markazlashtirilgan manbaga borishi kerak edi. Buning ortidan izolyatsiya va avtonomiya paydo bo'ldi - har bir xizmat boshqalardan mustaqil edi. Ular Web API-dan mutlaqo hamma narsa uchun foydalanishga qaror qilishdi - agar siz ma'lumot olishni yoki boshqa tizimga o'zgartirish kiritmoqchi bo'lsangiz, barchasi Web API orqali amalga oshirildi. Oxirgi katta narsa raqobatchilarning apparatiga asoslangan "Bell" meynfreymidan farqli ravishda "Bell on Bell" deb nomlangan yangi meynfreym edi.
Shunday qilib, 18 oy davomida ular ushbu asosiy tamoyillar asosida tizimni qurdilar va uni oldindan ishlab chiqarishga olib kelishdi. Dam olish kunlaridan keyin ishga qaytib, ishlab chiquvchilar yig'ilib, yangi tizim ulangan barcha serverlarni yoqdilar. 18 oylik ish, yuzlab ishlab chiquvchilar, eng zamonaviy Bell apparati - va hech qanday ijobiy natija yo'q! Bu juda ko'p odamlarning hafsalasi pir bo'ldi, chunki ular ushbu tizimni o'z noutbuklarida ko'p marta ishlatgan va hamma narsa yaxshi edi.
Ular bu muammoni hal qilish uchun barcha pullarini sarflash uchun aqlli edilar. Ular kalitlari bo'lgan eng zamonaviy server tokchalarini o'rnatdilar, gigabitli optik tolali, aqldan ozgan operativ xotiraga ega eng kuchli server uskunasidan foydalanishdi, barchasini ulashdi, sozlashdi - va yana hech narsa! Keyin ular sabab vaqt tugashi bo'lishi mumkin deb gumon qila boshladilar, shuning uchun ular barcha veb-sozlamalarga, barcha API sozlamalariga o'tishdi va butun vaqt tugashi konfiguratsiyasini maksimal qiymatlarga yangiladilar, shunda ular nimadir sodir bo'lishini kutishlari mumkin edi. saytga. Ular kutishdi va kutishdi va veb-sayt nihoyat yuklanmaguncha 9 yarim daqiqa kutishdi.
SHundan so'ng, hozirgi vaziyatni chuqur tahlil qilish zarurligi anglab yetdi va bizni taklif qilishdi. Biz aniqlagan birinchi narsa shundaki, 18 oylik rivojlanish davomida bironta ham haqiqiy "mikro" yaratilmagan - hamma narsa faqat kattalashdi. Shundan so'ng, biz falokat sababini tushunish uchun "regretrospektiv" yoki "qayg'uli retrospektiv" deb nomlanuvchi, shuningdek, "miya bo'roni" kabi "ayb bo'roni" deb nomlanuvchi o'limdan keyingi maqola yozishni boshladik.
Bizda bir nechta maslahatlar bor edi, ulardan biri API qo'ng'irog'i paytida trafikning to'liq to'yinganligi edi. Monolit xizmat arxitekturasidan foydalanganda, nima noto'g'ri bo'lganini darhol tushunishingiz mumkin, chunki sizda muvaffaqiyatsizlikka sabab bo'lishi mumkin bo'lgan hamma narsa haqida xabar beradigan bitta stek izi mavjud. Agar bir nechta xizmatlar bir vaqtning o'zida bir xil API-ga kirgan bo'lsa, WireShark kabi qo'shimcha tarmoq monitoringi vositalaridan foydalanishdan tashqari, izni kuzatishning hech qanday usuli yo'q, buning yordamida siz bitta so'rovni tekshirishingiz va uni amalga oshirish paytida nima sodir bo'lganligini bilib olishingiz mumkin. Shunday qilib, biz bitta veb-sahifani oldik va deyarli 2 hafta davomida jumboq qismlarini birlashtirdik, unga turli qo'ng'iroqlar qildik va ularning har biri nimaga olib kelganini tahlil qildik.
Bu rasmga qarang. Bu shuni ko'rsatadiki, bitta tashqi so'rov xizmatga qaytib keladigan ko'plab ichki qo'ng'iroqlarni amalga oshirishga undaydi. Ma'lum bo'lishicha, har bir ichki qo'ng'iroq ushbu so'rovga mustaqil ravishda xizmat ko'rsatish uchun qo'shimcha sakrashlarni amalga oshiradi, chunki u kerakli ma'lumotlarni olish uchun boshqa joyga aylana olmaydi. Bu rasm ma'nosiz qo'ng'iroqlar kaskadiga o'xshaydi, chunki tashqi so'rov qo'shimcha xizmatlarni chaqiradi, ular boshqa qo'shimcha xizmatlarni chaqiradi va hokazo, deyarli ad infinitum.
Ushbu diagrammadagi yashil rang yarim doirani ko'rsatadi, unda xizmatlar bir-biriga qo'ng'iroq qiladi - A xizmati B xizmatiga, B xizmati C xizmatiga qo'ng'iroq qiladi va yana A xizmatiga qo'ng'iroq qiladi.Natijada biz "tarqatilgan o'lik" ni olamiz. Bitta so'rov mingta tarmoq API qo'ng'iroqlarini yaratdi va tizimda o'rnatilgan nosozlikka chidamlilik va pastadir himoyasi bo'lmaganligi sababli, agar ushbu API qo'ng'iroqlaridan biri bajarilmasa ham, so'rov bajarilmaydi.
Biz matematika qildik. Har bir API chaqiruvi 150 ms dan oshmaydigan SLA va 99,9% ish vaqtiga ega edi. Bitta so'rov 200 xil qo'ng'iroqlarga sabab bo'ldi va eng yaxshi holatda sahifa 200 x 150 ms = 30 soniyada ko'rsatilishi mumkin edi. Tabiiyki, bu yaxshi emas edi. 99,9% ish vaqtini 200 ga ko'paytirsak, biz 0% foydalanish imkoniyatiga ega bo'ldik. Ma’lum bo‘lishicha, bu arxitektura boshidanoq barbod bo‘lishga mahkum bo‘lgan.
Biz ishlab chiquvchilardan 18 oylik ishdan keyin qanday qilib bu muammoni tan olmaganliklarini so'radik? Ma'lum bo'lishicha, ular faqat SLA kodini o'zlari ishlatgan kod uchun hisoblashgan, lekin agar ularning xizmati boshqa xizmatga qo'ng'iroq qilsa, ular SLAda bu vaqtni hisobga olmagan. Bitta jarayonda ishga tushirilgan hamma narsa 150 ms qiymatiga amal qildi, ammo boshqa xizmat jarayonlariga kirish umumiy kechikishni bir necha barobar oshirdi. Olingan birinchi saboq: "Sizning SLA nazorati ostidamisiz yoki SLA sizni nazorat qiladimi?" Bizning holatda, bu ikkinchisi edi.
Biz kashf etgan keyingi narsa shundaki, ular Piter Deytch va Jeyms Gosling tomonidan ishlab chiqilgan taqsimlangan hisoblash noto'g'ri tushunchalari haqida bilishgan, ammo ular uning birinchi qismini e'tiborsiz qoldirishgan. Unda aytilishicha, "tarmoq ishonchli", "nol kechikish" va "cheksiz o'tkazish qobiliyati" degan gaplar noto'g'ri tushunchadir. Boshqa noto'g'ri tushunchalar orasida "tarmoq xavfsiz", "topologiya hech qachon o'zgarmaydi", "har doim faqat bitta ma'mur bor", "ma'lumotlarni uzatish narxi nolga teng" va "tarmoq bir hil".
Ular xato qilishdi, chunki ular o'z xizmatlarini mahalliy mashinalarda sinab ko'rdilar va hech qachon tashqi xizmatlarga ulanmaganlar. Mahalliy ravishda ishlab chiqishda va mahalliy keshdan foydalanishda ular hech qachon tarmoq hoplariga duch kelmadilar. Rivojlanishning barcha 18 oyi davomida ular tashqi xizmatlarga ta'sir ko'rsatsa nima bo'lishi mumkinligi haqida hech qachon hayron bo'lishmagan.
Agar oldingi rasmdagi xizmat chegaralariga qarasangiz, ularning barchasi noto'g'ri ekanligini ko'rishingiz mumkin. Xizmat chegaralarini qanday aniqlash bo'yicha maslahat beradigan ko'plab manbalar mavjud va ko'pchilik buni noto'g'ri qiladi, masalan, keyingi slayddagi Microsoft.
Ushbu rasm "Mikroservislarni qanday qurish kerak" mavzusidagi MS blogidan olingan. Bu oddiy veb-ilova, biznes mantig'i bloki va ma'lumotlar bazasini ko'rsatadi. So'rov to'g'ridan-to'g'ri keladi, ehtimol veb uchun bitta server, biznes uchun bitta server va ma'lumotlar bazasi uchun bitta server mavjud. Agar siz trafikni oshirsangiz, rasm biroz o'zgaradi.
Bu erda ikkita veb-server o'rtasida trafikni taqsimlash uchun yuk balansi, veb-xizmat va biznes mantig'i o'rtasida joylashgan kesh va biznes mantig'i va ma'lumotlar bazasi o'rtasidagi boshqa kesh keladi. Aynan mana shu Bell arxitekturasi 2000-yillarning oʻrtalarida yuklarni muvozanatlash va koʻk/yashil ilovalarni qoʻllashda foydalanilgan. Bir muncha vaqtgacha hamma narsa yaxshi ishladi, chunki bu sxema monolit tuzilish uchun mo'ljallangan edi.
Quyidagi rasmda MS qanday qilib monolitdan mikroservislarga o'tishni tavsiya etishi ko'rsatilgan - oddiygina har bir asosiy xizmatlarni alohida mikroservislarga bo'lish. Aynan ushbu sxemani amalga oshirish jarayonida Bell xatoga yo'l qo'ydi.
Ular o'zlarining barcha xizmatlarini turli darajalarga bo'lishdi, ularning har biri ko'plab individual xizmatlardan iborat edi. Masalan, veb-xizmat tarkibiga kontentni ko'rsatish va autentifikatsiya qilish uchun mikroservislar, biznes mantiqiy xizmati buyurtmalar va hisob ma'lumotlarini qayta ishlash uchun mikroservislardan iborat edi, ma'lumotlar bazasi maxsus ma'lumotlarga ega mikroservislar to'plamiga bo'lingan. Veb, biznes mantig'i va ma'lumotlar bazasi ham fuqaroligi bo'lmagan xizmatlar edi.
Biroq, bu rasm butunlay noto'g'ri edi, chunki u kompaniyaning IT klasteridan tashqarida hech qanday biznes bo'linmalarini xaritada ko'rsatmagan. Ushbu sxema tashqi dunyo bilan hech qanday aloqani hisobga olmadi, shuning uchun, masalan, uchinchi tomon biznes tahlillarini qanday olish mumkinligi aniq emas edi. Shuni ta'kidlaymanki, ularda ko'proq pul olish uchun iloji boricha ko'proq odamlarni boshqarishga intilayotgan individual xodimlarning martabasini rivojlantirish uchun bir nechta xizmatlar ixtiro qilingan.
Ular mikroservislarga o'tish N-darajali jismoniy qatlamning ichki infratuzilmasini olish va unga Docker-ni yopishtirish kabi oson ekanligiga ishonishdi. Keling, an'anaviy N-darajali arxitektura qanday ko'rinishini ko'rib chiqaylik.
U 4 darajadan iborat: UI foydalanuvchi interfeysi darajasi, biznes mantiqiy darajasi, ma'lumotlarga kirish darajasi va ma'lumotlar bazasi. Keyinchalik progressiv DDD (Domenga asoslangan dizayn) yoki dasturiy ta'minotga yo'naltirilgan arxitektura, bu erda ikkita o'rta daraja domen ob'ektlari va ombordir.
Men ushbu arxitekturada o'zgarishlarning turli sohalarini, turli mas'uliyat sohalarini ko'rib chiqishga harakat qildim. Oddiy N-darajali dasturda strukturani yuqoridan pastgacha vertikal ravishda o'tkazadigan turli xil o'zgarishlar sohalari tasniflanadi. Bular Katalog, shaxsiy kompyuterlarda bajariladigan konfiguratsiya sozlamalari va mening jamoam tomonidan amalga oshirilgan Checkout tekshiruvlari.
Ushbu sxemaning o'ziga xos xususiyati shundaki, bu o'zgarishlar sohalarining chegaralari nafaqat biznes mantiqiy darajasiga, balki ma'lumotlar bazasiga ham ta'sir qiladi.
Keling, xizmat ko'rsatish nimani anglatishini ko'rib chiqaylik. Xizmat ta'rifining 6 ta xarakterli xususiyati mavjud - bu dasturiy ta'minot:
- muayyan tashkilot tomonidan yaratilgan va foydalanilgan;
- tizimda ma'lum turdagi ma'lumotlarning mazmuni, qayta ishlanishi va/yoki taqdim etilishi uchun javobgardir;
- muayyan operatsion ehtiyojlarni qondirish uchun mustaqil ravishda qurish, joylashtirish va ishga tushirish mumkin;
- shartnomalar yoki shartnoma kafolatlari asosida ma'lumotlarni taqdim etgan holda iste'molchilar va boshqa xizmatlar bilan muloqot qiladi;
- o'zini ruxsatsiz kirishdan va ma'lumotlarini yo'qotishdan himoya qiladi;
- nosozliklarni axborotga zarar yetkazmaydigan tarzda hal qiladi.
Bu xususiyatlarning barchasini bir so'z bilan ifodalash mumkin "avtonomiya". Xizmatlar bir-biridan mustaqil ravishda ishlaydi, ma'lum cheklovlarni qondiradi va shartnomalarni belgilaydi, ular asosida odamlar kerakli ma'lumotlarni olishlari mumkin. Men aniq texnologiyalarni eslatmadim, ulardan foydalanish o'z-o'zidan ravshan.
Endi mikroservislarning ta'rifini ko'rib chiqamiz:
- mikroservis kichik hajmga ega va bitta aniq muammoni hal qilish uchun mo'ljallangan;
- Mikroservis avtonomdir;
- Mikroservis arxitekturasini yaratishda shaharsozlik metaforasi qo'llaniladi. Bu Sem Nyumanning "Mikroservislarni qurish" kitobidagi ta'rif.
Cheklangan kontekstning ta'rifi Erik Evansning "Domenga asoslangan dizayn" kitobidan olingan. Bu hajmli me'moriy modellar bilan ishlaydigan, ularni turli Cheklangan kontekstlarga ajratadigan va ular orasidagi o'zaro ta'sirni aniq belgilab beruvchi DDD arxitektura dizayni markazining asosiy namunasidir.
Oddiy qilib aytganda, Chegaralangan kontekst ma'lum bir moduldan foydalanish mumkin bo'lgan doirani bildiradi. Ushbu kontekstda, masalan, biznes domenida ko'rish mumkin bo'lgan mantiqiy birlashtirilgan model mavjud. Buyurtmalar bilan shug'ullanadigan xodimlardan "mijoz kim" deb so'rasangiz, siz bitta ta'rifga ega bo'lasiz, agar siz savdo bilan shug'ullanadiganlardan so'rasangiz, boshqasini olasiz va ijrochilar sizga uchinchi ta'rifni beradi.
Shunday qilib, Cheklangan kontekstda aytilishicha, agar biz xizmatlarimizning iste'molchisi nima ekanligiga aniq ta'rif bera olmasak, keling, ushbu atamaning ma'nosi haqida gapirishimiz mumkin bo'lgan chegaralarni aniqlaymiz va keyin bu turli xil ta'riflar orasidagi o'tish nuqtalarini aniqlaymiz. Ya'ni, agar biz buyurtma berish nuqtai nazaridan mijoz haqida gapiradigan bo'lsak, bu buni va buni anglatadi, agar sotish nuqtai nazaridan bo'lsa, bu shuni anglatadi.
Mikroservisning keyingi ta'rifi - bu ish jarayonining tarkibiy qismlarining atrof-muhitga "oqishini" oldini oluvchi har qanday turdagi ichki operatsiyalarni inkapsulyatsiya qilish. Keyinchalik "tashqi o'zaro ta'sirlar yoki tashqi aloqalar uchun aniq shartnomalar ta'rifi" keladi, bu SLAlardan qaytib keladigan shartnomalar g'oyasi bilan ifodalanadi. Oxirgi ta'rif hujayra yoki hujayraning metaforasi bo'lib, mikroservis ichidagi operatsiyalar to'plamining to'liq inkapsulyatsiyasini va unda tashqi dunyo bilan aloqa qilish uchun retseptorlarning mavjudligini anglatadi.
Shunday qilib, biz Bell Computers’dagi yigitlarga shunday dedik: “Biz siz yaratgan tartibsizliklarni tuzata olmaymiz, chunki sizda buni amalga oshirish uchun pulingiz yo‘q, lekin barchasini amalga oshirish uchun biz faqat bitta xizmatni tuzatamiz. tuyg'u." Shu o‘rinda men sizga yagona xizmatimiz so‘rovlarga 9 yarim daqiqadan tezroq javob berishi uchun qanday tuzatganimizni aytib berishdan boshlayman.
22:30 min
Davomi tez orada...
Bir oz reklama
Biz bilan qolganingiz uchun tashakkur. Bizning maqolalarimiz sizga yoqdimi? Ko'proq qiziqarli tarkibni ko'rishni xohlaysizmi? Buyurtma berish yoki do'stlaringizga tavsiya qilish orqali bizni qo'llab-quvvatlang, , Siz uchun biz tomonidan ixtiro qilingan boshlang'ich darajadagi serverlarning noyob analogi: (RAID1 va RAID10, 24 tagacha yadro va 40 Gb gacha DDR4 bilan mavjud).
Amsterdamdagi Equinix Tier IV ma'lumotlar markazida Dell R730xd 2 baravar arzonmi? Faqat shu yerda Gollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! Haqida o'qing
Manba: www.habr.com