gRPC (framework RPC của Google)

1. Tổng quan

A. Định nghĩa

gRPC là framework gọi thủ tục từ xa (RPC, Remote Procedure Call) hiệu năng cao cho phép các tiến trình·máy chủ khác nhau gọi hàm ở xa như thể gọi hàm cục bộ. Giao diện được định nghĩa bằng IDL trung lập ngôn ngữ gọi là Protocol Buffers (protobuf), mã client·server được sinh tự động từ định nghĩa đó, và việc truyền tải được thực hiện bằng tuần tự hóa nhị phân (binary) trên HTTP/2. Năm 2015, Google thiết kế lại hệ thống RPC nội bộ (Stubby) và công bố ra ngoài, hiện nay do CNCF (Cloud Native Computing Foundation) quản lý.

Ý tưởng cốt lõi của gRPC là hồi sinh truyền thống RPC “xử lý lời gọi mạng như lời gọi hàm cục bộ” trên nền hạ tầng hiện đại. Trong khi REST hướng tài nguyên — “biểu diễn tài nguyên (resource) bằng URL và thao tác bằng động từ HTTP” — thì gRPC hướng hành vi (phương thức) — “sẽ làm gì”. Nhà phát triển khai báo trước hợp đồng dịch vụ như GetUser(UserRequest) returns (UserReply), và công cụ sinh stub cho các ngôn ngữ ở cả hai phía (Go·Java·Python·C++, v.v.) từ hợp đồng đó. Kết quả là client chỉ cần gọi phương thức đã được sinh mà không cần biết chi tiết mạng·tuần tự hóa.

Vì vậy, gRPC không nên được hiểu là một giao thức truyền thông đơn thuần mà là một đặc tả tích hợp gói gọn IDL (hợp đồng)·sinh mã·tuần tự hóa·truyền tải·xác thực thành một. Tệp .proto trở thành nguồn sự thật duy nhất (single source of truth) của API, cho phép các microservice đa ngôn ngữ chia sẻ hợp đồng này và được phát triển·triển khai độc lập.

B. Bối cảnh xuất hiện và sự cần thiết

gRPC ra đời từ nhận thức vấn đề cụ thể là sự lan rộng của kiến trúc microservice (MSA) quy mô lớn. Trong môi trường hàng trăm~hàng nghìn dịch vụ gọi nhau với số lần khổng lồ mỗi giây, JSON/REST dạng văn bản gây ra ba loại chi phí kinh niên. Thứ nhất là chi phí tuần tự hóa·payload: JSON dễ đọc cho con người nhưng tên trường lặp lại ở mỗi thông điệp và phân tích cú pháp chậm. Thứ hai là chi phí kết nối: HTTP/1.1 xử lý yêu cầu-phản hồi tuần tự trên một kết nối nên độ trễ khứ hồi (round-trip) tích lũy trong truyền thông nội bộ khối lượng lớn. Thứ ba là sự mong manh của hợp đồng: JSON của REST ràng buộc schema yếu nên lỗi chính tả tên trường·không khớp kiểu chỉ lộ ra khi chạy.

gRPC đối mặt trực diện bằng cách ① giảm mạnh payload bằng tuần tự hóa nhị phân Protobuf, ② xử lý đồng thời nhiều lời gọi bằng đa hợp (multiplexing) trên một kết nối duy nhất của HTTP/2, ③ phát hiện không khớp hợp đồng ngay tại thời điểm biên dịch bằng IDL kiểu mạnh. Đặc biệt, gRPC hỗ trợ streaming như một chức năng hạng nhất ở cấp giao thức, biểu đạt tự nhiên các mẫu mà REST khó xử lý như luồng dữ liệu thời gian thực·truyền thông hai chiều.

Tóm lại, gRPC đồng thời nhắm tới bốn nhu cầu: ① truyền thông nội bộ độ trễ thấp·thông lượng cao, ② tích hợp dựa trên hợp đồng giữa các dịch vụ đa ngôn ngữ (polyglot), ③ đa dạng mô hình gọi bao gồm streaming, ④ năng suất phát triển nhờ sinh mã. Tuy nhiên, do là định dạng nhị phân nên con người khó đọc trực tiếp và khó gọi trực tiếp từ trình duyệt, nên việc áp dụng dựa trên tiền đề phán đoán bối cảnh sử dụng (nội bộ vs công khai ra ngoài).

