比較 gRPC 服務與 HTTP API
注意
這不是這篇文章的最新版本。 如需目前版本，請參閱本文的 .NET 8 版本。
警告
不再支援此版本的 ASP.NET Core。 如需詳細資訊，請參閱 .NET 和 .NET Core 支援原則。 如需目前版本，請參閱本文的 .NET 8 版本。
本文說明 gRPC 服務如何與具有 JSON 的 HTTP API 進行比較 (包括 ASP.NET Core Web API)。 用來為您的應用程式提供 API 的技術是一個重要的選擇，而且 gRPC 與 HTTP API 相較之下提供獨特的優點。 本文討論 gRPC 的優點和弱點，並建議優先使用 gRPC 而非其他技術的案例。
高階比較
下表提供 gRPC 與具有 JSON 之 HTTP API 間的高階功能比較。
| 功能 | gRPC | 搭配 JSON 的 HTTP API |
|---|---|---|
| 合約 | 必要 (.proto) |
選用 (OpenAPI) |
| 通訊協定 | HTTP/2 | HTTP |
| 承載 | Protobuf (小型、二進位) | JSON (大型、人類可讀) |
| 規範性 | 嚴格規格 | 鬆散。 任何 HTTP 都是有效的。 |
| 串流 | 用戶端、伺服器、雙向 | 用戶端、伺服器 |
| 瀏覽器支援 | 否 (需要 grpc-web) | Yes |
| 安全性 | 傳輸 (TLS) | 傳輸 (TLS) |
| 用戶端程式碼產生 | 是 | OpenAPI + 協力廠商工具 |
gRPC 強度
效能
gRPC 訊息是使用 Protobuf (一種有效率的二進位訊息格式) 進行序列化。 Protobuf 會在伺服器和用戶端上非常快速地序列化。 Protobuf 序列化會導致小型訊息承載，這在行動應用程式這類有限頻寬案例中十分重要。
gRPC 是針對 HTTP/2 所設計，而後者是 HTTP 的主要修訂，可透過 HTTP 1.x 提供顯著的效能優勢：
- 二進位框架和壓縮。 HTTP/2 通訊協定在傳送和接收方面都十分精簡且具效率。
- 透過單一 TCP 連線來多工處理多個 HTTP/2 呼叫。 多工處理會消除行首封鎖。
HTTP/2 不是 gRPC 所獨有。 許多要求類型 (包括具有 JSON 的 HTTP API) 都可以使用 HTTP/2，並受益於其效能改善。
程式碼產生
所有 gRPC 架構都會提供程式碼產生的第一級支援。 gRPC 開發的核心檔案是 .proto 檔案，而其定義 gRPC 服務和訊息的合約。 從此檔案中，gRPC 架構會產生服務基底類別、訊息和完整用戶端。
在伺服器與用戶端之間共用 .proto 檔案，即可從端對端產生訊息和用戶端程式碼。 用戶端的程式碼產生可消除用戶端和伺服器上的訊息重複，並為您建立強型別用戶端。 不需要撰寫用戶端，可在具有許多服務的應用程式中節省大量開發時間。
嚴格規格
搭配 JSON 的 HTTP API 的正式規格不存在。 開發人員會討論 URL、HTTP 動詞和回應碼的最佳格式。
gRPC 規格對於 gRPC 服務必須遵循的格式具有規範性。 gRPC 可消除爭論，並節省開發人員時間，因為 gRPC 在平台和實作之間是一致的。
串流
HTTP/2 提供長期即時通訊串流的基礎。 gRPC 提供透過 HTTP/2 進行串流的第一級支援。
gRPC 服務支援所有串流組合：
- 一元 (無串流)
- 伺服器對用戶端串流
- 用戶端對伺服器串流
- 雙向串流
期限/逾時和取消
gRPC 可讓用戶端指定他們願意等待 RPC 完成的時間長度。 期限會傳送至伺服器，而且伺服器可以決定超過期限時應該採取的動作。 例如，伺服器可能會在逾時時取消進行中 gRPC/HTTP/資料庫要求。
透過子系 gRPC 呼叫來傳播期限和取消，有助於強制執行資源使用量限制。
gRPC 建議案例
gRPC 非常適合下列案例：
- 微服務：gRPC 是針對低延遲和高輸送量通訊所設計。 gRPC 最適合首重效率的輕量型微服務。
- 點對點即時通訊：gRPC 對雙向串流具有絕佳的支援。 gRPC 服務可以在不輪詢的情況下即時推送訊息。
- Polyglot 環境：gRPC 工具支援所有常用開發語言，因此讓 gRPC 成為多語言環境的絕佳選擇。
- 網路限制環境：使用 Protobuf (一種輕量型訊息格式) 來序列化 gRPC 訊息。 gRPC 訊息一律會小於對等的 JSON 訊息。
- 處理序間通訊 (IPC)：Unix 網域通訊端和具名管道這類 IPC 傳輸可以與 gRPC 搭配使用，以在相同機器的應用程式之間進行通訊。 如需詳細資訊，請參閱與 gRPC 的處理程序間通訊。
gRPC 弱點
有限的瀏覽器支援
目前，您無法直接從瀏覽器呼叫 gRPC 服務。 gRPC 大量使用 HTTP/2 功能，而且沒有瀏覽器提供透過 Web 要求支援 gRPC 用戶端所需的控制層級。 例如，瀏覽器不允許呼叫端要求使用 HTTP/2，或提供基礎 HTTP/2 框架的存取權。
ASP.NET Core 上的 gRPC 提供兩個瀏覽器相容方案：
gRPC-Web 允許瀏覽器應用程式使用 gRPC-Web 用戶端和 Protobuf 來呼叫 gRPC 服務。 gRPC-Web 需要瀏覽器應用程式產生 gRPC 用戶端。 gRPC-Web 可讓瀏覽器應用程式受益於 gRPC 的高效能和低網路使用量。
.NET 具有 gRPC-Web 的內建支援。 如需詳細資訊，請參閱 ASP.NET Core gRPC 應用程式中的 gRPC-Web。
gRPC JSON 轉碼可讓瀏覽器應用程式呼叫 gRPC 服務，就像它們是具有 JSON 的 RESTful API 一樣。 瀏覽器應用程式不需要產生 gRPC 用戶端或知道 gRPC 的任何資訊。 使用 HTTP 中繼資料來標註
.proto檔案，可以自動從 gRPC 服務建立 RESTful API。 轉碼允許應用程式同時支援 gRPC 和 JSON Web API，而不需要複製為兩者建置個別服務的工作。.NET 具有從 gRPC 服務建立 JSON Web API 的內建支援。 如需詳細資訊，請參閱 ASP.NET Core gRPC 應用程式中 的 gRPC JSON 轉碼。
注意
gRPC JSON 轉碼需要 .NET 7 或更新版本。
人類無法讀取
HTTP API 要求會以文字形式傳送，而且人們可以進行讀取和建立。
預設會使用 Protobuf 來編碼 gRPC 訊息。 雖然 Protobuf 可效率地傳送和接收，但人類無法讀取其二進位格式。 Protobuf 需要 .proto 檔案中所指定的訊息介面描述，才能正確還原序列化。 需要額外的工具，才能分析線路上的 Protobuf 承載，並手動撰寫要求。
具有伺服器反映和 gRPC 命令列工具這類功能，可協助處理二進位 Protobuf 訊息。 此外，Protobuf 訊息支援與 JSON 之間的來回轉換。 內建 JSON 轉換提供有效率方式，以在偵錯時，將 Protobuf 訊息轉換成人類可讀形式，以及將人類可讀形式轉換成 Protobuf 訊息。
替代架構案例
在下列案例中，建議優先使用其他架構，而不是 gRPC：
- 瀏覽器可存取的 API：瀏覽器中未完全支援 gRPC。 gRPC-Web 可以提供瀏覽器支援，但有其限制，並引進伺服器 Proxy。
- 廣播即時通訊：gRPC 支援透過串流進行即時通訊，但沒有向已登錄連線廣播訊息的概念。 例如，在應該將新聊天訊息傳送給聊天室中所有用戶端的聊天室案例中，需要每個 gRPC 呼叫，才能將新的聊天訊息個別串流至用戶端。 SignalR 是此案例的有用架構。 SignalR 具有持續性連線的概念，以及廣播訊息的內建支援。
