-
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》
网友评论