Dựng một gRPC unary service từ đầu: định nghĩa protobuf, sinh mã client/server, chạy end-to-end. Đo thật trong Go 1.23: RPC gọi như hàm cục bộ, protobuf nhỏ hơn JSON khoảng 3,75 lần trên dây và marshal nhanh hơn khoảng 2 lần.
gRPC có ba kiểu stream: server stream, client stream, và bidirectional. Đo thật trong Go 1.23: cả ba chạy end-to-end, và gửi 1000 phần tử bằng một server-stream nhanh hơn 1000 lời gọi unary khoảng 25 lần với ít hơn 20 lần bộ nhớ.
Mổ xẻ cách Protocol Buffers mã hóa dữ liệu ở tầng byte trong Go 1.23: tag byte gộp số trường và wire type, varint co giãn theo giá trị, và một cạm bẫy thật: int32 âm tốn 11 byte trong khi sint32 (zigzag) chỉ 2 byte.
Protobuf gọn hơn JSON nhiều — nhưng vì sao? Bài này mổ xẻ wire format tới từng byte: mỗi field là một tag ghép field number với wire type, số nén bằng varint 7 bit. Dùng gói protowire của Go (không cần protoc) để tự mã hóa một sản phẩm, in ra 20 byte hex và giải thích từng byte là gì, rồi giải mã lại chứng minh. Cùng dữ liệu, JSON tốn 58 byte còn Protobuf chỉ 20.
Phần 3 đã thấy Protobuf gọn hơn qua từng byte. Bài này cân đầy đủ trên cùng một đơn hàng thật (nested + slice): đo kích thước lẫn tốc độ marshal/unmarshal. Kết quả đo được: Protobuf nhỏ hơn ~2 lần, và giải mã nhanh gấp ~9,7 lần JSON (283 vs 2743 ns) — lợi thế lớn nhất nằm ở giải mã, nơi JSON phải parse text và dùng reflection.
Protobuf nhỏ hơn JSON ~2 lần — ai cũng biết. Nhưng nếu bạn vốn đã gzip dữ liệu trước khi gửi thì sao? Bài này đo thật 1000 đơn hàng: JSON nén gzip xuống 11,6 lần, Protobuf chỉ 5,1 lần (vì đã gọn, ít phần lặp). Kết quả bất ngờ: JSON+gzip (33KB) không chỉ nhỏ hơn Protobuf thô (188KB) mà còn nhỏ hơn cả Protobuf+gzip — nén xóa gần hết lợi thế kích thước của Protobuf.