gRPC là gì? Điều gì giúp GRPC trở nên mạnh mẽ?

gRPC là mã nguồn mở mới, dựa trên RPC framework, đem lại hiệu suất và hiệu quả cao trong mọi môi trường. Hỗ trợ cả hai loại là request và response thông thường và giao tiếp dài như long-running streaming. Nó là công nghệ giao tiếp máy chủ-máy khách (client-server) phát triển bởi Google. Nó được thiết kế để tối ưu hóa hiệu suất và độ tin cậy trong việc giao tiếp giữa các dịch vụ phân tán, đặc biệt là trong môi trường microservices. Chúng ta cùng tìm hiểu kỹ hơn về gRPC trong bài viết dưới đây nhé!
 

gRPC là một framework RPC mã nguồn mở, hiện đại và 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 khởi công phát triển vào năm 2015, đến 08/2016 thì được phát hành 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.

Gần đây các backend developer phải đứng trước lựa chọn dùng REST API hay dùng gRPC. Tại sao đã có REST API rồi còn phải thêm gRPC chi vậy? Vậy thì bài viết này mình sẽ làm rõ các khác biệt của chúng.

1.Vì sao cần gRPC?

Ví dụ 2 service đang trao đổi JSON

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.

2. RPC không phải REST API

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 không có ý định làm một bài riêng cho RPC vs REST API nên sẽ giới thiệu sơ lược thôi. RPC có từ rất lâu rồi, trước khi có REST API rất nhiều. Hồi đó lập trình viết hàm, gọi hàm trên một codebase (local procedure).

Nhưng rồi cũng sẽ có lúc những procedure này cần tái sử dụng nhiều hơn, hoặc “cách ly” nó để có tải cao hơn. Như vậy việc sử dụng lời gọi từ xa (remote call) là đương nhiên.

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 thông tin cụ thể nào đó. Bản chất giống y như ta đang gọi hàm, chỉ là hàm đó ở máy chủ khác hoặc service khác. Từ đó response trả về chỉ là kết quả của “hàm” thôi, không hơn, không kém.

Về mindset, nếu bạ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ường trả về 1 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 và xoá resource. Nếu vậy muốn resource làm một cái gì đó hoặc tính toán cụ thể cái gì đó thì chính là RPC-base APIs.

Hình dáng của RPC-base APIs trong thực tế:

• POST /songs/:id/play (play bài hát, thành công thì return true hoặc 1)
• GET /songs/:id/calculate_total_views (trả về con số tổng lượt xem của bài hát)

Bảng này so sánh các thao tác (Operation) giữa mô hình RPC và REST, với các URL tương ứng cho mỗi phương thức.

Nguồn: Alexsoft

3. gRPC hoạt động như thế nào?

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ứ:

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

Sức mạnh của HTTP/2 các bạn nên xem qua bài: HTTP/2 là gì? HTTP/2 với HTTP/1 (rất hay và mình khuyến khích nên xem)

Thậm chí ở thời điểm mình viết bài này, HTTP/3 đang dần được support và sẽ sớm được sử dụng rộng rãi. Rất nhiều service Google đã và đang hoạt động với HTTP/3. gRPC cũng đã vận hành được với HTTP/3 thông qua một số thư viện chưa chính thức.

Chi tiết giao thức HTTP/3 mình cũng có viết ở đây: HTTP/3 là gì? Giao thức tăng hiệu suất website

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

Mình sẽ viết chi tiết về Protobuf (và hướng dẫn sử dụng nó với Golang) trong một bài khác, trong khuôn khổ bài này mình chỉ muốn giới thiệu gRPC thôi cho gọn. Nhưng về tốc độ encode/decode các bạn có thể xem qua một benchmark dưới đây:

Nguồn: Medium (Nguyễn Hữu Đồng)

4. Điểm mạnh của gRPC

Với kiến trúc và các thức mã hoá, giải mã các parameter khác biệt. Cộng với HTTP/2, rõ ràng gRPC đem tới một số ưu điểm khác biệt.

Đầu tiên là về hiệu năng

Peformance

Theo các đánh giá khác nhau, gRPC đem lại tốc độ và bảo mật API gấp 10 lần so với REST+JSON truyền thống. Do có protobuf và HTTP/2, protobuf sẽ tuần tự hoá (serializes) các tin nhắn ở phía server và client một cách nhanh chóng. Kích thước của tin nhắn lúc này cũng trở nên nhỏ gọn, HTTP/2 cũng cung cấp phương pháp nén file, header nhỏ hơn, giúp việc gửi nội dung giữa Client và Server trở nên nhanh chóng hơn.

Streaming

Với HTTP/2 và gRPC, việc streaming bây giờ có thể thực hiện nhanh chóng theo nhiều cách khác nhau:

• Unary (no streaming) – không streaming
• Client-to-server streaming – từ client tới server
• Server-to-client streaming – từ server tới client
• Bi-directional streaming – streaming 2 chiều

