PRN232 Chương 9 - gRPC Service và Protocol Buffers
Chương 9 môn PRN232 trình bày gRPC: hợp đồng chặt chẽ khai báo trong file .proto thay cho tài liệu rời rạc, Protocol Buffers với định dạng nhị phân nhỏ và nhanh hơn JSON cùng tập kiểu vô hướng độc lập ngôn ngữ, nền tảng truyền tải HTTP/2 và cơ chế Server Push, GrpcChannel như kết nối dùng lại được cho nhiều lời gọi, override phương thức RPC với ServerCallContext, streaming hai chiều đọc ghi độc lập, và các tình huống REST/JSON vẫn phù hợp hơn gRPC. Trọn bộ câu hỏi trắc nghiệm có giải thích.
Bắt đầu bằng Chế độ học nếu bạn muốn đáp án và giải thích hiện ngay sau mỗi câu — không bấm giờ, dừng lúc nào cũng được. Chọn Thi thử khi muốn biết mình đang ở đâu: có bấm giờ, chấm điểm ở cuối, và giải thích chỉ mở sau khi nộp.
AREST APIs are strictly-typed, while gRPC is loosely-typed.
BgRPC APIs are defined by a formal contract (.proto file), while REST APIs often rely on documentation (like OpenAPI) that is separate from the implementation.
CgRPC can only be used for internal, server-to-server communication.
DREST APIs support streaming, while gRPC does not.
Lời giải
Một trong những điểm khác biệt chính giữa gRPC và một API HTTP REST thông thường là cách định nghĩa và quản lý các dịch vụ API. gRPC sử dụng một hợp đồng chính thức (.proto file) để định nghĩa các dịch vụ API, trong khi các API HTTP REST thường dựa vào tài liệu (như OpenAPI) riêng biệt với triển khai. Điều này giúp cho gRPC cung cấp tính nhất quán và bảo mật cao hơn trong việc triển khai và sử dụng các dịch vụ API. Ngoài ra, việc sử dụng hợp đồng chính thức cũng giúp cho gRPC hỗ trợ các tính năng như mã hóa và xác thực tự động, giúp tăng cường bảo mật cho các dịch vụ API.
gRPC được xây dựng trên nền tảng của giao thức truyền tải nào? gRPC sử dụng giao thức HTTP/2 làm giao thức truyền tải cơ bản. Điều này cho phép gRPC tận dụng các tính năng của HTTP/2 như hỗ trợ nhiều luồng truyền tải, hỗ trợ các tính năng như server push, và hỗ trợ các tính năng khác. gRPC cũng có thể hoạt động trên các giao thức khác như TCP/IP trực tiếp, HTTP/1.1, UDP, nhưng giao thức HTTP/2 là giao thức được khuyến nghị và được sử dụng rộng rãi nhất.
gRPC thường sử dụng định dạng serialize nào mặc định? gRPC là một framework giao tiếp mạng được thiết kế để xây dựng các ứng dụng phân tán. Nó thường sử dụng định dạng serialize Protocol Buffers mặc định. Protocol Buffers là một định dạng serialize được thiết kế bởi Google, nó cho phép định nghĩa các cấu trúc dữ liệu và serialize chúng thành các byte array. Điều này giúp giảm thiểu kích thước dữ liệu và tăng tốc độ truyền dữ liệu. Ngoài ra, Protocol Buffers cũng hỗ trợ các tính năng như tính nhất quán và khả năng mở rộng, giúp dễ dàng triển khai và bảo trì các ứng dụng gRPC.
AJSON has a richer set of built-in data types, including Date and Guid.
BProtobuf has a well-defined, language-agnostic set of scalar types, and data is validated against this schema during serialization.
CJSON does not distinguish between integers and floating-point numbers.
DProtobuf uses strings for all data types.
Lời giải
Protobuf và JSON là hai định dạng dữ liệu khác nhau trong việc xử lý kiểu dữ liệu. Protobuf có một bộ sưu tập kiểu dữ liệu scalar được định nghĩa rõ ràng và không phụ thuộc vào ngôn ngữ lập trình, và dữ liệu được xác thực dựa trên lược đồ này khi thực hiện quá trình serialize. Điều này giúp đảm bảo tính toàn vẹn và chính xác của dữ liệu trong quá trình truyền tải. Ngược lại, JSON không có bộ sưu tập kiểu dữ liệu được định nghĩa rõ ràng như Protobuf, và dữ liệu được xác thực dựa trên cấu trúc dữ liệu được định nghĩa trong mã nguồn.
Để tạo một client gRPC trong ứng dụng console .NET 8, bạn cần sử dụng thư viện gRPC .NET. Đầu tiên, bạn cần thêm gói gRPC .NET vào dự án của mình. Sau đó, bạn cần tạo một đối tượng kênh gRPC bằng cách sử dụng phương thức GrpcChannel.ForAddress(). Phương thức này sẽ tạo một kênh gRPC kết nối đến địa chỉ server gRPC. Sau khi tạo kênh gRPC, bạn có thể tạo một client gRPC bằng cách sử dụng lớp Greeter.GreeterClient và truyền đối tượng kênh gRPC vào trong nó. Điều này cho phép client gRPC giao tiếp với server gRPC.
BNever; the client and server can read and write in any order, their streams operate independently.
COnly if the client explicitly signals it has finished writing.
DThis is configured by the wait_for_client option in the .proto file.
Lời giải
Trong cuộc gọi streaming hai chiều, khi nào thì máy chủ chờ đợi khách hàng gửi tất cả các tin nhắn trước khi gửi tin nhắn của nó? Câu trả lời đúng là "Không bao giờ; khách hàng và máy chủ có thể đọc và viết theo bất kỳ thứ tự nào, các luồng của họ hoạt động độc lập". Điều này có nghĩa là trong một cuộc gọi streaming hai chiều, khách hàng và máy chủ có thể đọc và viết các luồng dữ liệu của họ mà không cần chờ đợi nhau. Điều này cho phép khách hàng và máy chủ tương tác với nhau một cách linh hoạt và hiệu quả hơn. Tuy nhiên, điều này cũng có thể dẫn đến tình huống phức tạp khi khách hàng và máy chủ cần đồng bộ hóa các luồng dữ liệu của họ.
AWhen building a browser-based client application that needs to directly call the API without a proxy layer.
BFor high-throughput, low-latency communication between microservices.
CWhen a strict, language-agnostic contract is required.
DWhen bi-directional streaming is a core requirement.
Lời giải
Một API RESTful HTTP/JSON truyền thống phù hợp hơn với gRPC trong trường hợp xây dựng một ứng dụng khách dựa trên trình duyệt cần gọi trực tiếp API mà không cần một lớp trung gian proxy. Điều này là vì API RESTful HTTP/JSON dễ dàng được truy cập từ trình duyệt web thông qua các phương thức HTTP như GET, POST, PUT và DELETE. Trong khi đó, gRPC yêu cầu sử dụng các phương thức RPC (Remote Procedure Call) và giao thức HTTP/2, điều này có thể gây khó khăn khi truy cập từ trình duyệt web. Ngoài ra, API RESTful HTTP/JSON cũng dễ dàng được tích hợp với các công cụ và thư viện khác nhau, giúp dễ dàng xây dựng và quản lý ứng dụng.
Để thực hiện SayHello RPC, bạn phải ghi đè phương thức nào trong lớp dịch vụ C# của mình?
Trong khi xây dựng một dịch vụ RPC, bạn cần phải ghi đè phương thức SayHello để thực hiện chức năng này.
Phương thức SayHello phải được ghi đè với các thuộc tính sau:
- Nó phải là phương thức override (ghi đè) để đảm bảo rằng nó được gọi khi có yêu cầu RPC.
- Nó phải có kiểu trả về là Task<HelloReply> để đảm bảo rằng phương thức này trả về một kết quả.
- Nó phải có tham số đầu vào là HelloRequest request để nhận yêu cầu từ client.
- Nó phải có tham số thứ hai là ServerCallContext context để có thể truy cập vào thông tin về cuộc gọi RPC.
Vì vậy, phương thức SayHello phải được ghi đè như sau:
Lời giải
public override Task<HelloReply>SayHello(HelloRequest request, ServerCallContext context)
BgRPC Remote Procedure Calls (a recursive acronym)
CGeneral Routing and Procedure-Calling
DGraph-based Procedure Calls
Lời giải
gRPC là một framework được sử dụng để xây dựng các ứng dụng phân tán. Nó cho phép các ứng dụng giao tiếp với nhau qua các cuộc gọi thủ tục. gRPC Remote Procedure Calls (RPC) là một trong những tính năng chính của gRPC. Nó cho phép các ứng dụng gọi các thủ tục trên các máy chủ khác nhau và nhận lại kết quả. gRPC sử dụng giao thức HTTP/2 để truyền tải dữ liệu và cho phép các ứng dụng giao tiếp với nhau một cách hiệu quả. gRPC Remote Procedure Calls (a recursive acronym) là tên chính thức của gRPC, nó được thiết kế để cho phép các ứng dụng giao tiếp với nhau một cách hiệu quả và linh hoạt.
AThe ability for the client to push data to the server's cache.
BA security feature that pushes updates to the client.
CThe ability for the server to send resources to the client that it anticipates the client will need, without the client explicitly requesting them.
DA mechanism for streaming video content.
Lời giải
Trong HTTP/2, 'Server Push' là tính năng cho phép máy chủ gửi tài nguyên đến khách hàng mà không cần khách hàng yêu cầu rõ ràng. Điều này cho phép máy chủ dự đoán những tài nguyên mà khách hàng sẽ cần trong tương lai và gửi chúng trước khi khách hàng yêu cầu. Tính năng này giúp cải thiện hiệu suất và giảm thời gian tải trang. Ví dụ, nếu khách hàng đang xem trang web có nhiều hình ảnh, máy chủ có thể gửi hình ảnh đó đến khách hàng trước khi khách hàng yêu cầu, giúp trang web tải nhanh hơn. Tính năng Server Push là một trong những tính năng quan trọng của HTTP/2 và giúp cải thiện hiệu suất của giao tiếp giữa máy chủ và khách hàng.
CA long-lived connection to a gRPC service, which can be reused for multiple calls.
DA specific type of streaming method.
Lời giải
Trong gRPC, một "kênh" (channel) được định nghĩa là một kết nối lâu dài đến một dịch vụ gRPC, có thể được tái sử dụng cho nhiều cuộc gọi. Điều này cho phép các ứng dụng gRPC thực hiện nhiều cuộc gọi đến một dịch vụ mà không cần phải thiết lập lại kết nối mới. Mỗi kênh được tạo ra bằng cách gọi phương thức `CreateChannel` và nó được sử dụng để thực hiện các cuộc gọi đến dịch vụ gRPC. Kênh có thể được sử dụng để thực hiện các cuộc gọi một chiều, hai chiều hoặc streaming. Việc sử dụng kênh giúp cải thiện hiệu suất và giảm thiểu thời gian thiết lập kết nối.
AProtobuf is a human-readable text format, making it easier to debug.
BProtobuf uses a binary serialization format, which is typically smaller and faster to parse than text-based JSON.
CProtobuf is natively supported by all web browsers without any libraries.
DProtobuf has a more flexible schema that can be changed by the client at will.
Lời giải
Protobuf là một định dạng serialize binary, giúp giảm kích thước dữ liệu và tăng tốc độ parse so với định dạng JSON text-based. Điều này là do định dạng binary không cần phải được mã hóa thành chuỗi text như JSON, giúp giảm thiểu dữ liệu cần truyền tải và tăng tốc độ xử lý. Ngoài ra, định dạng binary cũng giúp giảm thiểu khả năng xảy ra lỗi khi truyền tải dữ liệu. Vì vậy, sử dụng Protobuf có thể giúp giảm thiểu thời gian truyền tải và tăng tốc độ xử lý dữ liệu, đặc biệt là khi cần truyền tải một lượng lớn dữ liệu.
