Çfarë është një mesh i shërbimeve dhe pse do ta përdornit atë?

Question

Accepted Answer

Një **service mesh** (Istio, Linkerd) zhvendos shqetësimet e rrjetimit ndër-shërbimeve — riprova, timeout, mTLS, rrugëzim prometi, aftësinë e vëzhgimit — **jashtë kodit të aplikacionit** dhe në një shtresën e infrastrukturës së rrjetit të **sidecar proxy**-ve.

## Si funksionon

Sëdo instance i shërbimit ekzekutohet pranë një **sidecar proxy** (p.sh., Envoy). I gjithë trafiku rrjedh përmes proxy-ve, të cilat formojnë **data plane**-in; një **kontrol plane** i konfiguron ata.

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

## Çfarë ofron

- **mTLS** midis shërbimeve automatikisht (zero ndryshime në aplikacion).
- **Reziliencë** — riprova, timeout, circuit breaking në proxy.
- **Menaxhimi i trafikut** — canary, A/B, rrugëzim i ponderuar.
- **Aftësia e vëzhgimit** — metrika uniforme, gjerësi, regjistrat.

## Shembull politike

```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
```

## Kompromise

Një mesh shton latencë (hopa shtesë), mbingarkesë burimesh (një proxy për pod), dhe kompleksitet operacional të vërtetë.

## Pse ka rëndësi

Një mesh standardizoi reziliencën, sigurinë dhe aftësinë e vëzhgimit në çdo shërbim pa patur secilin ekip të ri-implementojë logjikën e rrjetimit në gjuhë të ndryshme.

Megjithatë, është e rëndë: adoptojeni vetëm kur keni aq shërbime që logjika e rrejtimit të duplikuar tejkalon kostot operacionale të mesh-it.