Interoperability

Interoperability (tương tác), cũng giống như HTTP1, gRPC hỗ trợ tích hợp với hầu hết các ngôn ngữ lập trình phổ biến hiện nay như Java, JavaScript, Ruby, Python, Go, Dart, Objective-C, C#

Security

HTTP/2 luôn đi kèm với TLS giúp đảm bảo tính bảo mật của API. gRPC cũng được khuyến khích để sử dụng với SSL/TLS để mã hoá dữ liệu, giúp việc truyền dữ liệu từ Client tới Server trở nên an toàn hơn

5. Điểm yếu của gRPC

Với vô vàn điểm mạnh không có nghĩa là gRPC không có điểm yếu, dưới đây là một số điểm yếu có thể nhìn thấy rõ khi sử dụng gRPC.

Limited Browser Support

g RPC sử dụng trên nền HTTP/2 nên không thể gọi trực tiếp các service từ g RPC từ trình duyệt web. Lúc này nếu muốn sử dụng HTTP/2 ta cần proxy và g RPC web để chuyển đổi từ HTTP/1.1 qua HTTP/2

Non-human Readable Format

Không giống như JSON hay các giao thức khác, Protobuf sẽ nén các tin nhắn từ g RPC thành các dữ liệu khó đọc với con người. Trường hợp có xảy ra lỗi, để thực hiện truy nguyên hoặc kiểm tra cũng là một điều khó khăn.

6. So sánh RESTful API và gRPC​

Bảng so sánh​

Wow, thực ra cũng không có gì đặc biệt cả. Nếu RestFull API sử dụng HTTP/2 thậm chí HTTP/3 thì sẽ cũng nhanh như vậy, vậy tại sao cần dùng gRPC?
 

7. Tại sao không sử dụng HTTP/2 mà sử dụng gRPC?​

• Về mặt hiệu suất vì cả 2 đều sử dụng HTTP/2 nên không có gì khác biệt. Tuy nhiên, thồng thường khi sử dụng gRPC chúng ta sẽ sử dụng protobuf để truyền dữ liệu và protobuf nhỏ gọn hơn JSON nên sẽ giúp giảm dung lượng truyền tải.
• Về mặt kết nối. Nhiều thư viện rest chỉ hỗ trợ HTTP/1.1 nên sẽ không thể tận dụng được HTTP/2. Còn gRPC thì sẽ hỗ trợ HTTP/2 từ đầu.
  • Ví dụ Resttemplate chỉ hỗ trợ HTTP/1.1, nếu muốn sử dụng HTTP/2 thì cần phải sử dụng WebClient hoặc OkHttp.
• Về mặt quản lý contract. Với gRPC, chúng ta sẽ sử dụng protobuf để định nghĩa contract chặt chẽ hơn so với RESTful API.
• Về mặt sử dụng. gRPC sẽ khiến cho code của repo trở nên sạch sẽ hơn, dễ đọc hơn. Bởi vì nó giống như là việc gọi một method.

8. Khi nào sử dụng RestFull API và gRPC.​

Về điều này chúng ta sẽ cần xem xét từng trường hợp cụ thể. Nó giống như là một chai nước tăng lực monster và một chai nước suối lavie. Mỗi chai nước sẽ phù hợp với một trường hợp cụ thể.

Khi nào sử dụng RestFull API?​

Hmm, một câu hơn đơn giản hơn là tại sao RestFull API lại phát triển? Câu trả lời là bởi vì sự phát triển mạnh mẽ của các công nghệ web. RestFull API sử dụng HTTP để hoạt động, vì vậy nó ban đầu được sử dụng để cung cấp API cho các ứng dụng web. Tuy nhiên, với sự phát triển của công nghệ, các API cần được nhiều bên sử dụng, việc định nghĩa và phát triển song song các giao thức cho từng nền tảng nữa sẽ tốn rất nhiều chi phí. Vì vậy, RestFull API được sử dụng để có thể tích hợp với mọi nền tảng.

• Sử dụng RestFull API khi bạn mong muốn phát triển các API mà có thể tích hợp với mọi nền tảng. Từ web, mobile app, desktop app, server app, hay thậm chí là script shell.

• Tích hợp được bất kể ngôn ngữ gì. Từ Java, Python, Ruby, PHP, hay thậm chí là C++.

• Nếu API của bạn là Global API, nghĩa là nó sẽ được sử dụng bởi nhiều bên khác nhau, thì RestFull API là lựa chọn tốt nhất để có thể hỗ trợ mọi nền tảng và mọi ngôn ngữ.

• Và tất nhiên rồi, nếu bạn hỗ trợ truy cập từ web browser thì bắt buộc cần sử dụng RestFull API.

  • Trong trường hợp sử dụng RestFull API từ web browser, chúng ta cũng sẽ sử dụng được nhiều service hỗ trợ như Web Browser cache, CDN cache, ... để giúp tăng tốc độ truy cập.

