1.什么是gRPC

gRPC是rpc框架中的一種，是rpc中的大哥

是一個高性能，開源和通用的RPC框架，基于Protobuf序列化協(xié)議開發(fā)，且支持眾多開發(fā)語言。

面向服務端和協(xié)議端，基于http/2設計，帶來諸如雙向流，流控，頭部壓縮，單TCP連接上的多路復用請求等特性。這些特性使得其在移動設備上表現的更好，更省電和節(jié)省空間。

在gPRC里客戶端可以向調用本地對象一樣直接調用另一臺不同機器上服務端應用的方法，使得您能夠更容易地創(chuàng)建分布式應用和服務。

與許多RPC系統(tǒng)類似，gRPC也是基于以下理念：定義一個服務，指定其能夠被遠程調用的方法（包含參數和返回類型）。在服務端實現這個接口。并運行一個gRPC服務器來處理客戶端調用。在客戶端擁有一個存根能夠向服務端一樣的方法。

補充一個知識點（HTTP/2 與HTTP1.X的區(qū)別）

用于數據傳輸的二進制分幀

HTTP/2采用二進制格式傳輸協(xié)議，而非HTTP/1.x的文本格式。

多路復用

HTTP/2支持通過同一個連接發(fā)送多個并發(fā)的請求。

而HTTP/1.x雖然通過pipeline也能并發(fā)請求，但多個請求之間的響應依然會被阻塞。

服務端推送

服務端推送是一種在客戶端請求之前發(fā)送數據的機制。在HTTP/2中，服務器可以對客戶端的一個請求發(fā)送多個響應。而不像HTTP/1.X一樣，只能通過客戶端發(fā)起request,服務端才產生對應的response。

減少網絡流量的頭部壓縮。

HTTP/2對消息頭進行了壓縮傳輸，能夠節(jié)省消息頭占用的網絡流量。至于如何壓縮的，可以查看這篇：HPACK: Header Compression for HTTP/2[1]

2.gRPC大致請求流程

1.客戶端(gRPC Stub)調用A方法，發(fā)起RPC調用

2.對請求信息使用Protobuf進行對象序列化壓縮（IDL）

3.服務端（gPRC Server)接收到請求后，解碼請求體，進行業(yè)務邏輯處理并返回。

4.對響應結果使用Protobuf進行對象序列化壓縮（IDL）

5.客戶端接受到服務端響應，解碼請求體。回調被調用的A方法，喚醒正在等待響應（阻塞）的客戶端調用并返回響應結果

3.gRPC的優(yōu)勢

性能

gRPC消息使用一種有效的二進制消息格式protobuf繼續(xù)寧序列化。Protobuf在服務器和客戶機上的序列化非?？臁rotobuf序列化之后的消息體積很小，能夠有效負載，在移動應用程序等有限寬帶場景中顯得很重要。與采用文本格式的json相比，采用二進制格式的protobuf在速度上可以達到前者的5倍

代碼生成

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

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

嚴格的規(guī)范

不存在具有JSON的HTTP API的正事規(guī)范。開發(fā)人員不需要討論URL，HTTP動詞和響應代碼的最佳格式。（不需要考慮用post還是get，get還是put)

該gRPC規(guī)范是規(guī)定有關gPRC服務必須遵循的格式。gRPC消除了爭論并節(jié)省了開發(fā)人員的時間，因為gRPC在各個平臺上和實現之間是一致的

流

gRPC服務支持所有流組合：

• 一元（沒有媒體流）：最簡單的rpc調用，一個請求對象對應一個返回對象?？蛻舳税l(fā)起一次請求客戶端相應一個數據，即標準的RPC通信。
• 服務器到客戶端流：客戶端流式rpc客戶端傳入多個請求對象。服務端返回一個響應結果。應用場景：物聯(lián)網終端向服務器報送數據。
• 客戶端到服務器流：服務端流式rpc一個請求對象，服務端可以傳回多個結果對象。服務端流PRC下，客戶端發(fā)出一個請求，但不會立即得到一個響應，而是在服務器與客戶端之間建立一個單向的流，不斷獲取響應直到流關閉。應用場景舉例：典型的例子是客戶端向服務端發(fā)送一個股票代碼，服務端就把該股票的實時數據源源不斷的返回客戶端
• 雙向流媒體：雙向流式RPC結合客戶端流式RPC和服務端流式RPC，可以傳入多個對象，返回多個響應對象。應用場景：聊天應用

截至時間/超時和取消

gRPC允許客戶端指定他們愿意等待RPC完成時間。該期限被發(fā)送到服務端，服務端可以決定在超出了期限時采取什么行動，例如，服務器可能會在超時時取消正在進行的gPRC/HTTP/數據庫請求

通過子gRPC調用截至時間和取消操作有助于實施資源使用限制

4.gRPC的劣勢

瀏覽器支持有限

當下，不能從瀏覽器調用gRPC服務 ,

gRPC Web是gRPC團隊的一項附加技術，它在瀏覽器中提供有限的gRPC支持。gRPC Web由兩部分組成：支持所有現代瀏覽器的JavaScript客戶端和服務器上的gRPC Web代理。gRPC Web客戶端調用代理，代理將在gRPC請求上轉發(fā)到gRPC服務器。

gRPC Web并非支持所有gRPC功能。不支持客戶端和雙向流，并且對服務器流的支持有限。

不是人類可讀的

HTTP API請求以文本形式發(fā)送，可以由人讀取和創(chuàng)建。

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

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

5.使用場景

建議使用的場景：

• 微服務：gRPC設計為低延遲和高吞吐量通信，非常適用效率至關重要的輕型微服務
• 點對點實時通信：gRPC可以實時推送消息而無需輪詢
• 多語言混合開發(fā)環(huán)境：支持所有流行開發(fā)語言
• 網絡受限環(huán)境：使用Protobuf(一種輕量級消息格式)序列化gRPC消息。gRPC消息始終小于等效的JSON消息
• 不建議使用場景：
• 瀏覽器可訪問的API：瀏覽器不支持gRPC,gRPC-Web有局限性而且還引入了服務器代理
• 廣播實時通信
• 進程間通信

 到此這篇關于什么是gRPC的文章就介紹到這了,更多相關gRPC內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論