Bài 46 — Observability cho Microservices: Service Mesh

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn đang vận hành hệ thống của một sàn thương mại điện tử tại Việt Nam. Ban đầu chỉ có một ứng dụng monolith duy nhất, mọi thứ nằm gọn trong một tiến trình. Khi có sự cố, bạn mở log của đúng một service, đọc, và tìm ra nguyên nhân. Nhưng rồi công ty tăng trưởng, đội ngũ tách monolith thành 40, 80, rồi 200 microservice. Một request của khách hàng khi bấm "Đặt hàng" giờ đây đi qua chục service khác nhau: API Gateway, Auth, Cart, Inventory, Pricing, Payment, Notification... Và bây giờ, khi khách hàng phàn nàn "đặt hàng chậm", bạn không còn biết chậm ở đâu.

Đây chính là bài toán mà Service Mesh ra đời để giải quyết. Trong các bài trước bạn đã học về ba trụ cột observability (logs, metrics, traces ở Bài 19), về distributed tracing với OpenTelemetry (Bài 23), và về các pattern như circuit breaker, retry, timeout (Bài 47). Bài này ghép các mảnh đó lại ở tầng hạ tầng: làm sao để có được observability và độ tin cậy cho giao tiếp giữa các service mà không phải sửa code của từng service. Với một kỹ sư vận hành (SRE, DevOps, Platform Engineer), hiểu Service Mesh là hiểu cách kiểm soát "phần chìm của tảng băng" — mạng lưới liên lạc nội bộ mà bình thường không ai nhìn thấy nhưng lại là nơi 80% sự cố microservice ẩn náu.

Khái niệm cốt lõi

Service Mesh là gì

Service Mesh là một lớp hạ tầng chuyên trách cho giao tiếp service-to-service. Nó nhận lấy các trách nhiệm vốn thường bị nhồi vào code ứng dụng — như routing, retry, timeout, mã hóa mTLS, thu thập metrics/traces — và tách chúng ra thành một tầng độc lập, đồng nhất cho toàn hệ thống.

Điểm mấu chốt cần nhớ: mọi lời gọi mạng giữa các service không đi thẳng từ service A sang service B nữa. Thay vào đó, request đi qua một proxy đặt cạnh mỗi service. Proxy này chặn lấy toàn bộ lưu lượng vào/ra, và chính tại đây, mesh thực hiện phép màu của mình: đo đạc, mã hóa, thử lại, định tuyến.

Kiến trúc: Data Plane và Control Plane

Service Mesh gồm hai phần:

Data Plane là tập hợp các proxy chạy cạnh từng service. Mẫu hình phổ biến nhất là sidecar: mỗi Pod (trong Kubernetes) có thêm một container proxy chạy song song với container ứng dụng. Ứng dụng gọi localhost, proxy nhận lấy và chuyển tiếp. Proxy phổ biến nhất là Envoy (do Lyft phát triển, nay là dự án CNCF). Data plane là nơi thực sự xử lý từng byte lưu lượng.

Control Plane là bộ não. Nó không đụng vào lưu lượng thật, mà cấu hình cho tất cả proxy trong data plane: "service này retry 3 lần", "timeout 2 giây", "5% lưu lượng đi sang phiên bản mới". Nó cũng cấp phát và luân chuyển chứng chỉ TLS cho mTLS. Các control plane phổ biến: Istio (với istiod), Linkerd, Consul Connect, và Cilium (dùng eBPF).

Một xu hướng mới cần biết: sidecarless mesh. Istio có chế độ Ambient Mesh dùng node-level proxy (ztunnel) thay vì sidecar mỗi Pod, còn Cilium dùng eBPF ở tầng kernel. Lý do: sidecar tuy tiện nhưng tốn tài nguyên — mỗi Pod thêm 50-150MB RAM và một chút latency. Với 2000 Pod, đó là hàng trăm GB RAM chỉ để chạy proxy.

Ba nhóm năng lực mesh mang lại

1. Observability (trọng tâm bài này). Vì mọi lưu lượng đều đi qua proxy, mesh tự động sinh ra ba loại tín hiệu mà không cần sửa code:

