რა არის სერვისის ქსელი და რატომ გამოიყენებდით მას?

Question

Accepted Answer

**სერვისის ქსელი** (Istio, Linkerd) გადააქვს ჯვარედინი ქსელის შინაარსი — გაიმეორება, ტايმ-ავტი, mTLS, ტრაფიკის მარშრუტიზაცია, დაკვირვება — **აპლიკაციის კოდიდან** და **sidecar proxies**-ის ქსელის ინფრასტრუქტურის დონეზე.

## როგორ მუშაობს

სერვისის ყველა ინსტანცია **sidecar proxy**-ს გვერდით გაშვებულია (მაგ., Envoy). ყველა ტრაფიკი გადის proxy-ების მეშვეობით, რომლებიც ქმნიან **data plane**-ს; **control plane** მათ ელაპარაკება.

```text
┌─────────────────┐        ┌─────────────────┐
│ Service A       │        │ Service B       │
│  app  ⇄ [proxy] │◀──────▶│ [proxy] ⇄  app  │
└─────────────────┘  mTLS  └─────────────────┘
        ▲ configured by ▲
        └──── Control Plane (Istio/Linkerd) ────┘
```

## რას უზრუნველყოფს

- **mTLS** სერვისებს შორის ავტომატურად (აპ-ის ცვლილების გარეშე).
- **სიმტკიცე** — გაიმეორება, ტайმ-აუტი, circuit breaking proxy-ში.
- **ტრაფიკის მენეჯმენტი** — canary, A/B, წონიანი მარშრუტიზაცია.
- **დაკვირვება** — ერთიანი მეტრიკა, traces, logs.

## პოლიტიკის მაგალითი

```yaml
# shift 10% of traffic to v2 (canary), no code change
route:
  - destination: { host: orders, subset: v1 }
    weight: 90
  - destination: { host: orders, subset: v2 }
    weight: 10
```

## კომპრომისები

ქსელი ზრდის latency-ს (დამატებითი hops), რესურსების ზეწოლას (ერთი proxy თითო pod-ზე) და რეალურ ოპერაციულ სირთულეს.

## რატომ არის მნიშვნელოვანი

ქსელი სტანდარტიზирует სიმტკიცეს, უსაფრთხოებას და დაკვირვებას ყველა სერვისის ზე, ყოველი omed ჯგუფი მათი განსხვავებული ენებით არ გაიმეორებს.

მაგრამ ეს მძიმეა: მხოლოდ მიიღეთ, როდესაც საკმარისი სერვისი გაქვთ ისე, რომ გამოგანმეორებული ქსელის ლოგიკა გადააჭარბოს ქსელის ოპერაციულ ღირებულებას.