gRPC 学习笔记

gRPC 主要使用同步请求-响应模型来交互，但是在初次连接建立后，可以实现全异步或者流模式；
SOAP：Simple Object Access Protocol，是面向服务架构（SOA——service-oriented architecture）的标准沟通技术，用来在服务间传输基于XML结构的数据。传输可以基于任意底层传输协议，如HTTP；
REST：Repressentational State Transfer ，是面向资源架构（ROA——resource-oriented architecture）的基础；
- 面向资源架构：将分布式应用建模为一个资源的集合，访问这些资源的客户端可以修改资源的状态（创建、读取、更新、删除等）
gRPC的优势：
- 高效的内部进程沟通（inter-process communication）
- 简单、优雅的服务接口和框架定义
- 强类型，支持多种语言，便于约定服务和消息体
- 支持双向流
gRPC的缺点：
- 可能不适合面向外部服务的场景
  - gRPC 服务协议驱动、强类型的特征可能会限制对外服务的灵活性，同时会削弱使用者的控制能力（The contract-driven, strongly typed nature of gRPC services may hinder the flexibility of the services that you expose to the external parties, and consumers get far less control）
- 当有大量的服务定义被修改时，需要重新生成客户端和服务端的代码
gRPC 中，所有的请求都是 HTTP POST 请求，需要在 content-type 里加上 application/grpc前缀；待调用的远程方法作为一个单独的 HTTP 头部发送
Protocol buffer 的编码方式：

pb.png
Tag 由两部分组成：

| Field Index | Wire Type |
- Field Index：定义 message 时加在每个字段前的数字
- Wire Type：由字段的实际类型决定，占 3 个bit，用来定位 Value 的长度
  
  Tag.png
- 注意：在处理负数时，使用 sint 比使用 int 更高效
- Tag value = (field_index << 3) | wire_type
当消息被编码时，它的 tags 和 values 被连接到一个比特流中，流的结尾处用一个值为0的tag来标记
Length-Prefixed Message Framing：
- gRPC 使用 Length-Prefixed Message Framing 技术来进行消息分帧，即，在写入消息本身之前，先写入消息的长度；
- 在编码二进制消息之前，可以分配4个字节来指定消息的长度，这意味着 gRPC communication 可以处理上限为 4G 的消息
  
  frame.png
- 写在消息长度之前的是一个1字节的无符号整数，用来指示数据是否压缩过
  - 压缩标志设为1，代表数据经过了压缩，压缩方法写在HTTP头中
gRPC 使用 HTTP/2 作为传输协议；
请求消息：
- 包含三个主要部分：请求头，带长度前缀的消息以及一个流结束的标志
```
    HEADERS (flags = END_HEADERS)
    :method = POST
    :scheme = http // 如果允许TLS，则使用 https
    :path = /ProductInfo/getProduct // 端点的路径：/{service name}/{method name}
    :authority = abc.com // 定义目标 URI 的虚拟主机名
    te = trailers // 定义不兼容代理的检测，gRPC 必须是 trailers
    grpc-timeout = 1S // 定义超时时间，如果不定义，则默认为无穷大
    content-type = application/grpc
    grpc-encoding = gzip // 定义消息压缩的方式
    authorization = Bearer xxxxxx</pre>
```
- 注意 content-type 必须以 application/grpc 为前缀，否则的话，gRPC 服务器会返回一个 415（Unsupported Media Type）状态码
- 以 : 开头的字段称为保留头，HTTP/2 要求保留头必须写在其他头部字段之前
- gRPC 的头部字段可以分为两类：call-definition headers 和 custom metadata
  - call-definition header：由 HTTP/2 预定义的头部，必须设置在 custom metadata 之前
  - custom metadata：由应用层定义的任意键值对，注意自定义时不要使用grpc-开头的键名，这些是保留的键名
- 通过在最后一个数据帧上加上 END_STREAM 标志来结束请求消息
```
    DATA (flags = END_STREAM)
    <Length-Prefixed Message></pre>
```
响应消息：
- 通常也包含三个部分：响应头，带长度前缀的消息和trailers，但是可以不包含带长度前缀的消息
```
    HEADERS (flags = END_HEADERS)
    :status = 200
    grpc-encoding = gzip
    content-type = application/grpc</pre>
```
- 结束标志不与数据帧一起发送，而是作为单独的头部发送，称为 trailer
```
    HEADERS (flags = END_STREAM, END_HEADERS)
    grpc-status = 0 # OK 
    grpc-message = xxxxxx</pre>
```
- 如果在请求调用的过程中出现错误，server 只发送一个 trailer 作为响应，不发送数据帧，以下头部会包含在 trailer 中：
```
    HEADERS (flags = END_STREAM, END_HEADERS)
    grpc-status = 0 # OK 
    grpc-message = xxxxxx</pre>
```
gRPC 沟通模型中的不同消息流：
- Simple RPC
  
  simpleRPC.png
- Server-streaming RPC
  
  ServerStreamRPC.png
- Client-streaming RPC
  
  ClientStreamRPC.png
- Bidirectional-streaming RPC
  
  BidirectionalStreamRPC.png

gRPC 实现架构

gRPCArchitecture.png
- grpc 基于两个快速高效的协议构建：protocol buffers 和 HTTP/2
- protocol buffers：一个语言无关、平台无关，具有可扩展结构数据序列化机制的数据序列化协议；
  - 生成的是二进制负载
负载均衡：
- 负载均衡可以在服务器端实现（反向代理），也可以在客户端实现
  - 服务器端实现：客户端将请求发送到代理服务器，由代理服务器选择一个后端服务器重新建立连接转发请求，最后将结果返回给客户端
  - 客户端实现：客户端自己实现对服务器状态的监控和选择算法，服务器将自身状态与请求结果一并返回给客户端，客户端更新服务器状态
- 负载均衡的模式.png
- 服务端负载均衡：
  - 分为传输层（L3/L4）和应用层（L7）两种；
  - 传输层负载均衡：负载均衡器与选中的服务器建立新的连接，将来自客户端的请求拷贝转发到选中的服务器。
    - 优点：不需要做太多额外处理，延迟小，消耗资源少
  - 应用层负载均衡：负载均衡器解析 HTTP/2 请求，根据请求的内容决定转发到哪个服务器
    
    服务端负载均衡.png
- 客户端负载均衡：
  - 胖客户端（thick client）：由客户端全权处理服务器的所有信息，包括通过类库整合服务发现、名字解析、配置中心等
  - 后备负载均衡器（lookaside load balancer)：由一个单独的负载均衡器来管理服务器的相关信息，客户端向该负载均衡器发起请求，获得服务器的地址，然后自己根据地址向服务器发起请求。服务器日常将自己的状态上报给负载均衡器
- 最佳实践：
  
  负载均衡最佳实践.png

参考资料

《gRPC: Up and Running》
RPC的负载均衡