Metrics vàng: cho mỗi cặp service, mesh đo request rate, error rate, và latency (đây chính là RED Method ở Bài 22 — Rate, Errors, Duration). Bạn có ngay bảng "golden signals" cho toàn bộ đồ thị gọi.
Distributed tracing: proxy tự động truyền các trace header (như traceparent của W3C, hoặc B3 header). Tuy nhiên — điểm này cực kỳ quan trọng — mesh chỉ nối được các span nếu ứng dụng chịu truyền tiếp (propagate) các header đó giữa request vào và request ra. Mesh không thể tự đoán request nào thuộc trace nào bên trong code của bạn.
Service topology: mesh biết chính xác service nào gọi service nào, vẽ được bản đồ phụ thuộc theo thời gian thực (Kiali cho Istio làm việc này).

2. Traffic management. Định tuyến theo phần trăm (canary), theo header (A/B test), theo phiên bản. Retry, timeout, circuit breaking, fault injection.

3. Security. mTLS tự động — mọi giao tiếp nội bộ được mã hóa và xác thực hai chiều mà ứng dụng không cần biết. Cùng với đó là các policy ủy quyền: service A có được phép gọi service B không.

Vì sao observability qua mesh lại mạnh

Trước khi có mesh, muốn có metrics cho mọi lời gọi, mỗi đội phải tự nhúng thư viện client, tự đặt tên metric, tự thống nhất label. Kết quả: đội Java đo một kiểu, đội Go đo một kiểu, đội Node.js quên đo. Mesh mang lại tính đồng nhất: cùng một tập metric, cùng label source_workload, destination_workload, response_code, cho mọi service bất kể ngôn ngữ. Đây là giá trị lớn nhất — quan sát đồng nhất, không phụ thuộc ngôn ngữ (language-agnostic).

Nhưng cũng phải thành thật: mesh chỉ nhìn thấy tầng giao tiếp mạng (L7). Nó biết "request tới /checkout mất 3 giây và trả về 500", nhưng không biết vì sao — không thấy bên trong hàm nào chậm, query SQL nào treo. Đó là việc của APM (Bài 50) và tracing chi tiết trong code. Mesh cho bạn bức tranh giữa các service; nó không thay thế observability bên trong mỗi service.

Tình huống thực tế

Tình huống 1 — Sàn TMĐT Đông Nam Á và "ẩn số 3 giây"

Một sàn thương mại điện tử tầm trung ở khu vực (giả định tên "ShopSEA", quy mô ~120 microservice trên Kubernetes) gặp than phiền kéo dài: checkout thỉnh thoảng mất tới 3-4 giây, nhưng không đội nào nhận trách nhiệm. Đội Payment nói "code tôi chạy 200ms là xong", đội Cart cũng nói tương tự. Mỗi đội chỉ nhìn thấy phần của mình.

Sau khi triển khai Istio và bật Kiali, họ nhìn vào bản đồ phụ thuộc và thấy điều bất ngờ: service checkout gọi pricing, và pricing gọi promotion theo kiểu tuần tự cho từng sản phẩm trong giỏ. Metric của mesh cho thấy p50 mỗi lời gọi promotion chỉ 40ms, nhưng với giỏ 30 sản phẩm thì thành 30 x 40ms = 1.2 giây, và khi promotion bị chậm (p99 lên 300ms) thì tổng vọt lên 3 giây. Đây là bài toán N+1 request ẩn ở tầng mạng mà không log nào của từng service chỉ ra được, vì mỗi lời gọi riêng lẻ đều "nhanh".

Bài học: Metrics đồng nhất theo cặp service (source → destination) của mesh phơi bày các anti-pattern giao tiếp mà log rời rạc từng service không thấy. Họ sửa bằng cách gộp lời gọi promotion thành batch, checkout p99 giảm từ 3.2s xuống 600ms.

Tình huống 2 — Fintech Việt Nam và yêu cầu mã hóa nội bộ

Một công ty fintech tại TP.HCM (giả định "PayViet") bị bên kiểm toán yêu cầu: toàn bộ lưu lượng nội bộ giữa các service phải được mã hóa, kể cả trong cùng cluster. Trước đó, đội đã định sửa 60 service để thêm TLS thủ công — ước tính 3 tháng công việc, và chắc chắn sẽ có service làm sai cấu hình chứng chỉ.

Thay vào đó họ triển khai Linkerd (nổi tiếng nhẹ và dễ vận hành hơn Istio). Chỉ bằng việc inject sidecar, mTLS được bật mặc định cho toàn bộ giao tiếp — mã hóa và xoay chứng chỉ tự động mỗi 24 giờ. Đội không sửa một dòng code ứng dụng nào. Ngoài ra, dashboard của Linkerd cho họ luôn success rate và latency của từng service, giúp họ đạt yêu cầu về audit trail giao tiếp.

