服务治理 - rpc (business)retry 中间件

背景

rpc请求的时候，上游调用下游，如果失败了希望能够重试，如果每个业务代码都自己写一遍调用不同下游的代码，过于繁琐
需要有一个重试的组件，封装所有上游调用下游的请求，支持重试

定义

适用场景：后续调用不通，而不是下游返回了失败之类的结果，只要下游返回结果则代表链路通畅
retry: 次数
retry_interval: 重试之间休息的时间

实体名称

upstream:上游
downstream:下游
methodName:方法名

上游可以根据需要更加细化，比如包含cluster名称等

实现

配置重试

重试次数

即用一个分布式服务框架，如zk等，写一个特定key
如/retry/upstream/downstream/methodName

值为正整数
为10则代表upstream调用downstream的methodName这个方法时，最多重试10次

重试间隔

/retry_interval/upstream/downstream/methodName
值为正整数，单位为ms
为1000代表每次重试间隔1s

重试生效，读配置

框架上用middleware,切面等方式（我是以py的django框架为基础，其他语言也有自己的框架)，该中间件的处理在upstream调用下游的时候

比如upstream在调用downstream的方法methodName的时候，
会去访问分布式配置的key，记录retry和retry_interval
py伪代码

cnt = 0
while cnt < retry:
  if cnt >= 1
    time.sleep(retry_interval)
  cnt+=1
  try:
    res = doRequest(req)
  except Exception,e:
    last_error = e
  if res is not None:
    return res
  raise last_error

思考

1.和前面服务治理组件之间的先后顺序关系

仁者见仁，建议设置顺序为先ACL，degradation，再走retry

2.调用失败，异常和返回失败，异常的关系

调用失败，异常相当于链路没有走通，可能是网络等原因，此种情况框架做重试
返回失败，异常则基本上是链路走通，且很有可能是符合预期的，此种情况框架不做重试，需要自行定位上下游代码原因

3.重试的变种

上面重试是直接失败了就睡n秒，可以在此基础上附加很多东西
如时间窗口计算失败率，如果失败率>0.05就不重试了认为下游不稳定
另外sleep时间也可以不断的乘2，类似这种