Đặt một load balancer thường trước gRPC là một bẫy: vì gRPC giữ một kết nối HTTP/2 lâu dài, LB mức kết nối (L4) ghim mọi request vào đúng một backend. Bài này đo thật trong go-lab: chạy 3 server, dùng client-side round-robin, gọi 300 RPC — chia gần như hoàn hảo 100/99/101 giữa ba server. Hiểu vì sao gRPC cần cân tải ở mức RPC (client-side hoặc proxy L7), không phải mức kết nối.
Một service gRPC chạy được chưa phải chạy được trong production. Bài này đo thật trong go-lab ba tính năng vận hành: health check để orchestrator biết pod sống hay chết (SERVING và NOT_SERVING đổi được), server reflection để grpcurl liệt kê service mà không cần file .proto, và graceful shutdown để khi deploy không rớt request đang chạy — GracefulStop chờ request 800ms hoàn thành nhưng từ chối request mới ngay.
Mười một bài, hàng chục phép đo thật — giờ gộp lại thành quyết định dùng được. Bài tổng kết này so gRPC với REST và GraphQL để biết khi nào chọn cái nào, một cây quyết định có nên dùng gRPC không, và một checklist đưa service gRPC lên production ánh xạ về từng bài: contract-first, field number bất biến, deadline, interceptor, status code, TLS, streaming đúng chỗ, load balancing, health check, graceful shutdown.
REST + JSON có mặt khắp nơi và dễ đọc — vậy vì sao nhiều hệ chuyển sang gRPC cho giao tiếp nội bộ? Bài này đo thật: cùng một Order, protobuf chỉ 26 byte so với JSON 70 byte (gọn hơn 63%), và một unary gRPC call đạt gần 14.000 call/s với 0,072 ms/call. Giải thích vì sao protobuf nhỏ thế, gRPC nhanh thế, và cái giá phải trả: cần .proto, codegen, và byte nhị phân không đọc được bằng mắt.
Bài trước đo được protobuf gọn hơn JSON 63% nhưng chưa nói vì sao. Bài này mổ xẻ từng byte: serialize {id:1001, name:abc, big:7} ra 11 byte rồi giải mã thủ công — 08 là tag field 1, e907 là varint 1001, a001 là tag field 20 tốn 2 byte. Đo thật varint co giãn theo giá trị (id 5 tốn 2 byte, id 10 tỷ tốn 6 byte), và vì sao wire chỉ chứa số field nên đổi tên không phá nhưng đổi field number thì phá.
REST chỉ có một mô hình: request rồi response. gRPC có bốn, mở khoá bằng từ khoá stream trong .proto. Bài này chạy thật cả bốn trong một service: unary (1 req→1 resp), server streaming (1 req→5 resp), client streaming (4 req→1 resp tổng đúng 500), và bidirectional (3 msg↔3 msg xen kẽ). Mỗi kiểu hợp một dạng dữ liệu khác nhau, và chọn đúng kiểu là một quyết định thiết kế API thật.