Bài học: Đây là ví dụ kinh điển của "tách concern ra khỏi ứng dụng". mTLS là bài toán hạ tầng, không nên là bài toán code. Mesh biến 3 tháng công thành vài ngày, đồng thời loại bỏ nguy cơ mỗi đội tự cấu hình sai. Bài học phụ: chọn mesh phù hợp quy mô — với nhu cầu chính là mTLS + metrics cơ bản, Linkerd đơn giản hơn Istio rất nhiều.

Tình huống 3 — Cái bẫy "bật tracing tưởng đủ" ở một startup logistics

Một startup logistics (giả định "GiaoNhanh") triển khai Istio, bật tracing, hào hứng mở Jaeger lên để xem trace. Nhưng họ thấy toàn các trace rời rạc, mỗi span đứng một mình, không nối thành cây gọi hoàn chỉnh. Họ tưởng mesh hỏng.

Sự thật: Istio có tạo span cho từng hop, nhưng để nối các span thành một trace liên tục, ứng dụng phải truyền tiếp trace header (như x-request-id, traceparent, các B3 header) từ request nhận vào sang request gọi ra. Code của họ tạo HTTP client mới mỗi lần gọi và không copy các header đó, nên mesh mất dấu liên kết cha-con.

Bài học: Đây là hiểu lầm phổ biến nhất về mesh. Mesh cho bạn metrics gần như miễn phí, nhưng distributed tracing thực sự vẫn đòi hỏi ứng dụng hợp tác truyền context. Họ khắc phục bằng cách nhúng thư viện OpenTelemetry để tự động propagate header (như đã học ở Bài 23), sau đó Jaeger hiện đúng cây gọi và họ tìm ra một service geocoding bên thứ ba là thủ phạm gây timeout.

Hướng dẫn từng bước

Đây là lộ trình đưa observability qua Service Mesh vào hệ thống một cách an toàn:

Đánh giá nhu cầu trước khi cài. Đừng cài mesh vì "nghe hay". Bạn thực sự cần nó khi: có từ vài chục service trở lên, nhiều ngôn ngữ khác nhau, cần mTLS toàn hệ thống, hoặc cần metrics/canary đồng nhất. Nếu chỉ có 5 service, mesh là dao mổ trâu.

Chọn mesh theo quy mô và nhu cầu. Linkerd nếu ưu tiên nhẹ, đơn giản, chủ yếu cần mTLS + metrics. Istio nếu cần traffic management phong phú, đa protocol, hệ sinh thái lớn. Cilium/Ambient nếu quan tâm tiết kiệm tài nguyên ở quy mô rất lớn.

Triển khai trên môi trường staging trước. Cài control plane, rồi bật sidecar injection cho một namespace không quan trọng trước. Quan sát: latency có tăng không, Pod có khởi động đúng không.

Bật observability và kết nối vào stack sẵn có. Cấu hình mesh xuất metrics ra Prometheus, dựng dashboard Grafana, và bản đồ topology (Kiali cho Istio, dashboard tích hợp cho Linkerd). Đây là lúc bạn có ngay RED metrics cho mọi cặp service.

Kết nối tracing đúng cách. Trỏ mesh xuất trace sang Jaeger/Tempo, NHƯNG song song đó đảm bảo ứng dụng truyền tiếp trace header (dùng OpenTelemetry). Kiểm thử bằng một request thật, xác nhận trace nối liền trong Jaeger.

Rollout dần dần bằng chính mesh. Mở rộng sidecar sang từng namespace theo tuần. Dùng khả năng canary của mesh để đưa lưu lượng vào mesh từ từ nếu cần.

Thiết lập alerting dựa trên tín hiệu mesh. Đặt cảnh báo khi error rate giữa hai service vượt ngưỡng, hoặc latency p99 tăng đột biến (liên hệ Bài 18 về signal vs noise, Bài 21 về golden signals).

Lỗi thường gặp & mẹo

Tưởng mesh tự cho tracing đầy đủ. Như tình huống 3: mesh cho metrics tự động, nhưng tracing liền mạch vẫn cần ứng dụng propagate header. Luôn cặp mesh với OpenTelemetry.

