Kako se skalira posamezne storitve in poiščete ozka grla pri zmogljivosti?

Question

Accepted Answer

Ključna prednost mikrostoritev je **neodvisna skalabilnost vsake storitve** glede na njeno lastno obremenitev, namesto skaliranja cele aplikacije. Iskanje ozkih grl je nato stvar merjenja na ravni posamezne storitve in na ravni poskokov.

## Tehnike skaliranja

- **Horizontalno skaliranje** — dodajte bresstanjske instance za load balancer.
- **Avtomatsko skaliranje** — skaliranje na podlagi CPU, pomnilnika, globine vrste ali prilagojenih metrik.
- **Predpomnilnik** — zmanjšajte ponavljajočo se delo in obremenitev navzdol.
- **Asinkriona obdelava + vrste** — absorbirajte skoke; ločite počasno delo.
- **Skaliranje podatkov** — replike za branje, sharding, shrambe za posamezno storitev.

```yaml
# Kubernetes HPA: scale orders on CPU
minReplicas: 3
maxReplicas: 20
metric: cpu
targetUtilization: 70   # add pods when avg CPU > 70%
```

## Iskanje ozkih grl

```text
1. Metrics: which service has high latency / saturation? (RED/USE)
2. Traces: which SPAN in the request is slow?
3. Drill in: DB query? lock? N+1 calls? GC pause?
```

```text
Gateway ──┤ Orders ──┤ Payments ████████████ ← 80% of latency here
                       Inventory ─┤
```

## Pogosta ozka grla

```text
⚠️ Chatty synchronous calls (fan-out per request)
⚠️ Shared/overloaded database
⚠️ Missing or cold cache
⚠️ Unbounded retries amplifying load
```

## Pasti

Skaliranje storitve, katere ozko grlo je **skupna baza podatkov**, samo prenese več obremenitve na bazo — skaliramo pravo omejitev, ne simptoma.

## Zakaj je to pomembno

Neodvisno skaliranje vam omogoča, da porabo kapacitete natančno usmerite tja, kjer je obremenitev, kar je precej cenejše od maščevnega skaliranja monolita.

Kdaj pa se skalira naslepo, se zapravlja denar in lahko poslabša stvari; merjenje metrik na ravni posamezne storitve in sledenje na ravni poskokov vam pove pravo omejitev, ki jo je treba odpraviti.