Hvordan skalerer du individuelle services og finder performance-flaskehalse?

Question

Accepted Answer

En nøglefordel ved mikroservices er **uafhængig skalering af hver service** for at matche dens egen belastning, i stedet for at skalere hele appen. At finde flaskehalse er derefter et spørgsmål om måling per-service og per-hop.

## Skaleringsteknikker

- **Horisontalskalering** — tilføj stateless-instanser bag en load balancer.
- **Autoskalering** — skalering på CPU, hukommelse, kødybde eller brugerdefinerede metrics.
- **Caching** — reducér gentaget arbejde og downstream-belastning.
- **Async + køer** — absorbér spidser; dekoblet langsomt arbejde.
- **Dataskalering** — læse-replikaer, sharding, per-service-lagring.

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

## Finde flaskehalse

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

## Almindelige flaskehalse

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

## Faldgruber

Skalering af en service hvis flaskehals er en **delt database** flytter bare mere belastning over på DB — skalér den faktiske begrænsning, ikke symptomerne.

## Hvorfor det betyder noget

Uafhængig skalering lader dig bruge kapacitet præcist hvor belastningen er, hvilket er meget billigere end at skalere en monolith i sin helhed.

Men blind skalering spilder penge og kan forværre tingene; måling af per-service metrics og per-hop traces fortæller dig den faktiske begrænsning at rette op på.