Hey Xabr!

Koronavirus tufayli roʻy berayotgan voqealarni hisobga olib, bir qator internet xizmatlari yuklanishini boshdan kechira boshladi. Masalan, Buyuk Britaniyaning bir chakana savdo tarmog'i shunchaki onlayn buyurtma veb-saytini yopdi., chunki imkoniyatlar yetarli emas edi. Va shunchaki kuchliroq uskunani qo'shish orqali serverni tezlashtirish har doim ham mumkin emas, lekin mijozlar so'rovlarini qayta ishlash kerak (yoki ular raqobatchilarga o'tadi).

Ushbu maqolada men tez va nosozliklarga chidamli xizmatni yaratishga yordam beradigan mashhur amaliyotlarni qisqacha muhokama qilaman. Biroq, mumkin bo'lgan rivojlanish sxemalaridan men faqat hozirda foydalanilayotganlarini tanladim. foydalanish osonHar bir element uchun sizda tayyor kutubxonalar mavjud yoki muammoni bulutli platforma yordamida hal qilishingiz mumkin.

Gorizontal masshtablash

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

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

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

Yondashuvlar orasidagi farq shundaki, vertikal masshtablashda biz tugunlarning sig‘imini oshirishga tayyormiz, gorizontal masshtablashda esa yukni taqsimlash uchun yangi tugunlarni qo‘shishga tayyormiz.

CQRS

Buyruq so'rovi bo'yicha javobgarlikni ajratish Bu juda muhim namunadir, 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 shundaki, kiruvchi va chiquvchi ma'lumotlar oqimlari kesishmasligi kerak. Ya'ni, siz so'rov yubora olmaysiz va javob kuta olmaysiz; Buning o'rniga siz A xizmatiga so'rov yuborasiz, lekin B xizmatidan javob olasiz.

Ushbu yondashuvning birinchi foydasi - uzoq so'rov paytida ulanishlarni (so'zning keng ma'nosida) uzish qobiliyati. 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-bosqichda ulanish uzildi (tarmoq qayta ulandi yoki foydalanuvchi boshqa sahifaga o'tib, ulanishni buzdi). Bunday holda, server foydalanuvchiga aynan nima qayta ishlanganligi to'g'risida xabar beruvchi 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 intuitiv so'rov-javob yondashuvi mavjud emas. Biroq, ko'rib turganingizdek, so'rovni qayta ishlash jarayonida ulanishning uzilishi xatolikka olib kelmaydi. Bundan tashqari, agar foydalanuvchi haqiqatan ham bir nechta qurilmalardan (masalan, mobil telefon va planshet) xizmatga ulangan bo'lsa, har ikkala qurilmaga ham javob yuborilishini tashkil qilish mumkin.

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

Biroq, aslida, biz bir yo'nalishli oqimni funktsional (RX va shunga o'xshash usullar yordamida) boshqarish mumkinligidan qo'shimcha foyda olamiz. Bu muhim afzallikdir, chunki dastur hatto funktsional yondashuvdan foydalangan holda ham to'liq reaktiv bo'lishi mumkin. Keng ko'lamli dasturlar uchun bu rivojlanish va qo'llab-quvvatlash resurslarini sezilarli darajada kamaytirishi mumkin.

Ushbu yondashuvni gorizontal o'lchov bilan birlashtirish bir serverga so'rov yuborish va boshqasidan javob olish imkoniyatini beradi. Bu mijozga o'zi yoqtirgan xizmatni tanlash imkonini beradi, shu bilan birga asosiy tizim voqealarni to'g'ri qayta ishlashga qodir.

Tadbir manbalari

Ma'lumki, taqsimlangan tizimning asosiy xususiyatlaridan biri bu umumiy vaqt yoki umumiy tanqidiy bo'limning yo'qligi. Bitta jarayon uchun siz sinxronizatsiyani (mutexlardan foydalangan holda) amalga oshirishingiz mumkin, bu boshqa hech kim bir xil kodni bajarmasligini ta'minlaydi. Biroq, taqsimlangan tizim uchun bu xavfli, chunki u qo'shimcha xarajatlarni talab qiladi va miqyoslash maqsadini buzadi - barcha komponentlar hali ham bir xil narsani kutishadi.

