liuwenqiang1314的博客

在客户端和服务端的交互模式中，我们不免的遇到一类问题。那就是客户端访问的时候服务端可能并非是异常了，只是因为网络延迟或者抖动，可能操作客户端暂时访问不上服务端的情况，如果出现了此类情况的话。那么可以让客户端重试连接。尽可能的避免，因为网络问题，影响通信。从而保证了系统的可靠性。grpc同样是支持这个能力的，我们可以在客户端通过重试来保证请求的稳定性。接下来我们就在服务端模拟网络异常来学习一下grpc的客户端的重试机制。

我们前面介绍了一元操作下的拦截器的各种操作。但是我们说一元操作的特点它是一个请求一个响应，所以他的拦截器的时机就是对于这一个请求响应的拦截。这种特点决定了他无法对于流式的那种多个消息的拦截。试想一下你如何用一元拦截器拦截流式的某一个批次中的某一个消息呢？或者你能不断的拦截他的消息流吗。所以我们需要在流式操作下的拦截器来实现这个能力。下面我们先来搭建流式的客户端和服务端代码。

这就是grpc中比较常见的一元拦截器的使用，他是对于一元rpc的拦截。在各个拦截方法中我们可以定义一些自己的业务方法。进而灵活使用拦截器。而且你要是在某个点拦截之后不想继续往下走，那你就不要调用每个拦截方法的super，不要做后续的调用，直接断开链路即可。而且至于拦截请求还是响应就看你包装啥就完了，他不是耦合在一起的。后面我们再来分析监听流也就是流式和双向调用的拦截器。

我们完成了关于grpc的一些基础编程，但是实际开发中往往要和一些主流的框架体系做整合，融入到里面去。我们常见的就是springboot体系，那么grpc如何在springboot中使用这个问题我们今天就来探讨一下。

我们之前完成了一个基本的客户端和服务端通过grpc来调用的代码功能。我们使用的其实是一种最简单的通信方式，貌似和以前的spring mvc没啥区别，那么grpc作为一个基于http的双工的设计，肯定不是简单的只支持这样的能力。下面我们就来看看grpc所支持的这四种传输模式。

我们之前已经完成了对于api模块的开发，也就是已经生成了基础的类和对应的接口，现在我们需要完成的是client和server端的开发。其实如同thrift一样，现在要做的就是实现我们之前定义的service里面的hello方法，里面写我们的业务逻辑，然后通过grpc的server发布暴露出去给客户端使用。ok,我们就先来实现serve模块，然后再实现client模块。

我们之前学习了grpc的一些理论知识，现在我们开始正式进入编程环节。我们的项目结构和之前的thrift结构还是一样的，一个common,一个client，一个server。只不过在grpc这里common它一般叫做api模块。还是放置一些公共的实体类，业务service类之类的。

我们在前面学习了thrift rpc的知识，我们从其中接触到了IDL，编解码协议，服务的远程调用(调用远程服务就像在在本地调用一样)等各种概念。其实我个人对thrift的使用并不多，我更多的是使用今天我们要提到的一个RPC框架称之为gRPC，其实作为一个rpc框架，grpc和之前提到的thrift是有很多相似之处的，包括他也有IDL这个概念。只是语法不一样而已。但是作为一个非常流行的rpc框架，grpc是有自己的独到设计的，下面我们来看看他的一些特点和概念。

之前我们研究了一下thrift的一些知识，我们知道他是一个rpc框架，他作为rpc自然是提供了客户端到服务端的访问以及两端数据传输的消息序列化，消息的协议解析和传输，所以我们今天就来了解一下他是如何实现这些功能，并且如何在实际代码中使用。我们需要搭建环境。

1:i32 id,3:i32 age1、举一个struct的例子，如果你想生成一个User类型的代码，就要这样声明。里面有序号，类型，属性名称。2、struct的类不能继承，成员与成员之间的分割可以是逗号，也可以是分号。3、结构体里面的每一个字段都要进行编号，从1开始。4、结构是变量类型，变量名。5、还有一种类型，叫做optionl，就是可选类型，就是可以为空的类型，就是在序列化的时候是可选的，没有值就不序列化，有就序列化。默认为每一个成员都加入的关键字，可以不写。我上面就没写，其实默认就是。