1.什么是gRPC

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

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

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

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

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

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

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

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

多路復用

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

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

服務端推送

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

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

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

2.gRPC大致請求流程

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

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

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

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

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

3.gRPC的優(yōu)勢

性能

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

代碼生成

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

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

嚴格的規(guī)范

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

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

流

gRPC服務支持所有流組合：

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

截至時間/超時和取消

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

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

4.gRPC的劣勢

瀏覽器支持有限

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

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

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

不是人類可讀的

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

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

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

5.使用場景

建議使用的場景：

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

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