Bu bizni muhim haqiqatga olib keladi: tez taqsimlangan tizimni sinxronlashtirib bo'lmaydi, chunki bu unumdorlikni pasaytiradi. Boshqa tomondan, biz ko'pincha komponentlar o'rtasida ma'lum darajada muvofiqlikka muhtojmiz. Va buning uchun biz bilan yondashuvdan foydalanishimiz mumkin yakuniy izchillik, agar oxirgi yangilanishdan keyin ma'lum vaqt ichida 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 qat'iy izchillik, bu erda har bir tugun bir xil ma'lumotga ega (bu ko'pincha tranzaksiya faqat ikkinchi server javob berganidan keyin tuzilgan deb hisoblanganda erishiladi). Izolyatsiya darajasi tufayli bu erda ba'zi dam olishlar mavjud, ammo umumiy g'oya bir xil bo'lib qoladi - siz mutlaqo izchil dunyoda yashashingiz mumkin.

Ammo asl muammoga qaytaylik. Agar tizimning bir qismi bilan qurish mumkin bo'lsa yakuniy izchillik, keyin quyidagi diagramma qurish mumkin.

Ushbu yondashuvning muhim xususiyatlari:

• Har bir kiruvchi so'rov bitta navbatga joylashtiriladi.
• So'rovni ko'rib chiqishda xizmat vazifalarni boshqa navbatlarga ham qo'yishi mumkin.
• Har bir kiruvchi hodisa identifikatoriga ega (bu ikki nusxadan chiqarish uchun zarur).
• Navbat "faqat qo'shish" tamoyili bo'yicha ishlaydi. Elementlarni olib tashlash yoki qayta tartiblash mumkin emas.
• Navbat FIFO (birinchi kiruvchi, birinchi chiqadi) asosida ishlaydi. Agar parallel bajarish kerak bo'lsa, ob'ektlarni bir bosqichda turli navbatlarga o'tkazish kerak.

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

Shuni ta'kidlash kerakki, diagrammadagi xizmatlar alohida serverlarni ko'rsatishi shart emas. Ular hatto bir xil jarayonni baham ko'rishlari mumkin. Muhimi shundaki, bu narsalar gorizontal miqyosni osongina amalga oshirish mumkin bo'lgan tarzda mafkuraviy tarzda ajratilgan.

Va ikkita foydalanuvchi uchun diagramma quyidagicha ko'rinadi (turli foydalanuvchilar uchun mo'ljallangan xizmatlar turli xil ranglarda belgilangan):

Bunday kombinatsiyadan bonuslar:

• Axborotni qayta ishlash xizmatlari ajratilgan. Navbatlar ham ajratilgan. Agar tizimning o'tkazish qobiliyatini oshirish kerak bo'lsa, biz shunchaki ko'proq serverlarda ko'proq xizmatlarni ishga tushirishimiz kerak.
• Biz foydalanuvchidan ma'lumot olganimizda, ma'lumotlar to'liq saqlanishini kutishimiz shart emas. Buning o'rniga, biz shunchaki "OK" deb javob beramiz va keyin asta-sekin ishlov berishni boshlaymiz. Navbat cho'qqilarni ham yumshatadi, chunki yangi ob'ektni qo'shish tez sodir bo'ladi va foydalanuvchi butun tsikl tugashini kutishi shart emas.
• Misol sifatida, men bir xil fayllarni birlashtirishga harakat qiladigan deduplikatsiya xizmatini qo'shdim. Agar 1% hollarda bajarish uchun uzoq vaqt kerak bo'lsa, mijoz deyarli sezmaydi (yuqoriga qarang), bu katta ortiqcha, chunki biz endi 100% tezlik va ishonchlilikni talab qilmaymiz.

Biroq, kamchiliklar darhol ko'rinadi:

