Mười một phần qua, ta đã đi từ "vì sao gRPC" tới reflection — mỗi bài một demo chạy thật trên Go, mỗi kết luận một con số đo được. Nhưng gRPC không phải mười một tính năng rời rạc; chúng ghép thành một bộ công cụ để xây giao tiếp service-to-service chín chắn. Bài cuối này (phần 12, khép lại loạt gRPC nâng cao) làm hai việc: chạy một service capstone gộp nhiều mảnh lại để thấy chúng làm việc cùng nhau, và đúc kết toàn bộ thành một bảng số liệu thật cộng khung quyết định khi nào dùng gRPC, khi nào dùng REST.

Các mảnh ghép lại: một service hoàn chỉnh

Một service gRPC production không dùng từng tính năng riêng lẻ — nó gộp chúng: interceptor bọc mọi call để log/đo/auth (bài 6), handler kiểm deadline để không treo (bài 7), và trả lỗi bằng status code chuẩn (bài 8). Mình chạy thật một service như vậy:

g := grpc.NewServer(grpc.UnaryInterceptor(logI))   // bài 6: interceptor
func (s *srv) Get(ctx, r) (*Resp, error) {
    if r.Id <= 0 { return nil, status.Error(codes.InvalidArgument, ...) }  // bài 8: error model
    select {
    case <-time.After(20*ms): return &Resp{...}, nil
    case <-ctx.Done(): return nil, ctx.Err()       // bài 7: deadline
    }
}

Ảnh chụp nền tối capstone và khung quyết định gRPC vs REST output thật 1 service gộp interceptor deadline error, kết quả capstone thật 3 pattern trong 1 service LOG demo.API Get 20.9ms OK interceptor đo bài 6 call id 7 OK data ok call id -1 InvalidArgument error model bài 8 call deadline 5ms handler 20ms DeadlineExceeded bài 7, khung quyết định gRPC hay REST service-to-service nội bộ throughput cao gRPC API công khai client là trình duyệt REST JSON cần streaming realtime 2 chiều gRPC cần debug bằng mắt ai cũng gọi được REST nhiều ngôn ngữ cần type-safe contract gRPC, gRPC không tốt hơn REST nó đánh đổi khác hợp bài toán khác

Hình 1: Capstone thật — một service gộp interceptor (log mỗi call), deadline (huỷ khi quá hạn) và error model (InvalidArgument). Output: id=7 → OK, id=-1 → InvalidArgument, deadline 5ms (handler 20ms) → DeadlineExceeded. Bên dưới là khung quyết định gRPC vs REST.

Capstone chạy thật cho ba kết quả cùng lúc: interceptor log mọi call với thời gian và code; id=7 → OK; id=-1 → InvalidArgument; call với deadline 5ms (handler cần 20ms) → DeadlineExceeded. Ba pattern từ ba bài khác nhau phối hợp trong một service — đây mới là cách gRPC được dùng thật, không phải từng tính năng cô lập.

Toàn bộ loạt bài: những con số đo thật

Như mọi loạt trước, không con số nào bịa — mỗi cái đo trên go-lab:

Ảnh chụp bảng tổng kết 12 phần toàn số đo thật trên go-lab protoc grpc-go không bịa, 01 vì sao gRPC protobuf 26 byte vs JSON 70 byte giảm 63 phần trăm unary 14000 call mỗi giây, 02 wire format giải mã byte tag field dịch 3 hoặc type varint field lớn hơn 15 tốn 2 byte tag, 03 bốn kiểu RPC unary 1 1 server 1 5 client 4 1 tổng 500 bidi 3 3, 04 server streaming item đầu 58ms vs unary 529ms 9 lần tổng gần bằng, 05 client bidi upload 5 chunk 7936 byte bidi bình phương xen kẽ, 06 interceptor log đo mọi call auth chặn Secure, 07 deadline huỷ sau 101ms không chờ 500ms server dừng sớm, 08 error model InvalidArgument details field id NotFound retry theo code, 09 retry Unavailable tự retry server gọi thật 3 lần InvalidArgument 1 lần, 10 load balancing pick_first 300 0 0 vs round_robin 100 101 99, 11 reflection grpcurl list describe call không cần proto, 12 tổng kết capstone, checklist dùng gRPC luôn đặt deadline dùng status code chuẩn interceptor retry chỉ code tạm thời round_robin resolver động chỉ thêm field tắt reflection prod

Hình 2: Tổng kết 12 phần — mọi con số đo thật trên go-lab. Từ protobuf 26 vs JSON 70 byte, server streaming item đầu 58ms, deadline huỷ 101ms, retry 3 lần gọi, round_robin 100/101/99, tới reflection. Bên dưới là checklist dùng gRPC.

Khung quyết định: gRPC hay REST?

