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.
Bài viết này sẽ giúp anh em có cài nhìn sâu hơn về gRPC, kiến trúc cũng như điểm mạnh điểm yếu của gRPC.
Chưa bắt đầu đã nhảy lẹ dữ chời. Chung thuỷ với REST bao lâu mà nhảy lẹ dữ.-
Bắt đầu ngay thôi nào!
1. gRPC là gì?
gRPC is a robust open-source RPC (Remote Procedure Call) framework used to build scalable and fast APIs. It allows the client and server applications to communicate transparently and develop connected systems. Many leading tech firms have adopted gRPC, such as Google, Netflix, Square, IBM, Cisco, & Dropbox. gRPC là một khung dựa trên RPC framework (gọi thủ tục từ xa), sử dụng để xây dựng các API có tốc độ cao, khả năng mở rộng tốt. Nó cho phép client và server trong ứng dụng có thể giao tiếp minh bạch và phát triển các hệ thống được kết nối. Rất nhiều công ty công nghệ hàng đầu đã áp dụng gRPC như Google, Netflix, Square, IBM, Cisco và Dropbox
Không phải sính ngoại nhưng nghe thôi đã thấy nên tìm hiểu về gRPC, không phải cứ tech từ công ty công nghệ lớn là mình sẽ tìm hiểu. Nhưng gRPC là thứ đang dần thay thế REST, mà REST lại quá phổ biến. Nên tìm hiểu gRPC là chắc chắn phải làm rồi.
Liệng qua liệng lại xíu phía lịch sử thì gRPC đầu tiên được phát triển bởi Google, như là một phần mở rộng thêm của RPC framework. Sử dụng để kết nối nhiều microservices với nhiều techstack khác nhau. Sau một thời gian thì được chuyển qua open source, cho cộng đồng thoải mái sử dụng.
2. gRPC concepts
gRPC có được sự phát triển và thành công nhờ sử dụng các công nghệ mới hàng đầu, tốt hơn JSON và XML, cung cấp và gia tăng bảo mật cho API. Hầu hết các concept của gRPC đều bắt đầu từ
2.1 Protocol Buffers
Protocol Buffers hay còn gọi là Protobuf, là giao thức tuần tự hoá (serialization) của Google, cho phép định nghĩa các services tự động tạo ra các client libraries. gRPC sử dụng các giao thức này làm IDL (Interface Definition Language – Ngôn ngữ định nghĩa giao thức). Phiên bản hiện tại là proto3, bao gồm các tính năng mới và dễ dàng sử dụng.
Cả quá trình hoạt động của protobuf cho thấy nó có lợi thế hơn nhiều so với JSON và XML. Phân tích syntax bằng protobuf yêu cầu ít hơn tài nguyên CPU (do dữ liệu được chuyển thành dạng nhị phân). Các tin nhắn được mã hoá có kích thước nhỏ hơn.
Chính vì có kích thước nhỏ, việc trao đổi hoặc gửi nhận tin nhắn trở nên nhanh chóng, ngay cả khi máy sử dụng có CPU chậm (như điện thoại hoặc các thiết bị di động khác).
2.2 Streaming
Streaming là concept khác của gRPC, nơi mà nhiều processes được thực thi chỉ trong một request duy nhất. Streaming cũng được hỗ trợ bởi TCP và HTTP/2 (cho phép gửi nhiều response hoặc nhận nhiều request).
Streaming chia thành 3 loại chính dưới đây:
- Server-streaming RPCs: Client sẽ gửi một request duy nhất tới server và nhận lại một luồng dữ liệu. Server sẽ gửi toàn bộ nội dung trả về cho tới khi không nhận được tin nhắn nào nữa.
- Client-streaming RPCs: Kiểu này client sẽ gửi một chuỗi luồng dữ liệu tới server, server xử lý và trả về duy nhất một response cho client.
- Bidirectional-streaming RPCs: Streaming 2 chiều cho phép cả client và server gửi chuỗi tin nhắn tới nhau. Cả hai luồng này hoạt động độc lập, do đó chúng có thể truyền message theo bất cứ trình tự nào. Trình tự tin nhắn (messages) trong mỗi luồng được dữ nguyên.
2.3 HTTP/2
gRPC xây dựng dựa trên HTTP/2, được ra mắt vào năm 2015 để khắc phục các hạn chế của HTTP/1.1. Mặc dù tương thích như HTTP 1.1 nhưng HTTP/2 mang lại nhiều tính năng cao cấp hơn như:
- Binary Framing Layer
- Streaming
- Flow Control
- Header Compression
- Processing
Processing trong HTTP/2 giúp gRPC có thể hỗ trợ các process chạy đồng bộ và bất đồng bộ (synchronous and asynchronous). Có thể sử dụng để thực hiện các loại tương tác và phát trực tuyến gRPC.
Streaming – Bidirectional full-duplex streaming (truyền phát hai chiều) cho phép client có thể gửi yêu cầu (request) và nhận về phản hồi (response) đồng thời.
2.4 Channels
Channels là khái niệm cốt lõi trong gRPC. Các luồng trên HTTP/2 cho phép nhiều stream trên 1 connection mở.
3. Kiến trúc gRPC
Kiến trúc gRPC được mô tả theo hình vẽ dưới đây. Sơ đồ này chia thành 2 phần (client và server), trong mô hình này mọi client service đều bao gồm một stub. Stub là file được tự động tạo ra, nó tương tự như các interface hiện tại ta dùng để giao tiếp với phía server.
Khi máy khách gửi request tới Server, nó sẽ bao gồm API được gọi và các tham số (parameter). Lúc cần parameter thì đó là lúc và Stub ở phía client hoạt động, nó tuần tự hoá (serializes) các tham số bằng Protobuf, chuyển request này tới client time library (cái này ở local machine).
Sau đó, OS lúc này gửi tới server thông qua giao thức HTTP/2. OS của Server nhận các packets, gọi tới server stub procedure. Thủ tục stub này ở phía server sẽ giải mã (decode) các tham số nhận được, gọi các procedure tương ứng cũng bằng Protobuf.
Sau khi đã thực hiện xong, các dữ liệu mã hoá sẽ gửi lại cho Client và decode các tham số đó. Client tiếp tục xử lý và trả về cho phía enduser.
Tham khảo việc làm Front-end Developer hấp dẫn trên TopDev
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
4.1 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.
4.2 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
4.3 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#
4.4 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.
5.1 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
5.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. Tham khảo thêm về gRPC
gRPC là một công nghệ đầy hứa hẹn và đã đạt được một số bước tiến đáng kể trong lĩnh vực API. Tuy nhiên không phải nó có thể thay thế ngay lập tức REST trong một sớm một chiều.
Anh em có thể cân nhắc sử dụng gRPC khi cần kết nối các microservices ở quy mô lớn (large-scale), giao tiếp trong thời gian thực (real time communication), các hệ thống có tài nguyên và công suất thấp.
Cảm ơn anh em đã đọc bài – Thank your for your attension – Happy coding!
Tác giả: Kiên Nguyễn
Có thể bạn quan tâm:
- Giao tiếp Client / Server bằng gRPC
- Messege Queue – Bộ phận không thể thiếu trong các hệ thống lớn và Microservice Architecture
- Cách tuần tự hóa dữ liệu trong Java như Protobuf
Xem thêm Việc làm Developer hấp dẫn trên TopDev
