Hur skalar du enskilda tjänster och hittar prestandaflaskhalsar?

Question

Accepted Answer

En nyckelfördelning med microservices är **oberoende skalning av varje tjänst** för att matcha dess egen belastning, istället för att skala hela appen. Att hitta flaskhalsar är då en fråga om att mäta per-tjänst och per-hopp.

## Skalningstekniker

- **Horisontell skalning** — lägg till tillståndslösa instanser bakom en lastbalanserare.
- **Automatisk skalning** — skala på CPU, minne, kölängd eller anpassade mätvärden.
- **Caching** — minska upprepat arbete och downstreambelastning.
- **Async + köer** — absorbera toppar; frikoppla långsamt arbete.
- **Dataskalning** — läsrepliker, sharding, per-tjänst-lager.

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

## Hitta flaskhalsar

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

## Vanliga flaskhalsar

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

## Fallgrop

Skalning av en tjänst vars flaskhals är en **delad databas** flyttar bara mer belastning till DB:n — skala den faktiska begränsningen, inte symptomet.

## Varför det spelar roll

Oberoende skalning låter dig spendera kapacitet precis där belastningen är, vilket är mycket billigare än att skala en monolith i wholesale.

Men blind skalning slösar pengar och kan förvärra saker; mätning av per-tjänst-mätvärden och per-hopp-spår är det som talar om för dig den verkliga begränsningen att åtgärda.