Service mesh là gì và tại sao bạn lại dùng nó?

Question

Accepted Answer

Một **service mesh** (Istio, Linkerd) chuyển các mối quan tâm mạng xuyên suốt — retry, timeout, mTLS, định tuyến lưu lượng, observability — **ra khỏi code ứng dụng** và vào một tầng hạ tầng mạng gồm các **sidecar proxy**.

## Cách hoạt động

Mỗi instance service chạy bên cạnh một **sidecar proxy** (ví dụ Envoy). Mọi lưu lượng đi qua các proxy, vốn tạo thành **data plane**; một **control plane** cấu hình chúng.

```text
┌─────────────────┐        ┌─────────────────┐
│ Service A       │        │ Service B       │
│  app  ⇄ [proxy] │◀──────▶│ [proxy] ⇄  app  │
└─────────────────┘  mTLS  └─────────────────┘
        ▲ được cấu hình bởi ▲
        └──── Control Plane (Istio/Linkerd) ────┘
```

## Nó cung cấp gì

- **mTLS** giữa các service một cách tự động (zero thay đổi app).
- **Khả năng phục hồi** — retry, timeout, circuit breaking tại proxy.
- **Quản lý lưu lượng** — canary, A/B, định tuyến theo trọng số.
- **Observability** — metric, trace, log đồng nhất.

## Ví dụ policy

```yaml
# dồn 10% lưu lượng sang v2 (canary), không đổi code
route:
  - destination: { host: orders, subset: v1 }
    weight: 90
  - destination: { host: orders, subset: v2 }
    weight: 10
```

## Đánh đổi

Một mesh thêm độ trễ (các bước nhảy phụ), chi phí tài nguyên (một proxy cho mỗi pod), và độ phức tạp vận hành thực sự.

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

Một mesh chuẩn hóa khả năng phục hồi, bảo mật, và observability xuyên mọi service mà không cần mỗi team cài lại chúng bằng các ngôn ngữ khác nhau.

Nhưng nó nặng: chỉ áp dụng khi bạn có đủ service đến mức logic mạng bị lặp lại vượt quá chi phí vận hành của mesh.