Câu hỏi thực tế nhất không phải "gRPC có tốt không" mà "khi nào dùng gRPC, khi nào dùng REST". Dựa trên toàn loạt:

  • Service-to-service nội bộ, throughput cao → gRPC. protobuf gọn (63% ít byte, bài 1), HTTP/2 multiplexing, type-safe. Đây là điểm mạnh nhất của gRPC.
  • API công khai, client là trình duyệt → REST/JSON. REST dễ tiếp cận, debug bằng curl, mọi nơi hỗ trợ; gRPC khó dùng từ trình duyệt (cần gRPC-Web + proxy) và lộ rào cản codegen cho bên thứ ba.
  • Cần streaming / realtime hai chiều → gRPC. Bốn kiểu RPC (bài 3-5), đặc biệt bidirectional, làm được thứ REST cần WebSocket riêng.
  • Cần debug bằng mắt, ai cũng gọi được → REST. Dù reflection (bài 11) giúp nhiều, JSON text vẫn dễ đọc hơn protobuf nhị phân.
  • Nhiều ngôn ngữ, cần contract type-safe → gRPC. .proto sinh client cho mọi ngôn ngữ, bắt lỗi kiểu lúc compile.

Nguyên tắc bao trùm: gRPC không "tốt hơn" REST — nó đánh đổi khác, hợp bài toán khác. gRPC đổi tính dễ-đọc-dễ-tiếp-cận lấy hiệu năng, type-safety và streaming. Chọn theo vị trí trong kiến trúc, không theo độ hot.

Checklist dùng gRPC

Gộp bài học thành việc cần làm:

  1. Luôn đặt deadline cho mọi call (bài 7) — không có deadline là nguy cơ treo vô hạn và cascading failure.
  2. Dùng status code chuẩn + details (bài 8) — để client xử lý lỗi tự động, không parse text; không nhét mọi lỗi vào Internal.
  3. Interceptor cho log/metric/auth (bài 6) — viết một lần, áp mọi RPC; nhớ làm cả cho streaming.
  4. Retry chỉ code tạm thời + idempotent (bài 9) — chỉ retry Unavailable, và chỉ cho thao tác idempotent (hoặc dùng idempotency key).
  5. round_robin + resolver động (bài 10) — mặc định pick_first không rải tải; cần round_robin và resolver cập nhật theo backend.
  6. Chỉ thêm field, field number là hợp đồng (bài 2) — đổi tên an toàn, đổi field number phá vỡ.
  7. Tắt reflection ở production nhạy cảm (bài 11) — nó lộ toàn bộ API surface.

Đánh đổi cần cân nhắc

gRPC là đầu tư về công cụ và kỹ năng, không miễn phí. Dùng gRPC nghĩa là thêm .proto, codegen vào build, học status code, interceptor, service config — một đường cong học tập thật. Với một API nhỏ, REST + JSON đơn giản hơn nhiều và đủ dùng. gRPC đáng khi quy mô và yêu cầu (nhiều service, throughput cao, nhiều ngôn ngữ, streaming) vượt chi phí đó. Đừng chọn gRPC cho một endpoint CRUD đơn lẻ chỉ vì nó "nhanh hơn" — chi phí phức tạp sẽ không bõ.

Hệ sinh thái gRPC đòi hỏi hạ tầng hiểu HTTP/2. Nhiều công cụ quen thuộc (L4 load balancer, một số API gateway, log/trace tooling cho REST) không hiểu gRPC đúng cách (bài 10). Dùng gRPC thường kéo theo Envoy/proxy L7, service mesh, hoặc công cụ chuyên biệt. Đây là chi phí vận hành ẩn — tính vào quyết định, đừng chỉ nhìn code.

Phần lớn giá trị đến từ vài tính năng nền. Trong 11 kỹ thuật, bốn cái — protobuf + codegen, deadline, error code, interceptor — mang lại phần lớn giá trị cho đa số service. Streaming nâng cao, load balancing client-side, reflection là công cụ mạnh nhưng chỉ cần khi bài toán thật đòi hỏi. Bắt đầu với nền tảng vững (unary + deadline + error + interceptor), thêm phần còn lại khi cần — đừng dùng mọi tính năng chỉ vì có.

Ba ý mang về

  1. Các tính năng gRPC ghép thành một service hoàn chỉnh: đo thật capstone gộp interceptor (log mỗi call), deadline (DeadlineExceeded khi quá hạn) và error model (InvalidArgument) cùng chạy — gRPC được dùng thật bằng cách phối hợp, không phải từng tính năng cô lập.
  2. Khung quyết định dựa trên vị trí kiến trúc: service-to-service nội bộ/throughput cao/streaming/nhiều ngôn ngữ → gRPC; API công khai/trình duyệt/cần debug bằng mắt → REST — gRPC không tốt hơn, nó đánh đổi dễ-đọc lấy hiệu năng + type-safety.
  3. Bắt đầu với nền tảng, thêm nâng cao khi cần: bốn mảnh nền (protobuf, deadline, error code, interceptor) mang phần lớn giá trị; streaming/LB/reflection chỉ dùng khi bài toán đòi hỏi; và gRPC là đầu tư về công cụ + hạ tầng HTTP/2, chỉ bõ khi quy mô vượt chi phí.

Nguồn