• Bizning tizimimiz endi qat'iy izchillikka ega emas. Bu shuni anglatadiki, masalan, agar siz turli xizmatlarga obuna bo'lsangiz, siz nazariy jihatdan turli holatlarni olishingiz mumkin (chunki xizmatlardan biri ichki navbatdan bildirishnoma olishga ulgurmasligi mumkin). Yana bir natija shundaki, tizim endi umumiy vaqtga ega emas. Bu, masalan, barcha hodisalarni kelish vaqti bo'yicha tartiblashning iloji yo'qligini anglatadi, chunki serverlar o'rtasidagi soatlar sinxronlashtirilmasligi mumkin (aslida, ikkita serverda bir xil vaqtga ega bo'lish - bu utopiya).
• Endi hech qanday hodisani shunchaki orqaga qaytarib bo'lmaydi (ma'lumotlar bazasi bilan bo'lgani kabi). Buning o'rniga yangi voqea qo'shilishi 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-da 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 saqlanib 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, ma'lumotlar oqimlarini ajratmasdan samarali va qulay navbatlarga ega tizimni amalga oshirish juda qiyin, chunki u navbatlarning ijobiy ta'sirini inkor etadigan sinxronizatsiya nuqtalarini qo'shishni talab qiladi. Ikkala yondashuvdan bir vaqtning o'zida foydalanish dastur kodiga kichik tuzatishlarni talab qiladi. Bizning holatda, faylni serverga yuborishda javob faqat "OK" ni qaytaradi, bu shunchaki "fayl qo'shish operatsiyasi saqlangan" degan ma'noni anglatadi. Texnik jihatdan, 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" degan xabarnoma oladi.

Natijada:

• Fayl yuborish holatlari soni ortib bormoqda: klassik "fayl yuborilgan" o'rniga biz ikkitasini ko'ramiz: "fayl server navbatiga qo'shilgan" va "fayl xotiraga saqlangan". Ikkinchisi, boshqa qurilmalar endi faylni qabul qilishni boshlashi mumkinligini anglatadi (navbatlar turli tezliklarda ishlaydi).
• Taqdim etish ma'lumotlari endi turli kanallar orqali kelganligi sababli, biz fayllarni qayta ishlash holatini olish uchun echimlarni ishlab chiqishimiz kerak. Natijada, so'rovga javob berishning klassik usulidan farqli o'laroq, mijoz faylga ishlov berilayotganda qayta ishga tushirilishi mumkin, ammo ishlov berish holati to'g'ri bo'lib qoladi. Bundan tashqari, bu xususiyat aslida qutidan tashqarida ishlaydi. Natijada, biz endi muvaffaqiyatsizliklarga toqatliroq bo'lamiz.

Sharding

Yuqorida ta'riflanganidek, voqea manbalariga ega tizimlar qat'iy izchillikka ega emas. Bu shuni anglatadiki, biz bir nechta saqlash qurilmalarini ular o'rtasida sinxronizatsiya qilmasdan ishlatishimiz mumkin. Vazifamizga yaqinlashib, biz:

• Fayllarni turiga qarab ajrating. Masalan, tasvirlar/videolar dekodlanishi va samaraliroq format tanlanishi mumkin.
• Mamlakatlar bo'yicha alohida hisoblar. Ko'pgina qonunlar buni talab qilishi mumkin, ammo bu arxitektura buni avtomatik ravishda amalga oshirishga imkon beradi.

Agar siz ma'lumotlarni bir xotiradan boshqasiga ko'chirmoqchi bo'lsangiz, standart vositalar ishlamaydi. Afsuski, bu holda siz navbatni to'xtatishingiz, migratsiyani amalga oshirishingiz va keyin uni qayta ishga tushirishingiz kerak. Umuman olganda, siz ma'lumotlarni "tezda" ko'chira olmaysiz. Biroq, agar voqea navbati to'liq saqlangan bo'lsa va sizda oldingi saqlash holatlarining suratlari bo'lsa, voqealarni quyidagicha takrorlashingiz mumkin:

