本文翻譯自 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文件所示：
<code>Greet.proto/<code>
<code>// The greeting service definition./<code><code>service Greeter {/<code><code> // Sends a greeting/<code><code> rpc SayHello (HelloRequest) returns (HelloReply);/<code><code>}/<code>
<code>// The request message containing the user's name./<code><code>message HelloRequest {/<code><code> string name = 1;/<code><code>}/<code>
<code>// The response message containing the greetings/<code><code>message HelloReply {/<code><code> string message = 1;/<code><code>}/<code>
Protobuf IDL是一種語言無關的語法，因此它可以在gRPC服務和不同語言實現的客戶端之間共享。gRPC框架使用.proto文件來生成服務基類、消息和完整客戶端的代碼進行編碼。例如，這裡使用生成的強類型Greeter客戶端來調用服務：
<code>Program.cs/<code>
<code>var channel = GrpcChannel.ForAddress("https://localhost:5001")/<code><code>var client = new Greeter.GreeterClient(channel);/<code>
<code>var reply = await client.SayHelloAsync(new HelloRequest { Name = "World" });/<code><code>Console.WriteLine("Greeting: " + reply.Message);/<code>
通過在服務器和客戶端之間共享.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入門全家桶 。
恰童鞋騷年，風華也許不再正茂，但卻仍想揮斥方遒。
閱讀更多 心萊科技 的文章
