Πώς κλιμακώνετε μεμονωμένες υπηρεσίες και εντοπίζετε τα σημεία πνιγμού της απόδοσης;

Question

Accepted Answer

Το κύριο πλεονέκτημα των μικρουπηρεσιών είναι η **ανεξάρτητη κλιμάκωση κάθε υπηρεσίας** ώστε να ταιριάζει με το δικό της φορτίο, αντί να κλιμακώνουμε ολόκληρη την εφαρμογή. Η εύρεση σημείων πνιγμού είναι τότε θέμα μέτρησης ανά υπηρεσία και ανά hop.

## Τεχνικές κλιμάκωσης

- **Οριζόντια κλιμάκωση** — προσθήκη stateless instances πίσω από έναν load balancer.
- **Αυτόματη κλιμάκωση** — κλιμάκωση βάσει CPU, μνήμης, βάθους ουράς ή προσαρμοσμένων μετρικών.
- **Caching** — μείωση επαναλαμβανόμενης εργασίας και downstream load.
- **Async + ουρές** — απορρόφηση κορυφών; αποσύνδεση αργής εργασίας.
- **Κλιμάκωση δεδομένων** — read replicas, sharding, αποθήκες ανά υπηρεσία.

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

## Εύρεση σημείων πνιγμού

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

## Κοινά σημεία πνιγμού

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

## Παγίδα

Η κλιμάκωση μιας υπηρεσίας της οποίας το σημείο πνιγμού είναι μια **κοινή βάση δεδομένων** απλώς μεταφέρει περισσότερο φορτίο στη BD — κλιμακώστε τον πραγματικό περιορισμό, όχι το σύμπτωμα.

## Γιατί σημαίνει

Η ανεξάρτητη κλιμάκωση σας επιτρέπει να δαπανάτε χωρητικότητα ακριβώς όπου υπάρχει το φορτίο, το οποίο είναι πολύ φθηνότερο από την κλιμάκωση ενός monolith χονδρικά.

Αλλά η τυφλή κλιμάκωση σπαταλά χρήματα και μπορεί να επιδεινώσει τα πράγματα· η μέτρηση των μετρικών ανά υπηρεσία και των ιχνών ανά hop είναι αυτό που σας λέει τον πραγματικό περιορισμό που πρέπει να διορθώσετε.