Hey Xabr!

Koronavirus tufayli ro‘y berayotgan voqealarni inobatga olgan holda, bir qator internet-xizmatlari yuklamani oshira boshladi. Masalan, Buyuk Britaniyaning chakana savdo tarmoqlaridan biri shunchaki onlayn buyurtma berish saytini to'xtatdi., chunki imkoniyatlar yetarli emas edi. Va shunchaki kuchliroq uskunalarni qo'shish orqali serverni tezlashtirish har doim ham mumkin emas, lekin mijoz so'rovlarini qayta ishlash kerak (yoki ular raqobatchilarga o'tadi).

Ushbu maqolada men tez va nosozliklarga chidamli xizmatni yaratishga imkon beradigan mashhur amaliyotlar haqida qisqacha gapirib beraman. Biroq, mumkin bo'lgan rivojlanish sxemalaridan men faqat hozir mavjud bo'lganlarini tanladim foydalanish oson. Har bir element uchun sizda tayyor kutubxonalar mavjud yoki muammoni bulutli platforma yordamida hal qilish imkoniyati mavjud.

Gorizontal masshtablash

Eng oddiy va eng mashhur nuqta. An'anaviy ravishda, eng keng tarqalgan ikkita yuk taqsimlash sxemasi gorizontal va vertikal o'lchovdir. Birinchi holda xizmatlarning parallel ishlashiga ruxsat berasiz va shu bilan ular o'rtasida yukni taqsimlaysiz. Ikkinchisida Siz kuchliroq serverlarga buyurtma berasiz yoki kodni optimallashtirasiz.

Misol uchun, men mavhum bulutli fayllarni saqlashni olaman, ya'ni OwnCloud, OneDrive va boshqalarning analoglari.

Bunday sxemaning standart rasmi quyida keltirilgan, ammo u faqat tizimning murakkabligini ko'rsatadi. Axir, biz xizmatlarni qandaydir tarzda sinxronlashtirishimiz kerak. Agar foydalanuvchi faylni planshetdan saqlasa va keyin uni telefondan ko'rishni xohlasa nima bo'ladi?

Yondashuvlar orasidagi farq: vertikal masshtablashda biz tugunlarning kuchini oshirishga tayyormiz, gorizontal masshtablashda esa yukni taqsimlash uchun yangi tugunlarni qo'shishga tayyormiz.

CQRS

Buyruq so'rovi bo'yicha javobgarlikni ajratish Bu juda muhim naqsh, chunki u turli mijozlarga nafaqat turli xizmatlarga ulanish, balki bir xil voqealar oqimini olish imkonini beradi. Uning afzalliklari oddiy dastur uchun unchalik aniq emas, lekin band bo'lgan xizmat uchun juda muhim (va oddiy). Uning mohiyati: kiruvchi va chiquvchi ma'lumotlar oqimlari kesishmasligi kerak. Ya'ni, siz so'rov yubora olmaysiz va javob kuta olmaysiz, aksincha, siz A xizmatiga so'rov yuborasiz, lekin B xizmatidan javob olasiz.

Ushbu yondashuvning birinchi bonusi uzoq so'rovni bajarishda aloqani (so'zning keng ma'nosida) uzish qobiliyatidir. Masalan, ko'proq yoki kamroq standart ketma-ketlikni olaylik:

1. Mijoz serverga so'rov yubordi.
2. Server uzoq vaqt ishlov berishni boshladi.
3. Server mijozga natija bilan javob berdi.

