设想一下这种场景，我们调用一个服务，当调用很多次后这个服务依然处于根据我们配置条件下认为的异常时，这时候我们有必要再下次调用时直接去它降级的方法里去，这样可以节省资源。同时在之后的调用里，尝试着让一些调用再去真实调用，如果还是异常，那么继续服务降级，服务慢慢恢复调用成功了，那么也可以慢慢放行更多的调用。
hystrix内部给我们提供了一套算法来处理上面的事情，其目的就是为了更好的利用资源。简单来说就是我们去调用一个接口，明明它长期处于异常状态就不要去调用了，但是之后也需要尝试着让一两个调用去试试，如果可行，慢慢让剩下的调用继续调用，不行的话再去降级处理。
//服务熔断
@HystrixCommand(fallbackMethod = "paymentBreakerFallback",commandProperties = {
@HystrixProperty(name="circuitBreaker.enabled",value = "true"),//是否开启断路器
@HystrixProperty(name="circuitBreaker.requestVolumeThreshold",value = "10"),//请求次数
@HystrixProperty(name="circuitBreaker.sleepWindowInMilliseconds",value = "10000"),//时间窗口期
@HystrixProperty(name="circuitBreaker.errorThresholdPercentage",value = "60")//失败率
})
public String paymentBreaker(Integer id){
if(id<0){
throw new RuntimeException("id不能为负数");
}
return "线程池"+Thread.currentThread().getName()+"调用成功，流水号为"+ UUID.randomUUID().toString();
}
public String paymentBreakerFallback(Integer id){
return "id不能为负数，请稍后再试";
}
熔断里面必须包含服务降级
原文：https://www.cnblogs.com/johnzhao/p/14586452.html