• Voqealar manbasida har bir hodisa o'z identifikatoriga ega (ideal holda, kamaymaydigan). Bu biz saqlashga maydon qo'shishimiz mumkinligini anglatadi - oxirgi qayta ishlangan elementning identifikatori.
• Biz navbatni takrorlaymiz, shunda barcha hodisalar bir nechta mustaqil saqlash joylarida qayta ishlanishi mumkin (birinchisi hozirda ma'lumotlarni saqlaydi, ikkinchisi esa yangi, lekin hozir bo'sh). Ikkinchi navbat, tabiiyki, hozircha qayta ishlanmayapti.
• Biz ikkinchi navbatni boshlaymiz (ya'ni voqealarni takrorlashni boshlaymiz).
• Yangi navbat nisbatan bo'sh bo'lgach (ya'ni element qo'shish va uni olish o'rtasidagi o'rtacha vaqt farqi maqbuldir), o'quvchilar yangi xotiraga o'tishni boshlashlari mumkin.

Ko'rib turganingizdek, bizning tizimimizda qat'iy izchillik hech qachon bo'lmagan va hozir ham mavjud emas. Faqat yakuniy barqarorlik mavjud bo'lib, bu voqealar bir xil tartibda qayta ishlanishini kafolatlaydi (garchi, ehtimol, turli kechikishlar bilan). Bundan foydalanib, biz tizimni to'xtatmasdan ma'lumotlarni dunyoning boshqa tomoniga nisbatan osonlik bilan uzatishimiz mumkin.

Shunday qilib, onlayn fayllarni saqlash misolimizni davom ettirib, ushbu arxitektura allaqachon bizga bir qator bonuslarni taqdim etadi:

• Biz ob'ektlarni dinamik ravishda foydalanuvchilarga yaqinroq ko'chirishimiz va shu bilan xizmat sifatini yaxshilashimiz mumkin.
• Biz ba'zi ma'lumotlarni kompaniyalar ichida saqlashimiz mumkin. Masalan, korxona foydalanuvchilari ko'pincha o'z ma'lumotlarini boshqariladigan ma'lumotlar markazlarida saqlashni talab qiladilar (ma'lumotlar sizib chiqishining oldini olish uchun). Sharding yordamida biz buni osongina qo'llab-quvvatlay olamiz. Agar mijoz mos bulutga ega bo'lsa, bu vazifa yanada soddalashtiriladi (masalan, Azure o'z-o'zidan joylashtirilgan).
• Va eng muhimi, biz buni qilishimiz shart emas. Axir, boshlash uchun, barcha hisoblar uchun bitta xotira juda yaxshi bo'ladi (tezroq boshlash uchun). Va bu tizimning asosiy xususiyati shundaki, u kengaytiriladigan bo'lsa-da, boshida juda oddiy. Siz millionlab alohida mustaqil navbatlarni boshqaradigan kodni darhol yozishingiz shart emas va hokazo. Agar kerak bo'lsa, buni keyinroq qilishimiz mumkin.

Statik kontent hosting

Bu nuqta butunlay ravshan bo'lib tuyulishi mumkin, ammo u ko'proq yoki kamroq standart, yuqori yuklangan dastur uchun zarurdir. Uning mohiyati oddiy: barcha statik kontent ilova joylashgan serverdan emas, balki ushbu vazifaga maxsus ajratilgan maxsus serverlardan taqdim etiladi. Natijada, bu operatsiyalar tezroq amalga oshiriladi (masalan, Nginx Java serveriga qaraganda fayllarga tezroq va arzonroq xizmat qiladi). Bundan tashqari, CDN arxitekturasi mavjud (Kontentni etkazib berish tarmog'i) bizga fayllarimizni oxirgi foydalanuvchilarga yaqinroq joylashtirish imkonini beradi, bu esa xizmatdan foydalanish qulayligiga ijobiy ta'sir ko'rsatadi.

Statik tarkibning eng oddiy va eng standart namunasi veb-sayt uchun skriptlar va rasmlar to'plamidir. Bu juda oddiy - ular oldindan ma'lum va arxiv CDN serverlariga yuklanadi va u erdan oxirgi foydalanuvchilarga taqdim etiladi.

Biroq, amalda, statik tarkib uchun lambda arxitekturasiga biroz o'xshash yondashuvdan foydalanish mumkin. Keling, foydalanuvchilarga fayllarni tarqatishimiz kerak bo'lgan vazifamizga qaytaylik (onlayn fayllarni saqlash). Eng oddiy to'g'ridan-to'g'ri yechim - har bir foydalanuvchi so'rovi uchun barcha kerakli tekshiruvlarni (avtorizatsiya va h.k.) amalga oshiradigan va keyin faylni bizning xotiramizdan to'g'ridan-to'g'ri yuklab oladigan xizmatni yaratish. Ushbu yondashuvning asosiy kamchiligi shundaki, statik tarkib (va ma'lum bir tahrirga ega fayl asosan statik tarkibdir) biznes mantiqini o'z ichiga olgan bir xil server tomonidan xizmat qiladi. Buning o'rniga biz quyidagi sxemadan foydalanishimiz 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 miniatyura raqamli imzodir.
• Fayllarni tarqatish quyidagi variantlarga ega oddiy nginx tomonidan boshqariladi:
  • Kontentni keshlash. Ushbu xizmat alohida serverda joylashtirilishi mumkinligi sababli, biz yaqinda yuklab olingan barcha fayllarni diskda saqlash orqali kelajakka ishonch hosil qildik.
  • Ulanishni yaratishda kalitni tekshirish
• Majburiy emas: oqimli kontentni qayta ishlash. Misol uchun, agar biz xizmatdagi barcha fayllarni siqsak, ularni to'g'ridan-to'g'ri ushbu modulda ochishimiz mumkin. Natijada, IO operatsiyalari tegishli joylarda amalga oshiriladi. Java arxivatori juda ko'p keraksiz xotirani osongina ajratadi, ammo xizmatni an'anaviy Rust/C++ da biznes mantig'i bilan qayta yozish ham samarasiz bo'lishi mumkin. Bizning holatlarimizda biz turli jarayonlardan (hatto xizmatlardan) foydalanamiz, ya'ni biz biznes mantig'i va IO operatsiyalarini samarali ajratishimiz mumkin.

Bu sxema statik tarkibga xizmat ko'rsatishga unchalik o'xshamaydi (chunki biz butun statik paketni biron joyga yuklamaymiz), lekin aslida bu yondashuv o'zgarmas ma'lumotlarga xizmat qiladi. Bundan tashqari, ushbu sxema tarkib shunchaki statik bo'lmagan boshqa holatlarga umumlashtirilishi mumkin, lekin o'zgarmas va olinmaydigan bloklar to'plami sifatida taqdim etilishi mumkin (garchi ularni qo'shish mumkin bo'lsa ham).

Mana yana bir misol (mustahkamlash uchun): agar siz Jenkins yoki TeamCity bilan ishlagan bo'lsangiz, ikkala yechim ham Java-da yozilganligini bilasiz. Har ikkisi ham qurilish orkestrini, ham tarkibni boshqarishni boshqaradigan Java jarayonlari. Xususan, ularning ikkalasi ham "serverdan fayl/papkani uzatish" kabi vazifalarga ega. Masalan, artefakt yetkazib berish, manba kodini uzatish (agent kodni to'g'ridan-to'g'ri ombordan yuklab olmasa, lekin server buni amalga oshiradi) va jurnalga kirish. Bu vazifalarning barchasi turli xil IO yuklariga ega. Bu shuni anglatadiki, murakkab biznes mantig'i uchun mas'ul bo'lgan server katta ma'lumotlar oqimini o'zi orqali samarali ravishda o'tkazishi kerak. Va eng qizig'i shundaki, bu operatsiya aynan bir xil sxema bo'yicha Nginx-ga topshirilishi mumkin (ma'lumotlar kaliti so'rovga qo'shilishi kerakligidan tashqari).

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

Ko'rib turganingizdek, tizim tubdan murakkablashdi. Bu endi fayllarni mahalliy darajada saqlaydigan mini-jarayon emas. Endi u murakkab qo'llab-quvvatlashni, API versiyasini boshqarishni va hokazolarni talab qiladi. Shuning uchun, barcha diagrammalar chizilgandan so'ng, masshtablilik investitsiya qilishga arziydimi yoki yo'qligini yaxshilab baholash yaxshidir. Biroq, agar siz tizimni kengaytirish imkoniyatiga ega bo'lishni istasangiz (shu jumladan, ko'proq foydalanuvchilarni boshqarish uchun), bunday echimlarga murojaat qilishingiz kerak bo'ladi. Shu bilan birga, natijada tizim arxitekturasi ortib borayotgan yuk uchun tayyorlanadi (deyarli har bir komponent gorizontal masshtablash uchun klonlanishi mumkin). Tizim uni o'chirmasdan yangilanishi mumkin (ba'zi operatsiyalar biroz sekinroq bo'ladi).

