什么是gRPC

更新時間：2023年05月10日 09:00:53 作者：ZtCling

本文主要介紹了什么是gRPC，文中通過示例代碼介紹的非常詳細，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

1.什么是gRPC

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

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

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

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

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

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

用于數(shù)據(jù)傳輸?shù)亩M制分幀

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

多路復(fù)用

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

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

服務(wù)端推送

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

減少網(wǎng)絡(luò)流量的頭部壓縮。

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

2.gRPC大致請求流程

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

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

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

4.對響應(yīng)結(jié)果使用Protobuf進行對象序列化壓縮（IDL）

5.客戶端接受到服務(wù)端響應(yīng)，解碼請求體?；卣{(diào)被調(diào)用的A方法，喚醒正在等待響應(yīng)（阻塞）的客戶端調(diào)用并返回響應(yīng)結(jié)果

3.gRPC的優(yōu)勢

性能

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

代碼生成

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

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

嚴(yán)格的規(guī)范

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

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

流

gRPC服務(wù)支持所有流組合：

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

截至?xí)r間/超時和取消

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

通過子gRPC調(diào)用截至?xí)r間和取消操作有助于實施資源使用限制

4.gRPC的劣勢

瀏覽器支持有限

當(dāng)下，不能從瀏覽器調(diào)用gRPC服務(wù) ,

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

gRPC Web并非支持所有g(shù)RPC功能。不支持客戶端和雙向流，并且對服務(wù)器流的支持有限。

不是人類可讀的

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

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

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