rpc微服务的超时机制

对比dubbo和公司的soa

超时是针对消费端还是服务端

都是针对客户端
dubbo的超时是争对客户端的，由于是一种NIO模式，消费端发起请求后得到一个ResponseFuture，然后消费端一直轮询这个ResponseFuture直至超时或者收到服务端的返回结果。虽然超时了，但仅仅是消费端不再等待服务端的反馈并不代表此时服务端也停止了执行。
soa暂不清楚

超时在哪里设置

服务端和消费端都可以设置，无论是接口级别和方法级别都有支持

超时设置的优先级

dubbo : 客户端方法级>客户端接口级>客户端全局>服务端方法级>服务端接口级>服务端全局。

soa:客户端配置>服务端配置>框架默认配置
在上面优先级前提下，操作级别配置>服务级别配置>应用级别配置

超时的实现原理是什么

dubbo默认采用了netty做为网络组件，它属于一种NIO的模式。消费端发起远程请求后，线程不会阻塞等待服务端的返回，而是马上得到一个ResponseFuture，消费端通过不断的轮询机制判断结果是否有返回。

超时实现有什么意义

为了避免因为某种原因导致线程被长时间占用，最终出现线程池用完返回拒绝服务的异常。

服务降级

超时就可以与服务降级结合起来，当消费端发生超时时自动触发服务降级