Eng boshida aytib o'tganimdek, hozirda bir qator onlayn xizmatlar yukini ko'paytirmoqda. Va ularning ba'zilari shunchaki to'g'ri ishlashni to'xtatdi. Aslida, tizimlar korxonalar pul ishlashlari kerak bo'lgan paytda qulab tushdi. Shunday qilib, etkazib berishni kechiktirish o'rniga, mijozlarga "keyingi bir necha oyga yetkazib berishni rejalashtirishni" taklif qilish o'rniga, tizim shunchaki: "Raqobatchilarga boring". Bu, aslida, past mahsuldorlikning narxidir: yo'qotishlar aynan foyda eng yuqori bo'lganda sodir bo'ladi.

xulosa

Bu yondashuvlarning barchasi bir muncha vaqtdan beri mavjud. Masalan, VK uzoq vaqtdan beri tasvirlarga xizmat ko'rsatish uchun statik kontentni joylashtirish g'oyasidan foydalangan. Ko'pgina onlayn o'yinlar o'yinchilarni mintaqalar bo'yicha ajratish yoki o'yin joylarini ajratish uchun shardingdan foydalanadi (agar dunyoning o'zi birlashgan bo'lsa). Voqealar manbalari elektron pochtada faol qo'llaniladi. Doimiy ravishda ma'lumotlarni qabul qiladigan ko'pgina savdo ilovalari, aslida, kiruvchi ma'lumotlarni filtrlash uchun CQRS yondashuviga asoslangan. Gorizontal masshtablash esa ko'p xizmatlarda uzoq vaqtdan beri qo'llanilgan.