2. Kiến trúc gRPC và luồng gọi

Hệ thống gRPC có cấu trúc xử lý hợp đồng .proto bằng trình biên dịch (protoc) để sinh stub phía client và skeleton phía server, và khi chạy, hai thành phần này được kết nối qua kênh HTTP/2 để trao đổi thông điệp. Client gọi phương thức của stub, runtime gRPC tuần tự hóa đối số thành Protobuf và truyền đi dưới dạng frame HTTP/2, còn server giải tuần tự hóa để thực thi phần hiện thực thực tế rồi gửi phản hồi về theo cùng đường đó.

flowchart LR
    subgraph CLIENT["Client (ngôn ngữ bất kỳ)"]
      APP1["Mã ứng dụng"] --> STUB["Stub được sinh (Stub)"]
    end
    STUB -->|"Tuần tự hóa Protobuf + HTTP/2"| SRV
    subgraph SRV["gRPC server"]
      SKEL["Skeleton phía server"] --> IMPL["Hiện thực dịch vụ (logic nghiệp vụ)"]
      IMPL --> DB[("Kho dữ liệu")]
    end
    PROTO["Hợp đồng (.proto)"] -->|"protoc sinh mã"| STUB
    PROTO -->|"protoc sinh mã"| SKEL

Yếu tố then chốt của cấu trúc trên là hợp đồng (.proto) đồng thời quy định mã của cả hai phía. Dù client và server khác ngôn ngữ·khác nhóm, vì dùng chung .proto nên các thay đổi hợp đồng như thêm trường·đổi kiểu được phản ánh nhất quán cho cả hai phía ở bước sinh mã. Điều này giảm về mặt cấu trúc căn bệnh kinh niên trong vận hành API là “tài liệu và hiện thực không khớp nhau”.

Lời gọi gRPC phụ thuộc mạnh vào HTTP/2 ở tầng truyền tải. Những gì HTTP/2 cung cấp — ① đa hợp stream chở đồng thời nhiều yêu cầu trên một kết nối TCP, ② nén header (HPACK), ③ server push·điều khiển luồng — là nền tảng giúp gRPC đạt độ trễ thấp và streaming. Bảng dưới đây so sánh mang tính khái niệm các đặc tính truyền tải·tuần tự hóa so với REST (HTTP/1.1·JSON), nhưng chênh lệch hiệu năng thực tế thay đổi tùy kích thước thông điệp·ngôn ngữ·mạng, nên cần hiểu là xu hướng chứ không phải con số tuyệt đối.

3. Các thành phần cốt lõi — Protobuf·hợp đồng dịch vụ·4 mô hình gọi

Bộ khung của gRPC là định nghĩa thông điệp·dịch vụ kiểu mạnh được mô tả bằng Protocol Buffers. Trong tệp .proto, khai báo thông điệp (cấu trúc dữ liệu) và dịch vụ (tập phương thức có thể gọi), và mỗi trường được gán một số hiệu trường (tag). Số hiệu này là khóa của mã hóa nhị phân, nên quy tắc cốt lõi của tương thích ngược là không tái sử dụng số hiệu đã triển khai. Ví dụ định nghĩa như sau.

syntax = "proto3";
message UserRequest { int32 id = 1; }
message UserReply { int32 id = 1; string name = 2; }
service UserService {
  rpc GetUser(UserRequest) returns (UserReply);
}

Ở đây số hiệu trường (1, 2) được giữ nguyên dù thứ tự·tên thay đổi, nên thay đổi mang tính tiến hóa như thêm trường mới với số hiệu lớn không làm hỏng client hiện có. “Tương thích ngược dựa trên số hiệu” này là cơ chế cốt lõi giúp việc tiến hóa hợp đồng an toàn hơn so với JSON của REST. Ngược lại, nếu tái sử dụng số hiệu trường hoặc đổi kiểu thì cách diễn giải nhị phân bị lệch và có thể xảy ra hỏng dữ liệu âm thầm (silent), nên nhất thiết cần kỷ luật thay đổi .proto ở cấp tổ chức.

