Đã đăng vào about 4 hours ago 8 phút đọc

REST vs gRPC: Tại sao service nội bộ dùng gRPC, còn public API vẫn trung thành với REST

Hôm nay chúng ta giải quyết một câu hỏi cực kỳ thực tế: tại sao các hệ thống microservices hiện đại đang có xu hướng chuyển sang dùng gRPC khi giao tiếp giữa các service, nhưng khi tạo public API cho developer bên ngoài, RESTful vẫn chiếm ưu thế? REST thì quá quen rồi, nên hôm nay mình sẽ lướt nhanh phần đó, rồi đi sâu vào gRPC và đặc biệt là sự khác biệt giữa HTTP/1.1 và HTTP/2.

RESTful API

Hình ảnh minh họa giao tiếp RESTful API giữa client và server

RESTful API là kiến trúc chạy trên HTTP, dùng các method chuẩn như GET, POST, PUT, PATCH, DELETE và trao đổi dữ liệu chủ yếu qua JSON hoặc XML. Ưu điểm lớn nhất là dễ đọc, dễ debug, tương thích mọi browser và gần như ai cũng biết dùng từ ngày đầu học lập trình.

Nhưng chính sự "thoải mái" này cũng kéo theo overhead: payload JSON dài, header lặp lại ở mỗi request, kết nối HTTP/1.1 chịu nhiều hạn chế khi hệ thống phình to. Khi xử lý hàng nghìn request mỗi giây giữa các service, những thứ này bắt đầu trở thành nút thắt cổ chai.

gRPC là gì?

HÌnh ảnh minh họa giao tiếp GRPC giữa các services trong kiến trúc microservices

Hình ảnh minh họa giao tiếp GRPC giữa các services trong kiến trúc microservices

gRPC (gRPC Remote Procedure Call) là framework mã nguồn mở của Google, cho phép các service gọi nhau như gọi hàm local. Điểm khác biệt cốt lõi đến từ ba thứ.

Protocol Buffers (Protobuf). Thay vì JSON text, gRPC serialize dữ liệu sang định dạng nhị phân. Không có key lặp lại — parser chỉ cần đọc byte offset thay vì tokenize toàn bộ string. Kết quả là payload thường nhỏ hơn JSON từ 3 đến 10 lần.

HTTP/2. gRPC bắt buộc chạy trên HTTP/2 — đây là lý do quan trọng giúp gRPC đạt hiệu năng cao. HTTP/2 hỗ trợ multiplexing, nén header bằng HPACK và loại bỏ Head-of-Line Blocking.

Contract-first và code generation. Bạn định nghĩa API trong file .proto. Từ đó, gRPC tự sinh code cho Go, Java, Node, Python, C#... Kiểu dữ liệu được kiểm tra ngay lúc compile time, không phải runtime — giảm đáng kể bug liên quan đến type mismatch giữa các service.

Ngoài ra, gRPC hỗ trợ bốn kiểu giao tiếp native:

Unary: 1 request / 1 response, giống REST thông thường.
Server Streaming: 1 request / nhiều response, phù hợp realtime dashboard.
Client Streaming: nhiều request / 1 response, tối ưu upload file lớn.
Bidirectional Streaming: stream hai chiều độc lập, lý tưởng cho chat realtime hay game multiplayer.

HTTP/1.1 vs HTTP/2: Sự khác biệt cốt lõi

Head-of-Line Blocking trong HTTP/1.1

HTTP/1.1 có hỗ trợ Keep-Alive (giữ TCP connection sống để tái sử dụng, tránh handshake lặp lại) và Pipelining (gửi nhiều request mà không chờ response từng cái). Tuy nhiên, có một vấn đề nghiêm trọng: response bắt buộc phải trả về đúng thứ tự gửi vào. Nếu request đầu tiên chậm, mọi request phía sau đều bị chặn — dù server đã xử lý xong từ lâu. Hiện tượng này gọi là Head-of-Line (HOL) Blocking.

Điều quan trọng cần làm rõ: Keep-Alive chỉ giúp tái sử dụng TCP connection, không giải quyết được HOL Blocking. Hai thứ này thường bị nhầm lẫn với nhau. Thực tế, hầu hết browser và client đều tắt pipelining, thay vào đó mở song song nhiều connection để né vấn đề này — nhưng cách đó lại tốn thêm tài nguyên TCP.

HTTP/2 Multiplexing — giải pháp thực sự