Biroq, eng muhimi, bu naqshlarning barchasi zamonaviy ilovalarda qo'llanilishi juda oson bo'lib qoldi (agar ular mos bo'lsa, albatta). Bulutli hisoblash turli xil ma'lumotlar markazlarida alohida ajratilgan serverlarga buyurtma berishdan ko'ra osonroq bo'lgan qismlarni ajratish va gorizontal o'lchovni taklif qiladi. RX kabi kutubxonalarning rivojlanishi tufayli CQRS ancha osonlashdi. O'n yil oldin, bir nechta veb-saytlar buni qo'llab-quvvatlay olardi. Tayyor Apache Kafka konteynerlari tufayli Event Sourcing-ni sozlash juda oson. O'n yil oldin, bu innovatsion bo'lar edi; endi bu odatiy holga aylandi. Xuddi shunday, Static Content Hosting bilan foydalanuvchilarga qulayroq texnologiyalar (jumladan, batafsil hujjatlar va katta javoblar bazasi) bu yondashuvni yanada soddalashtirdi.

Natijada, bir qator juda murakkab me'moriy naqshlarni amalga oshirish endi ancha soddalashdi, ya'ni ularni erta ko'rib chiqishga arziydi. O'n yillik dastur yuqorida ko'rsatilgan yechimlardan birini yuqori amalga oshirish va operatsion xarajatlari tufayli tark etgan bo'lsa-da, yangi dastur yoki ehtimol refaktoring endi me'moriy jihatdan kengaytiriladigan (ishlash nuqtai nazaridan) va yangi mijoz so'rovlariga (masalan, shaxsiy ma'lumotlarni mahalliylashtirish uchun) tayyor bo'lgan xizmatni yaratishi mumkin.

Va eng muhimi: agar sizda oddiy dastur bo'lsa, iltimos, ushbu yondashuvlardan foydalanmang. Ha, ular chiroyli va qiziqarli, lekin 100 kishilik trafik eng yuqori bo'lgan sayt uchun klassik monolit ko'pincha etarli bo'lishi mumkin (hech bo'lmaganda tashqi tomondan; ichki tomondan hamma narsani modullarga bo'lish mumkin va hokazo).

Manba: www.habr.com