【gRPC】5 分钟入门扫盲

1,233 阅读5分钟

背景

笔者观察到,在自动驾驶、在线教育等领域,越来越多的使用 gRPC 作为网络通信的方式,代替了传统的 RESTful 方式。我们可以直观的体会到,这些场景具有明显的低延时、高可用的诉求,同时传输数据量会很大。相信对于 gRPC 不太了解的同学已经有了一些猜想。下面我们就来系统的初步了解下 gRPC

正文

gRPC 是什么

gRPC (gRPC Remote Procedure Calls) is an open source remote procedure call (RPC) system initially developed at Google in 2015 as the next generation of the RPC infrastructure Stubby. It uses HTTP/2 for transport, Protocol Buffers as the interface description language. —— wikipedia

详见:en.wikipedia.org/wiki/GRPC

  • Google 2015 年发布。还算年轻,普及率肯定比较有限。不过有大厂背书,用于生产还是有保障的;
  • 基于 HTTP/2 协议传输。可以肯定,在传输效率上有很大提升,但是还是普及率的问题,目前只会适用于一些特定场景;
  • 使用 Protocol Buffers 作为接口描述语言。又是一个比较陌生的概念,简单粗暴的理解就是对标 XMLJSON,是 Google 2008 年发布的一种序列化数据结构的协议,语言无关。值得一提的是从 2015.12.31 发布的 3.0.0 Beta 2 版本开始,才支持 JavaScript。我们先按下不表,先知道 gRPC 用了一种新序列化协议,代价是客户端和服务端都要同时维护一份 xxx.proto描述文件来进行序列化和反序列化即可。(2021.11.08 补【gRPC】2 分钟学会 Protocol Buffer 语法

一种简单的类比来理解:序列化 - JSON.strigify反序列化 - JSON.parse。我们再用一个图来进一步理解一下 gRPC 的应用过程: grpc-proto_concept.png

  1. Client 用 proto 文件序列化数据,生成二进制数据;
  2. Client 发起 proto request,用二进制数据进行传输;
  3. Server 收到数据后用相同的 proto 文件反序列化二进制数据,进行消费;
  4. Server 将要返回的数据用 proto 序列化,生成二进制数据;
  5. Server 返回 proto response,用二进制进行传输;
  6. Client 收到数据后用 proto 文件反序列化,进行消费。

gRPC 有什么优势

一个字:

先要明确下比较对象和应用范围。我们先不扩展的太开,只限定在前后端通信这个场景下。目前主流的前后端通信方式是采用 JSON 作为数据协议,以 HTTP/1.1 为主。

gRPC 的快,主要体现在两方面:传输速度快序列化速度快

序列化速度快,主要是因为数据是以二进制传输的,而 JSON + HTTP/1.1 是以文本格式(JSON.strigify),直接处理二进制数据显然要比处理文本数据要快。

传输速度快,有两点原因,一是因为采用了 HTTP/2 协议,具有如下好处:

  • 使用二进制格式传输,更高效、更紧凑;
  • 对报头压缩,降低开销;
  • 多路复用,一个网络连接实现并行请求;
  • 服务器主动推送,减少请求的延迟;
  • 默认使用加密。

二是因为数据体积小。服务端和客户端都有一份 proto 文件(有点拿空间换时间的意思),可以省略 key(用序号代替)只传 value。而且由于不是文本格式,数字也可以直接用二进制表示,进一步节省了空间。

具体对比的数据可前往《来也科技 Protobuf 最佳工程实践》查看。

gRPC 有什么用

现在微服务大行其道,一个复杂的系统,有上百个微服务都不算是夸张的。毕竟微服务之间走的是网络通信,提升网络通信的效率,往往会有指数倍的收益。可以预见的是,随着 AI、大数据的深度应用,以后的系统的肯定会越来越复杂,微服务的数量会越来越多。当到达一个临界值时,网络传输速率将会成为一个瓶颈,gRPC 的采用也会水到渠成。

另外,对于一些前后端交互频繁且数据量大的场景,gRPC 也是一个很好的落地场景。最典型的就是在线教育,另外笔者大胆判断,在“云游戏”前端领域 gRPC 也会有一席之地。但是,由于 gRPC 要基于 HTTP2 协议,所以要加一层 envoy 的代理来应对 HTTP1.x 的情况,这无疑会大大影响性能。所以在解决这层代理之前,前端使用 gRPC 的收益其实并没有多大。

最后,一些典型的对于性能、带宽、资源敏感的场景,肯定是最适合落地的,不过以笔者的见识,目前只能想到 IoT,欢迎大家补充。

结语

在了解 gRPC 之后,笔者情不自禁的联想到了“低时延、高可用”、“5G”、“IoT”、“物联网”等关键词。也尝试搜索了一下,可惜收获有限。加上毕竟是初学,认识深度还远远不够,所以在文章里也不敢过多的聊这些内容,以免贻笑大方。姑且算立帖为证吧,过几年回过头来看一下,肯定很有意思。

挖个坑,作为码农,“Talk is cheap, show me the code.” 才是应有的行事风格。正在写一篇关于前端封装 gRPC + TS 的文档,相信结合代码来学习,效率肯定更高。

TO BE CONTINUED...

Flux libraries are like glasses: you’ll know when you need them.—— Dan Abramov, the author of Redux
Flux 架构就像眼镜:您自会知道什么时候需要它。

参考文献