ASP.NET Core: So sánh các dịch vụ gRPC với API HTTP

Trong bài viết này

1. So sánh cấp cao
2. Điểm mạnh của gRPC
3. Kịch bản được đề xuất gRPC
4. Điểm yếu của gRPC
5. Kịch bản framework thay thế
6. Tài nguyên bổ sung

Bài viết này giải thích cách so sánh các dịch vụ gRPC với API HTTP có JSON (bao gồm API web ASP.NET Core). Công nghệ dùng để cung cấp API cho ứng dụng của bạn là một lựa chọn quan trọng và gRPC mang lại những lợi ích độc đáo so với API HTTP. Bài viết này thảo luận về điểm mạnh và điểm yếu của gRPC và đề xuất các kịch bản sử dụng gRPC thay vì các công nghệ khác.

So sánh cấp cao

Bảng sau đây cung cấp bảng so sánh cấp cao về các tính năng giữa gRPC và API HTTP với JSON.

Điểm mạnh của gRPC

Hiệu suất

Tin nhắn gRPC được tuần tự hóa bằng Protobuf, một định dạng tin nhắn nhị phân hiệu quả. Protobuf tuần tự hóa rất nhanh trên máy chủ và máy khách. Việc tuần tự hóa Protobuf dẫn đến tải trọng tin nhắn nhỏ, điều quan trọng trong các tình huống băng thông hạn chế như ứng dụng dành cho thiết bị di động.

gRPC được thiết kế cho HTTP/2, một phiên bản chính của HTTP mang lại những lợi ích đáng kể về hiệu suất so với HTTP 1.x:

• Đóng khung và nén nhị phân. Giao thức HTTP/2 nhỏ gọn và hiệu quả cả trong việc gửi và nhận.
• Ghép nhiều lời gọi HTTP/2 qua một kết nối TCP. Ghép kênh giúp loại bỏ việc chặn đầu dòng.

HTTP/2 không dành riêng cho gRPC. Nhiều loại yêu cầu, bao gồm API HTTP với JSON, có thể sử dụng HTTP/2 và hưởng lợi từ những cải tiến về hiệu suất của nó.

Tạo mã

Tất cả các framework gRPC đều cung cấp hỗ trợ hạng nhất cho việc tạo mã. Tệp cốt lõi để phát triển gRPC là tệp .proto xác định hợp đồng của các dịch vụ và tin nhắn gRPC. Từ tệp này, các framework gRPC tạo ra một lớp cơ sở dịch vụ, các thông báo và một ứng dụng khách hoàn chỉnh.

Bằng cách chia sẻ tệp .proto giữa máy chủ và máy khách, tin nhắn và mã máy khách có thể được tạo từ đầu đến cuối. Việc tạo mã của máy khách sẽ loại bỏ sự trùng lặp các thông báo trên máy khách và máy chủ, đồng thời tạo ra một máy khách có định kiểu mạnh cho bạn. Không cần phải viết ứng dụng khách giúp tiết kiệm đáng kể thời gian phát triển trong các ứng dụng có nhiều dịch vụ.

Đặc tả kỹ thuật nghiêm ngặt

Thông số kỹ thuật chính thức cho API HTTP có JSON không tồn tại. Các nhà phát triển tranh luận về định dạng tốt nhất của URL, HTTP Verb và mã phản hồi.

Đặc tả gRPC mang tính quy định về định dạng mà dịch vụ gRPC phải tuân theo. gRPC loại bỏ tranh luận và tiết kiệm thời gian của nhà phát triển vì gRPC nhất quán trên các nền tảng và quá trình triển khai.

Truyền phát

HTTP/2 cung cấp nền tảng cho các luồng giao tiếp thời gian thực, tồn tại lâu dài. gRPC cung cấp hỗ trợ hạng nhất để truyền phát qua HTTP/2.

Dịch vụ gRPC hỗ trợ tất cả các kết hợp phát trực tuyến:

• Unary (không truyền phát)
• Truyền phát từ máy chủ đến máy khách
• Truyền phát từ máy khách đến máy chủ
• Truyền phát hai chiều

Hạn chót/hết thời gian và hủy bỏ

gRPC cho phép máy khách chỉ định khoảng thời gian chúng sẵn sàng đợi RPC hoàn thành. Thời hạn được gửi đến máy chủ và máy chủ có thể quyết định hành động cần thực hiện nếu vượt quá thời hạn. Ví dụ: máy chủ có thể hủy các yêu cầu gRPC/HTTP/cơ sở dữ liệu đang diễn ra khi hết thời gian chờ.

Truyền đạt về thời hạn và hủy bỏ thông qua các lệnh gọi gRPC con giúp thực thi các giới hạn sử dụng tài nguyên.

Kịch bản được đề xuất gRPC

gRPC rất phù hợp với các tình huống sau:

