Spring cloud微服务安全实战-6-9sentinel之熔断降级

来讲一下降级规则

服务会互相调用，服务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对熔断降级的支持

结束