როგორ დააკომპლექტოთ ცალკეული სერვისები და იპოვოთ შესრულების ვიწრო ადგილები?

Question

Accepted Answer

მიკროსერვისების ძირითადი სარგებელი არის **თითოეული სერვისის დამოუკიდებელი მასშტაბირება** თავისი დატვირთვის შესაბამისად, მთელი აპლიკაციის მასშტაბირების ნაცვლად. ვიწრო ადგილების პოვნა არის სერვის-განზომილებიანი და hop-განზომილებიანი გაზომვის საკითხი.

## მასშტაბირების ტექნიკა

- **ჰორიზონტალური მასშტაბირება** — უდებს აპატიურ ინსტანციებს load balancer-ის უკან.
- **თვითგაკორექტირება** — მასშტაბი CPU, მეხსიერება, რიგის სიღრმე ან მორგებული მეტრიკები.
- **კეშირება** — შეამცირეთ განმეორებული სამუშაო და ქვემოთ მიმავალი დატვირთვა.
- **ასინქ + რიგები** — შეწოვა თავდასხმები; გამოიყვანეთ ნელი სამუშაო.
- **მონაცემთა მასშტაბირება** — წაკითხვის ასლები, 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
```

## სახიფათო ინციდენტი

სერვისის მასშტაბირება, რომლის ვიწრო ადგილი არის **გაზიარებული მონაცემთა ბაზა**, უბრალოდ გადააქვს მეტი დატვირთვა DB-ში — მასშტაბი რეალური შეზღუდვა, არა სიმპტომი.

## რატომ მნიშვნელოვანია ეს

დამოუკიდებელი მასშტაბირება საშუალებას გაძლევთ ზუსტად იქ დახარჯოთ სიმძლავრე, სადაც დატვირთვა მდებარეობს, რაც ბევრად დაბალია, ვიდრე monolit-ის მთელი მასშტაბირება.

მაგრამ ცრუ მასშტაბირება ფულს ხელოვთ ხელმოწერას და შეიძლება ხელი შეუშალოს; სერვის-განზომილებიანი მეტრიკებისა და hop-განზომილებიანი ტრეკების გაზომვა არის ის, რაც გიჩვენებთ რეალურ შეზღუდვას, რომელიც უნდა გამოასწოროთ.