gRPC原理简析
gRPC原理简析gRPC是由谷歌提出并开发的RPC协议，gRPC提供了一套机制，使得应用程序之间可以进行通信。 降级开发者的使用门槛，屏蔽网络协议，调用对端的接口就像是调用本地的函数一样。而gRPC的核心组成部分则是protocol buffers和http2.0，以下将详细讨论：
protocol buffers
简介
开发者可以使用 pb compiler 生成用于读写数据代码。 多语言支持特性，轻松支持技术栈不同的上下游。 Protocol buffers是一个灵活的、高效的、自动化的用于对结构化数据进行序列化的协议。各种类型所用的编码算法如下所示：
编码算法
varints 编码
每字节使用第一位表示后面是否还有内容，另外7位保存真是数据。 使用小端模式(数据低位在低地址，高位在高地址)。 小整数使用该编码，空间能得到较大压缩，大整数可以考虑fix32 fix64代替。
以下我们看一个示例，varints 如何表示300
1010 1100 0000 0010
- -
↓ ↓
下一字节有数据下字节为空
所以其实真正表示300的数据位
010 1100000 0010
再转为对人类相对友好的大端模式表示即可得
000 0010010 1100
zigzag 编码
对于int32, int64来说，高位置1表示负数，int64表示一个负数会使用10个字节，绝对值较小的负数会造成较多的空间浪费。 sint32, sint64会使用该编码方式,建议在存在负数且绝对值较小的场景下使用。 编码算法 sint32(n << 1) ^ (n >> 31), sint64(n << 1) ^ (n >> 63)
定长编码
在真实的数据前，使用一个varints 来表示数据长度 string, bytes, embedded messages, packed repeated fields均使用该编码方式 数据格式如下:
repeated 编码
在2.1版本，会被默认编码成TVTVTVTV（T代表tag，V代表数据本身）的格式，如
在3.0版本，会被默认编码成TVVVVVV的格式，通过减少tag来达到节约空间的目的。
message struct 编码
Protobuf 消息是一系列的键值对组成。消息的二进制版本仅使用 field 数字当作 key，不同 field 的属性和类型只能通过消息类型的定义 在解码端确定。 如果消息中不存在该 field，那么序列化后的 Message Buffer 中也不会有该 field，这些特性都有助于节约消息本身的大小。 完整数据示例如下：
type 0 代表varints
tag num ↑ 数据，300
↑ ↑ ↑
↓ ↓
↓长度为4字节
type 2, 定长编码
HTTP 2.0
特性
新的二进制格式。 流量控制。 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。 header压缩，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小，像cookie这类重复的数据来回传输很占用带宽。 双向数据流，服务端也能具备主动推送消息的能力
gRPC
优势
效率高于 restful 服务，编码节约空间，使得在低带宽场景下很有优势。 pb compiler生成数据读写代码，提高开发者编码效率。 支持向上游传递超时时间，让上游在发现超时时主动决定如何执行后续操作，http1.1则会直接断开连接。
缺点
只有少数浏览器支持gRPC。 移动端网络可能在wifi及4G频繁切换，无法体现出长连接以及多路复用的优势。 编码后数据可读性低，json则具有很高的可读性。
小结
gRPC其实就是使用protocol buffer作为序列化协议（编码解码），http2.0作为通讯协议的RPC协议。
reference
https://developers.google.com/protocol-buffers/docs/overview https://developers.google.com/protocol-buffers/docs/encoding
头条内推请扫码，成功入职小李同学请吃饭~~~
页:
[1]