1.开篇
前面那四篇文章，基本上都是在聊sentinel中有关限流降级的内容，现在该聊聊sentinel中的服务熔断了。
内容大致就是 @SentinelResource 注解中的fallback属性，同时分别整合Ribbon、OpenFeign。
2.项目源码
github源码地址：https://github.com/2656307671/SpringCloud-Alibaba-Sentinel
gitee源码地址：https://gitee.com/szh-forever-young/SpringCloud-Alibaba-Sentinel
下面的测试对应了git仓库中的9003、9004、84这三个微服务模块。前提是nacos启动成功、sentinel启动成功。先对9003、9004中的请求 /paymentSQL/{id} 进行一次访问。可以正常拿到数据，说明微服务提供者启动成功。
2.1 Sentinel + Ribbon
测试完9003、9004之后，我们启动84微服务消费者模块，因为nacos默认集成了ribbon，所以这里访问 /consumer/fallback/{id} 自然是一次9003、一次9004，已经实现了负载均衡。
下面来说服务熔断，就要通过 @SentinelResource 注解中的fallback属性来配置。如果我们什么都不配，注解中只写一个标注服务熔断的唯一名称value属性，那么此时如果出错，反馈给用户的将会是error page，看上去很不友好。
所以这里在 @SentinelResource 注解中进行fallback属性的配置，详情参考仓库代码。配置了fallback之后再访问，由于id=4、5这两个值我没有添加，所以访问必然出错，但我们配置了fallback属性，此时出错就会走fallback对应的兜底方法。
上面的案例只配置了fallback，可以看到出错之后会走fallback中定义的兜底方法。
下面演示只配置blockHandler的情况。当异常数达到两次之后，未来2秒的时间窗口内，将转向blockHandler中定义的降级限流方法。
2.1.3 fallback和blockHandler都配置
因为blockHandler负责的是在sentinel页面中的降级限流，所以我们这里先对fallback请求方法做一个配置。QPS > 1 则触发blockHandler的降级限流。
id=1，数据存在，正常情况下1s内访问1次，是可以拿到数据的。
下面这张图是我在1s内访问了多次，则满足配置 QPS > 1，触发blockHandler相关的降级限流方法。
id=4，数据不存在，访问之后直接会报 IllegalArgumentException 非法参数异常，而我们的@SentinelResource注解中的fallback属性可以来处理该异常信息，此时不再返回error page，而是返回fallback中定义的兜底方法。
上面的截图1s内只访问了1次id=4这个请求，下面我1s内访问多次，此时满足 QPS > 1，直接触发blockHandler相关的降级限流方法。
根据fallback和blockHandler都配置的情况，我们可以得出结论：👇👇👇
· fallback管理Java中的运行时异常信息，如果出现异常，则走fallback中定义的兜底方法。
· blockHandler一般需要在sentinel中进行配置，只要你满足了QPS、异常数等这些配置信息，一定走blockHandler中定义的降级限流方法。
· 例如上面的案例，异常1s内出现1次，则走fallback；1s内超过1次，则走blockHandler。
2.2 Sentinel + OpenFeign
使用Sentinel集成OpenFeign了话，首先要做一些修改。
1. 因为nacos默认继承了ribbon，所以sentinel中可以直接使用ribbon，不用再添加ribbon依赖。但是openfeign不一样，需要pom中额外添加openfeign的依赖。
2. 在yml配置文件中，激活sentinel对openfeign的支持。
3. 连接服务提供者的业务接口上需要添加 @FeignClient 注解等相关配置信息。
4. 主启动类上添加@EnableFeignClients 注解表示开启对OpenFeign的支持。
下面就做一个简单的测试了，需要启动84微服务消费者、9004微服务提供者。进行一次访问，可以拿到数据。
此时将9004微服务提供者停掉，再次访问，可以看到84微服务消费者进行了自动降级，也就是找不到微服务提供者9004，会去找连接服务提供者的业务接口，根据业务接口上的 @FeignClient 注解等相关配置信息，找到相应的接口实现类中的降级方法，进行自动降级。
