本文翻譯自?ASP.NET Blog | gRPC vs HTTP APIs，作者 James，譯者?Edison Zhou。

現在，ASP.NET Core使開發人員可以構建gRPC服務。gRPC是一個遠程過程調用框架，專注于高性能和開發人員的生產力。ASP.NET Core 3.0中集成了gRPC，因此您可以結合使用現有的ASP.NET Core日志系統，配置系統，身份驗證模式來構建新的gRPC服務。

這篇文章將gRPC與基于JSON的HTTP API進行了比較，討論了gRPC的優缺點，以及何時可以使用gRPC構建應用程序。

gRPC的優點

增強開發人員的生產力

???????使用gRPC服務，客戶端應用程序可以直接在不同計算機上的服務應用上調用方法，就好像它是本地對象一樣。gRPC基于定義服務的思想，指定可以通過傳遞參數和返回類型的遠程調用方法。服務器端，實現此接口并運行gRPC服務來處理客戶端調用。客戶端，使用強類型的gRPC客戶端，該客戶端提供與服務器相同的方法。

　　gRPC能夠實現對代碼生成的完美支持的目標。gpro開發的核心文件是.proto文件，該文件使用Protobuf接口定義語言（IDL）定義gRPC服務和消息的契約，例如下面這個Greet.proto文件所示：

Greet.proto
// The greeting service definition.service Greeter { // Sends a greeting rpc SayHello (HelloRequest) returns (HelloReply);}
// The request message containing the user's name.message HelloRequest { string name = 1;}
// The response message containing the greetingsmessage HelloReply { string message = 1;}

?　　Protobuf IDL是一種語言無關的語法，因此它可以在gRPC服務和不同語言實現的客戶端之間共享。gRPC框架使用.proto文件來生成服務基類、消息和完整客戶端的代碼進行編碼。例如，這里使用生成的強類型Greeter客戶端來調用服務：

Program.cs
var channel = GrpcChannel.ForAddress("https://localhost:5001")var client = new Greeter.GreeterClient(channel);
var reply = await client.SayHelloAsync(new HelloRequest { Name = "World" });Console.WriteLine("Greeting: " + reply.Message);

　　通過在服務器和客戶端之間共享.proto文件，可以端到端地生成消息和客戶端代碼。客戶端的代碼生成消除了客戶端和服務器上重復的消息定義，并為您創建了一個強類型的客戶端。無需編寫客戶端，可在擁有許多服務的應用程序中為開發者節省大量開發時間。

高性能

????? gRPC消息使用Protobuf（一種有效的二進制消息格式）進行序列化。Protobuf在服務器和客戶端上可以實現非常快速地序列化。Protobuf序列化產生的消息負載也較小，這在有限帶寬的移動應用程序等情況下很重要。

　　gRPC需要HTTP/2，這是HTTP的主要版本，與HTTP 1.x相比，它具有顯著的性能優勢：

• 二進制成幀和壓縮。HTTP/2協議在發送和接收方面都是緊湊高效的。

• 在單個TCP連接上多個HTTP/2調用的復用。復用消除了應用程序層的隊頭阻塞。

實時服務

????????HTTP/2為長期的實時通信流提供了基礎，gRPC為通過HTTP/2的流傳輸提供很好的支持。

　　gRPC服務支持所有流組合：

• 一元（無串流）

• 服務器到客戶端流

• 客戶端到服務器流

• 雙向流

　　請注意，將消息廣播到多個連接的概念本身并不天然存在于gRPC中。例如，在一個聊天室中，一個新的聊天消息應該發送到該聊天室中的所有客戶端，這就要求每個gRPC調用將新的聊天消息分別流式傳輸到客戶端。SignalR是此方案的一個適用框架，SignalR具有持久連接的概念，并內置了對廣播消息的支持。

超時措施 與 取消機制

?????? gRPC允許客戶端指定他們愿意等待一個RPC完成的最長時間。該期限被發送到服務器，服務器可以決定它是否超出了限期采取什么行動。例如，服務器可能會在超時后取消正在進行的gRPC/HTTP/數據庫請求。

　　通過子gRPC調用傳播最長時限和取消機制，有助于強制執行資源限制行為。

gRPC的缺點

有限的瀏覽器支持

????????gRPC具有出色的跨平臺支持！如今，gRPC已經有了多種編程語言的實現。但是，您仍然無法直接從瀏覽器中調用gRPC服務。gRPC大量使用了HTTP/2的功能，但卻沒有瀏覽器提供支持gRPC客戶端的Web請求所需的控制級別。例如，瀏覽器不允許調用者要求使用HTTP/2，或提供對HTTP/2協議之下的幀的訪問。

　　gRPC-Web是gRPC團隊的另一項技術，可在瀏覽器中提供有限的gRPC支持。gRPC-Web由兩部分組成：一個支持所有現代瀏覽器的JavaScript客戶端，以及服務器上的一個gRPC-Web代理。gRPC-Web客戶端調用代理，代理將gRPC請求轉發到gRPC服務器。

　　gRPC-Web并非支持所有gRPC的功能。例如，它不支持客戶端和雙向流，并且對服務器流的支持也很有限。

可讀性不高

???????使用JSON的HTTP API請求以文本形式發送，并且適合利于閱讀和創建。

　　默認情況下，gRPC消息使用Protobuf編碼。盡管Protobuf可以高效發送和接收，但其二進制格式不是很可讀的。Protobuf要求在.proto文件中指定的消息接口描述才能正確地反序列化。此外，還需要額外的工具來分析網絡上的Protobuf有效負載并手動編寫請求。

　　好在，已經有了一些諸如服務器反射和gRPC命令行工具之類的功能來輔助二進制Protobuf消息。另外，Protobuf消息也支持與JSON之間的轉換。內置的JSON轉換提供了一種在調試時將Protobuf消息與可讀的JSON形式之間相互轉換的有效方法。

gRPC建議使用場景

????gRPC非常適合以下情況：

• 微服務?– gRPC專為低延遲和高吞吐量通信而設計。gRPC對于效率至關重要的輕量級微服務非常有用。

• 點對點實時通信?– gRPC對雙向流具有出色的支持。gRPC服務可以實時推送消息而無需輪詢。

• 多種語言環境?– gRPC工具支持所有流行的開發語言，因此gRPC是多語言環境的理想選擇。

• 網絡受限的環境?– gRPC消息使用一種輕量級消息格式Protobuf進行序列化。gRPC消息的大小始終小于同等級別的JSON消息。

小結

???????gRPC是ASP.NET Core開發人員的一個強大的新工具。盡管gRPC不能完全替代HTTP API，但在某些情況下可以提供更高的生產率和性能優勢。

　　ASP.NET Core上的gRPC現在已經可用了！如果您想了解有關gRPC的更多信息，請查看以下資源：

• 閱讀gRPC for .NET Core文檔。

• 試用gRPC入門教程。

• 觀看gRPC for ASP.NET Core，這是一個高性能API的新框架，在NDC Sydney上介紹了gRPC的簡介。

　　此外，這里譯者也推薦一下俺們大成都的曉晨Master的最新博文系列：ASP.NET Core gRPC入門全家桶?。

恰童鞋騷年，風華也許不再正茂，但卻仍想揮斥方遒。

本公眾號會長期關注和分享.NET Core，Microservice，Cloud Native，DevOps等技術內容文章，還會與你分享個人生活成長的點滴及各類好書的讀書筆記，希望能對你有所幫助，一起成長！

點個【在看】，和更多人一起分享！

總結

以上是生活随笔為你收集整理的【译】gRPC vs HTTP APIs的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。