Trong tài liệu này giới thiệu các định nghĩa chính về gRPC và tổng quan về kiến trúc của gRPC và vòng đời(Life cycle) của RPC. Bài viết này giả định bạn đã đọc bài gRPC là gì?

Tổng quan

Định nghĩa dịch vụ (Service)

Bắt đầu với đoạn mã dưới đây.

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 surface

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 (các) yêu cầu tới server và server trả về (các) phản hồi protocol buffer.

Synchronous vs. asynchronous

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.

Deadlines/Timeouts

gRPC cho phép client chỉ định thời gian họ sẵn sàng chờ đợi RPC hoàn thành trước khi RPC bị chấm dứt với lỗi DEADLINE_EXCEEDED. Về phía server có thể truy vấn để xem liệu một RPC cụ thể đã hết thời gian hay còn bao nhiêu thời gian để hoàn thành RPC.

Deadline hoặc timeout chờ được chỉ định khác nhau tùy theo ngôn ngữ – ví dụ, không phải tất cả các ngôn ngữ đều có thời hạn mặc định, một số API ngôn ngữ hoạt động theo thời hạn (thời điểm cố định) và một số API ngôn ngữ hoạt động theo thời gian chờ (thời lượng).

RPC termination

Trong gRPC, cả client và server đều đưa ra các quyết định độc lập và cục bộ về sự thành công của cuộc gọi và kết luận của chúng có thể không khớp. Điều này có nghĩa là, ví dụ, bạn có thể có một RPC kết thúc thành công ở phía server, nhưng không thành công ở phía client (Các phản hồi đã đến sau thời hạn) Nó cũng có thể cho server quyết định hoàn thành trước khi client gửi tất cả các yêu cầu của nó.

Cancelling RPCs

Client hoặc server có thể hủy RPC bất cứ lúc nào. Việc hủy bỏ chấm dứt RPC ngay lập tức để không có công việc nào được thực hiện nữa. Đây không phải là một cách hoàn hảo, những thay đổi được thực hiện trước khi hủy sẽ không được khôi phục.

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

Truy cập vào metadata phụ thuộc vào ngôn ngữ.

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.

Nguồn: Sưu tầm từ internet via devnow.vn

====

[HANOI_Nguồn: Sưu tầm từ internet] Tại buổi Nguồn: Sưu tầm từ internet ngày 14/01/2020 với chủ đề “Migrating APIs from REST to gRPC and LOOP Case study” do anh Việt Nguyễn – CTO | LOOP trình bày, hứa hẹn sẽ mang đến những giải pháp cho vấn đề giao tiếp giữa các services từ chính trường hợp của LOOP.

🔥 Những nội dung chính trong buổi chia sẻ này:

• Hệ thống gRPC (Remote Procedure Calls) được phát triển tại Google gRPC là gì?
• Vấn đề mà đội ngũ LOOP gặp phải trong quá trình phát triển sản phẩm? Làm thế nào để các service của bạn giao tiếp được với nhau?
• Thách thức đã gặp phải và cách thức triển khai?

 = = = 

**Nhập ngay code EARLYBIRD@1401 để giảm 100.000đ cho các vé đầu tiên!

⏰ Thời gian: 18:30 – 21:00 ngày 14/01/2020
📌 Địa điểm: UP Bách Khoa Hà Nội, tầng 3 toà nhà A1-7, 17 Tạ Quang Bửu, HBT.
🎟 Đăng ký ngay tại: https://meetup.vn/e/F3S

===

LIÊN HỆ

Event team: event@applancer.net | 028 6681 3236
Ms. Thoa | thoa.nguyen@applancer.net | 038 5098 969

=== Sự kiện thuộc chuỗi PRODUCT IN REAL LIFE (https://topdev.vn/page/series-product-in-real-life/) hằng tuần được tổ chức bởi TopDev – Giải pháp tuyển dụng ngành IT ===