[Phỏng vấn Backend] gRPC là gì?

I. Giới thiệu

Là một backend thì chắc hẳn bạn đã nghe đến gRPC. Trong quá trình phỏng vấn mình cũng được hỏi về cái này khá nhiều, 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à 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à kỹ thuật cho phép chương trình thực thi procedure/function 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ư 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 là một định dạng nhị phân, giúp giảm đáng kể lưu lượng truyền tải. 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ải thiện hiệu suất so với HTTP/1.1.

So sánh các bước giữa http/1.1 vs http/2

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.

1. 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.

2. 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:

• 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.

Tham khảo

Group discord 2k+ mems: chém gió về lập trình và làm pet project cùng nhau