Spring Cloud Alibaba之服务容错组件 - 注解

2019-07-16 本文已影响0人匆匆岁月

@SentinelResource注解

接下来我们就学习下，如何使用@SentinelResouce 注解灵活的定义控制资源以及如何配置控制策略。

自定义资源点

第一步：在应用中中添加注解支持配置：

@EnableDiscoveryClient
@SpringBootApplication
public class UserApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserApplication.class, args);
    }

    // 注解支持的配置Bean
    @Bean
    public SentinelResourceAspect sentinelResourceAspect() {
        return new SentinelResourceAspect();
    }
}

第二步：在需要通过Sentine来控制流量的地方使用 @SentinelResouce 注解，比如下面控制Service逻辑层某个方法为例：

@Slf4j
@Service
public class TestService {

    @SentinelResource(value = "doSomeThing")
    public void doSomeThing(String str) {
        log.info("限流测试: {}", str);
    }
}

实现 - 限流控制

第一步：在web层调用这个被限流的方法：

@Slf4j
@RestController
public class UserController {

    @Autowired
    private TestService testService;

    @GetMapping("/user/{id}")
    public String getUser(@PathVariable("id") Long id) {
        testService.doSomeThing("pyy");
        return "success";
    }
}

第二步：启动测试应用，启动Sentinel-Dashboard。发一个请求到/user/1接口上，使得Sentinel-Dashboard上可以看到如下图所示的几个控制点：

可以看到，除了如之前入门实例中那样有/user/1资源点之外，多了一个doSomeThing资源点。可以通过界面为这个资源点设置限流规则，比如将其QPS设置为2。由于/user/1资源不设置限流规则，所以只要请求/user/1接口，就可以直接模拟调用doSomeThing资源，来观察限流规则是否生效。

下面可以通过任何postman工具来调用/hello接口，只要QPS超过2，那么就会出现如下的错误返回，代表限流策略生效了。

此时，服务端的控制台也会有对应的限流报错日志

2019-07-16 13:50:53.505 ERROR 13920 --- [nio-9001-exec-7] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.reflect.UndeclaredThrowableException] with root cause

com.alibaba.csp.sentinel.slots.block.flow.FlowException: null

实现限流的异常处理

默认情况下，Sentinel对控制资料的限流处理是直接抛出异常，也就是上一节中贴出的日志内容。在没有合理的业务承接或者前端对接清苦啊下可以这样，但是正常情况下为了更好的用户业务，都会实现一些限流之后的特殊处理，我们不希望展示一些生硬的报错信息。那么只需要基于上面的例子再做一些加工即可实现，比如：

@Slf4j
@Service
public class TestService {

    @SentinelResource(value = "doSomeThing", blockHandler = "exceptionHandler")
    public void doSomeThing(String str) {
        log.info("限流测试: {}", str);
    }

    
    // 限流与阻塞处理
    public void exceptionHandler(String str, BlockException ex) {
        log.error( "blockHandler：" + str, ex);
    }
}

通过 @SentinelResource 注解的 blockHandler 属性指定具体的处理函数
实现处理函数，该函数的传参必须与资源点的传参一样，并且最后加上 BlockException 异常参数; 同时，返回类型必须也一样。

如果使用过Hystrix的同学，应该看到这个设计和HystrsicCommand中定义fallback很类似。

/**
     * 使用Hystrix断路器
     * @param id
     * @return
     */
    @HystrixCommand(fallbackMethod = "fallback")
    @GetMapping("/hystrix/{id}")
    public String findUserHystrix(@PathVariable("id") Long id){
        return restTemplate.getForObject("http://USER-SERVICE/user/{1}",User.class,id).toString();
    }

    private String fallback(Long id){
        return "Error:"+id;
    }

完善上面改动后，再重新启动、访问接口（注意限流规则需要配置好），就会看到后天打印 exceptionHandler 中定义的日志输出。
而在实际应用中，只要根据业务需要对限流请求做缓存或前端提示等，都可以基于此方法实现。

实现 - 熔断降级

@SentinelResource 注解除了可以用来做限流控制之外，还能实现与Hystrix类似的 熔断降级策略。下面就看看具体如何实现。

第一步：与限流控制一样，使用 @SentinelResource 注解标记资源点，比如：

@Slf4j
@Service
public class TestService {
    
    @SentinelResource(value = "doSomeThing2")
    public void doSomeThing2(String str) {
        log.info("限流测试2: {}", str);
        throw new RuntimeException("发生异常");
    }
}

这里在TestService类中创建了一个新的方法，并使用@SentinelResource将该资源命名为doSomeThing2。该方法会抛出异常，以配合后续制定基于异常比例的降级策略（类似Hystrix）。Sentinel相比Hystrix更丰富，还有基于响应时间和异常数的降级策略。

第二步：在Web层调用这个被保护的方法：

@Slf4j
@RestController
public class UserController {

    @Autowired
    private TestService testService;

    @GetMapping("/user/{id}")
    public String getUser(@PathVariable("id") Long id) {
        testService.doSomeThing2("pyy " + new Date());
        return "success";
    }
}

第三步：启动测试应用，启动 Sentinel-Dashboard。发一个请求到/user/1接口上，使得 Sentinel-Dashboard上可以看到名为doSomeThing2的资源点。然后点击”降级“按钮，为该资源设置降级规则。这里使用异常比例策略，比例设置为0.5（即：50%的异常率），时间窗口设置为2（秒）。

