歡迎光臨
每天分享高質量文章

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

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

作者:依樂祝
原文鏈接:https://www.cnblogs.com/yilezhu/p/10645804.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 有興趣的小伙伴可以閱讀原文進行查看。

    赞(0)

    分享創造快樂