为什么要使用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难以推广。

参考资料：

维基百科RPC定义

为什么要使用gRPC？

更多文章