Monolithic architecture — ilovaning ko‘p funksional qismlari bitta deploy qilinadigan dasturiy birlik ichida quriladigan arxitektura. Foydalanuvchi interfeysi server qismi, biznes modullar va ma’lumotlarga kirish kodi bir process yoki bitta paket sifatida yetkazilishi mumkin. “Monolit” kod tartibsiz degani emas: ichkarida aniq modullar va qatlamlar bo‘lishi mumkin.
Deployment birligi
Monolitning asosiy belgisi — o‘zgarishlar odatda bitta build artifact va release orqali deploy qilinadi. Bitta moduldagi kichik tuzatish ham butun ilovani qayta yig‘ish va ishga tushirishni talab qilishi mumkin. Buning evaziga versiyalar orasidagi muvofiqlik sodda: barcha modul bir release tarkibida sinovdan o‘tadi.
Ilova bir nechta replica sifatida gorizontal masshtablanishi mumkin. Monolit “faqat bitta server” degani emas. Load balancer ortida o‘nlab bir xil instance ishlashi mumkin, ammo har instance barcha funksional kodni olib yuradi.
Ichki chaqiruvlar
Modullar bir processda funksiya yoki metod chaqiruvi orqali aloqa qiladi. Tarmoq serializationi, retry va distributed tracing talab qilinmaydi. Bitta database transaction bir nechta modul o‘zgarishini atomik qamrab olishi mumkin. Bu kuchli consistency talab qiladigan workflowlarni soddalashtiradi.
Shu bilan birga umumiy xotira va database schema yashirin coupling yaratishi mumkin. Bir modul boshqa modulning ichki jadvaliga bevosita yozsa, chegaralar zaiflashadi. Modular monolith har modulga public interface va ma’lumot egaligini belgilab, ichki bog‘liqlikni nazorat qiladi.
Masshtablash xususiyati
Butun ilova birga masshtablanadi. Faqat rasm qayta ishlash qismi CPU talab qilsa ham, yangi replica boshqa barcha modullarni ham yuklaydi. Kichik va o‘rta tizimda bu ortiqcha xarajat boshqaruv soddaligidan kam bo‘lishi mumkin. Alohida workload keskin farqlansa, background worker yoki keyinchalik xizmat ajratilishi mumkin.
Startup va build vaqti kod bazasi kattalashganda ortadi. Bir processdagi memory leak yoki crash butun instancega ta’sir qiladi, lekin boshqa replicalar xizmatni davom ettirishi mumkin. Resource limit va health check ishlatiladi.
Ishlab chiqish va jamoa
Bitta repository va lokal process yangi developerga butun oqimni ishga tushirishni osonlashtirishi mumkin. Refactor IDE va compiler yordamida modul chegaralari bo‘ylab atomik bajariladi. Test environmentda ko‘p servis orchestrationi talab qilinmaydi.
Katta jamoada bitta codebase va release pipeline koordinatsiya navbatini yaratishi mumkin. Modul ownership, dependency rule va mustaqil test suite bu muammoni kamaytiradi. Microservicega bo‘lish tashkiliy muammoni avtomatik hal qilmaydi; u tarmoq va operatsion murakkablik qo‘shadi.
Ma’lumot va nosozlik
Monolit ko‘pincha bitta relational database ishlatadi, ammo bu majburiy emas. Bitta schema foreign key va joinni osonlashtiradi. Modul chegarasida schema ownership bo‘lmasa, o‘zgarishlar bir-biriga qattiq bog‘lanadi.
Deployment rollback bitta artifactni orqaga qaytaradi, lekin database migration backward-compatible bo‘lishi kerak. Rolling deploymentda eski va yangi instance bir vaqtda ishlashi mumkin. Monolit bo‘lsa ham distributed deployment muammolari mavjud.
Modul chegaralari
Modular monolitda modul boshqa modulning ichki classi yoki jadvaliga emas, e’lon qilingan API yoki eventga murojaat qiladi. Build-time dependency testi taqiqlangan importni aniqlashi mumkin. Bir process ichidagi event bus distributed broker kafolatlariga ega emas, lekin modullarni bevosita chaqiruvdan ajratadi. Transaction ichida synchronous event va commitdan keyingi event semantikasi alohida belgilanadi.
Evolyutsiya
Keyinchalik xizmat ajratish zarur bo‘lsa, aniq modul boundary ma’lumot va API ko‘chirishni yengillashtiradi. Taqsimlangan tizimga o‘tilganda oldingi in-process atomiklik yo‘qoladi; retry, idempotency va observability yangi talab sifatida paydo bo‘ladi.
Bog‘liq tushunchalar
Modular monolith, Microservices, Deployment unit, Coupling, Layered architecture, Database transaction