Tasavvur qilaylik, 2-bandda ulanish uzilgan (yoki tarmoq qayta ulangan yoki foydalanuvchi boshqa sahifaga o'tib, ulanishni buzgan). Bunday holda, server foydalanuvchiga aniq nima ishlov berilganligi haqida ma'lumot bilan javob yuborishi qiyin bo'ladi. CQRS-dan foydalanib, ketma-ketlik biroz boshqacha bo'ladi:

1. Mijoz yangilanishlarga obuna bo'ldi.
2. Mijoz serverga so'rov yubordi.
3. Server "so'rov qabul qilindi" deb javob berdi.
4. Server "1" nuqtadan kanal orqali natija bilan javob berdi.

Ko'rib turganingizdek, sxema biroz murakkabroq. Bundan tashqari, bu erda so'rov-javobning intuitiv yondashuvi etishmayapti. Biroq, ko'rib turganingizdek, so'rovni qayta ishlash paytida ulanishning uzilishi xatolikka olib kelmaydi. Bundan tashqari, agar foydalanuvchi xizmatga bir nechta qurilmalardan (masalan, mobil telefon va planshetdan) ulangan bo'lsa, javob ikkala qurilmaga ham kelishiga ishonch hosil qilishingiz mumkin.

Qizig'i shundaki, kiruvchi xabarlarni qayta ishlash kodi mijozning o'zi ta'sir qilgan voqealar uchun ham, boshqa voqealar, shu jumladan boshqa mijozlar uchun ham bir xil bo'ladi (100% emas).

Biroq, aslida biz bir yo'nalishli oqimni funktsional uslubda (RX va shunga o'xshash) ishlatish mumkinligi sababli qo'shimcha bonus olamiz. Va bu allaqachon jiddiy plyus, chunki aslida dastur to'liq reaktiv bo'lishi mumkin, shuningdek, funktsional yondashuv yordamida. Yog 'dasturlari uchun bu rivojlanish va qo'llab-quvvatlash resurslarini sezilarli darajada tejash imkonini beradi.

Agar biz ushbu yondashuvni gorizontal masshtablash bilan birlashtirsak, bonus sifatida biz bir serverga so'rov yuborish va boshqasidan javob olish imkoniyatiga ega bo'lamiz. Shunday qilib, mijoz o'zi uchun qulay bo'lgan xizmatni tanlashi mumkin va ichidagi tizim hali ham voqealarni to'g'ri qayta ishlash imkoniyatiga ega bo'ladi.

Tadbir manbalari

Ma'lumki, taqsimlangan tizimning asosiy xususiyatlaridan biri - umumiy vaqt, umumiy tanqidiy bo'limning yo'qligi. Bitta jarayon uchun siz sinxronizatsiya qilishingiz mumkin (xuddi shu mutekslarda), uning ichida bu kodni boshqa hech kim bajarmayotganiga ishonchingiz komil. Biroq, bu taqsimlangan tizim uchun xavflidir, chunki u qo'shimcha xarajatlarni talab qiladi, shuningdek, masshtablashning barcha go'zalligini o'ldiradi - barcha komponentlar hali ham bittasini kutishadi.

Bu erdan biz muhim faktni olamiz - tez taqsimlangan tizimni sinxronlashtirish mumkin emas, chunki u holda biz ishlashni pasaytiramiz. Boshqa tomondan, biz ko'pincha komponentlar o'rtasida ma'lum bir mustahkamlikka muhtojmiz. Va buning uchun siz bilan yondashuvdan foydalanishingiz mumkin yakuniy izchillik, agar oxirgi yangilanishdan keyin ma'lum vaqt davomida ma'lumotlar o'zgarmasa ("oxir-oqibat"), barcha so'rovlar oxirgi yangilangan qiymatni qaytarishi kafolatlangan.