gRPC quy định bốn mô hình gọi, và đây là điểm khác biệt của gRPC khi nâng streaming lên thành chức năng hạng nhất của giao thức. Unary (đơn nguyên) là 1 yêu cầu-1 phản hồi, tương tự REST. Server streaming (streaming phía server) là với 1 yêu cầu, server gửi tuần tự nhiều phản hồi, dùng cho truy vấn khối lượng lớn·đăng ký nhận tin. Client streaming (streaming phía client) là client gửi nhiều thông điệp và server phản hồi một lần, phù hợp cho tải lên·tổng hợp. Bidirectional streaming (streaming hai chiều) là hai phía trao đổi stream độc lập, dùng cho dạng hội thoại như chat·cộng tác thời gian thực.

sequenceDiagram
    participant C as Client
    participant S as Server
    Note over C,S: Unary (đơn nguyên)
    C->>S: 1 yêu cầu
    S-->>C: 1 phản hồi
    Note over C,S: Server streaming
    C->>S: 1 yêu cầu
    S-->>C: Stream phản hồi (N mục)
    Note over C,S: Bidirectional streaming
    C->>S: Stream yêu cầu (N mục)
    S-->>C: Stream phản hồi (M mục)

4. So sánh và áp dụng — Phân vai với REST·GraphQL như thế nào

Tiêu chí phân biệt gRPC với REST·GraphQL là bối cảnh sử dụng “ai gọi·gọi từ đâu”. Thế mạnh của gRPC (hiệu quả nhị phân·kiểu mạnh·streaming) được phát huy tối đa trong truyền thông nội bộ giữa các dịch vụ, nhưng do là định dạng nhị phân nên con người khó đọc trực tiếp bằng công cụ phát triển của trình duyệt, và trình duyệt không xử lý trực tiếp được frame HTTP/2 nên phải đi qua tầng proxy gọi là gRPC-Web. Vì vậy mẫu chủ đạo trong thực tiễn là phân vai “API công khai ra ngoài dùng REST/GraphQL, giữa các microservice nội bộ dùng gRPC”.

Lý do căn bản tạo nên khác biệt là mục tiêu tối ưu hóa khác nhau. REST ưu tiên tính phổ quát và khả năng đọc (hệ sinh thái web·caching·sự hiểu của con người), GraphQL ưu tiên tổ hợp dữ liệu do client chủ đạo (giải quyết over/under-fetching), còn gRPC ưu tiên độ trễ thấp·thông lượng cao giữa máy với máy. Do đó không có cái nào tuyệt đối vượt trội, mà phải chọn theo tính chất lưu lượng (nội bộ/bên ngoài), bên tiêu thụ (con người/máy·trình duyệt/server) và mẫu dữ liệu (đơn lẻ/stream). Bảng dưới đây tóm tắt phán đoán này.

Về trường hợp áp dụng cụ thể, các doanh nghiệp quy mô lớn như Netflix·Google xử lý lời gọi giữa hàng nghìn dịch vụ nội bộ bằng gRPC để giảm độ trễ và băng thông, đồng thời kết hợp với service mesh (Istio·Linkerd) để bổ sung quan sát·bảo mật·điều khiển lưu lượng. Ngoài ra, việc chính Kubernetes sử dụng rộng rãi truyền thông họ gRPC cho giao tiếp giữa các thành phần control plane và truy cập kho trạng thái (etcd) cho thấy gRPC đã trở thành phương tiện truyền thông nội bộ chuẩn trên thực tế của hạ tầng cloud native.

5. Chuyên sâu — Xử lý lỗi·xác thực·gRPC-Web và xu hướng mới

gRPC biểu đạt thành công/thất bại không bằng mã trạng thái HTTP mà bằng mã trạng thái riêng (status code). Vì trả về các mã chuẩn như OK, NOT_FOUND, INVALID_ARGUMENT, DEADLINE_EXCEEDED, UNAVAILABLE kèm thông điệp·chi tiết (detail), các client đa ngôn ngữ có thể xử lý lỗi một cách nhất quán. Ngoài ra, bằng cách lan truyền (propagation) deadline/timeout theo từng lời gọi để các dịch vụ hạ nguồn kế thừa thời điểm hạn chót do lời gọi thượng nguồn đặt ra, gRPC ngăn chặn về mặt cấu trúc việc chờ vô hạn và cạn kiệt tài nguyên trong chuỗi gọi quy mô lớn. Về bảo mật, gRPC lấy TLS làm tiền đề mặc định để mã hóa kênh, và kết hợp theo chuẩn việc xác thực·phân quyền·ghi log thông qua token·TLS hai chiều (mTLS)·interceptor.

