Distributed monolith — bir nechta alohida process yoki xizmat sifatida deploy qilingan, ammo o‘zgarish, release, ma’lumot va ishlash nuqtayi nazaridan bir-biriga shu qadar qattiq bog‘langanki, amalda bitta monolit kabi boshqariladigan tizim. U microservice networking murakkabligini oladi, lekin mustaqil deploy va failure isolation afzalliklarini to‘liq bermaydi.
Belgilari
Tizim quyidagi xususiyatlarning bir nechtasiga ega bo‘lishi mumkin:
- bitta feature uchun ko‘p xizmatni bir vaqtda o‘zgartirish talab qilinadi;
- barcha xizmat faqat bir xil versiyalar to‘plamida ishlaydi;
- umumiy database schema’ga bevosita yozadi;
- uzun synchronous chaqiruv zanjirisiz request tugamaydi;
- bitta xizmat nosozligi butun foydalanuvchi oqimini to‘xtatadi;
- local development uchun butun platformani ishga tushirish kerak;
- release pipeline barcha xizmatni birgalikda deploy qiladi.
Xizmatlar sonining ko‘pligi microservice arxitekturasini avtomatik anglatmaydi. Muhim mezon ularning mustaqil evolyutsiya va ish chegarasidir.
Paydo bo‘lish sabablari
Monolit texnik qatlamlar bo‘yicha bo‘linib, “user service”, “data service” va “business service” yaratilsa, bitta use-case tarmoq bo‘ylab ko‘p marta qatnaydi. Business capability o‘rniga classlar remote servicega aylantiriladi. Natijada latency, serialization va partial failure qo‘shiladi, ammo ownership ajralmaydi.
Shared library barcha domen model va clientni bir versiyada saqlasa, kichik o‘zgarish barcha service’ni yangilashga majbur qiladi. Shared database esa migration va rollbackni global qiladi. Tashkiliy jihatdan jamoalar servicega egalik qilmasa, markaziy release koordinatsiyasi saqlanib qoladi.
Runtime coupling
Synchronous chain A -> B -> C -> D bo‘lsa, yakuniy availability har xizmat availabilitysining ko‘paytmasiga bog‘liq. Timeoutlar yig‘iladi, retry esa downstreamga request storm keltirishi mumkin. Circuit breaker simptom tarqalishini cheklaydi, lekin user operatsiyasi barcha xizmat javobisiz ma’nosiz bo‘lsa asosiy coupling qoladi.
Asinxron event har doim yechim emas. Consumer producerning ichki event formatiga qattiq bog‘lansa yoki global transaction kutsa, temporal coupling boshqa ko‘rinishda davom etadi. Event contract va ma’lumot ownershipi aniq bo‘lishi kerak.
Ma’lumot chegarasi
Har service o‘z ma’lumotiga egalik qilishi mustaqillikni kuchaytiradi. Boshqa xizmat jadvalini bevosita query qilish o‘rniga API, event projection yoki aniq shared kernel ishlatiladi. Bu eventual consistency va dublikat ma’lumot keltirishi mumkin, lekin failure va schema boundaryni ochiq qiladi.
Bir transaction bir nechta service database’iga cho‘zilsa distributed transaction yoki saga kerak. Agar barcha invariant doimo bir transactionda bo‘lishi shart bo‘lsa, bu funksiyalarni bitta boundaryda saqlash to‘g‘riroq bo‘lishi mumkin.
Evolyutsiya yo‘li
Avval change coupling va incident graph o‘lchanadi. Birgalikda o‘zgaradigan xizmatlar qayta birlashtirilishi yoki business capability bo‘yicha chegarasi tuzatilishi mumkin. API backward-compatible qilinib, consumer versiyalari mustaqil migratsiya qilinadi. Database ownership va deploy pipeline bosqichma-bosqich ajratiladi.
Maqsad xizmatlar sonini ko‘paytirish emas. Modular monolith ayrim tizim uchun tarmoqsiz aniq boundary beradi. Haqiqiy mustaqil scaling, ownership yoki failure isolation kerak bo‘lgan modul keyin servicega chiqariladi.
Deploy testi
Mustaqillikni amaliy tekshirish uchun bitta service’ning backward-compatible versiyasi qolganlarini qayta deploy qilmasdan chiqariladi. Agar shared library, migration yoki config barcha pipeline’ni majburan ishga tushirsa, deployment coupling bor. Chaos test bitta service’ni o‘chirib, tizimning qaysi biznes imkoniyatlari degradatsiya bo‘lishini ko‘rsatadi; butun platforma to‘xtasa failure isolation zaif.
Bog‘liq tushunchalar
Microservice architecture, Monolithic architecture, Coupling, Service boundary, Shared database, Saga