Kako prosljeđujete pojedinatne usluge i kako nalazite uska grla u performansama?

Question

Accepted Answer

Ključna prednost microservicesa je **sposobnost da svaku uslugu neovisno prosljeđujete** kako bi se prilagodila vlastitom opterećenju, umjesto da cijelu aplikaciju prosljeđujete. Pronalaženje uskih grla je tada pitanje mjerenja po usluzi i po skoku.

## Tehnike prosljeđivanja

- **Vodoravno prosljeđivanje** — dodajte bez-stanja primjerke iza balanser opterećenja.
- **Automatsko prosljeđivanje** — prosljeđujte na temelju CPU-a, memorije, dubine reda čekanja ili prilagođenih metrika.
- **Cacheiranje** — smanjite ponovljeni rad i opterećenje nizvodno.
- **Async + redovi čekanja** — apsorbirajte vrhove; odvojite spori rad.
- **Prosljeđivanje podataka** — replike za čitanje, sharding, po-uslužne pohrane.

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

## Pronalaženje uskih grla

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

## Česta uska grla

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

## Zamka

Prosljeđivanje usluge čije je usko grlo **zajednička baza podataka** samo premješta više opterećenja na DB — prosljeđujte stvarno ograničenje, ne simptom.

## Zašto je važno

Neovisno prosljeđivanje vam omogućava da precizno alocirati kapacitet gdje je opterećenje, što je daleko jeftinije od prosljeđivanja monolita na veleprodaju.

Ali slijepo prosljeđivanje troši novac i može pogoršati stvari; mjerenje po-uslužnih metrika i po-skoknih tragova je ono što vam govori pravo ograničenje koje trebate ispraviti.