Sidecar pattern là gì? Kiến trúc tách phụ trợ khỏi ứng dụng chính
Sidecar pattern (mẫu xe bên cánh) là một mẫu kiến trúc phần mềm trong đó các chức năng phụ trợ — logging, monitoring, caching, retry, service discovery, mã hóa, luồng điều khiển — được tách khỏi ứng dụng chính và đóng gói thành một container hoặc tiến trình riêng, chạy cạnh (side by side) với ứng dụng trong cùng một pod, container group, hoặc máy chủ. Ứng dụng chính không cần biết mã nguồn hay thư viện của phần phụ trợ này; nó chỉ cần một interface đơn giản (thường là localhost port hoặc Unix socket) để giao tiếp.
Sidecar pattern là phản ánh trực tiếp của mẫu Data Sidecar và mẫu Sidecar của Microsoft Azure Architecture Center, và là nền tảng kiến trúc của service mesh (Istio, Linkerd, Consul Connect) trong đó Envoy đóng vai trò sidecar proxy cho mọi service.
Vì sao không nhúng logic phụ trợ trực tiếp vào ứng dụng?
Trước khi có mẫu sidecar, các chức năng phụ trợ thường được nhúng trực tiếp vào code ứng dụng bằng thư viện. Cách này tạo ra nhiều vấn đề:
- Lặp lại code: mỗi service phải tự tích hợp lại logging, metrics, tracing. Code trùng lặp và không nhất quán giữa các service.
- Ngôn ngữ lạp trình phụ thuộc: thư viện sidecar phải có sẵn cho mọi ngôn ngữ và framework. Với công nghệ mới hoặc ngôn ngữ niche, việc tìm thư viện chuẩn rất khó.
- Ràng buộc phiên bản: nâng cấp thư viện sidecar (ví dụ OpenTelemetry SDK) buộc phải rebuild và redeploy toàn bộ ứng dụng, tạo rủi ro breaking change giữa các service.
- Tách biệt trách nhiệm: logic hạ tầng lẫn vào business logic, làm code khó đọc và khó test.
Sidecar pattern tách hai loại logic này ra. Ứng dụng chỉ tập trung vào nghiệp vụ; sidecar lo phần hạ tầng. Nhờ chạy trong cùng một pod, sidecar có thể chia sẻ network namespace với ứng dụng (localhost là địa chỉ thật, không cần mã hóa TLS qua mạng) và chia sẻ volume (ví dụ sidecar đọc cùng log file của ứng dụng).
Các thành phần chính và cách hoạt động
Một deployment sidecar điển hình gồm các thành phần sau:
- Ứng dụng chính (main container): xử lý business logic, không cần thay đổi khi thêm sidecar.
- Sidecar container: chạy cùng pod, giao tiếp với main container qua
localhost:<port>vì chúng dùng chung network namespace. - Shared volume: thường là volume ghi log, ví dụ sidecar Fluent Bit hoặc Vector đọc file log của ứng dụng và đẩy ra hệ thống tập trung.
- Service mesh control plane (tùy chọn): Istio/Linkerd inject sidecar proxy tự động vào mọi pod, không cần sửa deployment.
Trong Kubernetes, sidecar thường được khai báo trong cùng một Pod spec với hai container. Có hai trạng thái phổ biến: sideactor luôn hoạt động suốt vòng đời của pod, hoặc sidecar dạng Job chạy một lần rồi kết thúc (ví dụ sidecar migration database chạy trước khi app khởi động). Từ Kubernetes 1.28, tính năng native sidecar containers cho phép khai báo container phụ với field restartPolicy: Always trong init container, giúp quản lý vòng đời đúng cách — container phụ khởi động trước, kết thúc sau main container.
Ở tầng ứng dụng, phổ biến là mẫu Sidecar proxy: sidecar đứng giữa ứng dụng và thế giới bên ngoài, xử lý TLS termination, retries với backoff, circuit breaking, load balancing, và tracing. Envoy là proxy phổ biến nhất, dùng độc lập (LYFT) hoặc dưới dạng sidecar do Istio quản lý.
Khi nào nên và không nên dùng sidecar
Sidecar pattern phù hợp khi:
- Chức năng phụ trợ cần áp dụng đồng nhất cho mọi service trong hệ thống (observability, mTLS, traffic policy).
- Ứng dụng viết bằng nhiều ngôn ngữ và bạn không muốn phụ thuộc vào thư viện sidecar riêng cho từng ngôn ngữ.
- Cần nâng cấp độc lập logic hạ tầng mà không rebuild ứng dụng.
- Cần cô lập tài nguyên: sidecar với resource limit riêng không ảnh hưởng app.
Ngược lại, sidecar không nên dùng khi:
- Chức năng phụ trợ quá đơn giản — thêm một HTTP client proxy chỉ để log request là không đáng; log trực tiếp rẻ hơn nhiều.
- Hệ thống chỉ có 1-2 service — overhead vận hành (thêm container, thêm image, thêm config) không bù được lợi ích.
- Bạn cần truyền dữ liệu lớn giữa app và sidecar — chuyển qua localhost vẫn tốn copy bộ nhớ; nên dùng shared memory hoặc volume trực tiếp.
- Hệ thống đã có service mesh cung cấp sidecar rồi — thêm sidecar thủ công sẽ tạo chồng chất không cần thiết.
Trade-off và lưu ý vận hành
Sidecar đánh đổi sự đơn giản của một container lấy khả năng tách sưu hiệu. Các chi phí cần tính đến:
- Tài nguyên tăng: mỗi pod mang thêm một container. Với 500 pod, sidecar 50MB RAM và 0.1 CPU sẽ cộng thêm 25GB RAM cho cả cluster. Cần đặt resource requests/limits chặt chẽ.
- Latency nội bộ: mọi request đi qua sidecar thêm một network hop (dù chỉ vài chục microsecond). Với service gọi service ở quy mô lớn, đây là chi phí nhân lên nhiều lần.
- Failure mode mới: sidecar lỗi có thể làm hỏng cả pod. Nhiều tổ chức thêm liveness probe riêng cho sidecar và thiết kế để app vẫn hoạt động ở chế độ degraded nếu mất observability.
- Quản lý cấu hình: sidecar cần policy riêng (routing rule, retry budget, mTLS mode). Quản lý thủ công sẽ nhanh chóng trở nên rối — đó là lý do service mesh tồn tại.
Kết luận, sidecar pattern là giải pháp kinh điển cho việc tách logic hạ tầng khỏi logic nghiệp vụ. Nó không phải lựa chọn mặc định cho mọi trường hợp — với hệ thống nhỏ hoặc chức năng phụ trợ đơn giản, cách làm trực tiếp vẫn hợp lý hơn. Nhưng khi quy mô và số service đủ lớn, sidecar (thường do service mesh inject tự động) là cách duy nhất để đồng nhất chính sách bảo mật và observability mà không phải sửa từng ứng dụng.
Nguồn tham khảo:
