知識星球
上一篇文章我帶著大家體驗了一把《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 有興趣的小夥伴可以閱讀原文進行檢視。
