Suốt mười một bài, chúng ta đi từ "gRPC là gì" tới những chi tiết vận hành sâu: wire format Protobuf đến từng byte, bốn kiểu RPC, tiến hoá schema, deadline, interceptor, xử lý lỗi, metadata/auth, hiệu năng streaming, load balancing, và các tính năng production. Mỗi bài kèm một phép đo thật trong go-lab. Nhưng kiến thức rời rạc không giúp bạn ra quyết định. Hai câu hỏi thực tế: dự án của tôi có nên dùng gRPC thay REST không? và nếu có, cần chuẩn bị gì trước khi lên production? Bài cuối này (phần 12/12) gộp mọi thứ thành hai công cụ: một so sánh để chọn, và một checklist để triển khai.

Khi nào dùng gRPC — và khi nào REST/GraphQL

gRPC không phải "REST nhanh hơn" để thay thế mọi nơi — nó là công cụ cho một loại bài toán cụ thể. Chọn sai công cụ gây đau khổ không đáng.

Ảnh chụp bảng so sánh nền tối khi nào dùng gRPC và khi nào REST GraphQL, gRPC mạnh cho giao tiếp service-to-service hiệu năng cao REST GraphQL hợp hơn cho API ra trình duyệt. gRPC vs REST vs GraphQL tiêu chí payload gRPC Protobuf nhị phân nhỏ REST JSON text GraphQL JSON text, contract gRPC proto bắt buộc type-safe REST ad-hoc OpenAPI GraphQL schema GraphQL, streaming gRPC 4 kiểu sẵn HTTP/2 REST phải tự xây GraphQL subscription, trình duyệt gọi thẳng gRPC không cần grpc-web REST có GraphQL có, client chọn field gRPC không REST không GraphQL có query linh hoạt, hợp nhất cho gRPC service-to-service nội bộ hiệu năng cao REST API công khai CRUD đơn giản GraphQL API nhiều client data đồ thị. Cây quyết định có nên dùng gRPC giao tiếp giữa các service nội bộ không ra trình duyệt trực tiếp nếu không API ra web mobile REST CRUD hoặc GraphQL client chọn field nếu có cần throughput cao streaming contract chặt type-safe nếu có gRPC Protobuf nhỏ cộng HTTP/2 cộng proto nếu không vài call đơn giản REST nội bộ cũng đủ gọn hơn

Hình 1: So sánh gRPC với REST và GraphQL. gRPC thắng ở payload nhỏ, contract type-safe, streaming sẵn — hợp service-to-service nội bộ; REST cho API công khai CRUD; GraphQL khi client cần chọn field linh hoạt. Cây quyết định giúp chọn đúng.

Ba điểm quyết định từ bảng:

  • gRPC toả sáng cho giao tiếp service-to-service nội bộ hiệu năng cao: payload Protobuf nhỏ (bài 1, 2: 41 vs 88 byte), contract .proto type-safe bắt buộc, streaming sẵn 4 kiểu (bài 3, 9: nhanh gấp 61× unary). Khi cả hai đầu là service của bạn và cần tốc độ/kỷ luật, gRPC là lựa chọn.
  • REST hợp hơn cho API công khai ra trình duyệt: trình duyệt gọi thẳng được (gRPC cần grpc-web proxy), dễ debug bằng mắt (JSON text), mọi công cụ hỗ trợ sẵn. Cho CRUD đơn giản và API internet-facing, REST gọn hơn.
  • GraphQL khi client cần chọn field linh hoạt: nhiều loại client (web, mobile) muốn lấy đúng dữ liệu cần, tránh over-fetch, trên dữ liệu dạng đồ thị. Đây là thứ cả gRPC lẫn REST đều không có sẵn.

Cây quyết định gói gọn: Giao tiếp giữa service nội bộ? Không (ra web/mobile) → REST hoặc GraphQL. Có → cần throughput cao/streaming/contract chặt? Có → gRPC; không (vài call đơn giản) → REST nội bộ cũng đủ.

Checklist production và số liệu đã đo

Nếu đã chọn gRPC, đây là checklist đúc kết từ 11 bài — mỗi mục là một quyết định đã được giải thích và đo:

Ảnh chụp nền tối checklist đưa gRPC lên production đúc kết 11 bài đo thật mỗi mục gắn với một bài trong sê-ri chạy qua trước khi đưa service gRPC vào production. Checklist production contract-first proto là nguồn duy nhất sinh code CI p1, field number bất biến reserved khi xoá p4, đặt deadline cho mọi call context p5, interceptor logging cộng recover panic cộng auth p6 p8, status code chuẩn cộng rich error details p7, TLS bắt buộc metadata token không tự mã hoá p8, streaming đúng chỗ dữ liệu luồng không call lẻ p3 p9, LB mức RPC client-side round-robin hoặc L7 p10, health check cho orchestrator p11, graceful shutdown khi deploy p11, reflection cho dev cân nhắc tắt ở public p11. Số liệu thật đo qua sê-ri go-lab Protobuf 41 byte vs JSON 88 byte unary p1, wire 13 byte vs JSON 46 byte rỗng 0 byte p2, 4 kiểu RPC unary server client bidi p3, schema evolution unknown field được giữ p4, deadline 100ms trả về đúng 100ms p5, interceptor recover server sống sau panic p6, error NotFound InvalidArgument cộng field viol p7, auth token sai PermissionDenied p8, streaming nhanh gấp khoảng 61 lần unary p9, round-robin 300 call chia 100 99 101 p10, health SERVING NOT_SERVING graceful stop p11

