Service Mesh Cho Developer: Khi Nào Cần, Khi Nào Thừa?

5 Microservice, 10 Endpoint — Rồi Lạc Đường

Hệ thống có 5 microservice (ứng dụng chia nhỏ thành nhiều service độc lập). Mỗi service gọi 2-3 service khác qua API (giao diện giao tiếp giữa các phần mềm). Mọi thứ hoạt động ổn cho đến khi: một service chậm, kéo theo cả chuỗi timeout. Không ai biết request đi đâu, lỗi ở bước nào, và tại sao thời gian chờ bỗng nhiên tăng 300%.

Đây chính là bài toán mà service mesh sinh ra để giải quyết.

Service Mesh Là Gì?

Service mesh là tầng infra nằm giữa các microservice, xử lý ba việc chính: routing (chuyển tiếp request), bảo mật (mã hóa và xác thực giữa các service), quản sát (theo dõi traffic, latency, lỗi).

Cách hoạt động: mỗi pod được gắn một sidecar proxy. Mọi traffic đi qua proxy này thay vì gọi trực tiếp. App code không cần thay đổi.

• Istio — mạnh nhất, feature đầy đủ, nhưng nặng (Envoy proxy ăn tài nguyên).
• Linkerd — nhẹ hơn, dễ deploy hơn, phù hợp team nhỏ.
• Cilium — dùng eBPF thay vì sidecar, ít overhead hơn.

Khi Nào Cần, Khi Nào Thừa?

Cần service mesh khi:

• Nhiều microservice gọi qua lại phức tạp (10+ service)
• Cần mTLS giữa các service mà không muốn sửa code
• Traffic management: canary release, circuit breaker, retry policy
• Muốn tracing và monitoring chi tiết từng request

Không cần khi:

• Dưới 5 service, traffic thấp
• Monolith hoặc chỉ có 1-2 API
• Team chưa quen Kubernetes — thêm service mesh = thêm headache
• Chưa có bài toán quản sát thực sự

Service mesh giải quyết bài toán độ phức tạp giao tiếp. Nếu chưa có bài toán đó, đừng tạo ra nó.

Hệ Thống 5 Microservice Kia — Sau Khi Deploy Istio

Sau khi deploy Istio với sidecar proxy:

• Theo dõi: thấy rõ request đi qua service nào, chậm ở bước nào
• Bảo mật: traffic giữa các service được mã hóa, không cần sửa code
• Chống lỗi: config retry & timeout trong YAML, không hardcode trong app
• Giám sát: Grafana dashboard hiện latency từng service, lỗi theo thời gian thực

Tất cả không cần sửa một dòng code ứng dụng.

Tóm Tắt

• Service mesh = tầng mạng giữa microservice, xử lý routing, bảo mật, quản sát
• Hoạt động qua sidecar proxy gắn vào mỗi pod
• Istio mạnh nhất, Linkerd nhẹ nhất, Cilium hiện đại nhất (dùng eBPF)
• Chỉ cần khi hệ thống đủ phức tạp — dưới 5 service thì thừa
• Ưu điểm lớn nhất: app code không cần thay đổi

---

Bài viết thuộc series DevOps Handbook — hướng dẫn thực tế cho developer muốn hiểu sâu về infrastructure.