本文翻譯自 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的優點
1、增強開發人員的生產力
使用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 greetings message 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文件，可以端到端地生成消息和客戶端代碼。客戶端的代碼生成消除了客戶端和服務器上重復的消息定義，並為您創建了一個強類型的客戶端。無需編寫客戶端，可在擁有許多服務的應用程序中為開發者節省大量開發時間。
2、高性能
gRPC消息使用Protobuf（一種有效的二進制消息格式）進行序列化。Protobuf在服務器和客戶端上可以實現非常快速地序列化。Protobuf序列化產生的消息負載也較小，這在有限帶寬的移動應用程序等情況下很重要。
gRPC需要HTTP/2，這是HTTP的主要版本，與HTTP 1.x相比，它具有顯着的性能優勢：
- 二進制成幀和壓縮。HTTP/2協議在發送和接收方面都是緊湊高效的。
- 在單個TCP連接上多個HTTP/2調用的復用。復用消除了應用程序層的隊頭阻塞。
3、實時服務
HTTP/2為長期的實時通信流提供了基礎，gRPC為通過HTTP/2的流傳輸提供很好的支持。
gRPC服務支持所有流組合：
- 一元（無串流）
- 服務器到客戶端流
- 客戶端到服務器流
- 雙向流
請注意，將消息廣播到多個連接的概念本身並不天然存在於gRPC中。例如，在一個聊天室中，應將新的聊天消息發送到該聊天室中的所有客戶端，要求每個gRPC調用將新的聊天消息分別流式傳輸到客戶端。SignalR是此方案的一個適用框架，SignalR具有持久連接的概念，並內置了對廣播消息的支持。
4、超時措施 與 取消機制
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入門全家桶 。