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

現(xiàn)在，ASP.NET Core使開發(fā)人員可以構(gòu)建gRPC服務(wù)。gRPC是一個(gè)遠(yuǎn)程過程調(diào)用框架，專注于高性能和開發(fā)人員的生產(chǎn)力。ASP.NET Core 3.0中集成了gRPC，因此您可以結(jié)合使用現(xiàn)有的ASP.NET Core日志系統(tǒng)，配置系統(tǒng)，身份驗(yàn)證模式來構(gòu)建新的gRPC服務(wù)。

這篇文章將gRPC與基于JSON的HTTP API進(jìn)行了比較，討論了gRPC的優(yōu)缺點(diǎn)，以及何時(shí)可以使用gRPC構(gòu)建應(yīng)用程序。

gRPC的優(yōu)點(diǎn)

增強(qiáng)開發(fā)人員的生產(chǎn)力

???????使用gRPC服務(wù)，客戶端應(yīng)用程序可以直接在不同計(jì)算機(jī)上的服務(wù)應(yīng)用上調(diào)用方法，就好像它是本地對(duì)象一樣。gRPC基于定義服務(wù)的思想，指定可以通過傳遞參數(shù)和返回類型的遠(yuǎn)程調(diào)用方法。服務(wù)器端，實(shí)現(xiàn)此接口并運(yùn)行g(shù)RPC服務(wù)來處理客戶端調(diào)用。客戶端，使用強(qiáng)類型的gRPC客戶端，該客戶端提供與服務(wù)器相同的方法。

　　gRPC能夠?qū)崿F(xiàn)對(duì)代碼生成的完美支持的目標(biāo)。gpro開發(fā)的核心文件是.proto文件，該文件使用Protobuf接口定義語言（IDL）定義gRPC服務(wù)和消息的契約，例如下面這個(gè)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是一種語言無關(guān)的語法，因此它可以在gRPC服務(wù)和不同語言實(shí)現(xiàn)的客戶端之間共享。gRPC框架使用.proto文件來生成服務(wù)基類、消息和完整客戶端的代碼進(jìn)行編碼。例如，這里使用生成的強(qiáng)類型Greeter客戶端來調(diào)用服務(wù)：

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);

　　通過在服務(wù)器和客戶端之間共享.proto文件，可以端到端地生成消息和客戶端代碼。客戶端的代碼生成消除了客戶端和服務(wù)器上重復(fù)的消息定義，并為您創(chuàng)建了一個(gè)強(qiáng)類型的客戶端。無需編寫客戶端，可在擁有許多服務(wù)的應(yīng)用程序中為開發(fā)者節(jié)省大量開發(fā)時(shí)間。

高性能

????? gRPC消息使用Protobuf（一種有效的二進(jìn)制消息格式）進(jìn)行序列化。Protobuf在服務(wù)器和客戶端上可以實(shí)現(xiàn)非常快速地序列化。Protobuf序列化產(chǎn)生的消息負(fù)載也較小，這在有限帶寬的移動(dòng)應(yīng)用程序等情況下很重要。

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

• 二進(jìn)制成幀和壓縮。HTTP/2協(xié)議在發(fā)送和接收方面都是緊湊高效的。

• 在單個(gè)TCP連接上多個(gè)HTTP/2調(diào)用的復(fù)用。復(fù)用消除了應(yīng)用程序?qū)拥年?duì)頭阻塞。

實(shí)時(shí)服務(wù)

????????HTTP/2為長(zhǎng)期的實(shí)時(shí)通信流提供了基礎(chǔ)，gRPC為通過HTTP/2的流傳輸提供很好的支持。

　　gRPC服務(wù)支持所有流組合：

• 一元（無串流）

• 服務(wù)器到客戶端流

• 客戶端到服務(wù)器流

• 雙向流

　　請(qǐng)注意，將消息廣播到多個(gè)連接的概念本身并不天然存在于gRPC中。例如，在一個(gè)聊天室中，一個(gè)新的聊天消息應(yīng)該發(fā)送到該聊天室中的所有客戶端，這就要求每個(gè)gRPC調(diào)用將新的聊天消息分別流式傳輸?shù)娇蛻舳恕ignalR是此方案的一個(gè)適用框架，SignalR具有持久連接的概念，并內(nèi)置了對(duì)廣播消息的支持。

