gRPC的原理
大约 2 分钟
1. 简介
gRPC是Google推出的一种基于HTTP/2和Protobuf（Protocol Buffers）的远程调用框架（Remote Procedure Call，RPC），相比传统的HTTP远程调用（比如组里正在用的Feign是HTTP+JSON）效率更高
gRPC有四种通信方式，分别是（其实就是一次请求和流式请求的2*2）：
- 客服端一次请求，服务器一次应答
- 客服端一次请求，服务器多次应答（流式）
- 客服端多次请求（流式），服务器一次应答
- 客服端多次请求（流式），服务器多次应答（流式）
2. 为什么速度快
2.1 Protobuf vs JSON
- 数据结构：JSON用key-value来描述；而Protobuf采用二进制编码，极大的减小了数据的传输量
- 解析速度：JSON在运行时解析；而Protobuf因为自动生成了代码，所以可以在编译时提前生成数据的结构，提升了编码解码的速度
然而JSON的可读性很好，对抓包太友好了
2.2 HTTP2 vs HTTP1
在常见网络协议中有简单的介绍HTTP协议的演进，其中HTTP/2进行了多路复用、二进制帧、头部压缩等改进，传输效率更高
注意
gRPC虽然快，但在我实际的工作中还是感觉到了有些不方便的地方
比如在老的SpringCloud+Nacos+Feign组的Java微服务中，网关可以直接将请求按照路径分发到各个微服务，同时也不需要事先过度去处理请求的参数
而最近我尝试使用Gin+Etcd+gRPC来组Golang微服务，我所面临的问题是，如果满足gRPC的设计理念，似乎只能在网关微服务使用Gin框架。而这带来的问题是，有些http请求的参数还是在Gin中处理比较方便，必须要先处理一遍再发送到各个微服务的RPC Server中。
而且无法向网关一样智能的转发请求，增加了额外的开发量。
不过凡事皆有代价，这可能就是Trade Off吧