Service Mesh Pattern: Sidecar Thực Sự Mang Lại Gì Cho Bạn

Service Mesh Là Gì

Service mesh là infrastructure layer chuyên dụng cho giao tiếp service-to-service. Nó được triển khai như sidecar proxy (thường là Envoy) cùng với mỗi service instance. Proxy chặn tất cả network traffic đến và từ service — bản thân service không biết proxy tồn tại.

Control plane (Istiod trong Istio) cấu hình các proxy: service nào có thể nói chuyện với nhau, traffic policy nào áp dụng.

Những Gì Nó Cung Cấp

Service Discovery

Kubernetes cung cấp service discovery cơ bản qua DNS. Service mesh mở rộng với:

• Thuật toán load balancing ngoài round-robin: least connection, ring hash (cho session affinity).
• Health-aware routing: proxy theo dõi endpoint health ở cấp connection.

mTLS

Mỗi service nhận certificate X.509 ngắn hạn. Sidecar xử lý TLS termination và client certificate presentation trong suốt.

Những gì điều này mang lại:

• Traffic service-to-service được mã hóa mà không cần thay đổi code.
• Authorization dựa trên identity: chỉ payment-service có thể gọi billing-service.
• Automatic certificate rotation (thường mỗi 24 giờ) mà không restart service.

Traffic Management

# Gửi 10% traffic đến v2, 90% đến v1
spec:
  http:
  - route:
    - destination:
        subset: v1
      weight: 90
    - destination:
        subset: v2
      weight: 10

Cho phép canary deployment, A/B testing, và blue/green rollout mà không cần thay đổi code.

Circuit Breaking

Ngăn service downstream chậm hay thất bại gây cascade failure. Khi service vượt quá ngưỡng lỗi, circuit mở và call fail fast thay vì xếp hàng và làm cạn kiệt thread pool.

Observability

Sidecar proxy emit metric, trace, và access log cho mọi service-to-service call mà không cần thay đổi code:

• Request rate
• Error rate (4xx/5xx)
• Latency (p50, p95, p99)
• Saturation (connection pool usage)

Chi Phí

Latency overhead. Mỗi request đi qua hai sidecar proxy. Istio thêm ~1-2ms mỗi hop. Linkerd thêm ít hơn (~0.5ms).

Memory mỗi pod. Mỗi Envoy sidecar dùng 50–150MB RAM. Cho cluster với 200 pod, đây là 10–30GB overhead.

Sự phức tạp vận hành. Mesh thêm control plane bạn phải vận hành, monitor, và upgrade.

Khi Nào Không Dùng Service Mesh

• Cluster nhỏ (< 20 service): chi phí vận hành không đáng.
• Triển khai non-Kubernetes: hầu hết mesh giả định Kubernetes.
• Pattern request-response đơn giản: nếu service của bạn có ít dependency và không cần traffic shifting.

Giải Pháp Thay Thế Nhẹ Hơn

Cilium eBPF triển khai tính năng service mesh ở kernel level mà không có sidecar per-pod. Latency overhead gần bằng không. Istio ambient mode (sidecarless) đi theo hướng tương tự.

Điểm Khởi Đầu Thực Tế

Bắt đầu không có mesh. Thêm vào khi bạn có vấn đề cụ thể nó giải quyết: bạn cần mTLS cho compliance, canary deployment, hay golden signal observability mà không cần sửa mọi application.

Dùng Linkerd nếu bạn muốn đơn giản và overhead thấp. Dùng Istio nếu bạn cần full feature set. Đừng áp dụng mesh để chuẩn bị cho quy mô bạn chưa có.