gRPC筆記

為什么要用RPC，數(shù)據(jù)編碼，請求映射？

數(shù)據(jù)編碼就是序列化，反序列化，將對象變成字節(jié)流發(fā)送給服務(wù)端，服務(wù)端將收到的字節(jié)流再轉(zhuǎn)化為對象

常見的序列化，反序列化工具XML, JSON, Protobuf。

既然Protobuf在某些場景下效率要比JSON高，為什么高？

Json的缺點(diǎn)就是非字符串的編碼效率低，int類型在內(nèi)存只占兩個字節(jié)65535， 轉(zhuǎn)化成JSON卻需要五個字節(jié)，bool則需要占用四到五個字節(jié)

另一個缺點(diǎn)就是信息冗余，面對同一個接口同一個對象，需要重復(fù)傳送相同的字段名。

Json在編碼效率和可讀性之間選擇了可讀性

Protobuf選用了VarInts對數(shù)字進(jìn)行編碼，解決了效率問題，另一方面將字段都指定為整數(shù)編號，傳輸?shù)臅r候只傳送字段編號，解決了冗余問題，Protobuf使用.proto文件作為schema記錄字段和編號的對應(yīng)關(guān)系

gRPC底層使用的HTTP/2協(xié)議

HTTP協(xié)議本身可以通過Content-Encoding表示壓縮算法，使用Contetn-length指定數(shù)據(jù)長度。

而gRPC重新定義了一套機(jī)制，因?yàn)間RPC支持stream rpc,流式接口。

gRPC支持三種流式接口，請求流，響應(yīng)流，雙向流。

請求流可以在RPC發(fā)起之后不斷發(fā)送新的請求消息，此類接口最典型的使用場景事發(fā)推送或者短信。

相應(yīng)流可以在RPC發(fā)起之后不斷接受新的響應(yīng)消息，最典型的場景就是訂閱消息通知

雙向流可以在RPC發(fā)起之后同時手法消息，最典型的場景就是實(shí)時語音轉(zhuǎn)字幕

為了實(shí)現(xiàn)流式傳輸，gRPC引入Length-Prefixed Message同一個gRPC請求的不同消息共用HTTP頭信息，只能給每個消息單獨(dú)加一個五字節(jié)的前綴來表示壓縮和長度信息。gRPC還定義了自己的grpc-status和grpc-message

HTTP/1.1也是支持復(fù)用TCP連接的，但這種復(fù)用有一個明顯的缺陷，所有請求必須排隊，先到先服務(wù)。

HTTP/2引入了stream的概念，解決了TCP鏈接復(fù)用的問題，可以在一條TCP連接上并行收發(fā)HTTP消息，而無需等待。

即gRPC為了實(shí)現(xiàn)流式特性，使用了HTTP/2進(jìn)行通信。