Cum scalezi serviciile individuale și cum găsești gâturile de sticlă de performanță?

Question

Accepted Answer

Un beneficiu cheie al microserviciilor este **scalarea independentă a fiecărui serviciu** pentru a se adapta propriei sale încărcări, în loc să scalezi întreaga aplicație. Găsirea gâturilor de sticlă este apoi o chestiune de măsurare per-serviciu și per-hop.

## Tehnici de scalare

- **Scalare orizontală** — adaugă instanțe fără stare în spatele unui load balancer.
- **Autoscaling** — scalare pe baza CPU, memoriei, adâncimii cozii, sau metrice personalizate.
- **Caching** — reduce munca repetată și încărcarea downstream.
- **Async + cozi** — absorbeți vârfurile; decuplați munca lentă.
- **Scalare de date** — replici de citire, sharding, depozite dedicate serviciilor.

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

## Găsirea gâturilor de sticlă

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

## Gâturi de sticlă comune

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

## Capcană

Scalarea unui serviciu al cărui gât de sticlă este o **bază de date comună** doar mută mai multă încărcătură pe baza de date — scalează constrângerea reală, nu simptomul.

## De ce contează

Scalarea independentă te lasă să alocați capacitate cu precizie acolo unde este încărcătura, ceea ce este mult mai ieftin decât scalarea unei monoliți pe scară largă.

Dar scalarea orbească risipește bani și poate înrăutăți lucrurile; măsurarea metricilor per-serviciu și urmele per-hop este ceea ce vă spune care este adevărata constrângere de remediat.