Mi az a service mesh és miért használnál egyet?

Question

Accepted Answer

A **service mesh** (Istio, Linkerd) Cross-cutting hálózati problémákat — retries, timeouts, mTLS, traffic routing, observability — **az alkalmazás kódján kívülre** helyezi egy **sidecar proxies** hálózati infrastruktúra rétegbe.

## Hogyan működik

Minden service instancia mellett egy **sidecar proxy** (pl. Envoy) fut. Az összes forgalom a proxykon keresztül áramlik, amelyek a **data plane**-t képezik; a **control plane** konfigurálja azokat.

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

## Mit biztosít

- **mTLS** a szolgáltatások között automatikusan (nulla alkalmazás módosítás).
- **Resilience** — retries, timeouts, circuit breaking a proxyn.
- **Traffic management** — canary, A/B, weighted routing.
- **Observability** — uniform metrikák, trace-ek, naplók.

## Politika példa

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

## Kompromisszumok

A mesh késleltetést (extra ugrások), erőforrás terhelést (egy proxy pod-onként) és valódi operatív bonyolultságot ad.

## Miért fontos

A mesh szabványosítja a resilience-t, biztonságot és observability-t az összes szolgáltatásban anélkül, hogy minden csapat különböző nyelveken újraimplementálná azokat.

De nehéz: csak akkor fogadja el, amikor elég szolgáltatása van ahhoz, hogy a duplikált hálózati logika felülmúlja a mesh operatív költségeit.