Kengaytiriladigan arxitektura — bu yuklama o‘sishi resurs qo‘shish bilan yopiladigan, kodni qayta yozish bilan emas, platforma tuzilishi. Ko‘pchilik loyiha uchun bu — qismlar orasida aniq chegarasi bo‘lgan modulli monolit, hajm o‘sishiga mo‘ljallangan ma’lumotlar bazasi, ilovadan chiqarilgan holat va monitoring. Mikroservislar hammaga kerak emas: ular yuklamaning o‘zini emas, mustaqil jamoalar va relizlar masalasini hal qiladi.
Qisqacha
Masshtablanuvchanlik — bu tizimning qayta qurmasdan yuklama o‘sishiga bardosh berish qobiliyati: foydalanuvchilar ko‘paydi, platforma xuddi shunday tez javob beradi, faqat ko‘proq resurs ishlatadi. Ikki yo‘l bor, va ular bir-birini almashtirmaydi.
Holat haqidagi bu izoh shunchaki rasmiyat emas. Foydalanuvchi sessiyalari, yuklangan fayllar va hisoblagichlar bitta server xotirasida turar ekan, ikkinchi server yordam bermaydi: so‘rovlarning bir qismi «noto‘g‘ri joyga» tushadi. Bundan tashqari, istalgan tizimda bir nechta mashinaga bo‘lib bo‘lmaydigan ish qoladi — masalan, ma’lumotlar bazasining bitta jadvaliga yozish. Aynan shu ulush gorizontal o‘sishning haqiqiy chegarasini belgilaydi.
Holatsiz ilova so‘rovlar orasida server bilan birga yo‘qotib bo‘lmaydigan hech narsani saqlamaydi. Twelve-Factor App metodikasi buni ochiq aytadi: ilova jarayonlari holatni saqlamaydi va o‘zaro hech narsa bo‘lishmaydi, saqlanishi kerak bo‘lgan ma’lumot esa tashqi servisda — odatda ma’lumotlar bazasida — yotadi. Foydalanuvchini muayyan serverga bog‘lashni, sticky sessions’ni, metodika tamoyil buzilishi deb ataydi.
Amalda bu shuni bildiradi: sessiyalar — Redis kabi umumiy omborda, yuklangan fayllar — ilova serveri diskida emas, obyekt omborida, uzoq amallar — vazifalar navbatida. Shunda istalgan server istalgan so‘rovni qayta ishlaydi, ishdan chiqqani esa ma’lumot yo‘qotmasdan yangisi bilan almashtiriladi.
Muhim Buni har qanday yuklamadan oldin tekshirish mumkin: balanslovchi ortida ilovaning ikkita nusxasini ishga tushiring va ikkalasi bilan ham ishlang. Agar nusxalar orasida almashganda foydalanuvchi tashqariga chiqarilsa, yuklangan fayl esa faqat bittasida ko‘rinsa, holat hali ham ilova ichida yashaydi.
Monolit — bu bitta ilovadan iborat platforma: katalog, buyurtmalar, to‘lovlar va bildirishnomalar umumiy kod va umumiy bazada yashaydi. Boshlash uchun bu variant normal va ko‘pincha o‘zini oqlaydi. Uchta yondashuv orasidagi farq moda emas, balki qismlar mustaqilligi uchun qancha narx to‘lashingizda.
| Yondashuv | Qachon mos keladi | Nima beradi | Nimadan xavf bor |
|---|---|---|---|
| Monolit | Mahsulotning birinchi versiyasi, bitta jamoa, yuklama noma’lum | Tez boshlanish, sodda sozlash, bitta baza va bitta deploy | Vaqt o‘tib qismlar bir-biriga yopishib qoladi, har qanday o‘zgarish qo‘shnilarga ham ta’sir qiladi |
| Modulli monolit | Mahsulot o‘sadi, jamoa bir necha guruhgacha, yuklama bashorat qilinadi | Modullar orasidagi chegara oldindan belgilangan, istalgan modulni keyinroq chiqarish mumkin | Chegarani intizom bilan saqlash kerak, aks holda u oddiy monolitga aylanadi |
| Mikroservislar | Turli reliz siklidagi bir nechta jamoa, yuklamasi keskin farq qiladigan qismlar | Mustaqil yangilanishlar, ortiqcha yuklangan qismlarni nuqtali kengaytirish | Servislar orasidagi tarmoq, taqsimlangan uzilishlar, o‘z infratuzilmasi va monitoringi |
«Bitta servis buzilishi butun tizimni qulatmaydi» degan gap faqat nosozliklar izolyatsiya qilinganda to‘g‘ri: barcha tashqi chaqiruvlar uchun taymaut, qayta urinishlar sonini cheklash, qo‘shni mavjud bo‘lmagan holat uchun zaxira ssenariy. Bularsiz mikroservislar kaskadli nosozlik beradi — sekin servis qolganlarning ulanishlarini ushlab turadi va butun zanjirni to‘xtatadi.
Ko‘pchilik loyiha uchun oqilona yo‘l — toza chegarali modulli monolit: modullar API, ma’lumot almashish uchun dasturiy interfeys, orqali muloqot qiladi va zarur bo‘lsa ularning istalgani platformani qayta yozmasdan alohida servisga chiqariladi. Server qismi qanday tuzilgani va bunday interfeyslar qanday loyihalanishi mobil ilova uchun backend va API haqidagi maqolada yoritilgan.
Tartib bilan ulanadi: indekslar va so‘rovlarni optimallashtirish, kesh, statikani CDN orqali uzatish, navbatlar va o‘qish uchun baza replikalari. Eng arzon usuldan boshlash kerak — har keyingisi avvalgisidan xizmat qilishda murakkabroq, va hammasini darhol yoqish hali foydalanmagan narsangiz uchun to‘lash demakdir.
Bulutdagi avtomasshtablash joriy yuklamaga qarab serverlarni qo‘shadi va olib tashlaydi. U keskin cho‘qqilarda yordam beradi, lekin bu qadamlarni almashtirmaydi: agar tor joy ma’lumotlar bazasi bo‘lsa, ortiqcha ilova serverlari faqat unga navbatni ko‘paytiradi.
Tizim tomonidan to‘rtta ko‘rsatkichga qaraladi. Google’ning SRE kitobi ularni oltin signallar deb ataydi: kechikish (so‘rovni qayta ishlash qancha vaqt oladi), trafik (qancha so‘rov kelmoqda), xatolar (muvaffaqiyatsizlar ulushi) va to‘yinganlik (eng tanqis resurslar qanchalik band). Trafik o‘zgarmasa-da kechikishning o‘sishi — zaxira tugayotganining birinchi belgisi.
Foydalanuvchi tomonidan tezlik Core Web Vitals bo‘yicha o‘lchanadi. Google ko‘rsatkich yaxshi hisoblanadigan chegaralarni belgilaydi va natijani yuklanishlarning 75-protsentili bo‘yicha, telefon va kompyuterlar uchun alohida, hisoblaydi.
Yuklama testi cho‘qqidan oldin o‘tkaziladi, keyin emas. Ssenariylar haqiqiy ishdan olinadi — ro‘yxatdan o‘tish, qidiruv, buyurtma rasmiylashtirish — yuklama asta oshiriladi va qancha bir vaqtdagi foydalanuvchida kechikish o‘sib, xatolar paydo bo‘lishi qayd etiladi. Olingan raqam aksiya kunidagi kutilmagan hodisa emas, ma’lum chegaraga aylanadi.
Qonunga rioya qilish uchun o‘z serveringiz shart emas: mamlakat hududidagi data-markazdagi bulut yetarli. 2026-yil 27-martdan O‘zbekistonda faqat biometrik va genetik ma’lumotlarni hamda aloqa operatorlari foydalanuvchilarining ma’lumotlarini saqlash majburiy — buni shaxsiy ma’lumotlar to‘g‘risidagi qonunning 27-1-moddasi, 2026-yil 26-martdagi O‘RQ-1125-son qonun tahririda, belgilaydi.
Muhim Qolgan shaxsiy ma’lumotlarni o‘sha moddaning shartlaridan biri bajarilganda xorijda saqlash mumkin. Shartlar, davlatlar ro‘yxati va xorijiy data-markazgacha kechikish tahlili — O‘zbekistondagi bulut va server haqidagi maqolada.
O‘z server doimiy yuqori yuklamada, xuddi shu quvvatni bir necha yil ijaraga olish sotib olishdan qimmatga tushganda yoki jihozni jismonan izolyatsiya qilish talab etilganda o‘zini oqlaydi. O‘zgaruvchan yuklamali platforma uchun bulut qulayroq: konfiguratsiya xarid va yetkazib berishni kutmasdan o‘zgartiriladi.
Narx platformaga haqiqatda qancha resurs kerakligiga va ular atrofidagi xizmatlar to‘plamiga — zaxira nusxalar, monitoring, DDoS’dan himoya va administratsiya — bog‘liq. Serverlar va bulut sahifasida ishlar tarkibi uchta vazifa bo‘yicha yozilgan.
Hisob ro‘yxatdan o‘tgan foydalanuvchilar sonidan emas, ular nima qilishidan o‘sadi: baza va zaxira nusxalar hajmidan, chiquvchi trafikdan, og‘ir hisobotlar va fayllarni fonda qayta ishlashdan. Boshida qo‘yilgan yechimlar byudjetni platforma allaqachon ishlab, uni to‘xtatib bo‘lmaydigan yuklama ostida arxitekturani qayta qurishdan kamroq oshiradi.
O‘sishga tayyorlik server hajmi bilan emas, kodni qayta yozmasdan nima qilish mumkinligi bilan tekshiriladi. Yuklama o‘sishidan oldin ro‘yxatdan o‘ting.
Ro‘yxatdan tashqarida ekspluatatsiya qoladi: nosozlikda kim navbatchi, qancha vaqtda javob beradi va tizimni kim yangilaydi. Bularsiz muvaffaqiyatli arxitektura ham qutqarmaydi — bunday ish qanday tashkil etilishi IT-infratuzilmani texnik qo‘llab-quvvatlash haqidagi maqolada yoritilgan.
Syntra Systems ishga tushirishdan oldin yuklamani hisoblaydi: qancha bir vaqtdagi foydalanuvchi kutiladi, yiliga qancha ma’lumot to‘planadi, cho‘qqilar qaysi soatlarda keladi va qaysi amallar eng og‘ir. Shu raqamlar bo‘yicha konfiguratsiyani tanlaymiz va nimani fon protsesslariga chiqarishni hal qilamiz, ishga tushirilgandan keyin esa uni haqiqiy ko‘rsatkichlar bo‘yicha qayta ko‘rib chiqamiz.
Misol UzFranchise Expo ko‘rgazmasida yuklama kirishga to‘g‘ri keldi: ikki kunda 3 539 ta QR-chipta skanerlandi, bitta mehmonni tekshirish 0,2 soniya oldi. Bunday yuklama bir tekis kelmaydi, shuning uchun zaxira kunlik o‘rtacha emas, cho‘qqi daqiqalar bo‘yicha hisoblanadi. Batafsil — ko‘rgazma keysida.
Platformani toza chegarali modullardan yig‘amiz, holatni ilovadan, hisobot va fayllarni qayta ishlashni esa alohida protsesslarga chiqaramiz. Syntra Cloudda, O‘zbekiston hududidagi data-markazda, kundalik zaxira nusxalash va mavjudlik monitoringi bilan joylashtiramiz.
Vazifangizni muhokama qilamiz
Nima qilish kerakligini yozing — muddat va narxni baholab, yechim taklif qilamiz.
Yo‘q. Kichik mahsulotga ko‘pincha ozoda modulli monolit mos keladi: u sozlashda soddaroq va ishlatishda arzonroq. Mikroservislar platforma ustida turli reliz siklidagi bir nechta jamoa ishlaganda yoki tizim qismlari yuklamasi keskin farq qilganda o‘zini oqlaydi.
Chegaralari bilan. Oddiy monolitda kodning istalgan qismi istalgan ma’lumotga to‘g‘ridan-to‘g‘ri murojaat qilishi mumkin, shuning uchun vaqt o‘tib o‘zgarishlar qo‘shnilarga ham ta’sir qiladi. Modulli monolitda modullar bir-biriga faqat berilgan interfeyslar orqali murojaat qiladi va boshqa jadvallarni o‘qimaydi — shunda modulni platformani qayta yozmasdan alohida servisga chiqarish mumkin.
Modulning o‘z reliz jadvaliga ega o‘z jamoasi paydo bo‘lganda, yoki uning yuklamasi platformaning qolgan qismidan keskin farq qilib, uni alohida kengaytirish kerak bo‘lganda. Shu ikki sababsiz, faqat arxitektura tozaligi uchun chiqarish odatda joyida qoldirishdan qimmatroqqa tushadi.
Avval o‘lchash kerak, qayta yozish emas. Sekin so‘rovlar jurnali va kechikish metrikalari vaqt aynan qayerda yo‘qolayotganini ko‘rsatadi: ma’lumotlar bazasidami, tashqi servisdami yoki fayllarni uzatishdami. Ko‘pincha birinchi yaxshilanishni indekslar, kesh va og‘ir amallarni fonga chiqarish beradi.
Konteynerlar deyarli hammaga foydali: ular istalgan serverda ishga tushirishni bir xil qiladi. Kubernetes bunga ko‘plab servislarni orkestratsiya qilishni va o‘z murakkabligini qo‘shadi, shuning uchun uni servislar ko‘p bo‘lganda va ularga xizmat qiladigan odam bo‘lganda oladi.
Ishga tushirishdan oldin, mavsumiy cho‘qqi yoki reklama kampaniyasidan oldin va ma’lumotlar bazasi yoki integratsiyalardagi katta o‘zgarishlardan keyin. Bu nuqtalar orasida monitoring yetarli: agar trafik o‘zgarmasa-da kechikish o‘sayotgan bo‘lsa, testni rejadan oldinroq takrorlash kerak.
Boshida farq katta emas: bu qo‘shimcha texnologiyalar emas, kod va ma’lumotlardagi tartib masalasi. Qimmatga tushadigani teskarisi — platforma allaqachon ishlayotganda, uni to‘xtatib bo‘lmaydigan va ma’lumotni yo‘qotmasdan ko‘chirish kerak bo‘lgan paytda arxitekturani qayta qurish.
