异常重试_简单rpc重试策略

微服务情况下，服务之间调用依赖于rpc，rpc调用便有几率导致问题，在不依赖于框架层级重试的前提下，前置系统如何判断是否进行重试便成了比较棘手的问题，下面介绍一个简单的设计思路。

首先包装一个rpc的结果处理类Repsonse , 包含调用状态(目前我是加了一个枚举，默认值为需重试needRetry)、ResponseCode、ResponseContent作为调用方和服务方交互的媒介。

如下：

/** * @program: luckyin * @description: rpc response * @author: taosha * @create: 2018-07-18 16:37 **/public class Response implements Serializable { private static final long serialVersionUID = -1L; protected ResponseStatus status; protected String content; protected String responseCode; //当处理失败时候，放入失败原因 protected String failCause; ...省略 } 

这个时候，你就会问，前置系统如何去分析返回结果呢？

server方处理逻辑为，在正确接收到请求之后，进行业务处理：

a. 如果业务处理失败：如参数不完整、黑名单等等一类重试也无法成功、或者server方不希望他成功的异常，那么返回status为Fail，其他返回内容这里不做多的解释；

b.如果业务处理成功或者幂等命中(也为业务成功)，那么status返回为success；

c.其他识别不了的异常，如网络抖动，server内部可能调用了其他的rpc服务或者db连接超时等异常，status返回为needRetry那么需要前置系统进行重试来保证业务成功。

至于如何包装返回值，这里就不再多说，如果想代码相对优雅，可以 基于aop或者自己创建一个工具类来处理。

这样，重试不依赖于框架的自动重试，client可以自己控制重试与否，是一个比较好的解决方式。当然，重试的前提，业务系统要做好接口等幂等功能，这个后面的文章也会单独说一下。

try again?