gRPC筆記
為什么要用RPC孤个，數(shù)據(jù)編碼，請求映射沛简？
數(shù)據(jù)編碼就是序列化齐鲤，反序列化，將對象變成字節(jié)流發(fā)送給服務(wù)端椒楣，服務(wù)端將收到的字節(jié)流再轉(zhuǎn)化為對象
常見的序列化给郊，反序列化工具XML, JSON, Protobuf。
既然Protobuf在某些場景下效率要比JSON高捧灰，為什么高淆九？
Json的缺點就是非字符串的編碼效率低，int類型在內(nèi)存只占兩個字節(jié)65535， 轉(zhuǎn)化成JSON卻需要五個字節(jié)炭庙，bool則需要占用四到五個字節(jié)
另一個缺點就是信息冗余饲窿，面對同一個接口同一個對象，需要重復(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重新定義了一套機制，因為gRPC支持stream rpc,流式接口腐碱。
gRPC支持三種流式接口誊垢，請求流，響應(yīng)流症见，雙向流喂走。
請求流可以在RPC發(fā)起之后不斷發(fā)送新的請求消息，此類接口最典型的使用場景事發(fā)推送或者短信谋作。
相應(yīng)流可以在RPC發(fā)起之后不斷接受新的響應(yīng)消息芋肠，最典型的場景就是訂閱消息通知
雙向流可以在RPC發(fā)起之后同時手法消息，最典型的場景就是實時語音轉(zhuǎn)字幕
為了實現(xiàn)流式傳輸遵蚜，gRPC引入Length-Prefixed Message同一個gRPC請求的不同消息共用HTTP頭信息帖池，只能給每個消息單獨加一個五字節(jié)的前綴來表示壓縮和長度信息。gRPC還定義了自己的grpc-status和grpc-message
HTTP/1.1也是支持復(fù)用TCP連接的吭净，但這種復(fù)用有一個明顯的缺陷睡汹，所有請求必須排隊，先到先服務(wù)寂殉。
HTTP/2引入了stream的概念囚巴，解決了TCP鏈接復(fù)用的問題，可以在一條TCP連接上并行收發(fā)HTTP消息友扰，而無需等待彤叉。
即gRPC為了實現(xiàn)流式特性，使用了HTTP/2進(jìn)行通信村怪。
