gRPC笔记
为什么要用RPC，数据编码，请求映射？
数据编码就是序列化，反序列化，将对象变成字节流发送给服务端，服务端将收到的字节流再转化为对象
常见的序列化，反序列化工具XML, JSON, Protobuf。
既然Protobuf在某些场景下效率要比JSON高，为什么高？
Json的缺点就是非字符串的编码效率低，int类型在内存只占两个字节65535， 转化成JSON却需要五个字节，bool则需要占用四到五个字节
另一个缺点就是信息冗余，面对同一个接口同一个对象，需要重复传送相同的字段名。
Json在编码效率和可读性之间选择了可读性
Protobuf选用了VarInts对数字进行编码，解决了效率问题，另一方面将字段都指定为整数编号，传输的时候只传送字段编号，解决了冗余问题，Protobuf使用.proto文件作为schema记录字段和编号的对应关系
gRPC底层使用的HTTP/2协议
HTTP协议本身可以通过Content-Encoding表示压缩算法，使用Contetn-length指定数据长度。
而gRPC重新定义了一套机制，因为gRPC支持stream rpc,流式接口。
gRPC支持三种流式接口，请求流，响应流，双向流。
请求流可以在RPC发起之后不断发送新的请求消息，此类接口最典型的使用场景事发推送或者短信。
相应流可以在RPC发起之后不断接受新的响应消息，最典型的场景就是订阅消息通知
双向流可以在RPC发起之后同时手法消息，最典型的场景就是实时语音转字幕
为了实现流式传输，gRPC引入Length-Prefixed Message同一个gRPC请求的不同消息共用HTTP头信息，只能给每个消息单独加一个五字节的前缀来表示压缩和长度信息。gRPC还定义了自己的grpc-status和grpc-message
HTTP/1.1也是支持复用TCP连接的，但这种复用有一个明显的缺陷，所有请求必须排队，先到先服务。
HTTP/2引入了stream的概念，解决了TCP链接复用的问题，可以在一条TCP连接上并行收发HTTP消息，而无需等待。
即gRPC为了实现流式特性，使用了HTTP/2进行通信。
