Nhấp một ngụm cà phê, viết thêm một dòng code
Cà Phê & Code là blog dành cho những người yêu công nghệ và lập trình. Nơi chia sẻ kiến thức coding, công cụ hữu ích, xu hướng công nghệ, kinh nghiệm phát triển phần mềm và những câu chuyện phía sau màn hình — tất cả được kể theo cách gần gũi, dễ hiểu, như một cuộc trò chuyện bên tách cà phê.
HTTPS an toàn nhưng không miễn phí: sau bắt tay TCP, TLS thêm một bắt tay riêng tốn CPU (toán khóa công khai) và một RTT. Bài này chạy thật trong Go với self-signed cert: TLS full handshake tốn 391µs so với TCP thường 23µs — thêm ~368µs, phần lớn là CPU. Session resumption (500/500 kết nối resumed) bỏ phần đắt; giải thích vì sao trên localhost nó chỉ nhanh 1,1 lần còn trên mạng thực tiết kiệm cả một RTT.
Bài 1 nói gRPC khó debug vì byte nhị phân và cần codegen. Reflection gỡ đúng nỗi đau đó. Bài này chạy thật: server bật reflection một dòng, rồi grpcurl — curl cho gRPC — liệt kê service, xem schema message, và gọi GetOrder nhận về JSON, tất cả KHÔNG cần file .proto trên máy. Server tự khai schema lúc chạy. Công cụ debug mạnh nhất cho gRPC — nhưng nên tắt ở production nhạy cảm vì nó lộ toàn bộ API.
Mười một phần qua ta mổ xẻ gRPC bằng demo đo thật. Bài cuối ghép lại: một service capstone gộp interceptor, deadline và error model cùng chạy; bảng tổng hợp mọi con số đo thật xuyên 12 bài (protobuf 26 vs JSON 70 byte, deadline huỷ 101ms, round_robin 100/101/99...); và khung quyết định gRPC vs REST — gRPC không tốt hơn, nó đánh đổi khác, hợp bài toán khác.
Cache nghe như giải pháp vạn năng cho hiệu năng, nhưng nhanh hơn bao nhiêu và khi nào mới đáng? Bài này đo thật: một query gộp 100.000 dòng trên PostgreSQL tốn 8.2ms mỗi lần tính; cache kết quả vào Redis thì GET chỉ 0.028ms (pipelined) hoặc 0.26ms (round-trip đơn) — nhanh hơn 30 đến 300 lần. Nhưng nói thẳng: với query đơn giản lấy một dòng theo khoá chính, chênh lệch nhỏ hơn nhiều. Cache thắng rõ khi tính toán gốc đắt.
gRPC giữ kết nối lâu dài, nên load balancer tầng kết nối không rải được từng request — gRPC tự cân bằng ở phía client. Bài này chạy thật với 3 server: chính sách mặc định pick_first dồn cả 300 request vào một server (2 server ngồi không); đổi sang round_robin thì 300 request rải đều 100/101/99. Đo bằng counter thật mỗi server. Client biết danh sách backend qua resolver và tự chọn — không cần proxy ở giữa.
Viết vòng lặp retry bằng tay ở từng chỗ gọi là lặp code và dễ sai. gRPC có retry policy khai bằng cấu hình. Bài này chạy thật: server fail 2 lần đầu với Unavailable rồi OK — client cấu hình retry tự thử lại và nhận thành công sau đúng 3 lần gọi server (đo bằng counter thật), với backoff tăng dần. Nhưng lỗi InvalidArgument thì không retry: server chỉ bị gọi 1 lần, vì gọi lại input sai vẫn sai.