gRPC-Web để vượt qua ràng buộc của trình duyệt là phương thức trong đó proxy (Envoy, v.v.) chuyển đổi yêu cầu tương thích HTTP/1.1 do trình duyệt gửi thành gRPC. Tuy nhiên do ràng buộc của trình duyệt, streaming phía client·streaming hai chiều có thể không được hỗ trợ đầy đủ, nên cấu hình phân tầng phổ biến là dùng REST/GraphQL cho frontend và dùng gRPC ở nội bộ sau gateway frontend-backend. Liên quan đến điều này, chiến lược giao diện kép dùng công cụ gateway để đồng thời công khai REST (JSON) và gRPC từ một .proto duy nhất cũng được dùng rộng rãi.

Về xu hướng mới, nổi bật là dòng chảy bảo đảm khả năng quan sát (tracing·metric) bên ngoài mã ứng dụng thông qua kết hợp với service mesh, cân bằng tải phía client thực hiện phân tải ở phía client, và sự kết hợp với xử lý sự kiện phi trạng thái. Tuy nhiên, các chức năng·phiên bản·chi tiết hiện thực này liên tục tiến hóa, nên khi áp dụng thực tế nên xác nhận phạm vi hỗ trợ bằng tài liệu chính thức tại thời điểm đó.

6. Các điểm cần lưu ý và hàm ý

Từ góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer), việc áp dụng gRPC cần đánh giá đồng thời các chiến lược·đánh đổi sau.

• Làm rõ ranh giới áp dụng: gRPC không phải giải pháp thay thế vạn năng mà có vùng thế mạnh rõ ràng là “truyền thông độ trễ thấp giữa các dịch vụ nội bộ”. Nếu cố thống nhất cả API công khai ra ngoài·API cho trình duyệt tiêu thụ bằng gRPC, tổng chi phí sở hữu có thể tăng lên do proxy gRPC-Web và giảm khả năng đọc. Thực tế nhất là chốt tiêu chuẩn phân tầng bên ngoài dùng REST/GraphQL, nội bộ dùng gRPC làm nguyên tắc kiến trúc.

• Quản trị hợp đồng (.proto): Phải kỷ luật hóa việc thay đổi .proto ở cấp tổ chức như cấm tái sử dụng số hiệu trường, quy tắc tương thích ngược, kho schema (schema registry)·kiểm chứng CI. Vì hợp đồng chính là tài sản dùng chung của nhiều nhóm, mấu chốt của vận hành ổn định là nội tại hóa việc review thay đổi, chính sách phiên bản và kiểm thử tương thích vào pipeline.

• Khả năng quan sát·mức trưởng thành vận hành: Giao thức nhị phân khó để con người gỡ lỗi bằng mắt. Phải bảo đảm truy vết phân tán (OpenTelemetry)·ghi log có cấu trúc·metric bằng interceptor/service mesh, và chuẩn hóa chính sách deadline·retry·circuit breaker thì mới kiểm soát được sự lan truyền sự cố trong chuỗi gọi quy mô lớn.

• Năng lực tổ chức và đường cong học tập: Rào cản gia nhập như sinh mã·toolchain·hiểu biết về HTTP/2 cao hơn REST. Kiểm chứng bằng dịch vụ thí điểm, song hành scaffolding·template chuẩn nội bộ và đào tạo để áp dụng dần dần sẽ giảm rủi ro.

• Triển vọng và công nghệ liên kết: gRPC đã được thiết lập như tiêu chuẩn nội bộ trên thực tế của cloud native (Kubernetes·service mesh), và xu hướng kết hợp với khả năng quan sát·zero trust (mTLS)·kiến trúc hướng sự kiện đang mở rộng. Thiết kế hấp thụ chuyển đổi giao thức (gRPC↔REST) ở tầng API gateway·BFF đang trở thành giải pháp thực tiễn đồng thời thỏa mãn cả bên tiêu thụ là con người và máy.

Tóm tắt một câu: gRPC là framework RPC kết hợp hợp đồng kiểu mạnh .proto và sinh mã, tuần tự hóa nhị phân Protobuf, đa hợp·streaming HTTP/2 để hiện thực truyền thông độ trễ thấp·thông lượng cao giữa các microservice, phân vai với REST/GraphQL dùng cho công khai ra ngoài và tạo thành trụ cột của chiến lược API phân tầng “nội bộ dùng gRPC”.