Microservices — Senior chuqurlik

To‘g‘ri o‘q — biznes qobiliyati (business capability)

Servislarni texnik qatlam bo‘yicha emas (UserDB-service, EmailService), balki biznes qobiliyati / subdomen bo‘yicha ajrat: Buyurtma, To‘lov, Inventar, Yetkazish. Bu — DDD bounded context (15-mavzu) bilan bir xil chegara.

To‘g‘ri o‘lcham va Conway qonuni

• Juda mayda emas: "nano-service"lar tarmoq shovqini va murakkablikni oshiradi. Servis — bitta jamoa egalik qila oladigan, mustaqil deploy bo‘ladigan biznes birligi.
• Conway qonuni: tizim tuzilishi jamoa tuzilishini aks ettiradi. Servis chegaralarini jamoa chegaralariga moslashtir — aks holda kommunikatsiya to‘qnashadi.
• Yuqori koh'eziya, past bog‘lanish: birga o‘zgaradigan narsa bitta servisda; kam bog‘langan narsalar alohida.

Sinxron: REST vs gRPC

// gRPC — servislararo SINXRON aloqa uchun (HTTP/2 + protobuf, tez, tipli)
// order.proto
syntax = "proto3";
service OrderService {
  rpc GetOrder (GetOrderRequest) returns (Order);           // request-response
  rpc StreamOrders (StreamRequest) returns (stream Order);  // server streaming
}

// NestJS gRPC klient — boshqa servisni chaqirish
@Injectable()
export class OrderClient implements OnModuleInit {
  private svc: OrderServiceGrpc;
  constructor(@Inject("ORDER_PKG") private client: ClientGrpc) {}
  onModuleInit() { this.svc = this.client.getService("OrderService"); }

  getOrder(id: string) {
    return firstValueFrom(this.svc.getOrder({ id }));   // tipli, Observable
  }
}

Shartnoma va versiyalash

Ikki yondashuv

• Client-side: klient registrydan (Consul, Eureka, etcd) manzilni so‘rab, o‘zi tanlaydi. Ko‘proq nazorat, klientga yuk.
• Server-side: klient LB/meshga yuboradi, u topadi. Klient sodda. Kubernetes buni tabiiy beradi (Service + kube-dns).

Database-per-service oqibatlari

• Cross-service query yo‘q: "buyurtma + mijoz ismi"ni bitta JOIN bilan ololmaysan (boshqa DB). Yechim: API composition (bir necha servisdan yig‘ish) yoki CQRS read model (9-mavzu — event’lardan tayyor ko‘rinish).
• Taqsimlangan tranzaksiya: bir amal ko‘p servisga tegsa — Saga (13-mavzu), 2PC emas.
• Ma’lumot dublikatsiyasi: har servis o‘ziga kerakli ma’lumotning nusxasini saqlaydi (mijoz ismi Buyurtma servisda ham) — event orqali yangilanadi.

Sidecar naqshi

Har servis yonida sidecar proxy (Envoy) turadi. Barcha kiruvchi/chiquvchi trafik u orqali o‘tadi — va u ilova bilmagan holda retry, timeout, circuit breaking, mTLS, tracing, load balancing qiladi:

# Service mesh (Istio) — cross-cutting concern'larni ILOVADAN chiqaradi (sidecar)
apiVersion: networking.istio.io/v1
kind: VirtualService
spec:
  http:
    - route:
        - destination: { host: order-service, subset: v1 }
          weight: 90                      # canary: 90% v1
        - destination: { host: order-service, subset: v2 }
          weight: 10                      # 10% v2
      retries: { attempts: 3, perTryTimeout: 2s }   # retry ILOVASIZ (mesh qiladi)
      timeout: 5s

Mustaqil deploy tamoyillari

• Bitta servis — bitta konteyner/pipeline: har servis o‘z CI/CD’siga ega, alohida deploy bo‘ladi.
• Backward-compatible o‘zgarish: yangi versiya eski klientlar bilan ishlashda davom etsin (2-bo‘lim).
• Canary/blue-green (5, 8-mavzu) — yangi versiyani asta chiqarish.

Contract testing — integratsiya buzilishini oldini olish

Servislar mustaqil deploy bo‘lsa — biri o‘zgarib, ikkinchisini bilmasdan buzishi mumkin. To‘liq integratsiya testi sekin va mo‘rt. Contract test (Pact) yechadi: iste’molchi o‘z kutilmasini yozadi, ta’minlovchi CI’da unga mosligini tekshiradi:

// CONTRACT TEST (Pact) — integratsiyani BUZMASDAN mustaqil deploy qilish
// Consumer (Buyurtma) o'z kutilmasini yozadi:
pact.given("order 42 mavjud")
   .uponReceiving("GetOrder so'rovi")
   .withRequest({ method: "GET", path: "/orders/42" })
   .willRespondWith({ status: 200, body: { id: "42", status: "confirmed" } });
// -> Provider (To'lov) shu shartnomaga MOS ekanini CI'da tekshiradi
//    endi biri o'zgarsa, deploy'dan OLDIN buzilish aniqlanadi

Qachon mikroservis (va qachon YO‘Q)

Senior tayyorlik cheklisti