Quên tính chi phí tài nguyên của sidecar. Mỗi sidecar tốn RAM/CPU và thêm một chút latency (thường +1-3ms mỗi hop, nhưng qua nhiều hop thì cộng dồn). Đo trước khi cam kết. Cân nhắc Ambient/eBPF nếu quy mô lớn.

Bật mTLS ở chế độ STRICT quá sớm. Nếu ép STRICT khi còn service chưa được inject sidecar, giao tiếp giữa service có mesh và service chưa có mesh sẽ đứt. Luôn bắt đầu ở chế độ PERMISSIVE (chấp nhận cả mã hóa lẫn plaintext), chuyển STRICT khi đã phủ mesh toàn bộ.

Coi mesh là "hộp đen thần thánh". Khi mesh trục trặc (Envoy config sai, control plane không đồng bộ), nó có thể chặn hoặc định tuyến sai lưu lượng, gây sự cố toàn cục. Đội phải hiểu cách debug Envoy, không được "cài rồi quên".

Nhầm mesh thay được APM. Mesh nhìn tầng mạng giữa các service; nó không thấy bên trong hàm, không thấy query DB chậm. Vẫn cần APM (Bài 50) cho phần bên trong service.

Mẹo — dùng label chuẩn của mesh để phân tích. Các label như source_workload, destination_service, response_code là kho báu. Một truy vấn Prometheus đơn giản trên destination_service + response_code=5xx cho bạn ngay danh sách service đang lỗi.

Mẹo — bắt đầu chỉ với observability. Bạn không cần dùng ngay tất cả tính năng. Nhiều đội chỉ bật mesh để lấy metrics + mTLS trong 6 tháng đầu, rồi mới dùng canary sau. Đi từng bước.

Bài tập thực hành

Vẽ đồ thị gọi hiện tại. Chọn một luồng nghiệp vụ trong hệ thống bạn đang làm (ví dụ "đăng nhập" hoặc "đặt hàng"). Vẽ ra tất cả các service mà một request đi qua và mũi tên gọi giữa chúng. Đánh dấu chỗ nào bạn không chắc latency là bao nhiêu — đó là những "điểm mù" mà mesh sẽ soi sáng.

Thực hành với cluster local. Cài minikube hoặc kind, triển khai Linkerd (dễ nhất cho người mới) theo hướng dẫn chính thức, cài ứng dụng demo (như emojivoto của Linkerd). Mở dashboard, quan sát success rate và latency real-time cho từng service.

Chứng minh giá trị của propagation. Với ứng dụng demo, mở Jaeger. Quan sát trace. Sau đó thử tìm trong code demo chỗ header được truyền tiếp. Viết một đoạn giải thích 5 câu: tại sao nếu bỏ dòng propagate header đó thì trace sẽ vỡ.

Thiết kế bảng so sánh quyết định. Lập bảng 3 cột: Linkerd / Istio / Cilium, so theo các tiêu chí: độ phức tạp vận hành, chi phí tài nguyên, độ phong phú traffic management, hỗ trợ mTLS. Rồi viết khuyến nghị cho một công ty 40 service, đội SRE 3 người — chọn cái nào và vì sao.

Tóm tắt

Service Mesh là lớp hạ tầng chuyên trách giao tiếp service-to-service, gồm data plane (các proxy như Envoy, thường theo mẫu sidecar) và control plane (bộ não cấu hình như Istio, Linkerd). Vì mọi lưu lượng đều đi qua proxy, mesh mang lại ba nhóm năng lực mà không cần sửa code ứng dụng: observability (metrics RED đồng nhất, tracing, service topology), traffic management (canary, retry, timeout), và security (mTLS tự động).

Với observability — trọng tâm bài này — giá trị lớn nhất là metrics đồng nhất, không phụ thuộc ngôn ngữ cho mọi cặp service, phơi bày các anti-pattern giao tiếp mà log rời rạc không thấy. Nhưng hãy nhớ hai giới hạn cốt lõi: (1) mesh cho metrics gần như miễn phí nhưng distributed tracing liền mạch vẫn cần ứng dụng propagate context qua OpenTelemetry; và (2) mesh chỉ nhìn tầng mạng giữa các service, không thay thế APM cho phần bên trong mỗi service. Triển khai thận trọng: staging trước, mTLS PERMISSIVE trước STRICT, tính chi phí sidecar, và chọn mesh vừa với quy mô — đừng dùng dao mổ trâu để giết gà.