Netty的深入浅出--21.gRPC双向流数据通信

继续上一章的内容，客户端请求是一个流对象，服务端响应一个集合

 客服端流式请求，服务端响应一个集合：

具体方法分析：

onNext()：这里面和之前的方法有点不同，在之前onNext()是用来返回给客户端响应的数据，而在现在是客户端发送流式请求之后，onNext()方法是接收客户端发送过来的流式请求；每接收一个数据，它就会被调用一次。

onError()：返回错误信息；

onCompleted()：这个和之前不同，在之前两个信息传递的时候，该方法只是一个起到通知的作用，而在这里它是返回给客户端响应数据的方法。

 客户端相比服务端，其编写难度更大。

客户端接收服务端的响应：

 我们仔细看一下，我们想获取getStudentWrapper()方法对象，发现根本就没有。

因为客户端向服务端发送请求，在这里你会发现我们无法使用blockingStub的获取相关方法，因为我们客户端发送流式请求的时候，gRPC不支持使用同步方式获得对象，要求使用异步获取相应对象 

在gRPC中存在一个方法，使用异步的方式来发送流式请求

现在你在写的时候，发现异步的stub竟然三种方式都可以；

总结来讲就是，客户端不管是不是以流式的方式发送请求，都可以采用异步来获取对象；

但是如果是流式的方式发送请求，都只能用异步来获取对象。

 发送请求信息；

这里和之前又有点不同，之前请求信息发送完之后，就没有然后了。而异步不同， 你不行调用onCompleted()方法通知。

注释掉之前那个打印调用：

启动服务器（服务器使用的是上一章提到的）：

 启动客户端（发现没有结果）：

原因主要是因为异步的原因：

数据还没来的急发送出去，就已经执行了Oncompleted()方法；

我们让程序休眠一段时间

启动服务器

启动客户端

还有最后一种形式：两端都是以流式方法发送请求和响应

定义两个流式请求参数 

编译器生成代码 

拷贝代码：

gRPC服务代码：

服务端代码编写：

 客户端代码编写：

注释掉之前的代码

打印服务端发送过来的信息

客户端向服务端发送流式请求：

运行之后

到现在为止gRPC的四种方式以及基本上写完了，对于gRPC也基本上学完了，大家注意是要理解它的四种方法以及使用场景，然后跟thrift进行对比。