背景
先介绍普通的超时配置
普通的超时控制：
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里面处理，通过这种方式，能减少在上游整体超时或者单个上游自身超时的情况下，对下游的请求量。
