16.2-bob: Capstone #2 — Mikroservis arxitekturasidagi loyiha

16-QISM — Katta Yakuniy Loyihalar · 2-mavzu

1. Kirish va motivatsiya

16.1-bobda monolit SaaS qurdik (hamma narsa bir Next.js ilovasida — frontend, backend, DB — bir joyda). Bu kichik-o'rta loyiha uchun ideal (sodda, tez). Lekin tizim juda katta bo'lganda (millionlab foydalanuvchi, ko'p jamoa, har xil yuk), monolit muammolar beradi: butun ilovani birga deploy qilish kerak (bir o'zgarish — hammasini qayta deploy), bir qism (masalan to'lov) yuqori yuk — butun ilova miqyoslanishi kerak, bir jamoa butun kodga tegadi (chalkashlik). Yechim — mikroservis arxitekturasi: tizimni mustaqil servislarga bo'lish (auth servisi, to'lov servisi, bildirishnoma servisi — har biri alohida, mustaqil deploy/miqyos).

Bu capstone — 9-QISM (arxitektura — SOLID, design patterns, mikroservis vs monolit) va 8-QISM (NestJS — mikroservis), 5-QISM (message queue) bilimini amaliyotga qo'yadi. Mikroservis — senior daraja arxitektura ko'nikmasi (system design — 15.7 — bilan bog'liq), va katta kompaniyalar (Netflix, Amazon, Uber — hammasi mikroservis) ishlatadi. Lekin muhim: mikroservis — har loyiha uchun emas (murakkab — over-engineering — 15.1: 2.8). Bu capstone uni o'rganish va qachon kerakligini ko'rsatadi (katta, murakkab tizim — mikroservis; kichik — monolit — 16.1).

Bu bob: mikroservis nima va nega (monolit vs mikroservis), loyiha g'oyasi (e-commerce platform — mikroservislarga bo'lingan), servislarga bo'lish (qaysi servis), servis muloqoti (REST/gRPC, message queue), ma'lumot (har servis o'z DB), bosqichma-bosqich qo'llanma, va mikroservis muammolari (murakkablik). Bu — mikroservis arxitekturasidagi loyiha bo'lib, uni to'liq ochib beramiz. Kodni esa o'zingiz yozasiz.

O'xshatish: Monolit vs mikroservis — bu katta universal do'kon vs savdo markazi. Monolit — bitta katta universal do'kon (hamma narsa bir bino — oziq-ovqat, kiyim, elektronika — bir tom ostida): kichik shaharda ideal (sodda, bir joyda), lekin o'ssa muammo (bir bo'lim ta'mirlash — butun do'kon yopiladi; elektronika bo'limi yuqori talab — butun do'konni kengaytirish kerak). Mikroservis — savdo markazi (ko'p mustaqil do'kon — har biri o'z binosida, o'z xodimlari, o'z ombori): har do'kon mustaqil (biri ta'mirlansa — boshqalari ishlaydi; elektronika do'koni kattalashsa — faqat u), lekin murakkabroq (ko'p do'kon — koordinatsiya, umumiy infratuzilma — yo'lak, xavfsizlik). Katta savdo markazi (katta tizim) — mikroservis (mustaqillik, miqyos); kichik do'kon (kichik tizim) — monolit (sodda — savdo markazi ortiqcha). Tanlov — hajmga bog'liq.

Nega muhim?

• Katta miqyos — mikroservis (mustaqil deploy/miqyos — Netflix, Amazon).
• Senior arxitektura — mikroservis dizayni (system design — 15.7 — bilan).
• 9-QISM amaliyoti — mikroservis vs monolit, servis muloqoti (real loyiha).
• Qachon kerak — katta/murakkab mikroservis; kichik monolit (16.1 — balans).

2. Mikroservis nima va loyiha g'oyasi

2.1. Monolit vs mikroservis

  MONOLIT vs MIKROSERVIS (arxitektura tanlovi):

  MONOLIT (16.1 — bir ilova):
  ┌─────────────────────────┐
  │ Frontend + Auth + To'lov │   hammasi bir kod, bir deploy, bir DB
  │ + Buyurtma + Bildirishnoma│
  └─────────────────────────┘
   Sodda (boshlash oson, bir joyda), tez (bir kod)
   Katta bo'lsa: bir o'zgarish  butun deploy; bir qism yuk  butun miqyos

  MIKROSERVIS (mustaqil servislar):
  ┌────────┐ ┌─────────┐ ┌────────┐ ┌──────────────┐
  │ Auth   │ │ To'lov  │ │Buyurtma│ │ Bildirishnoma│   har biri:
  │ servisi│ │ servisi │ │servisi │ │ servisi      │   mustaqil deploy/DB/jamoa
  └────────┘ └─────────┘ └────────┘ └──────────────┘
   Mustaqil (har servis alohida deploy/miqyos/jamoa)
   Texnologiya erkinligi (har servis o'z tili — Node, Go, ...)
   Murakkab (servis muloqoti, taqsimlangan tizim — CAP — 15.7)

   Monolit — bir ilova (sodda, kichik); mikroservis — mustaqil servislar (katta, miqyos)
   Mikroservis murakkab (muloqot, taqsimlangan) — katta tizim uchun (kichik  monolit)

Monolit vs mikroservis — ikki arxitektura yondashuvi (9-QISM). Monolit (16.1 — bir ilova): hamma narsa (frontend, auth, to'lov, buyurtma, bildirishnoma) bir kod, bir deploy, bir DB. Afzalligi — sodda (boshlash oson, bir joyda — hammasi), tez (bir kod — to'g'ridan chaqiruv). Kamchiligi — katta bo'lsa: bir o'zgarish butun deploy (kichik tuzatish — hammasini qayta chiqarish), bir qism yuk (masalan to'lov peak) butun ilova miqyoslanishi kerak (faqat to'lov emas — isrof). Mikroservis (mustaqil servislar): tizim mustaqil servislarga bo'lingan (Auth, To'lov, Buyurtma, Bildirishnoma — har biri alohida — mustaqil deploy/DB/jamoa). Afzalligi — mustaqil (har servis alohida deploy — biri o'zgarsa boshqalari tegmaydi; alohida miqyos — to'lov yuk — faqat to'lov servisi kengayadi; alohida jamoa — har servis o'z jamoasi), texnologiya erkinligi (har servis o'z tili — Auth Node, To'lov Go — mos). Kamchiligi — murakkab (servis muloqoti — qanday gaplashadi; taqsimlangan tizim — CAP — 15.7: 2.5 — izchillik qiyin; debugging — ko'p servis). Ikki nuqta: (1) monolit — bir ilova (sodda, kichik-o'rta loyiha); mikroservis — mustaqil servislar (katta, yuqori miqyos); (2) mikroservis murakkab (muloqot, taqsimlangan tizim) — katta tizim uchun (kichik monolit — over-engineering — 15.1: 2.8). Tanlov (9-QISM — monolit vs mikroservis) — hajmga va ehtiyojga bog'liq (kichik-o'rta — monolit — 16.1 — sodda; katta, ko'p jamoa, har xil yuk — mikroservis — mustaqillik, miqyos). Eng keng xato — kichik loyihaga mikroservis (murakkablik — over-engineering — koordinatsiya, debugging — 16.1 monolit yetadi). To'g'ri — monolitdan boshla (16.1 — sodda), o'ssa va kerak bo'lsa mikroservisga bo'l ("monolith first" — Martin Fowler). Bu capstone — mikroservisni o'rganish (qanday) va qachon (katta — kerak bo'lganda). Mikroservis — kuchli (katta miqyos), lekin murakkab (faqat kerak bo'lganda).

2.2. Loyiha g'oyasi (e-commerce platform)

  MIKROSERVIS E-COMMERCE PLATFORM (mustaqil servislar):

  SERVISLAR (har biri mustaqil):
  1. AUTH SERVISI: ro'yxat, login, JWT 14.6-bob, foydalanuvchi
  2. PRODUCT SERVISI: katalog, qidiruv (mahsulot ma'lumoti)
  3. CART SERVISI: savat (foydalanuvchi savati)
  4. ORDER SERVISI: buyurtma (yaratish, holat)
  5. PAYMENT SERVISI: to'lov (Stripe — alohida — xavfsizlik)
  6. NOTIFICATION SERVISI: email/push (asinxron)
  7. API GATEWAY: kirish nuqtasi (routing, auth, rate limit — 9-QISM)

  ASOSIY OQIM (buyurtma — servislar birga):
  Client  API Gateway  Order servisi 
    (Product servisi — narx tekshir) 
    (Payment servisi — to'lov) 
    (event: "buyurtma"  Notification servisi — email)

   E-commerce — Auth/Product/Cart/Order/Payment/Notification servislari + Gateway
   Har servis mustaqil (o'z DB, deploy); muloqot orqali birga (2.3)

Loyiha g'oyasi (e-commerce platform) — mikroservis capstone g'oyasi. E-commerce platform (mikroservislarga bo'lingan — onlayn do'kon, lekin katta miqyos — mikroservis). Servislar (har biri mustaqil — alohida deploy/DB/jamoa): (1) Auth servisi (ro'yxat, login, JWT — 14.6, foydalanuvchi boshqaruvi); (2) Product servisi (katalog, qidiruv — mahsulot ma'lumoti); (3) Cart servisi (savat — foydalanuvchi savati); (4) Order servisi (buyurtma — yaratish, holat); (5) Payment servisi (to'lov — Stripe — alohida — xavfsizlik izolyatsiyasi — to'lov maxfiy — 14-QISM); (6) Notification servisi (email/push — asinxron — 5.13, 5.19); (7) API Gateway (kirish nuqtasi — routing — qaysi servisga, auth, rate limit — 9-QISM — 13.6: middleware). Asosiy oqim (buyurtma — servislar birga ishlaydi): Client API Gateway Order servisi (Product servisi — narx tekshir) (Payment servisi — to'lov) (event: "buyurtma yaratildi" Notification servisi — email). Ikki nuqta: (1) e-commerce — Auth/Product/Cart/Order/Payment/Notification servislari + API Gateway (har biri bir biznes domeni — mustaqil); (2) har servis mustaqil (o'z DB, deploy), muloqot orqali birga (2.3 — REST/queue). Bu — mikroservis e-commerce'ning dizayni (har servis — bir biznes domeni — DDD — 9-QISM — domain-driven — Auth, Product, Order — har biri mustaqil mas'uliyat). API Gateway (9-QISM) — kirish nuqtasi (client bir joyga so'rov yuboradi — Gateway tegishli servisga yo'naltiradi — auth, rate limit markaziy). Payment alohida (xavfsizlik — to'lov maxfiy — alohida servis — izolyatsiya — buzilsa boshqa servislar xavfsiz). Asosiy oqim (buyurtma) — servislar muloqoti (Order Product Payment Notification — REST yoki queue — 2.3) — mikroservisning murakkabligi (servislar birga ishlaydi — koordinatsiya). Bu g'oya — e-commerce (16.1 SaaS monolit bilan taqqosla — bu katta miqyos — mikroservis). Sizning g'oyangiz boshqa bo'lishi mumkin (ride-sharing, food delivery — bir xil — servislarga bo'lish).

3. Servislarga bo'lish (decomposition)

  SERVISLARGA BO'LISH — qaysi servis (eng muhim qaror):

  BO'LISH TAMOYILLARI:
   BIZNES DOMENI bo'yicha (DDD — 9-QISM):
     Auth, Product, Order, Payment — har biri bir domen
     texnik bo'lish emas (frontend servisi, DB servisi — yomon)
   MUSTAQIL (har servis o'zicha ishlay olsin — kam bog'liqlik)
   BITTA mas'uliyat (Single Responsibility — 15.1 — servis darajasida)
   O'Z MA'LUMOTI (har servis o'z DB — boshqasiga to'g'ridan kirmaydi)

  SERVIS CHEGARASINI ANIQLASH:
   bir biznes imkoniyati (capability) = bir servis
   "buyurtma boshqaruvi"  Order servisi
   "to'lov"  Payment servisi (alohida — xavfsizlik)

  NOTO'G'RI BO'LISH (anti-pattern):
   juda mayda (har funksiya servis — koordinatsiya azobi — "nano-servis")
   juda bog'liq (servislar bir-birisiz ishlay olmaydi — "distributed monolith")

   Bo'lish — biznes domeni bo'yicha (DDD); mustaqil, bitta mas'uliyat, o'z DB
   Anti-pattern — juda mayda (nano) yoki juda bog'liq (distributed monolith)

Servislarga bo'lish (decomposition) — mikroservisning eng muhim, eng qiyin qarori. Bo'lish tamoyillari: (1) biznes domeni bo'yicha (DDD — Domain-Driven Design — 9-QISM): har servis bir biznes domeni (Auth — foydalanuvchi, Product — katalog, Order — buyurtma, Payment — to'lov); texnik bo'lish emas (frontend servisi, DB servisi — yomon — bular qatlam, domen emas); (2) mustaqil (har servis o'zicha ishlay olsin — kam bog'liqlik — biri boshqasiz ham qisman ishlaydi); (3) bitta mas'uliyat (Single Responsibility — 15.1: 2.3 — servis darajasida — Order servisi faqat buyurtma); (4) o'z ma'lumoti (har servis o'z DB — boshqa servis DB'siga to'g'ridan kirmaydi — faqat muloqot orqali — 2.3 — izolyatsiya). Servis chegarasini aniqlash: bir biznes imkoniyati (capability) = bir servis ("buyurtma boshqaruvi" Order servisi, "to'lov" Payment servisi — alohida — xavfsizlik). Noto'g'ri bo'lish (anti-pattern): (1) juda mayda (har funksiya servis — "nano-servis" — koordinatsiya azobi — 50 servis — har biri kichik — muloqot murakkab); (2) juda bog'liq (servislar bir-birisiz ishlay olmaydi — "distributed monolith" — mikroservisning murakkabligi + monolitning bog'liqligi — eng yomon). Ikki nuqta: (1) bo'lish — biznes domeni bo'yicha (DDD — 9-QISM); mustaqil, bitta mas'uliyat, o'z DB (har servis — bir domen, mustaqil); (2) anti-pattern — juda mayda (nano — koordinatsiya azobi) yoki juda bog'liq (distributed monolith — mikroservis foydasi yo'q). Servislarga bo'lish — mikroservisning eng qiyin qismi (chegarani qaerda — qancha servis — har biri nima). Biznes domeni (DDD — 9-QISM) — to'g'ri tamoyil (Order, Payment — biznes — mustaqil; frontend, DB — texnik — yomon). O'z DB (har servis — alohida ma'lumot — izolyatsiya — boshqa servis DB'siga tegmaydi — faqat muloqot) — mikroservisning kaliti (mustaqillik). Balans (juda mayda vs juda bog'liq) — to'g'ri granularlik (biznes domeni — Order, Payment — na juda mayda — har funksiya, na juda katta — hammasi bir). Bu — mikroservis dizaynining eng muhim qarori (noto'g'ri bo'lish — distributed monolith — eng yomon). To'g'ri — biznes domeni, mustaqil, o'z DB (9-QISM — DDD).

4. Servis muloqoti va ma'lumot

  SERVIS MULOQOTI — servislar qanday gaplashadi (2 usul):

  1. SINXRON (so'rov-javob — REST/gRPC):
   Order servisi  Product servisi (HTTP/gRPC)  narx javobi (kutadi)
   REST (oddiy, keng) yoki gRPC (tez, tipli — 9-QISM)
    oddiy;  bog'liqlik (Product yiqilsa — Order kutadi/yiqiladi)

  2. ASINXRON (event — message queue — 5.22, 9-QISM):
   Order servisi  event "buyurtma yaratildi"  queue (Kafka/RabbitMQ) 
    Notification servisi tinglaydi  email yuboradi
    mustaqil (Order Notification'ni kutmaydi);  murakkab (eventual)
   event-driven (servislar bog'liq emas — event orqali)

  MA'LUMOT (har servis o'z DB):
   Order servisi — Order DB; Product servisi — Product DB (alohida)
   ma'lumot kerak bo'lsa — muloqot (Product DB'ga to'g'ridan EMAS)
   izchillik — eventual (saga pattern — taqsimlangan tranzaksiya — 9-QISM)

   Muloqot — sinxron (REST/gRPC — kutadi) yoki asinxron (event/queue — mustaqil)
   Har servis o'z DB; ma'lumot — muloqot orqali (to'g'ridan kirmaydi); eventual izchillik

Servis muloqoti va ma'lumot — servislar qanday birga ishlaydi (mikroservisning murakkabligi). Servis muloqoti (2 usul): (1) sinxron (so'rov-javob — REST/gRPC): Order servisi Product servisi (HTTP yoki gRPC) narx javobini kutadi; REST (oddiy, keng — 5.7) yoki gRPC (tez, tipli — protobuf — 9-QISM); afzal — oddiy; kamchilik — bog'liqlik (Product servisi yiqilsa — Order kutadi yoki yiqiladi — kaskad); (2) asinxron (event — message queue — 5.22, 9-QISM): Order servisi event "buyurtma yaratildi" queue (Kafka/RabbitMQ) Notification servisi tinglaydi email yuboradi; afzal — mustaqil (Order Notification'ni kutmaydi — event tashladi, davom etadi — 13.5: 2.8 asinxron); kamchilik — murakkab (eventual — email biroz keyin); bu event-driven (servislar to'g'ridan bog'liq emas — event orqali — kam bog'liqlik). Ma'lumot (har servis o'z DB): Order servisi — Order DB, Product servisi — Product DB (alohida — izolyatsiya); ma'lumot kerak bo'lsa — muloqot (Order Product narxini so'raydi — Product DB'ga to'g'ridan EMAS — faqat Product servisi orqali — 3 — o'z DB); izchillik — eventual (taqsimlangan — darrov emas — saga pattern — taqsimlangan tranzaksiya — 9-QISM — masalan buyurtma + to'lov + zaxira — bir necha servis — koordinatsiya). Ikki nuqta: (1) muloqot — sinxron (REST/gRPC — kutadi — oddiy, lekin bog'liq) yoki asinxron (event/queue — mustaqil — murakkab, lekin kam bog'liq); (2) har servis o'z DB; ma'lumot — muloqot orqali (boshqa servis DB'siga to'g'ridan kirmaydi — izolyatsiya); eventual izchillik (taqsimlangan — saga). Muloqot — mikroservisning murakkabligi (servislar birga — qanday gaplashadi — sinxron tez/bog'liq, asinxron mustaqil/murakkab). Asinxron (event/queue) — afzalroq (kam bog’liqlik — Notification Order'ni bloklamaydi — mustaqil — 5.22), lekin murakkab (eventual). Har servis o'z DB (izolyatsiya — mustaqillik — kaliti) — lekin eventual izchillik (taqsimlangan — darrov izchillik qiyin — CAP — 15.7: 2.5 — saga pattern). Saga (taqsimlangan tranzaksiya — bir necha servis — masalan buyurtma: zaxira kamaytir + to'lov + email — biror qadam yiqilsa orqaga — kompensatsiya) — mikroservisning eng murakkab qismi. Bu — mikroservis muloqotining yuragi (servislar birga ishlash — sinxron/asinxron, o'z DB, eventual). Murakkab (monolit'dan — to'g'ridan chaqiruv emas — tarmoq orqali), lekin mustaqillik beradi.

5. Bosqichma-bosqich va texnologiya

  MIKROSERVIS QURISH (bosqichlar — 9, 8, 5, 10 QISM):

  BOSQICH 1 — MONOLITDAN BOSHLA (yoki reja):
   "monolith first" — avval monolit 16.1-bob, keyin bo'l (kerak bo'lsa)
   yoki: domenlarni aniqla (Auth, Product, Order, Payment)

  BOSQICH 2 — BIRINCHI SERVIS (Auth):
   NestJS (8-QISM) — Auth servisi (login, JWT — 14.6)
   o'z DB (PostgreSQL)

  BOSQICH 3 — SERVISLAR (har biri):
   Product, Cart, Order, Payment, Notification — har biri NestJS + DB

  BOSQICH 4 — MULOQOT:
   sinxron (REST/gRPC — 9-QISM) + asinxron (RabbitMQ/Kafka — 5.22)

  BOSQICH 5 — API GATEWAY:
   kirish nuqtasi (routing, auth, rate limit — 9-QISM)

  BOSQICH 6 — INFRA (10-QISM):
   Docker (har servis konteyner — 10.6) + Docker Compose / Kubernetes 10.10-bob
   har servis mustaqil deploy

  BOSQICH 7 — KUZATUV (taqsimlangan):
   markaziy log (har servis), tracing (so'rov servislar bo'ylab), monitoring

  TEXNOLOGIYA:
   NestJS (servislar — 8) + PostgreSQL/MongoDB (har servis DB — 6)
   RabbitMQ/Kafka (queue — 5.22) + gRPC/REST (muloqot)
   Docker + Kubernetes (10) + API Gateway

   Bosqichlar — monolitdan/domen  servislar  muloqot  gateway  infra  kuzatuv
   Texnologiya — NestJS + DB (har servis) + queue + Docker/K8s + Gateway

Bosqichma-bosqich va texnologiya — mikroservis qurish (9, 8, 5, 10 QISM amaliyoti). Bosqichlar: (1) monolitdan boshla (yoki reja) — "monolith first" (avval monolit — 16.1, keyin bo'l — kerak bo'lsa — 2.1; yoki domenlarni aniqla — Auth, Product, Order, Payment — DDD — 3); (2) birinchi servis (Auth) — NestJS (8-QISM — mikroservis uchun ideal — modullar, DI) — Auth servisi (login, JWT — 14.6), o'z DB; (3) servislar (har biri) — Product, Cart, Order, Payment, Notification — har biri NestJS + DB (mustaqil); (4) muloqot — sinxron (REST/gRPC — 9-QISM) + asinxron (RabbitMQ/Kafka — 5.22 — event-driven — 4); (5) API Gateway — kirish nuqtasi (routing, auth, rate limit — 9-QISM); (6) infra (10-QISM) — Docker (har servis konteyner — 10.6) + Docker Compose / Kubernetes (10.10 — orkestratsiya — ko'p servis boshqaruvi), har servis mustaqil deploy; (7) kuzatuv (taqsimlangan — qiyinroq) — markaziy log (har servis — bir joyda), tracing (so'rov servislar bo'ylab — qaysi servis sekin — distributed tracing — Jaeger), monitoring 13.10-bob. Texnologiya: NestJS (servislar — 8-QISM) + PostgreSQL/MongoDB (har servis DB — 6-QISM), RabbitMQ/Kafka (queue — 5.22) + gRPC/REST (muloqot), Docker + Kubernetes (10-QISM — orkestratsiya) + API Gateway. Ikki nuqta: (1) bosqichlar — monolitdan/domen servislar muloqot gateway infra kuzatuv (tizimli — domen servis muloqot infra); (2) texnologiya — NestJS + DB (har servis) + queue + Docker/K8s + Gateway (mikroservis stack). Bu — mikroservis qurish rejasi (9, 8, 5, 10 QISM — arxitektura, NestJS, queue, DevOps — birlashtirib). NestJS (8-QISM) — mikroservis uchun ideal (modullar, DI, mikroservis qo'llab-quvvatlash — 8.x). Docker + Kubernetes (10-QISM — 10.6, 10.10) — mikroservis infratuzilmasi (har servis konteyner — Docker; ko'p servis boshqaruvi — Kubernetes — orkestratsiya, miqyos, self-healing). Kuzatuv (taqsimlangan — qiyinroq — monolit'dan — bir so'rov ko'p servis bo'ylab — tracing kerak — qaysi servis muammo). Texnologiya erkinligi (mikroservis — 2.1 — har servis o'z tili — bu yerda NestJS bir xil, lekin har xil bo'lishi mumkin — Go to'lov uchun). Bu capstone — mikroservis amaliyoti (9-QISM arxitektura real loyiha — servislar, muloqot, infra). Murakkab (monolit'dan — ko'p servis, muloqot, infra, kuzatuv) — shuning uchun katta tizim uchun (2.1 — kichik — monolit). Bosqichma-bosqich — Auth servislar muloqot Gateway infra kuzatuv (har biri mos QISM).

5.1. API Gateway, service discovery va marshrutlash

  API GATEWAY — yagona kirish nuqtasi 9.8-bob:

  Client
    │  (bitta manzil — api.dokon.uz)
    ▼
  ┌──────────────────────────────┐
  │  API GATEWAY                 │
  │  · marshrutlash (routing)    │  /auth/*  Auth servisi
  │  · auth tekshiruvi (JWT)     │  /product/*  Product servisi
  │  · rate limit 14.8-bob         │  /order/*  Order servisi
  │  · so'rovni yig'ish (BFF)    │
  └──────────────────────────────┘
    │        │         │
    ▼        ▼         ▼
  Auth    Product    Order  ...

  SERVICE DISCOVERY — servis manzilini topish:
   servislar dinamik (konteyner ko'chib yuradi — IP o'zgaradi)
   registr (Consul/Eureka yoki K8s Service DNS — 10.8) manzilni topadi
   Gateway "Order servisi qaerda?"  registr javob beradi

   Gateway — bitta kirish nuqtasi (marshrutlash, auth, rate limit markaziy)
   Service discovery — dinamik manzil (registr/DNS orqali topiladi)

API Gateway 9.8-bob — mikroservis tizimining yagona kirish nuqtasi. Client ichki servislarni (Auth, Product, Order) to'g'ridan bilmaydi — u faqat Gateway'ga (masalan api.dokon.uz) so'rov yuboradi, Gateway esa uni tegishli servisga yo'naltiradi (/auth/* Auth servisi, /product/* Product servisi). Gateway markazlashtiradigan vazifalar: (1) marshrutlash (routing — qaysi yo'l qaysi servisga); (2) auth tekshiruvi (JWT'ni bir joyda tekshiradi — 14.6 — har servis alohida tekshirmaydi — markazlashuv); (3) rate limit (14.8 — so'rovlar sonini cheklash — DoS himoya); (4) so'rovni yig'ish (bir client ekrani uchun bir necha servisdan ma'lumot — Gateway yig'ib beradi — BFF, Backend For Frontend namunasi). Service discovery — servis manzilini topish muammosi: konteyner muhitida 10.8-bob servislar dinamik (konteyner qayta ishga tushsa IP o'zgaradi — statik manzil ishlamaydi). Yechim — registr: har servis o'zini registrga yozadi (Consul, Eureka), yoki Kubernetes'da Service DNS (servis nomi orqali topiladi — order-service DNS ismi — 10.8). Gateway "Order servisi hozir qaerda?" deb registrdan/DNS'dan manzilni oladi. Ikki nuqta: (1) Gateway — bitta kirish nuqtasi (marshrutlash, auth, rate limit markaziy — client ichki tuzilmani bilmaydi); (2) service discovery — dinamik manzil (registr yoki K8s DNS orqali topiladi — statik IP emas). Gateway yo'q bo'lsa — har client har servisning manzilini bilishi, har birida auth qilishi kerak (chalkash, xavfsiz emas). Gateway bilan — markazlashuv (auth, rate limit, marshrutlash — bir joyda — 13.6: middleware g'oyasi tizim darajasida). Bu bo'limda kod yechimi ataylab berilmagan — Gateway'ni NestJS bilan (8.16 — mikroservis moduli) yoki maxsus vosita (Kong, Traefik) bilan qurish sizning capstone qaroringiz.

5.2. Taqsimlangan tranzaksiya: Saga va eventual izchillik

  MUAMMO — bir amal, bir necha servis 9.7-bob:
  "Buyurtma yaratish" =
    Order (buyurtma yoz) + Payment (pul yech) + Inventory (zaxira kamaytir)
   uch xil servis, uch xil DB  bitta ACID tranzaksiya YO'Q 9.5-bob

  SAGA — qadamlar ketma-ketligi + kompensatsiya 9.7-bob:
  qadam 1: Order yaratildi (holat: PENDING)
  qadam 2: Payment muvaffaqiyatli
  qadam 3: Inventory kamaytirildi
   hammasi OK  Order holat: CONFIRMED

  AGAR qadam 3 YIQILSA (zaxira yetmadi):
   KOMPENSATSIYA (orqaga qaytarish amallari):
    · Payment'ni qaytar (refund)
    · Order holat: CANCELLED
   "orqaga qaytarish" — teskari amal (delete emas, kompensatsiya)

  EVENTUAL IZCHILLIK (CAP — 9.10):
   darrov emas — bir zumdan keyin barcha servis kelishadi
   oraliqda: Order CONFIRMED, lekin email hali kelmagan (normal)

   Bir amal ko'p servisda  ACID yo'q  Saga (qadamlar + kompensatsiya)
   Izchillik — eventual (darrov emas); CAP — izchillik vs qulaylik trade-off

Taqsimlangan tranzaksiya — mikroservisning eng murakkab qismi. Monolitda "buyurtma yaratish" bitta DB tranzaksiyasi (ACID — hammasi yoki hech nima — 9.5). Mikroservisda esa bu amal uch xil servis, uch xil DB ustidan boradi: Order (buyurtma yozadi), Payment (pul yechadi), Inventory (zaxira kamaytiradi) — ular ustidan yagona ACID tranzaksiya YO'Q (har servis o'z DB — database-per-service — 9.5 — boshqa servis DB'siga tegib bo'lmaydi). Yechim — Saga namunasi 9.7-bob: amalni qadamlar ketma-ketligiga bo'lish, va har qadam uchun kompensatsiya (orqaga qaytaruvchi amal) tayyorlash. Oqim: qadam 1 — Order yaratildi (holat PENDING); qadam 2 — Payment muvaffaqiyatli; qadam 3 — Inventory kamaytirildi; hammasi o'tsa Order holati CONFIRMED bo'ladi. Agar qadam 3 yiqilsa (zaxira yetmasa), tizim kompensatsiya ishga tushiradi: Payment'ni qaytaradi (refund — chunki ACID rollback yo'q — teskari amal qilish kerak), Order holatini CANCELLED qiladi. Muhim: kompensatsiya "o'chirish" emas — u teskari biznes amali (to'lovni qaytarish, holatni bekor qilish). Saga ikki uslubda quriladi: xoreografiya (har servis event tinglaydi va o'z qadamini bajaradi — markaziy boshqaruv yo'q — 9.7 event-driven) yoki orkestratsiya (bitta koordinator qadamlarni ketma-ket chaqiradi). Buning natijasi — eventual izchillik (CAP teoremasi — 9.10, 15.7: 2.5): taqsimlangan tizimda izchillik darrov emas — bir zumdan keyin barcha servis kelishadi; oraliqda holat vaqtincha nomuvofiq bo'lishi normal (Order CONFIRMED, lekin email hali kelmagan). Ikki nuqta: (1) bir amal ko'p servisda ACID yo'q Saga (qadamlar + kompensatsiya — biror qadam yiqilsa teskari amallar); (2) izchillik — eventual (darrov emas — CAP: izchillik va qulaylik orasida trade-off — 9.10). Bu — mikroservisga o'tishning eng katta narxi: monolitda bepul bo'lgan izchillikni (bitta tranzaksiya) endi qo'lda, Saga bilan boshqarasiz. Aynan shu murakkablik "monolith first" maslahatining sababidir (6-bo'lim). Bu bo'limda Saga'ning to'liq kodi ataylab berilmagan — uni loyihada aniq bir oqim (buyurtma) uchun o'zingiz loyihalaysiz (9.7 CQRS/event sourcing mos kelsa — o'sha bilan).

5.3. Ishonchlilik, kuzatuvchanlik va test

  RESILIENCE — tarmoq ishonchsiz (9.6, 14.8):
   servis chaqiruvi = tarmoq so'rovi  yiqilishi/sekinlashishi mumkin
   TIMEOUT (cheksiz kutma), RETRY (qayta urin — ehtiyotkorlik bilan)
   CIRCUIT BREAKER 9.6-bob: servis ketma-ket yiqilsa — chaqiruvni to'xtat
    (kaskad yiqilishni to'sadi — "zanjir uzgich")

  OBSERVABILITY — taqsimlangan kuzatuv 10.9-bob:
   CORRELATION ID: bir so'rovga ID beriladi, barcha servisga uzatiladi
     loglarda bir so'rovni servislar bo'ylab kuzatish mumkin
   DISTRIBUTED TRACING (Jaeger/Zipkin): so'rov yo'lini vizual ko'rish
     qaysi servis sekin — aniqlanadi
   MARKAZIY LOG + METRIKA (Prometheus/Grafana — 10.9)

  TEST — mikroservisga xos 14.8-bob:
   KONTRAKT TEST: servislar API kelishuvini buzmaganini tekshirish
   INTEGRATSIYA TEST: servislar birga to'g'ri ishlashini tekshirish

   Resilience — timeout/retry/circuit breaker (tarmoq ishonchsiz — kaskad to's)
   Kuzatuv — correlation ID + tracing; test — kontrakt + integratsiya

Ishonchlilik (resilience) — mikroservisda servis chaqiruvi endi tarmoq so'rovi (monolitdagi to'g'ridan funksiya chaqiruvi emas), demak u yiqilishi yoki sekinlashishi mumkin. Himoya vositalari: (1) timeout — cheksiz kutmaslik (Product servisi javob bermasa — belgilangan vaqtdan keyin to'xta); (2) retry — qayta urinish (vaqtinchalik uzilishda — lekin ehtiyotkorlik bilan, aks holda yiqilgan servisni yana ko'proq yuklaydi); (3) circuit breaker ("zanjir uzgich" — 9.6, 14.8): servis ketma-ket yiqilaversa, unga chaqiruvni to'xtatib turadi (darrov xato qaytaradi — servis tiklanishiga vaqt beradi) — bu kaskad yiqilishni to'sadi (bir servis yiqilib butun tizimni tortib tushirmaydi). Kuzatuvchanlik (observability) — taqsimlangan muhitda debugging monolitdan qiyinroq (bir so'rov ko'p servis bo'ylab boradi — 6-bo'lim): (1) correlation ID — har kiruvchi so'rovga yagona ID beriladi va u barcha servisga uzatiladi — natijada loglarda bitta so'rovni servislar bo'ylab kuzatish mumkin (aks holda loglar aralashib ketadi); (2) distributed tracing (Jaeger, Zipkin) — so'rovning to'liq yo'lini vizual ko'rsatadi (qaysi servisda qancha vaqt ketgan — sekin bo'g'inni topish); (3) markaziy log va metrika (Prometheus/Grafana — 10.9 — har servis logi bir joyda, monitoring). Test — mikroservisga xos ikki tur qo'shiladi (14.8 test asoslari ustiga): (1) kontrakt test — ikki servis orasidagi API kelishuvini (so'rov/javob shakli) biror servis buzmaganini tekshiradi (Order Product'dan kutgan javob shakli o'zgarmaganmi); (2) integratsiya test — servislar birga to'g'ri ishlashini tekshiradi (butun buyurtma oqimi — Order Payment Notification). Ikki nuqta: (1) resilience — timeout/retry/circuit breaker (tarmoq ishonchsiz — kaskad yiqilishni to'sish); (2) kuzatuv — correlation ID + distributed tracing 10.9-bob; test — kontrakt + integratsiya 14.8-bob. Bu uchtasi — mikroservisni productionga tayyorlaydigan (o'rganish loyihasidan real tizimga) qatlam. Ularsiz mikroservis "ishlaydi", lekin biror servis yiqilganda butun tizim tortib tushadi va sabab topilmaydi. Kod yechimi ataylab berilmagan — circuit breaker'ni (masalan NestJS'da — 8.16) va correlation ID'ni (Gateway'da ID yaratib, servislarga header orqali uzatib) qanday qo'shishni loyihada o'zingiz amalga oshirasiz.

6. Mikroservis muammolari va qachon kerak

  MIKROSERVIS MUAMMOLARI (murakkablik — over-engineering xavfi):

  MURAKKABLIK:
   Taqsimlangan tizim (CAP — 15.7; eventual izchillik — saga)
   Servis muloqoti (tarmoq — sekin, ishonchsiz — retry, timeout)
   Debugging qiyin (so'rov ko'p servis bo'ylab — tracing)
   Deploy/infra murakkab (ko'p servis — Docker, K8s, CI/CD)
   Ma'lumot izchilligi (taqsimlangan — saga, eventual)
   Koordinatsiya (ko'p servis — versiyalash, API kelishuvi)

  QACHON MIKROSERVIS (kerak):
   Katta tizim (ko'p domen, ko'p jamoa)
   Har xil miqyos (bir qism yuqori yuk — alohida miqyos)
   Mustaqil jamoa/deploy (ko'p jamoa — alohida ishlash)
   Kichik/o'rta loyiha  MONOLIT (16.1 — sodda)

   Mikroservis murakkab (taqsimlangan, muloqot, debug, infra) — over-engineering xavfi
   Qachon — katta/ko'p jamoa/har xil miqyos; kichik  monolit (monolith first)

Mikroservis muammolari va qachon kerak — mikroservisning murakkabligi va to'g'ri qaror. Murakkablik (mikroservis — monolit'dan ancha murakkab — over-engineering xavfi — 15.1: 2.8): (1) taqsimlangan tizim (CAP — 15.7: 2.5 — izchillik qiyin; eventual — saga pattern — taqsimlangan tranzaksiya); (2) servis muloqoti (tarmoq orqali — sekin (to'g'ridan chaqiruvdan), ishonchsiz — tarmoq uzilishi — retry, timeout, circuit breaker); (3) debugging qiyin (bir so'rov ko'p servis bo'ylab — qaysi servis muammo — distributed tracing — 15.5'dan ancha qiyin); (4) deploy/infra murakkab (ko'p servis — Docker, Kubernetes, CI/CD — har servis — 10-QISM); (5) ma'lumot izchilligi (taqsimlangan — saga, eventual — darrov izchillik qiyin); (6) koordinatsiya (ko'p servis — versiyalash, API kelishuvi — bir servis API o'zgarsa boshqalari — buzilishi mumkin). Qachon mikroservis (kerak — bu murakkablikka arziydigan): (1) katta tizim (ko'p domen, ko'p jamoa); (2) har xil miqyos (bir qism yuqori yuk — masalan to'lov peak — faqat to'lov servisini miqyoslash — monolit'da butun ilova); (3) mustaqil jamoa/deploy (ko'p jamoa — har biri o'z servisini mustaqil — koordinatsiyasiz); (4) kichik/o'rta loyiha monolit (16.1 — sodda — mikroservis ortiqcha murakkablik). Ikki nuqta: (1) mikroservis murakkab (taqsimlangan, muloqot, debug, infra, koordinatsiya — over-engineering xavfi — 15.1: 2.8); (2) qachon — katta/ko'p jamoa/har xil miqyos; kichik monolit ("monolith first" — 2.1 — avval monolit, o'sganda bo'lish). Eng muhim dars — mikroservis kuchli, lekin murakkab — har loyiha uchun emas (2.1 — kichik loyihaga — over-engineering — koordinatsiya, debug, infra azobi — monolit yetadi). Qachon — katta tizim (ko'p domen, jamoa, har xil miqyos — murakkablikka arziydi). "Monolith first" (Martin Fowler) — avval monolit (16.1 — sodda — tez), o'sganda va kerak bo'lganda mikroservisga bo'lish (mikroservisdan boshlash — ko'pincha xato — talab noaniq, murakkablik erta). Bu capstone — mikroservisni o'rganish (qanday — 9-QISM amaliyoti) va qachon (katta — kerak bo'lganda — kichik emas). Senior arxitektura ko'nikmasi — mikroservisni bilish va qachon ishlatishni bilish (texnologiya emas — qaror — 15.7: trade-off). Ko'p kompaniya monolit'dan boshlab, o'ssa mikroservisga bo'lgan (Netflix, Amazon — katta — mikroservis; startup — monolit). Mikroservis — katta miqyos yechimi (murakkablik narxi bilan — faqat kerak bo'lganda).

7. Integratsiya — bu loyiha qaysi QISMlarni birlashtiradi

• Arxitektura (9-QISM): monolit vs mikroservis 9.5-bob, DDD bounded context 9.4-bob, API Gateway 9.8-bob, Saga 9.7-bob, CQRS/event-driven 9.7-bob, CAP 9.10-bob, circuit breaker 9.6-bob.
• NestJS 8.16-bob: servislar (modullar, DI, mikroservis transporti — TCP/gRPC/RabbitMQ).
• Message queue 5.22-bob: asinxron muloqot (RabbitMQ/Kafka).
• DB (6-QISM): har servis o'z DB (database-per-service).
• DevOps (10-QISM): Docker/K8s 10.8-bob, distributed tracing va monitoring 10.9-bob.
• Xavfsizlik (14-QISM): servis auth (JWT — 14.6), Gateway, rate limit 14.8-bob, Payment izolyatsiya.
• System design 15.7-bob: CAP, miqyos, trade-off.

8. Eng yaxshi amaliyotlar (best practices)

• Monolith first (avval monolit — o'ssa bo'lish — 2.1).
• Biznes domeni bo'yicha bo'lish (DDD — texnik emas — 3).
• Har servis o'z DB (izolyatsiya — mustaqillik — 4).
• Asinxron muloqot (event/queue — kam bog'liqlik — 4).
• API Gateway (kirish nuqtasi — auth/routing — 5.1).
• Saga bilan taqsimlangan tranzaksiya (kompensatsiya — eventual izchillik — 5.2).
• Circuit breaker + timeout/retry (kaskad yiqilishni to'sish — 5.3).
• Correlation ID + distributed tracing (taqsimlangan debugging — 5.3, 10.9).
• Docker + K8s (har servis konteyner — 10.8).
• Kontrakt + integratsiya test (servislar kelishuvi — 5.3, 14.8).
• Payment izolyatsiya (alohida servis — xavfsizlik — 2.2).
• Qachon mikroservis (katta — kichik monolit — 6).
• Anti-pattern'dan qochish (nano, distributed monolith — 3).

9. Capstone loyiha: "Mikroservis Platform"

Mikroservis arxitekturasini amalda mustahkamlash.

Maqsad

Mikroservis e-commerce (yoki o'z g'oyangiz) qurish — bir necha mustaqil servis, muloqot, infra.

Talablar (requirements)

1. Domen: biznes domenlariga bo'lish (Auth/Product/Order/Payment — 3).
2. Servislar: kamida 3 mustaqil servis (NestJS — 8.16).
3. O'z DB: har servis alohida DB (database-per-service — 4, 9.5).
4. Sinxron muloqot: REST/gRPC (Order Product — 4).
5. Asinxron muloqot: event/queue (buyurtma email — 4, 5.22, 9.6).
6. API Gateway: kirish nuqtasi (auth/routing/rate limit — 5.1, 9.8).
7. Taqsimlangan tranzaksiya: kamida bitta ko'p-servisli oqim Saga bilan (kompensatsiya — 5.2, 9.7).
8. Ishonchlilik: timeout/retry yoki circuit breaker (kamida bir chaqiruvda — 5.3, 9.6, 14.8).
9. Kuzatuv: markaziy log + correlation ID (so'rovni servislar bo'ylab kuzatish — 5.3, 10.9).
10. Docker: har servis konteyner 10.8-bob.
11. Orkestratsiya: Docker Compose/K8s 10.8-bob.
12. Test: kamida bitta kontrakt yoki integratsiya test (5.3, 14.8).
13. Qaror: nega mikroservis (yoki monolit yetadimi — 6).

Maslahatlar (hint)

• Biznes domeni (DDD — 3).
• Har servis o'z DB (4).
• Asinxron (kam bog'liqlik — 4).
• Payment alohida (xavfsizlik — 2.2).
• Over-engineering'dan qochish (kichik monolit — 6).

"Tayyor" mezonlari (acceptance criteria)

• 3+ mustaqil servis (o'z DB — database-per-service).
• Sinxron + asinxron muloqot.
• API Gateway (marshrutlash + auth + rate limit).
• Ko'p-servisli oqim Saga bilan (kompensatsiya ishlaydi).
• Ishonchlilik (timeout/retry yoki circuit breaker).
• Correlation ID bilan so'rovni servislar bo'ylab kuzatish.
• Docker (har servis) + orkestratsiya (Compose/K8s).
• Kamida bitta kontrakt yoki integratsiya test.
• Mikroservis qarori oqlangan (nega monolit emas).

Bu SIZNING capstone loyihangiz — kodini o'zingiz yozasiz.

Qiyinchilik bo'lsa — mos QISM (9 arxitektura, 8 NestJS, 5.22 queue, 10 DevOps), yoki «[bosqich] qanday?» degan savol bo'yicha yo'nalish olishingiz mumkin.

10. Xulosa va keyingi bobga ko'prik

Bu bobda mikroservis arxitektura capstone'ni rejalashtirdik:

• Monolit vs mikroservis 2.1-bob; g'oya (e-commerce — 2.2); bo'lish (DDD — 3); muloqot (REST/event — 4); bosqichlar/stack (5); Gateway va service discovery 5.1-bob; Saga va eventual izchillik 5.2-bob; resilience, kuzatuv, test 5.3-bob; muammolar/qachon (6).

Endi siz mikroservis tizimini loyihalay olasiz: biznes domenlariga bo'lish, servis muloqoti (sinxron/asinxron), API Gateway, taqsimlangan tranzaksiya (Saga), ishonchlilik (circuit breaker), kuzatuvchanlik (correlation ID), Docker/K8s — va eng muhimi, qachon mikroservis (katta) vs monolit (kichik). Bu — senior arxitektura ko'nikmasi.

Keyingi bob — 16.3-bob: Real-time ilova (chat/notifications). Mikroservisni bildik; endi real-time ilovani ko'ramiz: WebSocket (jonli ulanish), chat (xabar almashish), bildirishnoma (push), va real-time'ning muammolari (ulanish boshqaruvi, miqyos). Bu — Socket.io 5.13-bob amaliyoti — jonli, interaktiv ilova.

Foydalanilgan rasmiy/ishonchli manbalar

• "Building Microservices" (Sam Newman) — servislarga bo'lish, muloqot, resilience
• "Microservices Patterns" (Chris Richardson) — Saga, event-driven, decomposition, API Gateway
• "Domain-Driven Design" (Eric Evans) — bounded context, domen bo'yicha bo'lish
• "Release It!" (Michael Nygard) — circuit breaker, timeout, resilience namunalari
• NestJS Microservices docs; martinfowler.com (monolith first, microservices)
• Kubernetes, Docker, RabbitMQ/Kafka docs (mikroservis infra)
• OpenTelemetry / Jaeger / Zipkin docs (distributed tracing, correlation ID)