上一篇文章我帶著大家體驗了一把《 "ASP.NET Core 3.0 上的gRPC服務模板初體驗(多圖)" 》，如果有興趣的可以點擊鏈接進行查看，相信跟著做的你，也是可以跑起來的。這篇文章我們將一起來探討下gRPC服務如何與HTTP APIs進行比較。用於為應用程式提供API的技術是一個重要的選擇， ...
上一篇文章我帶著大家體驗了一把《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 有興趣的小伙伴可以閱讀原文進行查看。
