Si e shkallëzoni shërbimet individuale dhe si gjeni ngushtëzimet e performancës?

Question

Accepted Answer

Një përfitim kyç i microservices është **shkallëzimi i pavarur i secilit shërbimi** për të përputhur ngarkesën e tij, në vend të shkallëzimit të të gjithë aplikacionit. Gjetja e ngushtëzimeve është pastaj çështja e matjes për shërbim dhe për kërcim.

## Teknikat e shkallëzimit

- **Shkallëzimi horizontal** — shtoni instanca stateless pas një load balancer.
- **Shkallëzimi automatik** — shkallëzim sipas CPU, memorjes, thellësisë së radhës, ose metrikave përshtatëse.
- **Memorizim në cache** — zvogëloni punën e përsëritur dhe ngarkesën poshtë.
- **Asinkrion + radhë** — thithni kulmet; shpërndarni punën e ngadaltë.
- **Shkallëzimi i të dhënave** — replica për lexim, sharding, dyqane për shërbim.

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

## Gjetja e ngushtëzimeve

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

## Ngushtëzimet e zakonshme

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

## Kurth

Shkallëzimi i një shërbimi, ngushtëzimi i të cilit është një **bazë e dhënash e ndarë**, thjesht zhvendos më shumë ngarkesë në DB — shkallëzoni kufizimin aktual, jo simptomin.

## Pse është e rëndësishme

Shkallëzimi i pavarur ju lejon të shpenzoni kapacitetin saktësisht ku është ngarkesa, gjë që është shumë më lirë sesa shkallëzimi i një monoliti në toto.

Por shkallëzimi verbalisht shpërdoron paratë dhe mund të përkeqësojë gjërat; matja e metrikave për shërbim dhe gjurmime për kërcim është ajo që ju tregon kufizimin e vërtetë për të rregulluar.