Kas yra paslaugų tinklas ir kodėl jūs jį naudotumėte?

Question

Accepted Answer

**Paslaugų tinklas** (Istio, Linkerd) iš **programos kodo** iškeliamas skersai einančias tinklo problemas — bandymus, laiko pabaigos, mTLS, srautų maršrutizavimą, stebėjimą — į **šoninių tarpininkų** tinklo infrastruktūros sluoksnį.

## Kaip tai veikia

Kiekvienas paslaugos egzempliorius veikia šalia **šoninio tarpininko** (pvz., Envoy). Visas srautas eina per tarpininkus, kurie sudaro **duomenų plokštumą**; **valdymo plokštuma** juos sukonfigūruoja.

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

## Ką tai teikia

- **mTLS** tarp paslaugų automatiškai (be programos pakeitimų).
- **Atsparus** — bandymai, laiko pabaigos, grandinės nutraukimas tarpininkyje.
- **Srautų valdymas** — kanariuka, A/B, svertingas maršrutizavimas.
- **Stebėjimas** — vienodi metrika, pėdsakai, žurnalai.

## Politikos pavyzdys

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

## Kompromisai

Tinklas prideda latenciją (papildomi šuoliai), išteklių pridėtinį darbo krūvį (vieną tarpininką per pod) ir realią operacinę sudėtingumą.

## Kodėl tai svarbu

Tinklas standartizuoja atsparumą, saugumą ir stebėjimą visose paslaugose be to, kad kiekviena komanda jas iš naujo diegtų skirtingomis kalbomis.

Tačiau tai sunkus sprendimas: jį naudokite tik tada, kai turite tiek paslaugų, kad dubliuota tinklo logika viršytų tinklo eksploatacijos sąmatą.