Bạn mở rộng từng service và tìm điểm nghẽn hiệu năng như thế nào?

Question

Accepted Answer

Một lợi ích then chốt của microservices là **mở rộng từng service độc lập** để khớp với tải riêng của nó, thay vì mở rộng cả ứng dụng. Tìm điểm nghẽn khi đó là vấn đề đo lường theo từng service và từng bước nhảy.

## Các kỹ thuật mở rộng

- **Mở rộng theo chiều ngang** — thêm các instance không trạng thái sau một load balancer.
- **Autoscaling** — mở rộng theo CPU, bộ nhớ, độ sâu queue, hoặc metric tùy chỉnh.
- **Caching** — cắt giảm công việc lặp lại và tải downstream.
- **Async + queue** — hấp thụ các đợt tăng đột biến; tách rời công việc chậm.
- **Mở rộng dữ liệu** — read replica, sharding, kho dữ liệu riêng cho từng service.

```yaml
# Kubernetes HPA: mở rộng orders theo CPU
minReplicas: 3
maxReplicas: 20
metric: cpu
targetUtilization: 70   # thêm pod khi CPU trung bình > 70%
```

## Tìm điểm nghẽn

```text
1. Metric: service nào có độ trễ / mức bão hòa cao? (RED/USE)
2. Trace: SPAN nào trong request bị chậm?
3. Khoan sâu: Truy vấn DB? lock? lời gọi N+1? GC pause?
```

```text
Gateway ──┤ Orders ──┤ Payments ████████████ ← 80% độ trễ ở đây
                       Inventory ─┤
```

## Các điểm nghẽn phổ biến

```text
⚠️ Lời gọi đồng bộ hay tán gẫu (fan-out mỗi request)
⚠️ Database dùng chung/quá tải
⚠️ Thiếu cache hoặc cache nguội
⚠️ Retry không giới hạn khuếch đại tải
```

## Cạm bẫy

Mở rộng một service mà điểm nghẽn của nó là một **database dùng chung** chỉ dồn thêm tải lên DB — hãy mở rộng đúng ràng buộc thực sự, không phải triệu chứng.

## Tại sao điều này quan trọng

Mở rộng độc lập cho phép bạn chi năng lực chính xác ở nơi có tải, rẻ hơn nhiều so với mở rộng toàn bộ một monolith.

Nhưng mở rộng một cách mù quáng lãng phí tiền và có thể làm mọi thứ tệ hơn; đo lường metric theo từng service và trace theo từng bước nhảy là thứ cho bạn biết ràng buộc thực sự cần sửa.