Giới thiệu về gRPC
gRPC là gì ?
-
link: https://200lab.io/blog/grpc-la-gi/
-
gRPC là một framework RPC mã nguồn mở, hiện đại hiệu năng cao mà có thể chạy trên bất kì môi trường nào. Framework này được Google phát triển vào năm 2015, vào năm 2016 thì đưa vào chính thức. Đây được cho là mọt thế hệ tiếp theo của RPC ( Remote Procedure Calls ) đặc biệt là trong mô hình Microservices.
Tại sao cần gRPC ?
-
Dưới thời huy hoàng và phát triển rực rỡ từ REST API, cơ bản là giao tiếp giữa client và server đã được giải quyết khá tốt. Nhưng dưới thời đại Microservices, rõ ràng chúng ta cần một phương pháp tốt hơn để tăng tải và thông lượng giữa các services
-
Có thể các bạn sẽ không thấy đây là một vấn đề chẳng đáng để bận tâm xử lý, đặc biệt khi hệ thống có ít services, ít server/node. Ở đây chúng ta đang nói đến rất nhiều services và tải đang rất cao. Ví dụ vài trăm service và tải đâu đó ở ngưỡng trên 100k CCU – Concurrent users (số lượng user đang hoạt động cùng một thời điểm)
-
Khi đó nếu một request cần phải tổng hợp dữ liệu qua nhiều services. Ở mỗi đầu service khi nhận các request trung gian này, chúng phải encode và decode liên tục (VD: JSON data). Việc này có thể gây quá tải cho các CPU. Lẽ ra CPU nên dành cho việc khác quan trọng hơn là chỉ vì en/code dữ liệu trung gian.
==> Ý tưởng về việc làm thế nào để các service giao tiếp với nhau với tốc độ cao nhất, giảm tải encode/decode data chính là lý do thúc đẩy gRPC ra đời.
RPC không phải REST API
-
Hẳn là các bạn đang tự hỏi tại sao không phải gAPI, gREST mà lại là gRPC. Vì đơn giản là framework này chuyên dành cho RPC. Mà RPC là “thủ tục gọi từ xa” (Remote Procedure Call). Mình ghét dịch những cụm này kinh khủng, vì dịch xong cũng như chưa dịch.
-
Bạn có thể dùng kỹ thuật lập trình mạng thông thường để gởi và nhận các gói tin thực hiện RPC. Tuy nhiên các developer luôn khao khát những phương thức dễ dàng hơn, chuẩn hoá hơn. Từ khi REST API ra đời và trở nên phổ biến, RPC xài luôn REST API để implement phương thức giao tiếp. Cái này được gọi là: RPC-based APIs.
Sự khác biệt lớn nhất đó là:
- REST API: Client và Server cần trao đổi state thông qua các resource được trả về. Do đó các response trả về thường là một resource
-
RPC: Client cần server thực hiện tính toán hoặc trả về một số thong in cụ thể nào đó. Bản chất giống y như đang ọi hàm, chỉ là hàm đó ở máy chủ khác hoặc service khác. Từ đó response trả về kết quả của hàm thôi, không hơn, không kém.
-
VD:
-
Về mindset, nếu nạn đang muốn lấy thông tin users với ID= 1. REST API trả về full resource object user với ID = 1. Nhưng nếu bạn muốn tính tổng thu nhập của user = 1 trong tháng này, với RPC thì trả về 1 số tổng thu nhập là đủ. Nhưng REST API thườn trả về resource nào đó có chứa thông tin tổng thu nhập của user ( VD là resource user có thêm key “total revenue”).
- Nếu bạn vẫn chưa hiểu khác nhau chỗ nào, không sao hết, việc này không quan trọng. Nhưng hãy nhớ về các method của REST API chỉ tập trung vào tạo mới, đọc, sửa, xóa resource. Nếu muốn resource làm 1 cái gì đó hoặc tính toán cụ thể cái gì đó thì chính là RPC-baseAPI
gRPC hoạt động như thế nào?
-
Quay lại với câu chuyện tăng tải cho cả hệ thống nhiều services (hay Microservices), Google đã phát triển 2 thứ
-
- Một giao thức mới để tối ưu các connection, đảm bảo dữ liệu đi trao đổi liên tục với ít băng thông nhất có thể.
-
- Một định dạng dữ liệu mới để 2 đầu service (hoặc client và server) có thể hiểu được các message của nhau mà ít phải encode/decode.
-
Đầu tiên Google phát triển một giao thức thay thế cho HTTP/1.1 với tên gọi SPDY. Sau này giao thức này được open source thậm chí chuẩn hoá, lấy làm nền móng cho giao thức HTTP/2. Khi có HTTP/2 rồi thì giao thức SPDY ngừng phát triển. gRPC chính thức hoạt động trên HTTP/2 luôn từ sau năm 2015.
- HTTP/2 sẽ hoạt động rất tốt với binary thay vì là text. Vì thế Google phát minh kiểu dữ liệu binary mới với tên gọi: Protobuf (tên đầy đủ là Protocol Buffers).
==> Tóm lại, gRPC là một kỹ thuật rất ưu việt để scale tải hệ thống, đặc biệt trong hệ thống phân tán, nhiều services hoặc Microservices. Việc sử dụng tốt gRPC vẫn phụ thuộc phần lớn vào kỹ thuật xây dựng service và khả năng deploy và vận hành (DevOps).