Microservice — ma’lum business capability uchun javob beradigan, mustaqil ishlab chiqilishi va deploy qilinishi mumkin bo‘lgan kichik service arxitektura birligi.
Microservice architecture tizimni ko‘p mustaqil process yoki service’larga ajratadi. Har service o‘z API, data va lifecycle’iga ega bo‘lishi mumkin.
“Kichik” tushunchasi kod qatorlari bilan emas, mas’uliyat va mustaqillik bilan o‘lchanadi.
Business capability
Service texnik qatlam bo‘yicha emas, domain vazifasi bo‘yicha ajratiladi.
Misollar:
Faqat “database service”, “controller service” kabi qatlam bo‘yicha ajratish ko‘pincha foydali boundary bermaydi.
Mustaqil deployment
Microservice’ning asosiy xususiyati — boshqa service’larni majburan birga release qilmasdan yangilanish imkoniyati.
Buning uchun:
- versionlangan API;
- backward compatibility;
- alohida pipeline;
- mustaqil artifact;
- database migration;
- observability
zarur.
Agar barcha service doim birga deploy qilinsa, tizim distributed monolithga aylanishi mumkin.
Service aloqasi
Microservice’lar network orqali ishlaydi.
Usullar:
Network chaqiruv lokal function callga qaraganda sekin va ishonchsizroq.
Partial failure
Bir service ishlaydi, boshqasi vaqtincha ishlamasligi mumkin.
Bu partial failure.
Client quyidagilarni boshqaradi:
- timeout;
- retry;
- circuit breaker;
- fallback;
- bulkhead;
- idempotency;
- queue.
Cheksiz retry butun tizimni yanada yuklashi mumkin.
Data ownership
Har service o‘z data’siga egalik qiladi.
Boshqa service database tablega to‘g‘ridan-to‘g‘ri kirmaydi.
U API yoki event orqali ma’lumot oladi.
Bu mustaqillikni oshiradi, ammo cross-service query va transactionni murakkablashtiradi.
Database per service
Har service:
modelidan foydalanishi mumkin.
Muhim tamoyil — data contract service orqali boshqariladi.
Bir xil database server ishlatilishi arxitekturani avtomatik monolith qilmaydi, ammo table sharing coupling yaratadi.
Distributed transaction
Bir business operation bir nechta service’ni o‘zgartirsa global ACID transaction odatda qiyin.
Yondashuvlar:
Masalan, order yaratilib payment muvaffaqiyatsiz bo‘lsa order cancel qilinishi mumkin.
Eventual consistency
Service’lar holati bir vaqtda emas, vaqt o‘tishi bilan moslashadi.
Masalan, payment event yuboriladi, order service keyin statusni yangilaydi.
UI oraliq holatni tushunishi kerak:
- pending;
- processing;
- failed;
- completed.
API contract
Service consumerlar bilan contractga ega.
Contract:
- request;
- response;
- error;
- timeout;
- auth;
- version;
- rate limit;
- idempotency.
Provider o‘zgarishi consumerlarni buzmasligi uchun contract test ishlatiladi.
Service discovery
Dynamic muhitda service instance manzili o‘zgaradi.
- DNS;
- registry;
- orchestrator;
- service mesh
orqali endpointni topadi.
Client-side yoki server-side load balancing ishlatilishi mumkin.
Configuration
Har service environmentga mos:
oladi.
Config markaziy tizimdan kelishi mumkin, ammo service startup uchun critical dependencyga aylanmasligi kerak.
Observability
Distributed tizimda bitta request ko‘p service’dan o‘tadi.
Kerak bo‘ladi:
- centralized log;
- metric;
- distributed trace;
- correlation ID;
- service map;
- SLO;
- alert.
Faqat alohida service logi umumiy muammoni ko‘rsatmasligi mumkin.
Deployment
Microservice alohida deploy qilinadi.
Strategiyalar:
- rolling;
- canary;
- blue-green;
- feature flag.
Bir muddat eski va yangi service versionlari birga ishlashi mumkin.
API va event schema shu holatga mos bo‘lishi kerak.
Scale
Faqat ko‘p yuk oladigan service instance’lari oshiriladi.
Masalan, image processing service ko‘p CPU talab qiladi, user profile esa kam.
Mustaqil scale resource’dan samarali foydalanadi.
Biroq shared database yoki downstream limit bottleneck bo‘lishi mumkin.
Security
Har service attack surface va identityga ega.
Talablar:
- service-to-service authentication;
- authorization;
- TLS;
- secret management;
- network policy;
- minimal permission;
- audit;
- dependency patch.
“Internal network” avtomatik ishonch zonasi emas.
Team ownership
Microservice ko‘pincha mustaqil jamoaga tegishli.
Jamoa:
- code;
- deployment;
- on-call;
- monitoring;
- data;
- API
uchun javob beradi.
Service soni jamoa va operatsion qobiliyatdan tez o‘ssa murakkablik oshadi.
Microservice hajmi
Bir service bitta function bo‘lishi shart emas.
Juda mayda service:
- ko‘p network call;
- ko‘p deployment;
- ko‘p contract;
- tracing shovqini;
- transaction murakkabligi
keltiradi.
Boundary domain va ownership asosida tanlanadi.
API gateway
Tashqi clientlar ko‘p service manzilini bilmasligi uchun API gateway ishlatilishi mumkin. Gateway routing, authentication, rate limiting va protocol conversionni bajaradi. Business logicni gateway ichiga to‘plash yangi markaziy monolith yaratishi mumkin.
Outbox
Service database transactioni bilan event publish orasidagi uzilishni kamaytirish uchun outbox pattern ishlatiladi. Business o‘zgarish va outbox yozuvi bitta local transactionda saqlanadi. Alohida publisher outbox eventlarini brokerga yuboradi.
Contract test
Consumer service provider API’dan qanday foydalanishini contract test bilan qayd etadi. Provider yangi release’da shu contractlarni tekshiradi. Bu barcha service’ni bir muhitda to‘liq ishga tushirmasdan compatibility xatosini erta aniqlaydi.
Service catalog
Service owner, repository, on-call, SLO, dependency va API hujjati catalogda saqlanishi mumkin. Service soni ko‘payganda bunday metadata operatsion boshqaruv uchun zarur bo‘ladi.
Deployment chastotasi
Mustaqil release afzalligi faqat service pipeline’i boshqa service’larning tasdig‘ini kutmasdan xavfsiz deploy qila olsa yuzaga chiqadi.
Bog‘liq tushunchalar
Microservice architecture, Service boundary, API contract, Eventual consistency, Saga, Service discovery, Distributed tracing, Circuit breaker, Monolith, Service mesh