Klassik ma'lumotlar bazalari uchun u juda tez-tez ishlatilishini tushunish muhimdir kuchli mustahkamlik, bu erda har bir tugun bir xil ma'lumotga ega (bu ko'pincha tranzaktsiya faqat ikkinchi server javob berganidan keyin tuzilgan deb hisoblangan holatda erishiladi). Bu erda izolyatsiya darajalari tufayli ba'zi dam olishlar mavjud, ammo umumiy g'oya o'zgarishsiz qoladi - siz butunlay uyg'unlashgan dunyoda yashashingiz mumkin.

Biroq, keling, asl vazifaga qaytaylik. Agar tizimning bir qismi bilan qurish mumkin bo'lsa yakuniy izchillik, keyin biz quyidagi diagrammani qurishimiz mumkin.

Ushbu yondashuvning muhim xususiyatlari:

• Har bir kiruvchi so'rov bitta navbatga qo'yiladi.
• So'rovni ko'rib chiqishda xizmat vazifalarni boshqa navbatlarga ham qo'yishi mumkin.
• Har bir kiruvchi hodisa identifikatorga ega (bu deuplikatsiya uchun zarur).
• Navbat mafkuraviy ravishda "faqat qo'shish" sxemasiga muvofiq ishlaydi. Undan elementlarni olib tashlay olmaysiz yoki ularni qayta tartibga sola olmaysiz.
• Navbat FIFO sxemasiga muvofiq ishlaydi (tavtologiya uchun uzr). Agar parallel bajarish kerak bo'lsa, unda bir bosqichda ob'ektlarni turli navbatlarga o'tkazish kerak.

Sizga shuni eslatib o'tamanki, biz onlayn fayllarni saqlash ishini ko'rib chiqmoqdamiz. Bunday holda, tizim quyidagicha ko'rinadi:

Diagrammadagi xizmatlar alohida serverni anglatmasligi muhim. Hatto jarayon bir xil bo'lishi mumkin. Yana bir narsa muhim: mafkuraviy jihatdan, bu narsalar gorizontal o'lchovni osongina qo'llash mumkin bo'lgan tarzda ajratilgan.

Ikki foydalanuvchi uchun diagramma quyidagicha ko'rinadi (turli foydalanuvchilar uchun mo'ljallangan xizmatlar turli xil ranglarda ko'rsatilgan):

Bunday kombinatsiyadan bonuslar:

• Axborotni qayta ishlash xizmatlari ajratilgan. Navbatlar ham ajratilgan. Agar biz tizimning o'tkazuvchanligini oshirishimiz kerak bo'lsa, unda biz ko'proq serverlarda ko'proq xizmatlarni ishga tushirishimiz kerak.
• Biz foydalanuvchidan ma'lumot olganimizda, ma'lumotlar to'liq saqlanishini kutishimiz shart emas. Aksincha, biz faqat "ok" deb javob berishimiz va keyin asta-sekin ishlashni boshlashimiz kerak. Shu bilan birga, navbat cho'qqilarni yumshatadi, chunki yangi ob'ektni qo'shish tezda sodir bo'ladi va foydalanuvchi butun tsikldan to'liq o'tishni kutishi shart emas.
• Misol sifatida, men bir xil fayllarni birlashtirishga harakat qiladigan deduplikatsiya xizmatini qo'shdim. Agar u 1% hollarda uzoq vaqt ishlasa, mijoz buni deyarli sezmaydi (yuqoriga qarang), bu katta ortiqcha, chunki bizdan endi XNUMX% tezlik va ishonchlilik talab etilmaydi.

Biroq, kamchiliklar darhol ko'rinadi:

• Bizning tizimimiz o'zining qat'iy izchilligini yo'qotdi. Bu shuni anglatadiki, agar siz, masalan, turli xizmatlarga obuna bo'lsangiz, nazariy jihatdan siz boshqa holatni olishingiz mumkin (chunki xizmatlardan biri ichki navbatdan bildirishnoma olishga ulgurmasligi mumkin). Yana bir natija sifatida, tizim endi umumiy vaqtga ega emas. Ya'ni, masalan, barcha hodisalarni kelish vaqti bo'yicha tartiblash mumkin emas, chunki serverlar orasidagi soatlar sinxron bo'lmasligi mumkin (bundan tashqari, ikkita serverda bir vaqtning o'zida utopiya).
• Endi hech qanday hodisani shunchaki orqaga qaytarib bo'lmaydi (ma'lumotlar bazasida bo'lgani kabi). Buning o'rniga siz yangi hodisa qo'shishingiz kerak - kompensatsiya hodisasi, bu oxirgi holatni kerakli holatga o'zgartiradi. Shunga o'xshash sohadan misol sifatida: tarixni qayta yozmasdan (ba'zi hollarda bu yomon), siz git-dagi majburiyatni orqaga qaytara olmaysiz, lekin siz maxsus qilishingiz mumkin. orqaga qaytarish majburiyati, bu aslida eski holatni qaytaradi. Biroq, noto'g'ri majburiyat ham, orqaga qaytarish ham tarixda qoladi.
• Ma'lumotlar sxemasi nashrdan nashrga o'zgarishi mumkin, ammo eski voqealar endi yangi standartga yangilanmaydi (chunki hodisalarni printsipial jihatdan o'zgartirish mumkin emas).

Ko'rib turganingizdek, Event Sourcing CQRS bilan yaxshi ishlaydi. Bundan tashqari, samarali va qulay navbatlarga ega, ammo ma'lumotlar oqimlarini ajratmasdan tizimni amalga oshirish allaqachon qiyin, chunki siz navbatlarning barcha ijobiy ta'sirini zararsizlantiradigan sinxronizatsiya nuqtalarini qo'shishingiz kerak bo'ladi. Ikkala yondashuvni bir vaqtning o'zida qo'llash orqali dastur kodini biroz sozlash kerak. Bizning holatda, faylni serverga yuborishda javob faqat "ok" keladi, bu faqat "faylni qo'shish operatsiyasi saqlangan" degan ma'noni anglatadi. Rasmiy ravishda, bu ma'lumotlar boshqa qurilmalarda allaqachon mavjud degani emas (masalan, deuplikatsiya xizmati indeksni qayta tiklashi mumkin). Biroq, bir muncha vaqt o'tgach, mijoz "X fayli saqlandi" tarzida bildirishnoma oladi.

Natijada:

• Fayl yuborish holatlari soni ortib bormoqda: klassik "fayl yuborilgan" o'rniga ikkitasini olamiz: "fayl serverdagi navbatga qo'shildi" va "fayl xotirada saqlangan". Ikkinchisi, boshqa qurilmalar allaqachon faylni qabul qilishni boshlashi mumkinligini anglatadi (navbatlar turli tezlikda ishlashiga moslashtirilgan).
• Yuborish ma'lumotlari endi turli kanallar orqali kelayotganligi sababli, biz faylni qayta ishlash holatini olish uchun echimlarni topishimiz kerak. Buning oqibati: klassik so'rov-javobdan farqli o'laroq, mijoz faylni qayta ishlash vaqtida qayta ishga tushirilishi mumkin, ammo bu qayta ishlashning o'zi to'g'ri bo'ladi. Bundan tashqari, ushbu element, asosan, qutidan tashqarida ishlaydi. Natijada: biz muvaffaqiyatsizliklarga ko'proq toqat qilamiz.

Sharding

Yuqorida ta'riflanganidek, voqea manbalari tizimlarida qat'iy izchillik yo'q. Bu shuni anglatadiki, biz bir nechta saqlash joylarini ular o'rtasida sinxronlashsiz ishlatishimiz mumkin. Muammoimizga yaqinlashib, biz:

• Fayllarni turiga qarab ajrating. Masalan, rasmlar/videolar dekodlanishi va yanada samaraliroq formatni tanlashi mumkin.
• Mamlakatlar bo'yicha alohida hisoblar. Ko'pgina qonunlar tufayli bu talab qilinishi mumkin, ammo bu arxitektura sxemasi avtomatik ravishda bunday imkoniyatni beradi

Agar siz ma'lumotlarni bir xotiradan boshqasiga o'tkazmoqchi bo'lsangiz, standart vositalar endi etarli emas. Afsuski, bu holda siz navbatni to'xtatishingiz, migratsiyani amalga oshirishingiz va keyin uni boshlashingiz kerak. Umuman olganda, ma'lumotni "tezda" o'tkazib bo'lmaydi, biroq, agar voqea navbati to'liq saqlangan bo'lsa va sizda oldingi saqlash holatlarining suratlari bo'lsa, biz voqealarni quyidagicha takrorlashimiz mumkin:

• Voqealar manbasida har bir hodisa o'z identifikatoriga ega (ideal holda, kamaymaydi). Bu biz saqlashga maydon qo'shishimiz mumkinligini anglatadi - oxirgi qayta ishlangan elementning identifikatori.
• Biz navbatni takrorlaymiz, shunda barcha hodisalar bir nechta mustaqil xotiralar uchun qayta ishlanishi mumkin (birinchisi, ma'lumotlar allaqachon saqlangan, ikkinchisi esa yangi, ammo hali ham bo'sh). Ikkinchi navbat, albatta, hali qayta ishlanmayapti.
• Biz ikkinchi navbatni ishga tushiramiz (ya'ni voqealarni takrorlashni boshlaymiz).
• Yangi navbat nisbatan bo'sh bo'lsa (ya'ni, element qo'shish va uni olish o'rtasidagi o'rtacha vaqt farqi maqbuldir), siz o'quvchilarni yangi xotiraga o'tkazishni boshlashingiz mumkin.

Ko‘rib turganingizdek, tizimimizda qat’iy izchillik bo‘lmagan va hozir ham mavjud emas. Faqat yakuniy izchillik mavjud, ya'ni voqealar bir xil tartibda (lekin, ehtimol, turli kechikishlar bilan) qayta ishlanishi kafolati. Va bundan foydalanib, biz tizimni dunyoning boshqa tomoniga to'xtatmasdan ma'lumotlarni nisbatan osonlik bilan uzatishimiz mumkin.

Shunday qilib, fayllarni onlayn saqlash haqidagi misolimizni davom ettirsak, bunday arxitektura allaqachon bizga bir qator bonuslarni beradi:

• Biz ob'ektlarni dinamik tarzda foydalanuvchilarga yaqinroq ko'chirishimiz mumkin. Shu tarzda siz xizmat sifatini oshirishingiz mumkin.
• Biz ba'zi ma'lumotlarni kompaniyalar ichida saqlashimiz mumkin. Masalan, Enterprise foydalanuvchilari ko'pincha o'z ma'lumotlarini boshqariladigan ma'lumotlar markazlarida saqlashni talab qiladilar (ma'lumotlar sizib chiqmasligi uchun). Sharding orqali biz buni osongina qo'llab-quvvatlay olamiz. Agar mijoz mos bulutga ega bo'lsa, vazifa yanada osonlashadi (masalan, Azure o'z-o'zidan xostda).
• Va eng muhimi, biz buni qilishimiz shart emas. Axir, birinchi navbatda, biz barcha hisoblar uchun bitta xotiradan mamnun bo'lamiz (tezkor ishlashni boshlash uchun). Va bu tizimning asosiy xususiyati shundaki, u kengaytirilishi mumkin bo'lsa-da, dastlabki bosqichda bu juda oddiy. Siz millionlab alohida mustaqil navbatlar va boshqalar bilan ishlaydigan kodni darhol yozishingiz shart emas. Agar kerak bo'lsa, bu kelajakda amalga oshirilishi mumkin.

Statik kontent hosting

Bu nuqta juda aniq bo'lib tuyulishi mumkin, ammo u ko'proq yoki kamroq standart yuklangan dastur uchun zarurdir. Uning mohiyati oddiy: barcha statik tarkib dastur joylashgan bir xil serverdan emas, balki ushbu vazifaga maxsus ajratilgan maxsus serverlardan tarqatiladi. Natijada, bu operatsiyalar tezroq amalga oshiriladi (shartli nginx fayllarga Java serveriga qaraganda tezroq va arzonroq xizmat qiladi). Bundan tashqari CDN arxitekturasi (Kontentni etkazib berish tarmog'i) bizga fayllarimizni oxirgi foydalanuvchilarga yaqinroq joylashtirish imkonini beradi, bu esa xizmat bilan ishlash qulayligiga ijobiy ta'sir qiladi.

Statik tarkibning eng oddiy va eng standart namunasi veb-sayt uchun skriptlar va tasvirlar to'plamidir. Ular bilan hamma narsa oddiy - ular oldindan ma'lum, keyin arxiv CDN serverlariga yuklanadi, u erdan oxirgi foydalanuvchilarga tarqatiladi.

Biroq, aslida, statik tarkib uchun siz lambda arxitekturasiga biroz o'xshash yondashuvdan foydalanishingiz mumkin. Keling, bizning vazifamizga qaytaylik (onlayn fayllarni saqlash), unda biz foydalanuvchilarga fayllarni tarqatishimiz kerak. Eng oddiy yechim - har bir foydalanuvchi so'rovi uchun barcha kerakli tekshiruvlarni (avtorizatsiya va h.k.) amalga oshiradigan va keyin faylni to'g'ridan-to'g'ri bizning xotiramizdan yuklab oladigan xizmatni yaratish. Ushbu yondashuvning asosiy kamchiligi shundaki, statik tarkib (va ma'lum bir tahrirga ega bo'lgan fayl, aslida, statik tarkibdir) biznes mantig'ini o'z ichiga olgan bir xil server tomonidan tarqatiladi. Buning o'rniga siz quyidagi diagrammani yaratishingiz mumkin:

• Server yuklab olish URL manzilini taqdim etadi. Bu file_id + kalit shaklida bo'lishi mumkin, bu erda kalit keyingi 24 soat davomida resursga kirish huquqini beruvchi mini-raqamli imzodir.
• Fayl oddiy nginx tomonidan quyidagi variantlar bilan tarqatiladi:
  • Kontentni keshlash. Ushbu xizmat alohida serverda joylashgan bo'lishi mumkinligi sababli, biz o'zimizni diskda eng so'nggi yuklab olingan fayllarni saqlash imkoniyati bilan kelajak uchun zaxira qoldirdik.
  • Ulanishni yaratish vaqtida kalitni tekshirish
• Majburiy emas: oqimli kontentni qayta ishlash. Misol uchun, agar biz xizmatdagi barcha fayllarni siqib chiqarsak, biz to'g'ridan-to'g'ri ushbu modulda ochishimiz mumkin. Natijada: IO operatsiyalari tegishli joylarda amalga oshiriladi. Java-dagi arxivator juda ko'p qo'shimcha xotirani osongina ajratadi, lekin xizmatni biznes mantig'i bilan Rust/C++ shartlariga qayta yozish ham samarasiz bo'lishi mumkin. Bizning holatlarimizda turli jarayonlar (yoki hatto xizmatlar) qo'llaniladi va shuning uchun biz biznes mantig'i va IO operatsiyalarini juda samarali ajratishimiz mumkin.

Ushbu sxema statik tarkibni tarqatishga unchalik o'xshamaydi (chunki biz butun statik paketni biron joyga yuklamaymiz), lekin aslida bu yondashuv o'zgarmas ma'lumotlarni tarqatish bilan bog'liq. Bundan tashqari, ushbu sxema tarkib oddiygina statik bo'lmagan, balki o'zgarmas va o'chirilmaydigan bloklar to'plami sifatida ifodalanishi mumkin bo'lgan boshqa holatlarga umumlashtirilishi mumkin (garchi ularni qo'shish mumkin bo'lsa ham).

Yana bir misol (mustahkamlash uchun): agar siz Jenkins/TeamCity bilan ishlagan bo'lsangiz, ikkala yechim ham Java-da yozilganligini bilasiz. Ularning ikkalasi ham qurilish orkestrini va kontentni boshqarishni boshqaradigan Java jarayonidir. Xususan, ikkalasida ham "serverdan fayl/papkani uzatish" kabi vazifalar mavjud. Misol sifatida: artefaktlarni chiqarish, manba kodini o'tkazish (agent kodni to'g'ridan-to'g'ri ombordan yuklab olmasa, lekin server buni uning uchun qiladi), jurnallarga kirish. Bu vazifalarning barchasi IO yukida farqlanadi. Ya'ni, murakkab biznes mantig'i uchun mas'ul bo'lgan server bir vaqtning o'zida katta ma'lumotlar oqimini o'zi orqali samarali ravishda o'tkaza olishi kerak. Va eng qiziq tomoni shundaki, bunday operatsiya aynan bir xil sxema bo'yicha bir xil nginx-ga topshirilishi mumkin (ma'lumotlar kaliti so'rovga qo'shilishi kerakligidan tashqari).

Ammo, agar biz tizimimizga qaytsak, biz shunga o'xshash diagramma olamiz:

Ko'rib turganingizdek, tizim tubdan murakkablashdi. Endi bu faqat fayllarni mahalliy darajada saqlaydigan mini-jarayon emas. Endi talab qilinadigan narsa oddiy qo'llab-quvvatlash, API versiyasini boshqarish va boshqalar emas. Shuning uchun, barcha diagrammalar chizilgandan so'ng, kengaytirilishning qimmatga tushishini batafsil baholash yaxshidir. Ammo, agar siz tizimni kengaytirish imkoniyatiga ega bo'lishni istasangiz (shu jumladan ko'proq foydalanuvchilar bilan ishlash uchun), unda siz shunga o'xshash echimlarga murojaat qilishingiz kerak bo'ladi. Ammo, natijada, tizim me'moriy jihatdan ortib borayotgan yukga tayyor (deyarli har bir komponent gorizontal o'lchov uchun klonlanishi mumkin). Tizim uni to'xtatmasdan yangilanishi mumkin (shunchaki ba'zi operatsiyalar biroz sekinlashadi).

Boshida aytganimdek, hozirda bir qator Internet xizmatlari yuklamani oshira boshladi. Va ularning ba'zilari shunchaki to'g'ri ishlashni to'xtata boshladilar. Darhaqiqat, tizimlar biznes pul topishi kerak bo'lgan vaqtda muvaffaqiyatsizlikka uchradi. Ya'ni, etkazib berishni kechiktirish o'rniga, mijozlarga "kelgusi oylarga yetkazib berishni rejalashtirish" o'rniga, tizim shunchaki "raqobatchilaringizga boring" dedi. Aslida, bu past mahsuldorlikning narxi: yo'qotishlar aynan foyda eng yuqori bo'lganda sodir bo'ladi.

xulosa

Bu yondashuvlarning barchasi ilgari ma'lum edi. Xuddi shu VK uzoq vaqtdan beri tasvirlarni ko'rsatish uchun Static Content Hosting g'oyasidan foydalanib keladi. Ko'pgina onlayn o'yinlar o'yinchilarni mintaqalarga bo'lish yoki o'yin joylarini ajratish uchun Sharding sxemasidan foydalanadi (agar dunyoning o'zi bitta bo'lsa). Voqealar manbasini aniqlash usuli elektron pochtada faol qo'llaniladi. Ma'lumotlar doimiy ravishda olinadigan ko'pgina savdo ilovalari aslida olingan ma'lumotlarni filtrlash imkoniyatiga ega bo'lish uchun CQRS yondashuviga asoslangan. Xo'sh, gorizontal masshtablash ko'plab xizmatlarda uzoq vaqtdan beri qo'llanilgan.

Biroq, eng muhimi, bu naqshlarning barchasi zamonaviy ilovalarda qo'llanilishi juda oson bo'ldi (agar ular mos bo'lsa, albatta). Bulutlar Sharding va gorizontal miqyosni darhol taklif qiladi, bu turli xil ma'lumotlar markazlarida turli xil ajratilgan serverlarga buyurtma berishdan ko'ra osonroqdir. RX kabi kutubxonalarning rivojlanishi tufayli CQRS ancha osonlashdi. Taxminan 10 yil oldin, noyob veb-sayt buni qo'llab-quvvatlashi mumkin edi. Apache Kafka bilan tayyor konteynerlar tufayli Event Sourcing-ni sozlash ham juda oson. 10 yil oldin bu yangilik bo'lgan bo'lsa, endi bu odatiy holga aylandi. Static Content Hosting bilan ham xuddi shunday: qulayroq texnologiyalar (shu jumladan batafsil hujjatlar va javoblarning katta ma'lumotlar bazasi mavjudligi) tufayli bu yondashuv yanada soddalashdi.

Natijada, bir qator juda murakkab me'moriy naqshlarni amalga oshirish endi ancha soddalashdi, ya'ni uni oldindan diqqat bilan ko'rib chiqish yaxshiroqdir. Agar o'n yillik dasturda yuqoridagi echimlardan biri amalga oshirish va ishlatishning yuqori xarajati tufayli bekor qilingan bo'lsa, endi yangi dasturda yoki refaktoringdan so'ng siz allaqachon me'moriy jihatdan kengaytiriladigan xizmatni yaratishingiz mumkin ( ishlash bo'yicha) va mijozlarning yangi so'rovlariga tayyor (masalan, shaxsiy ma'lumotlarni mahalliylashtirish uchun).

Va eng muhimi: agar sizda oddiy dastur bo'lsa, iltimos, ushbu yondashuvlardan foydalanmang. Ha, ular chiroyli va qiziqarli, lekin 100 kishining eng yuqori tashrifi bo'lgan sayt uchun siz ko'pincha klassik monolit bilan olishingiz mumkin (hech bo'lmaganda tashqi tomondan, ichidagi hamma narsa modullarga bo'linishi mumkin va hokazo).

Manba: www.habr.com