1.什么是gRPC

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

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

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

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

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

補(bǔ)充一個(gè)知識(shí)點(diǎn)（HTTP/2 與HTTP1.X的區(qū)別）

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

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

多路復(fù)用

HTTP/2支持通過(guò)同一個(gè)連接發(fā)送多個(gè)并發(fā)的請(qǐng)求。

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

服務(wù)端推送

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

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

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

2.gRPC大致請(qǐng)求流程

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

2.對(duì)請(qǐng)求信息使用Protobuf進(jìn)行對(duì)象序列化壓縮（IDL）

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

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

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

3.gRPC的優(yōu)勢(shì)

性能

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

代碼生成

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

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

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

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

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

流

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

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

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

gRPC允許客戶(hù)端指定他們?cè)敢獾却齊PC完成時(shí)間。該期限被發(fā)送到服務(wù)端，服務(wù)端可以決定在超出了期限時(shí)采取什么行動(dòng)，例如，服務(wù)器可能會(huì)在超時(shí)時(shí)取消正在進(jìn)行的gPRC/HTTP/數(shù)據(jù)庫(kù)請(qǐng)求

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

4.gRPC的劣勢(shì)

瀏覽器支持有限

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

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

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

不是人類(lèi)可讀的

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

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

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

5.使用場(chǎng)景

建議使用的場(chǎng)景：

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

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

最新評(píng)論