Microservice architecture — tizimni biznes capability atrofida qurilgan, mustaqil deploy qilinadigan va tarmoq orqali aloqa qiladigan kichik xizmatlar to‘plami sifatida tashkil etish usuli. “Kichik” qat’iy satr sonini anglatmaydi; xizmat bitta jamoa boshqara oladigan aniq boundary, ma’lumot egaligi va release hayot sikliga ega bo‘lishi muhim.
Mustaqil xizmat
Xizmat o‘z API yoki event contractini e’lon qiladi va ichki implementatsiyasini yashiradi. Boshqa xizmat uning database jadvaliga bevosita yozmaydi. Mustaqil deployment yangi versiyani barcha xizmatni bir vaqtda release qilmasdan chiqarishga imkon beradi; buning uchun contract backward-compatible bo‘lishi kerak.
Har xizmat alohida process/containerda ishlashi mumkin. U o‘z workloadiga ko‘ra masshtablanadi. Biroq alohida deployment unitning o‘zi microservice emas: shared schema va lockstep release qolsa distributed monolith hosil bo‘ladi.
Service boundary
Boundary business capability va invariantlarga mos tanlanadi. Order va uning satrlari bir atomik invariantga ega bo‘lsa, ularni tasodifiy texnik qatlamlarga bo‘lish distributed transaction yaratadi. Domain-driven design bounded contextlari boundary topishda yordam berishi mumkin.
Juda mayda service network call, deployment, dashboard va on-call sonini oshiradi. Juda katta service esa mustaqil scaling va ownershipni cheklaydi. Boundary vaqt davomida change coupling va jamoa tuzilmasi asosida evolyutsiya qiladi.
Aloqa usullari
Synchronous HTTP/gRPC darhol javob talab qiladigan query yoki command uchun ishlatiladi. Timeout, retry, circuit breaker va idempotency kerak. Uzun service chain availability va latencyni yomonlashtiradi. API gateway tashqi client uchun routing va umumiy policy beradi.
Asinxron event temporal couplingni kamaytiradi va consumerga mustaqil qayta ishlash imkonini beradi. Evaziga duplicate delivery, ordering va eventual consistency paydo bo‘ladi. Event schema versiyalanadi; producer ichki database entitysini bevosita event sifatida oshkor qilmaydi.
Ma’lumot va tranzaksiya
Database-per-service ownershipni ajratadi. Bu har xizmat albatta alohida fizik server oladi degani emas; schema va yozish huquqi chegarasi muhim. Boshqa xizmat kerakli ma’lumotni API yoki event projection orqali oladi.
Bir biznes operatsiyasi bir nechta xizmatga tegsa, saga lokal tranzaksiyalar va kompensatsiyalarni muvofiqlashtiradi. Bu ACID transaction bilan teng emas: oraliq holatlar ko‘rinishi va kompensatsiya muvaffaqiyatsiz bo‘lishi mumkin.
Operatsion talablar
Service discovery, load balancing, centralized logs, metrics, distributed tracing, secret management va automated deployment zarur infratuzilma bo‘ladi. Har hop TLS, authentication va authorizationni hisobga oladi. Service mesh transport policylarini yon qatlamga ko‘chirishi mumkin, lekin noto‘g‘ri service boundaryni tuzatmaydi.
Failure isolation bulkhead va quota bilan kuchaytiriladi. Bir shared broker yoki database barcha service uchun yagona failure domain bo‘lishi mumkin. Disaster recovery faqat containerlarni emas, har service ma’lumoti va contractlarini qamrab oladi.
Sinov
Unit va component test lokal xulqni, contract test consumer-provider mosligini, integration test real database/brokerni tekshiradi. End-to-end testlar soni cheklangan kritik oqimga qaratiladi. Production observability distributed xatoni topish uchun trace ID orqali chaqiruvlarni bog‘laydi.
Versiya va moslik
Independent deploy paytida producer va consumer turli versiyada ishlaydi. Additive field, tolerant reader va oldindan e’lon qilingan deprecation compatibilityni saqlaydi. “Barcha service bir vaqtda yangilansin” talab qilinsa release coupling qaytadi. Database migrationda expand-and-contract, eventda schema compatibility, HTTPda parallel endpoint versiyasi ishlatilishi mumkin.
Bog‘liq tushunchalar
Service boundary, Distributed system, Saga, Service discovery, Distributed tracing, Distributed monolith