服务治理 - 超时控制之节省资源

背景

先介绍普通的超时配置

普通的超时控制:
A - > B - > C -> D
比如B->C 默认超时时间200ms,但是B->C实际调用了230ms
此时B知道调用超时了,会处理异常或者把异常返回给上游
这里方式较多,比如socket timeout,网上一堆资料

这里,B知道后续请求超时,B会处理异常返回给A
但是C不知道,C会接着走自己的逻辑,会继续把请求发送给D。对于D来说,这一次请求完全是浪费的,因为不管D处理结果成功失败,上游都已经当成失败了。

如何优化这样的场景呢?
工业界也会有这种情况,尤其是对于底层,中台这样的服务,有时候请求过来的时候,上游已经当成失败处理了,这个时候中台还去处理这些请求,浪费资源和效率

设计方式

这里只是提出简单的思路,并不给出详细的实现代码
上下游调用的时候设置一个TTL
每次调用请求的时候,在请求rpc context里面传递一下TTL,记录剩余多长时间。
那么,

上游调用下游时,检查当前的TTL是否<0,是的话就不调用了,节省下游资源
下游被上游调用时,同理,就直接返回错误。

思考

1.上面的例子都是简单的串行化例子,实际上还有ABCD串行化调用过程中,BC两步单独没有超时,但是整体已经超过了A的时间,此时C向D发出请求时,TTL也是<0
2.业务本地的处理逻辑还是会走完的。ABCD请求上面都正常,D本身超时了,D自己的业务逻辑也会走完。
3.这种检测机制可以放在middleware里面处理,通过这种方式,能减少在上游整体超时或者单个上游自身超时的情况下,对下游的请求量。

你可能感兴趣的:(服务治理 - 超时控制之节省资源)