【微服务】GRPC漫谈

在微服务架构中，可能完成一个请求需要多个服务进行协作，比如一个输出商品详情页的HTTP接口，聚合服务需要查询多个通用服务，如：

为了顺利完成如上所述的协作，微服务架构的多个服务之间需要进行相互通讯，在此场景下我们需要使用RPC（Remote Procedure Call）。

下图比较了RPC和REST：

简单来说：

设计目标：

其他优势：

HTTP2.0简介：分为Headers Frame（对应1.1的header）和DATA Frame（对应1.1的body）两部分

HTTP1.1 相较于 HTTP1.0的提升点：支持长连接（keep-alive）并默认打开，一个TCP请求上可以传送多个HTTP请求和响应，避免握手和挥手造成的延迟。

HTTP2.0 相较于 HTTP1.1的提升点：多路复用+头部压缩

基本概念

多路复用

头部压缩 HPACK

cient和server存储在一个HTTP2.0链接存续期间，共同维护一个header表

每次请求时相同的header数据不用在发送，只要发送差异即可（新增/修改）：比如ua，host，cookie等

PB性能更好 ：消息体积小且序列化较快

消息体积更小：平均约为JSON的1/3，网络传输快

序列化和反序列化快：约为JSON的20倍

1. HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

2. 思考gRPC ：为什么是HTTP/2

3. REST和RPC区别

4. 流行的RPC框架benchmark

缺点:目前版本来说实测性能肯定是差thrift一截的(实测grpc0.8版本).应该就是缺点吧,虽然用了netty和protobuf

优点:采用HTTP2的好处在于,因为添加了头信息,可以方便在框架层面对调用做拦截和控制(比如说限流,调用链分析,安全认证等)

而且http2为标准协议,也方便以后扩展兼容其它调用端

不过目前的grpc虽然支持了拦截,但是Header信息和消息体是分离的,而且暂时没法控制方法执行与否,所以很多功能还不能实现

(主要是没能从protobuf层面解决Header的问题)

另外,使用grpc既要安装protobuf又要使用maven或gradle的生成xxxGRPC的插件,实在麻烦,而且

client_to_server

client_to_server_streaming

server_to_client_streaming

bidirectional_streaming

几类调用方式实现的API也过于繁琐

所以综合起来目前我们在自己的分布式服务框架里使用的时自己实现的infogen-rpc框架，如果后面的release版本确实好用或许会换回来吧，毕竟grpc的多语言还是做得不错

---