1. Giới thiệu
gRPC là sự kết hợp của Protocol Buffers và HTTP/2 được phát triển bởi Google. gRPC nhẹ, nhanh và cung cấp hiệu năng tốt hơn so với sử dụng XML hoặc Json. gRPC cho phép định nghĩa cấu trúc của data dưới dạng file proto và nó tự động generate ra file sử dụng để giao tiếp với ngôn ngữ mà bạn sử dụng.
2. Các ngôn ngữ gRPC hỗ trợ:
- C++: follow the instructions under the
src/cpp
directory - C#: NuGet package
Grpc
- Dart: pub package
grpc
- Go:
go get google.golang.org/grpc
- Java: Use JARs from Maven Central Repository
- Kotlin: Use JARs from Maven Central Repository
- Node:
npm install grpc
- Objective-C: Add
gRPC-ProtoRPC
dependency to podspec - PHP:
pecl install grpc
- Python:
pip install grpcio
- Ruby:
gem install grpc
- WebJS: follow the grpc-web instructions
3. Tại sao cần gRPC
RPC có thể được xem như 1 giao thức request-response thông thường, tuy nhiên nó được dùng cho việc giao tiếp giữa các server với nhau (server – server) nhiều hơn là client – server. Việc này có ý nghĩa rất quan trọng vì trong các hệ thống phân tán (distributed system), application code ở nheiefu server hơn là 1 server. Ví dụ thường thấy nhất chính là kiến trúc Microservices.
Điều này nghĩa là: một request phía client có thể sẽ phải cần nhiều service chạy trên các server này để tổng hợp thông tin rồi mới response cho client. Sự liên lạc giữa các server lúc này sẽ là vấn đề mà trước đó tất cả service chạy trên 1 server thì khỏe re, vì local call nên chẳng ngại gì cả. Chính xác là khi đó, khi một server muốn “nói chuyện” với server khác sẽ cần phải encode data (JSON, XML), phía nhận cũng phải làm công việc ngược lại là decode data mới hiểu thằng kia nói gì với mình rồi lại phải encode lại tiếp. Việc này tiêu tốn khá nhiều tài nguyên xử lý (CPU) mà lẽ ra chỉ cần làm ở bước đầu và cuối (đầu nhận và trả về cuối cùng).
Tối ưu cho việc “giao tieeps” giữa các server là lí do gRPC ra đời.
Để giải bài toán trên, gRPC đã sử dụng binary để truyền đi thay vì phải encode chúng chúng thành các ngôn ngữ trung gian JSON/XML. Việc này rõ ràng đã làm tăng tốc giao tiếp các servers lên rất nhiều, giảm overhead cho CPUs. Google cũng “tiện tay” làm luôn cả protobuf (protocol buffers), đây là ngôn ngữ mà gRPC dùng như một default serialization format. Implement phần này thật sự phải là tay to lắm nên Google sử dụng protobuf như một script trung gian để generate phần hardcore cho các dev ở các ngôn ngữ phổ biến như: C++, C#, Go, Java, Python.
Thứ giúp gRPC giao tiếp binary ngon vậy chính là HTTP/2, đây vốn là giao thức có rất nhiều cải tiến so với HTTP/1.1. Bản thân HTTP/2 cũng được coi như là sự thay thế cho SPDY, giao thức mà cũng chính Google phát triển, open source vào 2012 và ngừng hỗ trợ vào 2015 (HTTP/2 có implement và thay thế rồi).
4. Phương thức gRPC
gRPC cho phép định nghĩa 4 loại phương thức của dịch vụ:
1) Unary RPCs khi client gửi một yêu cầu đến server và nhận về 1 phản hồi giống như 1 cuộc gọi phương thức bình thường.
2) Server streaming RPCs khi client gửi 1 yêu cầu đến server và nhận về 1 stream để đọc trình tự của thông điệp trả về.
3) Client streaming RPCs khi client ghi 1 chuỗi các thông điệp gửi đến server, stream được sử dụng. Client sẽ hoàn thành việc gửi thông điệp của nó, sau đó chờ server phản hồi. gRPC đảm bảo đặt hàng tin nhắn trong 1 cuộc gọi RPC riêng lẻ
4) Bidirectional streaming RPCs khi cả 2 gửi 1 chuỗi các thông điệp sử dụng đọc – viết stream. Hai luồng hoạt động độc lập, để client và server có thể đọc và viết theo bất kỳ thứ tự nào họ muốn: ví dụ, server có thể đợi để nhận tất cả các thông điệp của client trước khi viết phản hồi hoặc có thể đọc thông điệp sau đó viết tin nhắn hoặc 1 số kết hợp đọc và viết khác. Thứ tự của thông điệp trong mỗi luồng được bảo tồn.