Wie skalieren Sie einzelne Services und finden Performance-Engpässe?

Question

Accepted Answer

Ein Schlüsselvorteil von Mikroservices ist die **unabhängige Skalierung jedes Service** entsprechend der eigenen Last, anstatt die gesamte App zu skalieren. Engpässe zu finden ist dann eine Frage der Messung pro Service und pro Hop.

## Skalierungstechniken

- **Horizontale Skalierung** — staatlose Instanzen hinter einem Load Balancer hinzufügen.
- **Autoskalierung** — Skalierung basierend auf CPU, Speicher, Warteschlangentiefe oder benutzerdefinierten Metriken.
- **Caching** — wiederholte Arbeiten und nachgelagerter Last reduzieren.
- **Async + Warteschlangen** — Spitzen absorben; langsame Arbeit entkoppeln.
- **Datenskalierung** — Read-Replicas, Sharding, servicespezifische Speicher.

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

## Engpässe finden

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

## Häufige Engpässe

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

## Falle

Einen Service zu skalieren, dessen Engpass eine **gemeinsame Datenbank** ist, verlagert nur mehr Last auf die DB — skalieren Sie die eigentliche Beschränkung, nicht das Symptom.

## Warum es wichtig ist

Unabhängige Skalierung ermöglicht es Ihnen, Kapazität genau dort einzusetzen, wo die Last ist, was viel günstiger ist als ein monolithisches System pauschal zu skalieren.

Aber blinde Skalierung verschwendet Geld und kann die Dinge verschlimmern; die Messung von Service-spezifischen Metriken und Hop-spezifischen Traces sagt Ihnen, wo die eigentliche Bottleneck zu beheben ist.