超時(shí)措施 與 取消機(jī)制

?????? gRPC允許客戶端指定他們?cè)敢獾却粋€(gè)RPC完成的最長(zhǎng)時(shí)間。該期限被發(fā)送到服務(wù)器，服務(wù)器可以決定它是否超出了限期采取什么行動(dòng)。例如，服務(wù)器可能會(huì)在超時(shí)后取消正在進(jìn)行的gRPC/HTTP/數(shù)據(jù)庫請(qǐng)求。

　　通過子gRPC調(diào)用傳播最長(zhǎng)時(shí)限和取消機(jī)制，有助于強(qiáng)制執(zhí)行資源限制行為。

gRPC的缺點(diǎn)

有限的瀏覽器支持

????????gRPC具有出色的跨平臺(tái)支持！如今，gRPC已經(jīng)有了多種編程語言的實(shí)現(xiàn)。但是，您仍然無法直接從瀏覽器中調(diào)用gRPC服務(wù)。gRPC大量使用了HTTP/2的功能，但卻沒有瀏覽器提供支持gRPC客戶端的Web請(qǐng)求所需的控制級(jí)別。例如，瀏覽器不允許調(diào)用者要求使用HTTP/2，或提供對(duì)HTTP/2協(xié)議之下的幀的訪問。

　　gRPC-Web是gRPC團(tuán)隊(duì)的另一項(xiàng)技術(shù)，可在瀏覽器中提供有限的gRPC支持。gRPC-Web由兩部分組成：一個(gè)支持所有現(xiàn)代瀏覽器的JavaScript客戶端，以及服務(wù)器上的一個(gè)gRPC-Web代理。gRPC-Web客戶端調(diào)用代理，代理將gRPC請(qǐng)求轉(zhuǎn)發(fā)到gRPC服務(wù)器。

　　gRPC-Web并非支持所有g(shù)RPC的功能。例如，它不支持客戶端和雙向流，并且對(duì)服務(wù)器流的支持也很有限。

可讀性不高

???????使用JSON的HTTP API請(qǐng)求以文本形式發(fā)送，并且適合利于閱讀和創(chuàng)建。

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

　　好在，已經(jīng)有了一些諸如服務(wù)器反射和gRPC命令行工具之類的功能來輔助二進(jìn)制Protobuf消息。另外，Protobuf消息也支持與JSON之間的轉(zhuǎn)換。內(nèi)置的JSON轉(zhuǎn)換提供了一種在調(diào)試時(shí)將Protobuf消息與可讀的JSON形式之間相互轉(zhuǎn)換的有效方法。

gRPC建議使用場(chǎng)景

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

• 微服務(wù)?– gRPC專為低延遲和高吞吐量通信而設(shè)計(jì)。gRPC對(duì)于效率至關(guān)重要的輕量級(jí)微服務(wù)非常有用。

• 點(diǎn)對(duì)點(diǎn)實(shí)時(shí)通信?– gRPC對(duì)雙向流具有出色的支持。gRPC服務(wù)可以實(shí)時(shí)推送消息而無需輪詢。

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

• 網(wǎng)絡(luò)受限的環(huán)境?– gRPC消息使用一種輕量級(jí)消息格式Protobuf進(jìn)行序列化。gRPC消息的大小始終小于同等級(jí)別的JSON消息。

小結(jié)

???????gRPC是ASP.NET Core開發(fā)人員的一個(gè)強(qiáng)大的新工具。盡管gRPC不能完全替代HTTP API，但在某些情況下可以提供更高的生產(chǎn)率和性能優(yōu)勢(shì)。

　　ASP.NET Core上的gRPC現(xiàn)在已經(jīng)可用了！如果您想了解有關(guān)gRPC的更多信息，請(qǐng)查看以下資源：

• 閱讀gRPC for .NET Core文檔。

• 試用gRPC入門教程。

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

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

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

本公眾號(hào)會(huì)長(zhǎng)期關(guān)注和分享.NET Core，Microservice，Cloud Native，DevOps等技術(shù)內(nèi)容文章，還會(huì)與你分享個(gè)人生活成長(zhǎng)的點(diǎn)滴及各類好書的讀書筆記，希望能對(duì)你有所幫助，一起成長(zhǎng)！

點(diǎn)個(gè)【在看】，和更多人一起分享！

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。