Hi, I am

Ngô Tôn

I am a programmer.

Home / Programming / Web Development / Java / Tìm hiểu về gRPC

Tìm hiểu về gRPC

Trong bài viết này, Ngô Tôn .IT chia sẻ tới các bạn một số khái niệm về gRPC. Bài viết được tổng hợp và dịch lại từ các bài viết khác.

gRPC là gì?

gRPC là một RPC framework gíup kết nối giữa các service trong hệ thống, nó hỗ trợ load balancing, tracing, health checking và authentication, hỗ trợ từ ứng dụng mobile, trình duyệt cho tới back-end service.

gRPC sử dụng Protocol Buffer và giao thức HTTP/2 để transfer data thay vì JSON/XML và giao thức HTTP/1.1 truyền thống nên tốc độ được gia tăng đáng kể. Sự khác biệt giữa REST API vs RPC là REST được thiết kế để tập trung vào resource còn RPC thì tập trung vào action.

Protocol Buffers

Đầu tiên để làm việc với protocol buffers là xác định cấu trúc dữ liệu muốn serialize trong một file proto: đây là một tệp văn bản thông thường với phần mở rộng là .proto. Dữ liệu protocol buffers được cấu trúc như các message, trong đó mỗi message là một bản ghi logic thông tin nhỏ chứa một loạt các cặp name-value được gọi là các fields.

Tiếp theo sử dụng trình biên dịch protoc để tạo ra class truy cập dữ liệu bằng các ngôn ngữ lập trình khác. Cung cấp bộ truy cập đơn giản như name(), set_name() cho từng field, cũng như các phương thức serialize/parse toàn bộ cấu trúc từ các byte thô.

Về cơ bản, khi làm việc với gRPC bạn định nghĩa các action, input message, output mesage trong service, sau đó protobuf compiler sẽ generate code ra file theo ngôn ngữ bạn sử dụng. Sau đó bạn sẽ triển khai các action của service như những gì đã bạn đã mô tả .

Service

gRPC cho phép định nghĩa 4 loại phương thức của dịch vụ:

  • Unary RPCs: khi client gửi một yêu cầu đến server và nhận về một phản hồi giống như một cuộc gọi phương thức bình thường.
  • Server streaming RPCs: khi client gửi một yêu cầu đến server và nhận về một stream để đọc trình tự của thông điệp trả về.
  • Client streaming RPCs: khi client ghi một 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 một cuộc gọi RPC riêng lẻ.
  • Bidirectional streaming RPCs: khi cả 2 gửi một chuỗi các thông điệp sử dụng đọc-viết stream. Hai luồn hoặc độ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 một 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.
     

API

Bắt đầu từ định nghĩa dịch vụ trong tệp .proto, gRPC cung cấp các trình biên dịch protocol buffers tạo mã ở phía client và server. Các người dùng gRPC thường gọi các API này ở phía client và triển khai tương ứng ở phía server.

  • Về phía server, triển khai các phương thức được mô tả bởi dịch vụ và chạy một gRPC server để xử lý cuộc gọi từ client. gRPC infrastructure giả mã các yêu cầu, thực hiện các phương thức của dịnh vụ và mã hóa các phản hồi.
  • Về phía client, có một đối tượng local được gọi là stub thực hiện các phương thức tư tự dịch vụ. Sau đó, client có thể chỉ cần gọi các phương thức đó trên đối tượng local, gói các tham số cho loại tin nhắn protocol buffer thích hợp – gRPC xem xét sau khi gửi yêu cầu tới server và server trả về phản hồi protocol buffer.

Các cuộc gọi RPC đồng bộ chặn cho đến khi có phản hồi đến từ máy chủ. gRPC trong các ngôn ngữ lập trình có cả RPC động bộ và không đồng bộ.

Vòng đời RPC

Unary RPC

Một RPC đơn giản, khi một client gửi một yêu cấu đến server và nhận về một phản hồi.

  •  Khi client gọi phương thức trên đối tượng stub/client,  server được thông báo rằng RPC đã được gọi với metadata của client cho cuộc gọi này, tên phương thức và thời hạn quy định (specified deadline) nếu có.
  • Sau đó, client có thể gửi lại metadata ban đầu của chính nó (phải được gửi trước khi có bất kỳ phản hồi nào), hoặc chờ thông báo yêu cầu của client – điều xảy ra đầu tiên là dành riêng cho ứng dụng.
  • Khi server có thông báo yêu cầu của khách hàng, nó làm bất cứ việc gì là cần thiết để tạo và đưa ra phản ứng của nó. Phản hồi sau đó được trả lại (nếu thành công) cho client cùng với các chi tiết trạng thái (mã trạng thái và thông báo trạng thái tùy chọn) và trailing metadata tùy chọn.
  • Nếu trạng thái là OK, thì client sẽ nhận được phản hồi, hoàn thành cuộc gọi ở phía client.

Server streaming RPC

Một server-streaming RPC tương tự với ví dụ đơn giản ở Unary RPC, ngoại trừ server gửi lại một luồng phản hồi sau khi nhận được thông báo yêu cầu của client. Sau khi gửi lại tất cả các phản hồi của nó, chi tiết trạng thái của server (mã trạng thái và thông báo trạng thái tùy chọn) và trailing metadata tùy chọn được gửi lại để hoàn tất về phía server.Client hoàn thành một khi nó có tất cả các phản hồi của server.

Client streaming RPC

Một client-streaming RPC tương tự với ví dụ đơn giản ở Unary RPC, ngoại trừ client gửi một luồng yêu cầu đến server thay vì một yêu cầu. Server sẽ gửi lại một phản hồi duy nhất, thông thường nhưng không nhất thiết là sau khi nhận được tất cả các yêu cầu của client, cùng với các chi tiết trạng thái và trailing metadata tùy chọn.

Bidirectional streaming RPC

Một bidirectional streaming RPC là sự kết hợp của Server streaming và Client streaming RPC. Vì server và client có thể đọc và ghi theo bất kỳ thứ tự nào – các luồng hoạt động hoàn toàn độc lập.

Metadata

Metadata là thông tin về một cuộc gọi RPC cụ thể (chẳng hạn như  authentication) ở dạng danh sách các cặp khóa-giá trị,  trong đó các khóa là các chuỗi và các giá trị thường là các chuỗi (nhưng có thể là dữ liệu nhị phân).

Channels

gRPC channel cung cấp kết nối đến máy chủ gRPC trên server và port được chỉ định và được sử dụng khi tạo client stub (hoặc chỉ là client trong một số ngôn ngữ). Client có thể chỉ định đối số channel để sửa đổi hành vi mặc định của gRPC, chẳng hạn như bật và tắt nén tin nhắn. Một channel có trạng thái, bao gồm cả connected và idle. Cách gRPC xử lý việc đóng các channels phụ thuộc vào ngôn ngữ. Một số ngôn ngữ cũng cho phép truy vấn trạng thái channel.

About ngoton

Ngô Tôn is a programmer with passion for tailored software solutions. Comes with 7+ years of IT experience, to execute beautiful front-end experiences with secure and robust back-end solutions.

Check Also

Xóa các Object trùng lặp trong List Java

Khi làm việc với List trong Java, đôi lúc chúng ta cần tạo 1 List …

Leave a Reply

avatar
  Subscribe  
Notify of