gRPC在C++中的简单使用流程

参考： https://blog.csdn.net/fengbingchun/article/details/100626030

      毕笑      https://www.cnblogs.com/silvermagic/p/9087879.html

1．gRPC默认使用protocal buffers

2．第一步是在.proto中定义service：service serviceName  {rpc function(){}}

        有四种类型的方法：

        1）简单的rpc，就像普通的函数调用一样

        2）服务端流式rpc：在响应类型前加stream

        3）客户端流式rpc：在请求类型前加stream

        4）双向流失rpc：在请求和响应前加stream

3．从 .proto 的服务定义中生成 gRPC 客户端和服务器端的接口：make xx.grpc.pb.cc xx.pb.cc

4．创建服务器：

        1）实现service定义的生成的服务接口：茄搭做服务的实际的“工作”。

        2）运行一个 gRPC 服务器，监听来自客户端的请求并返回服务的响应。

5．创建客户端：

        1）创建一个存根

        2）调用服务的颤数拿方法

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相比还有差距，希望未来能够有所改进。

---