spring cloud alibaba 实战篇（五）——sentinel服务熔断

实战三，其实我们已经写到了服务降级，但是那是针对feign延迟做的一个服务降级，其实请求还打向了我们的payment-service。

但是在实际开发中，我们不光在服务提供者（payment-service）做限流处理，也要考虑我们的消费方（account-service）做主动的熔断

降级处理。避免服务请求一直等待，让服务提供者存在大量的排队和服务压力，消费方的体验也非常不好。如果该服务还为其他消费者提供服务，那么就容易产生服务雪崩效应了。

接来下，我们针对account-service做服务改造，让这个服务在调用payment-service超时一定次数时，就直接主动熔断降级。

引入sentinel相关jar包，引入的忽略

修改account-service的bootstrap.yml

配置和payment-service类似，但是要注意下红框，rule-tuype是degrade

这里有一个问题：配置了eager:true，你会发现2个服务在sentinel控制台都不出来了。这个是懒加载的意思，大家可以重启下sentinel控制台，

再访问下服务，可以在控制台看到payment-service和account-service都刷出来了，如果还是不能出来，添加jar包

正常情况是这样：

nacos新增配置

需要注意下Data  ID  要和bootstrap.yml配置文件中dataId一致

配置文件解析：

当资源的平均响应时间超过阈值500毫秒之后，资源进入准降级状态。如果接下来1秒内持续进入5个请求的RT都持续超过这个阈值，那么在接下的时间窗口（timeWindow）之内，对这个方法的调用都会自动地熔断。

接下来修改Nacos中配置项payment-service-dev.properties的sleep值，修改为1000，让/pay/balance接口响应前先挂起1秒钟来模拟服务器卡顿情况。

用浏览器打开http://localhost:8081/acc/user?id=2并连续刷新6次以上。可以观察到，从第7次开始接口不再等待1秒后返回，而是快速返回降级，并在接下来的10秒内（timeWindow:10），都处于主动熔断。

到这里就结束了，大家有疑问，可以给我留言。

最近在出差，等后面有时间，我会把gateway网关限流，nginx限流整套完善起来。