grpc优点,grpc效率

gRPC 4种rpc定义方法与3种stub介绍

有关gRPC官方介绍（ ）如下：

gRPC是一个能在不同语言不同平台中进行高效通信的服务。gRPC默认使用Protocol Buffers数据格式：

Protocol Buffers以.proto作为拓展名，是一系列以name-value键值对的形式存储的数据格式。

Protocol Buffers从开源到现在已经经过很长时间，目前已经到了proto3版本，有着更加简化的语法，更加有用的特性，能够支持更多的语言。你可以从 proto3 language guide 和? reference documentation 看到更多有用的东西。另外.proto的文件格式能够从 formal specification 获取到更详细的讲解。

每个参数带有一个唯一的标识符，这些标识符被用来在message的二进制中被识别出来。不是代表每个数据的数值。

有了gRPC，我们可以在.proto文件中定义我们的服务，并用gRPC支持的任何语言生成客户端和服务器，它可以在从大型数据中心内的服务器到您自己的平板电脑的各种环境中运行，不同语言和环境之间的所有复杂通信都由gRPC为您处理。我们还获得了使用协议缓冲区的所有优点，包括高效的序列化、简单的IDL和容易的接口更新。

声明定义proto使用3版本，如果不生命默认2版本号。

在proto文件中定义java_package，指定了我们要用于生成的Java类的包。如果.proto文件中没有显式的java_package选项，那么默认情况下将使用proto包（使用“package”关键字指定）。

使用service定义服务。然后在service中使用rpc方法定义，gRPC允许使用4种不同的定义方式，定义方法。

区别在客户端调用Grpc中Stub发送请求方法时：

可以使用message定义所有的request and response types，在service中使用到的数据格式。

怎么看待谷歌今年开源的RPC框架GRPC

缺点:目前版本来说实测性能肯定是差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的多语言还是做得不错

grpc原理

1）需要使用protobuf定义接口，即.proto文件

2）然后使用compile工具生成特定语言的执行代码，比如JAVA、C/C++、Python等。类似于thrift，为了解决跨语言问题。

3）启动一个Server端，server端通过侦听指定的port，来等待Client链接请求，通常使用Netty来构建，GRPC内置了Netty的支持。

4）启动一个或者多个Client端，Client也是基于Netty，Client通过与Server建立TCP长链接，并发送请求；Request与Response均被封装成HTTP2的stream Frame，通过Netty Channel进行交互。

对于GRPC的“鼓吹”，本文不多表述，截止到今日，GRPC仍然处于开发阶段，尚没有release版本，而且特性也很多需要补充；GRPC基于protobuf 3.x，但是protobuf 3.x也没有release版本；虽然HTTP2协议已成定局，但尚未被主流web容器包括代理服务器支持，这意味着GRPC在HTTP负载均衡方面尚有欠缺；最终，在短期内我们还不能在production环境中实施，可以做技术储备。不过GRPC的缺点，在将来将会成为它的优点，我们需要时间等待它的成熟。

1）GRPC尚未提供连接池

2）尚未提供“服务发现”、“负载均衡”机制

3）因为基于HTTP2，绝大部多数HTTP Server、Nginx都尚不支持，即Nginx不能将GRPC请求作为HTTP请求来负载均衡，而是作为普通的TCP请求。（nginx将会在1.9版本支持）

4）GRPC尚不成熟，易用性还不是很理想；就本人而言，我还是希望GRPC能够像hessian一样：无IDL文件，无需代码生成，接口通过HTTP表达。

5）Spring容器尚未提供整合。

在实际应用中，GRPC尚未完全提供连接池、服务自动发现、进程内负载均衡等高级特性，需要开发人员额外的封装；最大的问题，就是GRPC生成的接口，调用方式实在是不太便捷（JAVA），最起码与thrift相比还有差距，希望未来能够有所改进。