I. Giới thiệu
gRPC không phải là công nghệ mới nhưng cũng chẳng cũ. Làm backend thì chắc hẳn bạn đã nghe đến cái này. Trong quá trình phỏng vấn thì mình được hỏi về cái này cũng kha khá, mình sẽ chia sẻ lại câu trả lời của mình với mọi người.
II. gRPC là cái quần gì?
gRPC là công nghệ được phát triển bới google (thấy chữ g đầu là hiểu ròi). RPC là viết tắt của Remote Procedure Call, là một kỹ thuật cho phép một chương trình thực thi một thủ tục (procedure) hoặc hàm trên một máy tính từ xa như thể nó là một cuộc gọi cục bộ. Mục đích chính là để ẩn đi sự phức tạp của việc giao tiếp mạng. (nôm na là giống như gọi server A gọi function trong server B).
Cơ chế hoạt động của thằng này sẽ là:
- Client gọi một hàm cục bộ (stub)
- Stub đóng gói (marshalling) các tham số
- Stub gửi message qua mạng đến server
- Server nhận, giải mã (unmarshalling) và thực thi hàm
- Kết quả được gửi ngược lại theo quy trình tương tự
Tại sao sử dụng nó
Một lý do nhất mà nó được sử dụng trong hệ thống microservice đó là hiệu suất cao. Khi so sánh giữa gRPC với REST/JSON thì nó thường nhanh hơn 5-10 lần khi nhận dữ liệu, 7-15 lần khi gửi dữ liệu.
Hiệu suất cao:
- Multiplexing: Cho phép nhiều request/response được xử lý đồng thời trên cùng một kết nối TCP.
- Header compression: Giảm overhead bằng cách nén headers.
- Server push: Server có thể chủ động gửi resources tới client mà không cần client request.
- Binary framing: Dữ liệu được đóng gói dưới dạng binary, hiệu quả hơn so với text-based của HTTP/1.1. Tại sao lại có điều này, dưới đây là lý do:
Protobuf
- Thay vì truyền tải dữ liệu dạng json thì grpc sử dung protobuf để truyền tải, protobuf là một định dạng nhị phân, nhỏ gọn hơn so với JSON text-based, giúp giảm đáng kể lưu lượng truyền tải. gRPC sử dụng Protocol Buffers (protobuf) làm cơ chế serialize dữ liệu. Protobuf nhanh hơn 3-10 lần so với JSON trong việc serialize và deserialize dữ liệu.
Http/2
- gRPC sử dụng HTTP/2 làm giao thức truyền tải, cho phép kết nối nhiều requests trên cùng một kết nối TCP, giảm độ trễ và tăng throughput. HTTP/2 là phiên bản mới của HTTP, cải thiện hiệu suất so với HTTP/1.1. gRPC sử dụng HTTP/2 làm giao thức truyền tải.
So sánh các bước giữa http/1.1 vs http/2
| Bước | http/1.1 | http/2 |
|---|---|---|
| 1.Thiết lập kết nối | Cần thiết lập nhiều kết nối TCP cho các requests đồng thời | Chỉ cần một kết nối TCP duy nhất cho nhiều requests |
| 2.Gửi requests | Gửi tuần tự, một request phải đợi response trước khi gửi request tiếp theo (head-of-line blocking). Headers được gửi dưới dạng plain text | Multiplexing: Nhiều requests có thể được gửi đồng thời trên cùng một kết nối. Header compression: Headers được nén, giảm kích thước truyền tải |
| 3.Xử lý trên server | Xử lý tuần tự các requests | Có thể xử lý đồng thời nhiều requests trên cùng một kết nối |
| 4. Gửi responses | Responses được gửi tuần tự. Không có cơ chế server push | Responses có thể được gửi không theo thứ tự. Server push: Server có thể chủ động gửi resources mà client có thể cần |
| 5. Xử lý lỗi | Lỗi trong một request có thể ảnh hưởng đến toàn bộ kết nối | Xử lý lỗi độc lập cho từng stream, không ảnh hưởng đến các streams khác trên cùng kết nối |
| 6. Độ trễ | Độ trễ cao hơn do head-of-line blocking và việc thiết lập nhiều kết nối | Giảm đáng kể độ trễ nhờ multiplexing và sử dụng một kết nối duy nhất |
| 7. Sử dụng tài nguyên | Tốn nhiều tài nguyên hơn do cần duy trì nhiều kết nối | Sử dụng tài nguyên hiệu quả hơn nhờ chia sẻ một kết nối cho nhiều requests |
Nói thêm một chút về cách bắt tay 3 bước của http/1.1 vs http/2 để xem nó có gì khác nhau nào.
- Quá trình bắt tay 3 bước (Three-way handshake): là một phần của giao thức TCP, được sử dụng để thiết lập kết nối giữa client và server. Quá trình này giống nhau cho cả HTTP/1.1 và HTTP/2, vì cả hai đều sử dụng TCP làm giao thức vận chuyển:
- SYN: Client gửi gói SYN đến server.
- SYN-ACK: Server phản hồi với gói SYN-ACK.
- ACK: Client gửi gói ACK để xác nhận.
- Thiết lập kết nối TLS: Sau khi hoàn thành bắt tay TCP, nếu sử dụng HTTPS, một quá trình bắt tay TLS sẽ diễn ra. Quá trình này cũng tương tự cho cả HTTP/1.1 và HTTP/2, nhưng có một số khác biệt nhỏ:
- Client Hello: Client gửi phiên bản TLS, cipher suites, và một số ngẫu nhiên.
- Server Hello: Server chọn phiên bản TLS, cipher suite, và gửi chứng chỉ.
- Key Exchange: Trao đổi khóa và thiết lập mã hóa phiên.
- Finished: Cả hai bên xác nhận kết nối an toàn đã được thiết lập.
Khác biệt chính giữa HTTP/1.1 và HTTP/2 trong quá trình này:
- HTTP/1.1: Sau khi hoàn thành bắt tay TLS, client có thể bắt đầu gửi HTTP requests ngay lập tức.
- HTTP/2:
- Trong quá trình bắt tay TLS, client có thể gửi một setting frame SETTINGS_ENABLE_PUSH trong Client Hello để thông báo hỗ trợ HTTP/2.
- Sau khi hoàn thành bắt tay TLS, có một bước bổ sung gọi là "Application-Layer Protocol Negotiation" (ALPN) để xác định việc sử dụng HTTP/2.
- Client gửi connection preface (một chuỗi magic string và SETTINGS frame) để khởi tạo kết nối HTTP/2.
Tối ưu hóa trong HTTP/2:
HTTP/2 có một số tối ưu hóa để giảm độ trễ trong quá trình thiết lập kết nối:
- TLS False Start: Cho phép gửi dữ liệu ứng dụng trước khi hoàn thành bắt tay TLS.
- TLS 1.3 (nếu được hỗ trợ): Giảm số lượng roundtrips cần thiết để thiết lập kết nối an toàn.
- TCP Fast Open: Cho phép gửi dữ liệu trong SYN packet, giảm một roundtrip trong quá trình bắt tay TCP.
Các tính năng chính của gRPC
Các loại giao tiếp trong gRPC:
Unary calls:
- Giống như REST API truyền thống. Client gửi một request, server trả về một response. Server streaming:
- Client gửi một request, server trả về một stream các responses. Hữu ích cho việc gửi large datasets hoặc real-time updates. Client streaming:
- Client gửi một stream các requests, server trả về một response. Phù hợp cho uploading large files hoặc long-running computations. Bi-directional streaming:
- Cả client và server đều gửi và nhận stream các messages. Ideal cho real-time communication hoặc complex workflows Cách hoạt động của streaming:
- Khi một stream được mở, nó sử dụng một kết nối HTTP/2 duy nhất.
- Mỗi message trong stream được gửi như một frame HTTP/2 riêng biệt.
- Điều này cho phép truyền tải hiệu quả và real-time mà không cần nhiều kết nối TCP.
Khi nào thì sử dụng gRPC
- Backend to backend: gRPC đặc biệt hiệu quả trong việc truyền tải dữ liệu giữa các data centers hoặc giữa các service backend.
- Microservices: gRPC rất phù hợp cho kiến trúc microservices, đặc biệt khi cần giao tiếp giữa các service với hiệu suất cao và độ trễ thấp. Đối với các hệ thống xử lý hàng triệu request mỗi giây, hiệu suất cao của gRPC là một lợi thế lớn.
- Ứng dụng real-time: Các ứng dụng chat hoặc game online có thể tận dụng khả năng streaming của gRPC để xử lý giao tiếp real-time hiệu quả.
- Hệ thống IoT: Trong các hệ thống IoT với nhiều thiết bị giới hạn tài nguyên, gRPC giúp tối ưu hóa việc truyền tải dữ liệu với độ trễ thấp.
- API Gateways: gRPC có thể được sử dụng trong API gateways để chuyển đổi giữa gRPC (backend) và REST/JSON (client), tận dụng ưu điểm của cả hai phương thức.
III. Lưu ý khi lựa chọn
- gRPC có learning curve cao hơn so với REST, thề, viết cái này quằn lắm (so với viết Restfull thường), nếu bạn thực sự có case quan trọng cần hiệu suất cao, hết cái để tối ưu thì hẵng dùng thằng này.
- Debugging có thể phức tạp hơn so với REST APIs do tính chất nhị phân của protobuf.
- Hỗ trợ trực tiếp trên trình duyệt web còn hạn chế, cần sử dụng gRPC-Web hoặc proxy để chuyển đổi.