• Microservices: gRPC được thiết kế để giao tiếp có độ trễ thấp và thông lượng cao. gRPC rất phù hợp cho các vi dịch vụ nhẹ, nơi hiệu quả là rất quan trọng.
• Giao tiếp thời gian thực điểm-điểm: gRPC hỗ trợ tuyệt vời cho truyền phát hai chiều. Dịch vụ gRPC có thể đẩy tin nhắn trong thời gian thực mà không cần bỏ phiếu (polling).
• Môi trường đa ngôn ngữ: Công cụ gRPC hỗ trợ tất cả các ngôn ngữ phát triển phổ biến, khiến gRPC trở thành một lựa chọn tốt cho môi trường đa ngôn ngữ.
• Môi trường hạn chế về mạng: tin nhắn gRPC được tuần tự hóa bằng Protobuf, một định dạng tin nhắn nhẹ. Tin nhắn gRPC luôn nhỏ hơn tin nhắn JSON tương ứng.
• Giao tiếp giữa các tiến trình (IPC): Các phương thức vận chuyển IPC như socket miền Unix và các đường ống được đặt tên có thể được sử dụng với gRPC để giao tiếp giữa các ứng dụng trên cùng một máy. Để biết thêm thông tin, hãy xem Giao tiếp giữa các tiến trình với gRPC.

Điểm yếu của gRPC

Hỗ trợ trình duyệt hạn chế

Hiện tại, không thể gọi trực tiếp dịch vụ gRPC từ trình duyệt. gRPC sử dụng nhiều tính năng HTTP/2 và không có trình duyệt nào cung cấp mức độ kiểm soát cần thiết đối với các yêu cầu web để hỗ trợ máy khách gRPC. Ví dụ: trình duyệt không cho phép trình gọi yêu cầu sử dụng HTTP/2 hoặc cung cấp quyền truy cập vào các framework HTTP/2 cơ bản.

gRPC trên ASP.NET Core cung cấp hai giải pháp tương thích với trình duyệt:

• gRPC-Web cho phép các ứng dụng trình duyệt gọi các dịch vụ gRPC bằng máy khách gRPC-Web và Protobuf. gRPC-Web yêu cầu ứng dụng trình duyệt tạo máy khách gRPC. gRPC-Web cho phép các ứng dụng trình duyệt được hưởng lợi từ việc sử dụng gRPC hiệu suất cao và mạng thấp.

  .NET có hỗ trợ tích hợp cho gRPC-Web. Để biết thêm thông tin, hãy xem gRPC-Web trong ứng dụng gRPC ASP.NET Core.

• Chuyển mã JSON gRPC cho phép các ứng dụng trình duyệt gọi các dịch vụ gRPC như thể chúng là các API RESTful có JSON. Ứng dụng trình duyệt không cần tạo ứng dụng khách gRPC hoặc biết bất kỳ điều gì về gRPC. API RESTful có thể được tạo tự động từ các dịch vụ gRPC bằng cách chú thích tệp .proto bằng siêu dữ liệu HTTP. Chuyển mã cho phép ứng dụng hỗ trợ cả API web gRPC và JSON mà không cần nỗ lực xây dựng các dịch vụ riêng biệt cho cả hai.

  .NET có hỗ trợ tích hợp để tạo API web JSON từ các dịch vụ gRPC. Để biết thêm thông tin, hãy xem Chuyển mã JSON gRPC trong ứng dụng gRPC ASP.NET Core.

Ghi chú

Chuyển mã JSON gRPC yêu cầu .NET 7 trở lên.

Con người không thể đọc được

Yêu cầu API HTTP được gửi dưới dạng văn bản và con người có thể đọc và tạo.

Tin nhắn gRPC được mã hóa bằng Protobuf theo mặc định. Mặc dù Protobuf có thể gửi và nhận hiệu quả nhưng định dạng nhị phân của nó không thể đọc được. Protobuf yêu cầu mô tả giao diện của thông báo được chỉ định trong tệp .proto để giải tuần tự hóa đúng cách. Cần có công cụ bổ sung để phân tích tải trọng Protobuf trên dây và soạn yêu cầu bằng tay.

Các tính năng như phản ánh máy chủ và công cụ dòng lệnh gRPC tồn tại để hỗ trợ các thông báo Protobuf nhị phân. Ngoài ra, thông báo Protobuf hỗ trợ chuyển đổi sang và từ JSON. Tính năng chuyển đổi JSON tích hợp cung cấp một cách hiệu quả để chuyển đổi các tin nhắn Protobuf sang và từ dạng con người có thể đọc được khi gỡ lỗi.

Kịch bản framework thay thế

Các framework khác được đề xuất trên gRPC trong các trường hợp sau:

• API có thể truy cập trình duyệt: gRPC không được hỗ trợ đầy đủ trong trình duyệt. gRPC-Web có thể cung cấp hỗ trợ trình duyệt, nhưng nó có những hạn chế và giới thiệu proxy máy chủ.
• Phát sóng liên lạc theo thời gian thực: gRPC hỗ trợ liên lạc theo thời gian thực thông qua truyền phát, nhưng khái niệm truyền phát tin nhắn tới các kết nối đã đăng ký không tồn tại. Ví dụ: trong kịch bản phòng trò chuyện trong đó các tin nhắn trò chuyện mới sẽ được gửi đến tất cả các máy khách trong phòng trò chuyện, mỗi lời gọi gRPC được yêu cầu phải truyền phát riêng lẻ các tin nhắn trò chuyện mới đến máy khách. SignalR là một framework hữu ích cho kịch bản này. SignalR có khái niệm về kết nối liên tục và hỗ trợ tích hợp để phát tin nhắn.

Tài nguyên bổ sung

• Tạo máy khách và máy chủ .NET Core gRPC trong ASP.NET Core
• Tổng quan về gRPC trên .NET
• Dịch vụ gRPC với C#
• Di chuyển gRPC từ C-core sang gRPC cho .NET