進行API開發選gRPC仍是HTTP APIs?

上一篇文章我帶着你們體驗了一把《ASP.NET Core 3.0 上的gRPC服務模板初體驗(多圖)》，若是有興趣的能夠點擊連接進行查看，相信跟着作的你，也是能夠跑起來的。這篇文章咱們將一塊兒來探討下gRPC服務如何與HTTP APIs進行比較。用於爲應用程序提供API的技術是一個重要的選擇，與HTTP API相比，gRPC提供了獨特的優點。本文從gRPC的優缺點出發，並推薦了一些建議使用gRPC服務以及不建議使用gRPC服務的場景。

做者：依樂祝
原文連接：http://www.javashuo.com/article/p-vfomifku-kp.html

開始以前先看一下gRPC與帶有j'son的HTTP APIs對比表格

gRPC的優點

性能

gRPC消息使用一種有效的二進制消息格式protobuf進行序列化。Protobuf在服務器和客戶機上的序列化很是快。Protobuf序列化後的消息體積很小，可以有效負載，在移動應用程序等有限帶寬場景中顯得很重要。

gRPC是爲HTTP/2而設計的，它是HTTP的一個主要版本，與HTTP 1.x相比具備顯著的性能優點：：

• 二進制框架和壓縮。HTTP/2協議在發送和接收方面都很緊湊和高效。
• 經過單個TCP鏈接複用多個HTTP/2調用。多路複用消除了線頭阻塞。

代碼生成

全部gRPC框架都爲代碼生成提供了一流的支持。gRPC開發的核心文件是*.proto文件 ，它定義了gRPC服務和消息的約定。根據這個文件，gRPC框架將生成服務基類，消息和完整的客戶端代碼。

經過在服務器和客戶端之間共享*.proto文件，能夠從端到端生成消息和客戶端代碼。客戶端的代碼生成消除了客戶端和服務器上的重複消息，併爲您建立了一個強類型的客戶端。無需編寫客戶端代碼，可在具備許多服務的應用程序中節省大量開發時間。

嚴格的規範

不存在具備JSON的HTTP API的正式規範。開發人員不須要討論URL，HTTP動詞和響應代碼的最佳格式。（想一想，是用Post仍是Get好？使用Get仍是用Put好？一想到有選擇恐懼症的你是否是又開了糾結，而後浪費了大量的時間）

該gRPC規範是規定有關gRPC服務必須遵循的格式。gRPC消除了爭論並節省了開發人員的時間，由於gPRC在各個平臺和實現之間是一致的。

流

HTTP/2爲長期的實時通訊流提供了基礎。gRPC經過HTTP/2爲流媒體提供一流的支持。

gRPC服務支持全部流組合：

• 一元（沒有流媒體）
• 服務器到客戶端流
• 客戶端到服務器流
• 雙向流媒體

截至時間/超時和取消

gRPC容許客戶端指定他們願意等待RPC完成的時間。該期限被髮送到服務端，服務端能夠決定在超出了限期時採起什麼行動。例如，服務器可能會在超時時取消正在進行的gRPC / HTTP /數據庫請求。

經過子gRPC調用截至時間和取消操做有助於實施資源使用限制。

推薦使用gRPC的場景

gRPC很是適合如下場景：

• 微服務 - gRPC設計爲低延遲和高吞吐量通訊。gRPC很是適用於效率相當重要的輕型微服務。
• 點對點實時通訊 - gRPC對雙向流媒體提供出色的支持。gRPC服務能夠實時推送消息而無需輪詢。
• 多語言混合開發環境 - gRPC工具支持全部流行的開發語言，使gRPC成爲多語言開發環境的理想選擇。
• 網絡受限環境 - 使用Protobuf（一種輕量級消息格式）序列化gRPC消息。gRPC消息始終小於等效的JSON消息。

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功能。不支持客戶端和雙向流，而且對服務器流的支持有限。

不是人類可讀的

HTTP API請求以文本形式發送，能夠由人讀取和建立。

默認狀況下，gRPC消息使用protobuf編碼。雖然protobuf的發送和接收效率很高，但它的二進制格式是不可讀的。protobuf須要在*.proto文件中指定的消息接口描述才能正確反序列化。須要額外的工具來分析線路上的Protobuf有效負載，並手工編寫請求。

存在諸如服務器反射和gRPC命令行工具等功能，以幫助處理二進制protobuf消息。另外，Protobuf消息支持與JSON之間的轉換。內置的JSON轉換提供了一種有效的方法，能夠在調試時將Protobuf消息轉換爲可讀的形式。

不建議使用gRPC的場景

在如下場景中，建議使用其餘框架而不是gRPC：

• 瀏覽器可訪問的API - 瀏覽器不徹底支持gRPC。gRPC-Web能夠提供瀏覽器支持，但它有侷限性並引入了服務器代理。
• 廣播實時通訊 - gRPC支持經過流媒體進行實時通訊，但不存在向已註冊鏈接廣播消息的概念。例如，在應該將新聊天消息發送到聊天室中的全部客戶端的聊天室場景中，須要每一個gRPC呼叫以單獨地將新的聊天消息流傳輸到客戶端。對於這種場景，SignalR是這種狀況的有用框架。SignalR具備持久鏈接的概念和對廣播消息的內置支持。
• 進程間通訊 - 進程必須承載HTTP/2服務才能接受傳入的gRPC調用。對於Windows，進程間通訊管道是一種快速，輕量級的通訊方法。

總結

繼上一篇介紹了《ASP.NET Core 3.0 上的gRPC服務模板初體驗(多圖)》後，咱們又一塊兒來探討了一下gRPC服務的優缺點並給出了gRPC的一些使用場景以及非適用場景，但願對你們的使用有所幫助。最後感謝你們的閱讀。另外，文中大多內容來自於https://docs.microsoft.com/en-us/aspnet/core/gRPC/comparison?view=aspnetcore-3.0 有興趣的小夥伴能夠閱讀原文進行查看。