Khi nào có thể chọn sử dụng gRPC?​

Thực tế gRPC không sử dụng để giao tiếp với end-user. Mà nó được sử dụng để giao tiếp giữa các system hoặc service với nhau. Việc giao tiếp giữa các system và service cần phải nhanh chóng, chính xác và an toàn. Và gRPC sẽ giúp bạn làm được điều đó.

gRPC sẽ thân thiện với các developer, vì nó giống như là việc gọi một method. Và nó sẽ giúp cho code của bạn trở nên sạch sẽ hơn, dễ đọc hơn.

Vì vậy:

• Sử dụng gRPC khi service của bạn sẽ được các service khác hoặc system khác gọi đến không phải bởi end-user.

  • Ví dụ: Service của bạn cung cấp tính năng core thanh toán. Các service khi thực hiện phát triển tính năng thanh toán đều cần phải gọi đến service của bạn. Việc sử dụng gRPC sẽ giúp cho service của bạn trở nên nhanh chóng và thân thiện với các developer.

• Sử dụng gRPC khi bạn cần một contract chặt chẽ hơn. Vì với gRPC, bạn sẽ sử dụng protobuf để định nghĩa contract. Và nó sẽ giúp cho việc quản lý contract trở nên dễ dàng hơn.

• Khi bạn mong muốn việc giao tiếp giữa các service trở nên nhanh chóng và sytem của bạn trở nên nhanh chóng thì nên sử dụng gRPC.

9. Hỗ trợ song song cả gRPC và RestFull API​

Đây là một ý tưởng rất hay và đã được một số mạng blockchain sử dụng. Ví dụ như Cosmos.

Cosmos sử dụng gRPC để giao tiếp giữa các node và các service tích hợp thêm. Và sử dụng RestFull API để giao tiếp với end-user. Điều này giúp cho Cosmos trở nên nhanh chóng và dễ dàng tích hợp với mọi nền tảng.

Bởi vì mỗi công nghệ đều có ưu điểm và nhược điểm và sẽ phục vụ tốt cho một trường hợp cụ thể. Vì vậy, việc sử dụng song song cả 2 công nghệ sẽ giúp cho hệ thống của chúng ta trở nên mạnh mẽ và linh hoạt hơn.

Tuy nhiên vấn đề chi phí phát triển, bảo trì và quản lý cũng sẽ tăng lên. Vì vậy, khi sử dụng song song cả 2 công nghệ, chúng ta cần phải cân nhắc kỹ lưỡng.

10. Một số lưu ý trong gRPC

Mình đã sử dụng gRPC được khoảng 2 năm cho các hệ thống cỡ vừa và lớn. Dưới dây là các điểm lưu ý trên kinh nghiệm cá nhân:

• gRPC nên dùng để giao tiếp backend to backend. CPU không gánh nhiều cost cho encode/decoding mỗi đầu nữa. Tuy nhiên đặc tính mỗi đầu cần import file model chung (gen từ protobuf file) nên nếu update thì phải update đủ. Việc này vô tình tạo dependency cho các bên sử dụng, có thể nhiều bạn sẽ không thích điều này.
• gRPC thường được đấu nối vào service mesh (hoặc sidecar trong Microservices), để có thể xử lý connection HTTP/2 cũng như monitoring nó tốt hơn.
• gRPC support streaming 2 đầu nên rất được lòng các fan streaming system, event sourcing (stream event). VD: gRPC được sử dụng trong: vitess, neo4j vì lý do trên.
• gRPC nếu dùng cho frontend-backend thì thật sự rất cân nhắc. Connection statefull tạo nhiều sự khó chịu trong scale tải hoặc bạn có thể bị Head of line blocking (HOL).
• gRPC vẫn có thư viện gRPC Gateway chính chủ của Google. Tức là các bạn vẫn có thể chạy 1 port http/1 cho REST và 1 port http/2 của gRPC đồng thời. Như vậy không phải là không có cách để quay về REST thân quen, nhưng đương nhiên là đi qua proxy service nên cồng kềnh hơn.

11. Lời kết

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

Mình đã từng thấy nhiều team ứng dụng gRPC đạt nhiều hiệu quả to lớn. Song nhiều team đã từ bỏ quay về REST API. Liệu nó có hợp với hệ thống của bạn hay không có lẽ chính bạn mới có thể đưa ra câu trả lời. Với bản thân mình thì gRPC rất tốt, rất đáng để trải nghiệm và được nhiều công ty lớn tin dùng. Hiện tại, gRPC cũng đã thành viên trong Cloud Native Foundation.

Mình sẽ còn trở lại với các bài viết hướng dẫn về chủ đề này, giúp các bạn xây dựng một service cơ bản sử dụng gRPC để giao tiếp với nhau. Cảm ơn các bạn đã đọc bài viết.