grpc

RPC，全称Remote Procedure Call，中文译为远程过程调用。通俗地讲，使用RPC进行通信，调用远程函数就像调用本地函数一样，RPC底层会做好数据的序列化与传输，从而能使我们更轻松地创建分布式应用和服务。

 

• 1.我们使用什么数据模型？JSON、XML还是二进制流
• 2.我们使用什么协议传输？HTTP、TCP、还是HTTP/2
• 3.我们如何调用方法，以及处理错误
• 4.我们如何应对数据量大的情况
• 5.我们如何减少接口的延时等

gRPC，则是RPC的一种，它是免费且开源的，由谷歌出品。使用gRPC，我们只需要定义好每个API的Request和Response，剩下的gRPC这个框架会帮我们自动搞定。

另外，gRPC的典型特征就是使用protobuf（全称protocol buffers）作为其接口定义语言（Interface Definition Language，缩写IDL），同时底层的消息交换格式也是使用protobuf。

 

 

gRPC VS Restful

gRPC和Restful之间的对比，历来是学习gRPC的必修课，我会从文档规范、消息编码、传输协议、传输性能、传输形式、浏览器的支持度以及数据的可读性、安全性等方面进行比较。

文档规范

文档规范这种东西有点见仁见智，在我看来，gRPC使用proto文件编写接口（API），文档规范比Restful更好，因为proto文件的语法和形式是定死的，所以更为严谨、风格统一清晰；而Restful由于可以使用多种工具进行编写（只要人看得懂就行），每家公司、每个人的攥写风格又各有差异，难免让人觉得比较混乱。

另外，Restful文档的过时相信很多人深有体会，因为维护一份不会过时的文档需要很大的人力和精力，而公司往往都是业务为先；而gRPC文档即代码，接口的更改也会体现到代码中，这也是我比较喜欢gRPC的一个原因，因为不用花很多精力去维护文档。

消息编码

消息编码这块，gRPC使用protobuf进行消息编码，而Restful一般使用JSON进行编码

传输协议

传输协议这块，gRPC使用HTTP/2作为底层传输协议，据说也可替换为其他协议，但目前还未考证；而RestFul则使用HTTP。

传输性能

由于gRPC使用protobuf进行消息编码（即序列化），而经protobuf序列化后的消息体积很小（传输内容少，传输相对就快）；再加上HTTP/2协议的加持（HTTP1.1的进一步优化），使得gRPC的传输性能要优于Restful。

传输形式

传输形式这块，gRPC最大的优势就是支持流式传输，传输形式具体可以分为四种（unary、client stream、server stream、bidirectional stream），这个后面我们会讲到；而Restful是不支持流式传输的。

浏览器的支持度

不知道是不是gRPC发展较晚的原因，目前浏览器对gRPC的支持度并不是很好，而对Restful的支持可谓是密不可分，这也是gRPC的一个劣势，如果后续浏览器对gRPC的支持度越来越高，不知道gRPC有没有干饭Restful的可能呢？

消息的可读性和安全性

由于gRPC序列化的数据是二进制，且如果你不知道定义的Request和Response是什么，你几乎是没办法解密的，所以gRPC的安全性也非常高，但随着带来的就是可读性的降低，调试会比较麻烦；而Restful则相反（现在有HTTPS，安全性其实也很高）

代码的编写

由于gRPC调用的函数，以及字段名，都是使用stub文件的，所以从某种角度看，代码更不容易出错，联调成本也会比较低，不会出现低级错误，比如字段名写错、写漏。

gRPC的适用场景

从上面gRPC和Restful的比较中，我们其实也从侧面了解gRPC的优劣势，也能顺势推断出其应用场景。

总的来说，gRPC主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。Restful主要用于对外，比如提供接口给前端调用，提供外部服务给其他人调用等，