Jak skalujesz poszczególne usługi i znajdujesz wąskie gardła wydajności?

Question

Accepted Answer

Kluczową zaletą mikrousług jest **skalowanie każdej usługi niezależnie** do dopasowania jej własnego obciążenia, zamiast skalowania całej aplikacji. Znalezienie wąskich gardeł sprowadza się wtedy do pomiaru dla każdej usługi i dla każdego przeskoku.

## Techniki skalowania

- **Skalowanie horyzontalne** — dodaj bezstanowe instancje za load balancerem.
- **Autoskalowanie** — skaluj na podstawie CPU, pamięci, głębokości kolejki lub metryk niestandardowych.
- **Buforowanie** — zmniejsz powtarzaną pracę i obciążenie systemu podrzędnego.
- **Async + kolejki** — wchłoń skoki; rozseparuj powolną pracę.
- **Skalowanie danych** — repliki do odczytu, sharding, dedykowane magazyny danych per-usługę.

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

## Znajdowanie wąskich gardeł

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

## Typowe wąskie gardła

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

## Pułapka

Skalowanie usługi, której wąskim gardłem jest **współdzielona baza danych**, po prostu przenosi więcej obciążenia na bazę danych — skaluj rzeczywisty ogranicznik, nie objaw.

## Dlaczego to ważne

Niezależne skalowanie pozwala Ci zużyć zdolność dokładnie tam, gdzie jest obciążenie, co jest znacznie tańsze niż skalowanie monolitu hurtowo.

Ale ślepe skalowanie marnuje pieniądze i może pogorszyć sytuację; pomiary metryk per-usługę i ślady per-przeskok to to, co mówi Ci o rzeczywistym ograniczeniu do naprawienia.