SpringZuul熔断机制分析

关于配置针对每个服务进行熔断时间（全家桶版本为Edgware.RELEASE）

1.从SpringCloud Zuul的源代码角度进行分析：

SpringCloud在 HystrixCommandProperties 的构造方法加载配置文件的时候，在getProperty 方法处会增加两个配置属性到 ChainBuilder 中，default和配置文件中的服务名称 ( 如：app-user-service 注册到注册中心中的name )。如果在网关配置文件中配置default，在build方法中，会将两个配置属性增加到List中，并且会进行排序，排序之后default就会排在第二位。所以在熔断监听的时候，会出现去获取 app-user-service 的配置，默认为2000ms。

2.网关每次转发请求给服务的时候，执行底层发送之后会返回一个Feture对象，当网关的转发请求执行时间大于2000ms，则会为Feture设置一个error。Feture对象会调用isDone方法进行阻塞，当转发请求完成后，Done则会完成，但是这时候，会先判断Feture是否有Error，如有，则网关做转发失败处理，因为熔断时间已经到了。

3.关于网关调用服务执行流程，网关会在HystrixCommand类中的queue方法执行调用。第一行代码，则是将观察者设置为阻塞模式，这样网关在转发的时候，不是异步，而是等待网关执行完成才会执行后面的代码。 接着上一个问题，如果Spring运行时，读取的是超时是 2000ms，但是在网关转发调用服务时执行的时间为5000ms，其实在2000ms的时候，就应该关闭请求调用，返回Feture，但是却一直阻塞到5000ms直到请求返回，才返回Feture。不友好！！！由于调用已经超过熔断的2000ms，异步Listener会设置一个error，在getValue时，线判断如果 error != null，就会直接将异常返回并抛出。

4.因为请求属于阻塞形式的，当网关熔断后，并没有真正的熔断请求。所以此处可以修改成NIO形式，或者异步请求的形式。当网关转发超时熔断之后，立马将当前客户端的请求返回给客户端。