第四步：验证熔断降级
这里可以采用 Jmeter，压测工具配置

根据上面的降级策略配置，当doSomeThing2方法的调用QPS >= 5，如果异常率超过50%，那么后续2秒内的调用将直接出发熔断降级，默认情况会直接抛出DegradeException异常，比如：

2019-07-16 14:29:24.748 ERROR 5480 --- [nio-9001-exec-9] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.reflect.UndeclaredThrowableException] with root cause

com.alibaba.csp.sentinel.slots.block.degrade.DegradeException: null

熔断的讲解处理

在Sentinel中定义熔断的降级处理方法非常简单，与Hystrix非常相似。只需要使用@SentinelResource注解的fallback属性来指定具体的方法名即可。这里也需要注意传参与返回必须一致。比如：

@Slf4j
@Service
public class TestService {

    @SentinelResource(value = "doSomeThing2", fallback = "fallbackHandler")
    public void doSomeThing2(String str) {
        log.info("限流测试2: {}", str);
        throw new RuntimeException("发生异常");
    }

    public void fallbackHandler(String str) {
        log.error("fallbackHandler：" + str);
    }
}

完成上面的改造之后，重启应用，并重新设置doSomeThing2资源的熔断降级策略（使用异常百分比），然后使用 JMeter 工具频繁的请求/user/1接口。在QPS>=5之后，由于这个接口一直在抛出异常，所以一定会满足熔断降级条件，这时候就会执行fallbackHandler方法，不断的打印如下日志：

2019-07-16 14:36:04.974 ERROR 5744 --- [nio-9001-exec-8] com.thtf.demo.service.TestService        : fallbackHandler：pyy Tue Jul 16 14:36:04 CST 2019
2019-07-16 14:36:04.976 ERROR 5744 --- [nio-9001-exec-1] com.thtf.demo.service.TestService        : fallbackHandler：pyy Tue Jul 16 14:36:04 CST 2019
2019-07-16 14:36:04.977 ERROR 5744 --- [nio-9001-exec-3] com.thtf.demo.service.TestService        : fallbackHandler：pyy Tue Jul 16 14:36:04 CST 2019
2019-07-16 14:36:04.979 ERROR 5744 --- [nio-9001-exec-4] com.thtf.demo.service.TestService        : fallbackHandler：pyy Tue Jul 16 14:36:04 CST 2019
2019-07-16 14:36:04.980 ERROR 5744 --- [nio-9001-exec-7] com.thtf.demo.service.TestService        : fallbackHandler：pyy Tue Jul 16 14:36:04 CST 2019
2019-07-16 14:36:04.982 ERROR 5744 --- [nio-9001-exec-8] com.thtf.demo.service.TestService        : fallbackHandler：pyy Tue Jul 16 14:36:04 CST 2019
2019-07-16 14:36:04.983 ERROR 5744 --- [nio-9001-exec-1] com.thtf.demo.service.TestService        : fallbackHandler：pyy Tue Jul 16 14:36:04 CST 2019
2019-07-16 14:36:04.984 ERROR 5744 --- [nio-9001-exec-3] com.thtf.demo.service.TestService        : fallbackHandler：pyy Tue Jul 16 14:36:04 CST 2019
2019-07-16 14:36:04.986 ERROR 5744 --- [nio-9001-exec-4] com.thtf.demo.service.TestService        : fallbackHandler：pyy Tue Jul 16 14:36:04 CST 2019

注解属性说明

关于@SentinelResource 注解最主要的两个用法：限流控制和熔断降级的具体使用已经介绍完了。另外，该注解还有一些其他的更细致的属性配置，比如忽略某些异常的配置、默认降级函数等等，具体课件下面说明：

value：资源名称，必须项（不能为空）
entryType：entry 类型，可选项（默认为 EntryType.OUT）
blockHandler / blockHandlerClass: blockHandler对应处理 BlockException 的函数名称，可选项。blockHandler 函数访问范围需要是 public，返回类型需要与原方法相匹配，参数类型需要和原方法相匹配并且最后加一个额外的参数，类型为 BlockException。blockHandler 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 blockHandlerClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
fallback：fallback 函数名称，可选项，用于在抛出异常的时候提供 fallback 处理逻辑。fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore里面排除掉的异常类型）进行处理。fallback 函数签名和位置要求：
- 返回值类型必须与原函数返回值类型一致；
- 方法参数列表需要和原函数一致，或者可以额外多一个 Throwable
- 类型的参数用于接收对应的异常。
- fallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
defaultFallback（since 1.6.0）：默认的 fallback 函数名称，可选项，通常用于通用的 fallback 逻辑（即可以用于很多服务或方法）。默认 fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore里面排除掉的异常类型）进行处理。若同时配置了 fallback 和 defaultFallback，则只有 fallback 会生效。defaultFallback 函数签名要求：
- 返回值类型必须与原函数返回值类型一致；
- 方法参数列表需要为空，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。
- defaultFallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
exceptionsToIgnore（since 1.6.0）：用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出。

注：1.6.0 之前的版本 fallback 函数只针对降级异常（DegradeException）进行处理，不能针对业务异常进行处理。

注意： 若 blockHandler 和fallback 都进行了配置，则被限流降级而抛出 BlockException时只会进入blockHandler 处理逻辑。若未配置 blockHandler，则被限流降级时会将 BlockException 直接抛出。