Bài 1: gRPC là gì? Tại sao chúng ta cần gRPC thay vì REST/JSON?
1. gRPC là gì?
gRPC (phát âm là g-R-P-C) là một framework mã nguồn mở hiệu suất cao, do Google phát triển lần đầu vào năm 2015. Chữ "g" ban đầu thay đổi ý nghĩa theo từng phiên bản (ví dụ: gaRPC, grevious...), nhưng hiện tại nó chỉ đơn giản là tiền tố đại diện cho framework.
Bản chất gRPC là một công nghệ RPC (Remote Procedure Call - Gọi thủ tục từ xa).
Hiểu đơn giản: Thay vì viết code gọi API qua lại phức tạp giữa các hệ thống (như REST), gRPC cho phép một ứng dụng gọi thẳng một hàm/phương thức nằm trên một máy chủ khác (đặt ở một server khác, ngôn ngữ khác) y như thể đang gọi một hàm cục bộ (local function) ngay trong cùng một chương trình.
2. Gỡ rối cốt lõi: gRPC hoạt động như thế nào?
Để hiểu tại sao gRPC lại mạnh mẽ, chúng ta cần nhìn vào 2 "vũ khí bí mật" của nó:
- HTTP/2 làm giao thức truyền tải: Khác với HTTP/1.1 của REST (mỗi request phải mở một kết nối riêng hoặc dùng chung một kết nối nhưng phải xếp hàng tuần tự), HTTP/2 cho phép Multiplexing (đa hợp). Nhiều request và response có thể được truyền song song trên cùng một kết nối TCP duy nhất. Ngoài ra, HTTP/2 còn hỗ trợ nén header (HPACK) giúp giảm dung lượng mạng đáng kể.
- Protocol Buffers (Protobuf) làm định dạng dữ liệu: Thay vì dùng chuỗi JSON (vốn con người đọc được nhưng máy tính phân tích rất tốn kém), gRPC sử dụng Protobuf để biên dịch dữ liệu thành các đoạn byte nhị phân (binary) siêu nhỏ và cực kỳ tối ưu về tốc độ xử lý.
3. So sánh chi tiết: gRPC vs REST/JSON
| Tiêu chí | REST API (JSON) | gRPC (Protobuf) |
|---|---|---|
| Giao thức mạng | Thường dùng HTTP/1.1 | Bắt buộc dùng HTTP/2 |
| Định dạng dữ liệu | Văn bản (JSON, XML) – Dễ đọc bằng mắt thường | Nhị phân (Binary) – Máy tính đọc, con người khó đọc trực tiếp |
| Hiệu suất & Tốc độ | Chậm hơn do kích thước gói tin lớn và tốn thời gian parse JSON | Cực kỳ nhanh và nhẹ (nhỏ gọn hơn tới 3-10 lần, tốc độ parse nhanh hơn 5-10 lần) |
| Hợp đồng API (Contract) | Không bắt buộc (thường dùng Swagger/OpenAPI) | Bắt buộc qua file định nghĩa .proto (rất chặt chẽ) |
| Kiểu truyền thông | Chủ yếu là Request - Response (1 chiều) | Hỗ trợ toàn diện: Unary, Server Streaming, Client Streaming, Bidirectional Streaming (2 chiều thời gian thực) |
| Khả năng sinh code | Cần thư viện ngoài (Swagger Codegen...) | Hỗ trợ native thông qua protoc cho hầu hết mọi ngôn ngữ lập trình |
| Hỗ trợ từ Trình duyệt (Browser) | Tốt, native 100% | Cần cấu hình thêm (gRPC-Web) do trình duyệt hạn chế dùng HTTP/2 trực tiếp cho gRPC |
4. Tại sao chúng ta cần gRPC thay vì REST/JSON?
Dù REST/JSON vẫn là "ông vua" cho các Public API (cho phép bên thứ 3, Mobile App, Web Frontend truy cập), nhưng gRPC sinh ra để giải quyết các bài toán nội bộ khắt khe hơn:
- Giao tiếp giữa các Microservices (Service-to-Service): Trong kiến trúc Microservices, hàng chục hoặc hàng trăm service phải gọi nhau liên tục. Nếu dùng REST/JSON, độ trễ mạng (latency) sẽ cộng dồn rất lớn và tốn băng thông. gRPC giúp giảm thiểu tối đa độ trễ này.
- Hệ thống yêu cầu hiệu năng cực cao và thời gian thực (Real-time): Các ứng dụng như game server, hệ thống tài chính chứng khoán, dịch vụ IoT (nhận dữ liệu từ hàng triệu cảm biến), hay các hệ thống chat cần tốc độ phản hồi tính bằng mili-giây.
- Lập trình đa ngôn ngữ (Polyglot): Công ty bạn có team viết Backend bằng Go, team khác dùng Java, team khác nữa dùng Python? gRPC giải quyết trọn gói việc này bằng cách dịch file
.protochung thành mã nguồn chuẩn cho tất cả các ngôn ngữ mà không lo lệch cấu trúc dữ liệu. - Kiểm soát chặt chẽ hợp đồng dữ liệu (API Contract): Với REST, dev Frontend và Backend rất dễ cãi nhau vì sửa đổi trường dữ liệu JSON mà quên cập nhật tài liệu. Với gRPC, nếu không khớp file
.proto, mã nguồn thậm chí sẽ không thể biên dịch (compile error), giúp bắt lỗi ngay từ lúc viết code.
💡 Lời khuyên thực tế: gRPC không phải là "kẻ thay thế hoàn toàn" cho REST. REST vẫn tuyệt vời cho Frontend-to-Backend. Nhưng khi nói đến Backend-to-Backend (Microservices), gRPC là lựa chọn vượt trội.
All rights reserved
