Jak škálujete jednotlivé služby a najdete kritická místa výkonu?

Question

Accepted Answer

Klíčová výhoda mikroslužeb je **nezávislé škálování každé služby** tak, aby odpovídalo vlastnímu zatížení, namísto škálování celé aplikace. Hledání úzkých míst se pak redukuje na měření na úrovni služby a přeskoků.

## Techniky škálování

- **Horizontální škálování** — přidání bezstavových instancí za load balancer.
- **Automatické škálování** — škálování na základě CPU, paměti, hloubky fronty nebo vlastních metrik.
- **Cachování** — snížení opakované práce a zátěže na backend.
- **Asynchronní operace + fronty** — absorpce vrcholů; oddělení pomalých operací.
- **Škálování dat** — read repliky, sharding, úložiště specifické pro službu.

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

## Hledání úzkých míst

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

## Běžná úzká místa

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

## Úskalí

Škálování služby, jejímž úzkým místem je **sdílená databáze**, pouze přenáší více zátěže na DB — škálujte skutečné omezení, ne příznak.

## Proč je to důležité

Nezávislé škálování vám umožní přesně nasměřovat kapacitu tam, kde je zátěž, což je mnohem levnější než celoživotní škálování monolitu.

Ale slepé škálování plýtvá penězi a může věci zhoršit; měření metrik na úrovni služby a trasování na úrovni přeskoků vám řekne skutečné omezení, které je třeba opravit.