HTTP/2 giải quyết HOL Blocking bằng khái niệm Stream. Trên cùng một TCP connection, nhiều stream chạy song song và hoàn toàn độc lập nhau. Response có thể trả về theo bất kỳ thứ tự nào — B xong trước thì trả B ngay, không cần chờ A, không cần mở nhiều connection song song.

Lưu ý: HOL Blocking ở tầng TCP vẫn còn tồn tại trong HTTP/2 (vì TCP vẫn đảm bảo thứ tự packet), nhưng ảnh hưởng thực tế ít hơn rất nhiều so với HTTP/1.1. HTTP/3 dùng QUIC để giải quyết triệt để vấn đề này.

HPACK Header Compression

HTTP/1.1 gửi lại toàn bộ header ở mỗi request — Content-Type, Authorization, Accept-Encoding... có thể lên tới 500–800 bytes mỗi lần, và lặp đi lặp lại hoàn toàn giống nhau. HTTP/2 dùng HPACK với hai cơ chế: Static Table (đánh index sẵn các header phổ biến) và Dynamic Table. Từ request thứ hai trở đi, thay vì gửi nguyên cả key của header (Ví dụ: Authorization Bearer token), chỉ cần gửi một con số index vài byte — tiết kiệm băng thông đáng kể, đặc biệt khi hàng nghìn request được gửi mỗi giây.

Tại sao gRPC phù hợp cho internal-service synchronous call?

Trong kiến trúc microservices, khi Service A gọi Service B đồng bộ, latency và độ tin cậy là sống còn. Ba lý do gRPC chiếm ưu thế ở đây.

Đầu tiên là latency thấp và băng thông tối ưu. Kết hợp protobuf binary, HTTP/2 multiplexing và HPACK giúp payload nhỏ hơn 3–10 lần và loại bỏ HOL Blocking ở tầng HTTP.

Thứ hai là streaming native. Hỗ trợ 4 kiểu giao tiếp có sẵn mà không cần thêm WebSocket hay SSE riêng — cực hữu ích cho log streaming, realtime sync hay push notification nội bộ giữa các service.

Thứ ba là tích hợp sâu với service mesh. gRPC ăn khớp tốt với Kubernetes, Envoy và Istio. Health check, retry, timeout, circuit breaker được xử lý ở tầng infrastructure — code service không phải tự lo.

Tại sao RESTful vẫn thống trị public API?

Câu trả lời nằm ở developer experience, không phải hiệu năng.

JSON đọc được bằng mắt thường. Developer có thể test ngay bằng curl, Postman, hay thậm chí fetch() trực tiếp trong browser console mà không cần cài thêm bất kỳ tool nào. Với gRPC, bạn cần cài protoc, compile file .proto, hoặc dùng grpcurl khó để tiếp cận, đặc biệt với third party developer hay người mới học lập trình.
REST còn tận dụng được toàn bộ HTTP caching infrastructure: Cache-Control, ETag, CDN cache GET requests, WAF inspect được payload. gRPC dùng HTTP/2 binary stream nên các CDN proxy truyền thống không thể cache nội dung bên trong binary frame. Ngoài ra, trình duyệt không hỗ trợ gRPC native — muốn dùng phải qua gRPC-Web và một proxy gateway ở giữa, thêm complexity không cần thiết cho public API.
Cuối cùng, ecosystem của REST đã được chuẩn hoá: OAuth2, JWT, CORS, OpenAPI spec, Swagger UI... tất cả đều sẵn sàng, tài liệu đầy đủ và developer nào cũng quen.

Kết luận

Không có công nghệ nào thắng tuyệt đối. Chọn đúng bối cảnh mới là kỹ năng của một software engineer.

Dùng REST khi cần sự đơn giản, cần hỗ trợ browser native, muốn tận dụng CDN và HTTP cache. Dùng gRPC khi giao tiếp nội bộ giữa các service cần hiệu năng cao, cần streaming hai chiều, muốn type safety ở compile time.

Trong production, pattern phổ biến nhất là hybrid: API Gateway nhận REST từ bên ngoài, sử dụng gRPC để gọi nội bộ — tận dụng ưu điểm của cả hai.

Mọi người đang dùng REST, gRPC, hay hybrid? Hãy cùng chia sẻ dưới phần bình luận nhé

Cảm ơn mọi người đã dành thời gian đọc bài viết, nếu có sai sót gì mong mọi người góp ý ạ 😁

Tài liệu tham khảo