为什么要使用gRPC?

技术选型的时候,多问几个为什么总是没错的。对于RPC,为什么要选择gRPC而不是其他的呢?

这里要定义一下,RPC = Remote procedure call。我们暂且也把RESTful列入其中一起对比(准确的来说RESTful是一种风格, 但是你懂我想说的意思)。

由于技术更新迭代的速度非常之快,现在还是火热的技术,也许五年后就凉凉了,我们做技术选型的时候,期望能够尽可能找到 一个在未来一段时间内仍然适用的技术,其中很重要的一个原因是生态:

  • 生态
    • Nginx。gRPC有Nginx加持(详见 此处),可以方便的配置 证书、负载均衡等。此外还有其他众多软件,只要支持HTTP/2的,自然就能支持gRPC。
    • 众多语言支持(详见此处),可以看到,gRPC支持的语言众多,常见的语言基本都有,语言生态是 这么回事儿,比如,如果你能确定你未来几年都不会用Dart,那么你可以选择其他的RPC,但是谁知道Flutter又临们一脚把Dart 给整活了呢。为了应对未来的不确定性,最好选一个语言生态好的。

题外话,如果一定要说语言生态,RESTful是无敌的,基本上,是个语言都会支持HTTP。此处gRPC比其他RPC强,但是比不过RESTful。

  • 性能
    • Protobuf。Protobuf的压缩率是非常高的,可以参考 这里, 即使你对gRPC没有兴趣,也应该去读一下Protobuf编码规则, 相信会对你有所启发。
    • HTTP/2。HTTP/2的优势很多,详见 这里。结论我就 不赘述了,就一点:快很多。

题外话,在这一点上,RESTful比gRPC可要差远了,尤其是在传输大量数字的时候。当然了,自然是有很多其他语言在性能上强过 gRPC的。

  • 强类型。强类型,也就是说,写的时候,编译器会帮你检查很多东西,这样就不会留着在运行时报错,正所谓动态一时爽,重构火葬场。 从我个人体验来说,强类型的确能够帮助减少很多bug。

  • 自动生成SDK。当你对接很多RESTful API时,你会发现,每个语言都要封装一份SDK,否则就只能大家都裸写JSON,这是一件很蛋疼的 重复劳动的事情,gRPC解决了这个痛点(其它RPC大多也解决了)。

因此,选型的时候,gRPC很容易就胜出,没有哪一种RPC能做到多方面制胜。但是还是需要参考一点,这一点比较现实,那就是实际情况 中你会发现很难推动gRPC,因为大部分厂商都用不到那么高的性能,所以性能上对他们来说,20ms和100ms相差不大,而RESTful的生态 更加重要,再加上已有的工具、存量都偏向于RESTful,因此太难推动了。 可以参考:为什么gRPC难以推广


参考资料:


更多文章
  • 代码的坏味道
  • 消息分帧(字符串设计或协议设计)的两种形式
  • C, Go, Python的错误处理和异常机制杂谈
  • 好的命名是最好的文档
  • 读《系统之美:决策者的系统思考》
  • Linux高分屏支持
  • GCC默认的头文件搜索路径
  • 读《远见-如何规划职业生涯3大阶段》
  • 后端工程师学前端(五): SASS
  • 后端工程师学前端(四): CSS进阶(盒子模型)
  • 读《投资中最简单的事》
  • 后端工程师学前端(三): CSS进阶(特指度、单位和字体族)
  • 后端工程师学前端(二): CSS基础知识(规则与选择器)
  • Swift语法笔记
  • 读《管理的实践》