Hình 2: Bên trái — checklist production, mỗi mục trỏ về bài tương ứng. Bên phải — tổng hợp số liệu thật đo được qua sê-ri trong go-lab: kích thước, streaming, load balancing, và các hành vi vận hành.

Vài quyết định quan trọng nhất, nhắc lại ngắn gọn:

  • Contract-first (bài 1, 4): .proto là nguồn sự thật duy nhất, sinh code trong CI; field number bất biến, reserved khi xoá.
  • Deadline cho mọi call (bài 5): không call nào treo vô hạn; server dừng sớm qua ctx.Done().
  • Interceptor (bài 6, 8): logging + recover panic (server sống sau bug) + auth tập trung một chỗ.
  • TLS bắt buộc (bài 8): metadata/token không tự mã hoá — nối thẳng với kỷ luật bảo mật.
  • LB mức RPC (bài 10): client-side round-robin hoặc proxy L7 — đừng để L4 dồn hết vào một backend.
  • Health check + graceful shutdown (bài 11): để orchestrator biết service sống và deploy không rớt request.

Và các con số thật nhắc rằng gRPC đáng giá khi đúng chỗ: Protobuf nhỏ hơn JSON 2–3,5 lần, streaming nhanh gấp 61 lần nhiều unary call, round-robin chia tải đều 100/99/101. Nhưng cũng nhắc đo chứ đừng đoán — và vài phát hiện (streaming nhanh tới 61×, unknown field được giữ qua service cũ) chỉ rõ ràng khi chạy thật.

Vài sự thật cần giữ thẳng thắn

Mọi con số trong sê-ri đo trên localhost/go-lab. Chúng cho thấy bản chất cơ chế và hướng (Protobuf nhỏ hơn, streaming nhanh hơn, round-robin chia đều), nhưng giá trị tuyệt đối trên hạ tầng thật sẽ khác: round-trip mạng, TLS handshake, payload lớn hơn, nhiều client đồng thời. Dùng số của lab để quyết định kiến trúc, benchmark lại trên môi trường gần production để lấy con số dung lượng.

gRPC có cái giá về công cụ và hệ sinh thái. Payload nhị phân khó debug hơn JSON (cần grpcurl + reflection), trình duyệt không gọi thẳng được (cần grpc-web), và đội ngũ phải học Protobuf + quy trình sinh code. Với một dự án nhỏ, một team quen REST, và không có nhu cầu hiệu năng/streaming thật sự, chi phí này có thể lớn hơn lợi ích. Đây là lý do bảng so sánh ở Hình 1 bắt đầu bằng câu hỏi "bạn có thực sự cần không?".

Không phải chọn một loại cho toàn hệ thống. Thực tế phổ biến nhất là lai: gRPC cho giao tiếp giữa các service nội bộ (nơi cần tốc độ, contract chặt), và REST/GraphQL ở rìa (edge) hướng ra trình duyệt/mobile — thường qua một API gateway dịch REST ↔ gRPC. Đừng ép mọi thứ vào một giao thức; chọn đúng công cụ cho đúng ranh giới.

Ba ý mang về

  1. Chọn công cụ theo ranh giới, không theo thời thượng. gRPC cho service-to-service nội bộ hiệu năng cao (Protobuf nhỏ, contract type-safe, streaming); REST cho API công khai/CRUD; GraphQL khi client cần chọn field. Hệ thống thật thường lai — gRPC bên trong, REST/GraphQL ở rìa.
  2. Đưa gRPC lên production là một checklist, không phải một nút. Contract-first + field number bất biến, deadline mọi call, interceptor (log/recover/auth), status code chuẩn, TLS, streaming đúng chỗ, LB mức RPC, health check, graceful shutdown — mỗi mục đã được đo và giải thích; bỏ một mục thường mở một lỗ hổng.
  3. Đo chứ đừng đoán, và biết giới hạn phép đo. Sê-ri cho số thật (Protobuf 41B, streaming 61×, round-robin 100/99/101) nhưng trên localhost/go-lab — chúng dạy cơ chế, không thay benchmark trên hạ tầng thật. gRPC mạnh nhưng có giá công cụ; cân nhắc trước khi chọn.

Nguồn