来讲一下降级规则
服务会互相调用，服务A会有一些服务之间的依赖。
假设服务D的响应时间变长了。A调用D就会卡住了。
熔断，某一个服务出现问题，会把服务拖死。如果A出现,会把依赖A的那些服务拖死。
主要原理是在所有服务的前面加一个熔断器。平常是关闭的，如果发现后面的服务不可用，就提示打不开。
服务A调用服务D的时候，经过熔断器直接返回。不会让你再调用到服务D。这个时候服务A就不会因为服务D的相应时间变慢而在这里有线程堆积，在这等待，这样就解决了服务雪崩的问题。
详细看下熔断器
代码定义降级
degradeRule降级的规则
setGrade降级的策略：
每秒请求数大于等于5，降级规则才会生效。流量太小规则不会生效。
exception_count以分钟为范围
10秒，一般熔断器处于打开状态，到打开状态的一瞬间，之后的10秒钟之内，所有的请求直接就打回来，10秒后会跳到半打开的状态。
完整的代码
降低的规则在流量大于等于5才会生效。所以上面的qps规则刚才是1 一直都不会生效，这里我们改成10
10毫秒以上才会认为服务有问题。所以，订单的方法内 sleep 50毫秒。
重启orderAPI
服务是正常的
比较快速的去点击按钮访问。500就说明 我们的服务被熔断了。
等大概10秒钟，熔断窗口设置的是10秒，10秒之后，可能就会恢复回来。
这就是我们刚才设置的规则
控制台的输出。抛出降级的异常。
服务熔断后，指定另外一个降级逻辑处理
里面的方法名是可以随便起的。这里叫做doOnBlock。
doOnBlock这个方法默认应该在当前的这个类里面。doOnBlock这个方法和create 方法是一样的 只不过多了一个参数。BlockExcepion是所有sentinel异常的父类。流控、降级抛出的异常都是BlockException
异常后会走doBlock方法，并返回一个info
重启orderAPi测试
不管点击多快速 访问这个服务，都不会看到500错误了。因为我服务被熔断了。但是提供了一个降级的逻辑，仍然会有一个返回。
看日志就能看出来。
这就是sentinel对熔断降级的支持
结束