SpringCloud feign服务熔断下的异常处理操作

今天做项目的时候,遇到一个问题,如果我调用某个服务的接口,但是这个服务挂了,同时业务要求这个接口的结果是必须的,那我该怎么办呢,答案是通过hystrix,但是又有一点,服务不是平白无故挂的(排除服务器停电等问题),也就是说有可能是timeout or wrong argument 等等,那么我该如何越过hystrix的同时又能将异常成功抛出呢

第一点:先总结一下异常处理的方式:

1):通过在controller中编写@ExceptionHandler 方法

直接在controller中编写异常处理器方法

 @RequestMapping("/test")
 public ModelAndView test()
 {
  throw new TmallBaseException();
 }
 @ExceptionHandler(TmallBaseException.class)
 public ModelAndView handleBaseException()
 {
  return new ModelAndView("error");
 }

但是呢这种方法只能在这个controller中有效,如果其他的controller也抛出了这个异常,是不会执行的

2):全局异常处理:

@ControllerAdvice
public class AdminExceptionHandler
{
 @ExceptionHandler(TmallBaseException.class)
 public ModelAndView hAndView(Exception exception)
 {
  //logic
  return null;
 }
}

本质是aop代理,如名字所言,全局异常处理,可以处理任意方法抛出的异常

3)通过实现SpringMVC的HandlerExceptionResolver接口

public static class Tt implements HandlerExceptionResolver
 {
  @Override
  public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler,
   Exception ex)
  {
   //logic
   return null;
  }
 }
 

然后在mvc配置中添加即可

@Configuration
public class MyConfiguration extends WebMvcConfigurerAdapter {
    @Override
    public void configureHandlerExceptionResolvers(List<HandlerExceptionResolver> exceptionResolvers) {
    //初始化异常处理器链
        exceptionResolvers.add(new Tt());
    }
}

接下来就是Fegin ,如果想自定义异常需要了解1个接口:ErrorDecoder

先来看下rmi调用结束后是如果进行decode的

Object executeAndDecode(RequestTemplate template) throws Throwable {
    Request request = targetRequest(template);

    //代码省略
    try {
      if (logLevel != Logger.Level.NONE) {
        response =
            logger.logAndRebufferResponse(metadata.configKey(), logLevel, response, elapsedTime);
        response.toBuilder().request(request).build();
      }
      if (Response.class == metadata.returnType()) {
        if (response.body() == null) {
          return response;
        }
        if (response.body().length() == null ||
                response.body().length() > MAX_RESPONSE_BUFFER_SIZE) {
          shouldClose = false;
          return response;
        }
        // Ensure the response body is disconnected
        byte[] bodyData = Util.toByteArray(response.body().asInputStream());
        return response.toBuilder().body(bodyData).build();
      }
      //从此处可以发现,如果状态码不再200-300,或是404的时候,意味着非正常响应就会对内部异常进行解析
      if (response.status() >= 200 && response.status() < 300) {
        if (void.class == metadata.returnType()) {
          return null;
        } else {
          return decode(response);
        }
      } else if (decode404 && response.status() == 404 && void.class != metadata.returnType()) {
        return decode(response);
      } else {
        throw errorDecoder.decode(metadata.configKey(), response);
      }
    } catch (IOException e) {
      if (logLevel != Logger.Level.NONE) {
        logger.logIOException(metadata.configKey(), logLevel, e, elapsedTime);
      }
      throw errorReading(request, response, e);
    } finally {
      if (shouldClose) {
        ensureClosed(response.body());
      }
    }
  }

默认的解析方式是:

 public static class Default implements ErrorDecoder {
    private final RetryAfterDecoder retryAfterDecoder = new RetryAfterDecoder();
    @Override
    public Exception decode(String methodKey, Response response) {
        //获取错误状态码,生成fegin自定义的exception
      FeignException exception = errorStatus(methodKey, response);
      Date retryAfter = retryAfterDecoder.apply(firstOrNull(response.headers(), RETRY_AFTER));
      if (retryAfter != null) {
        //如果重试多次失败,则抛出相应的exception
        return new RetryableException(exception.getMessage(), exception, retryAfter);
      }
    //否则抛出默认的exception
      return exception;
    }

我们可以发现,做了2件事,第一获取状态码,第二重新抛出异常,额外的判断是否存在多次失败依然error的异常,并没有封装太多的异常,既然如此那我们就可以封装我们自定义的异常了

但是注意,这块并没有涉及hystrix,也就意味着对异常进行处理还是会触发熔断机制,具体避免方法最后讲

首先我们编写一个BaseException 用于扩展:省略getter/setter

public class TmallBaseException extends RuntimeException
{
 /**
  *
  * @author joker
  * @date 创建时间:2018年8月18日 下午4:46:54
  */
 private static final long serialVersionUID = -5076254306303975358L;
 // 未认证
 public static final int UNAUTHENTICATED_EXCEPTION = 0;
 // 未授权
 public static final int FORBIDDEN_EXCEPTION = 1;
 // 超时
 public static final int TIMEOUT_EXCEPTION = 2;
 // 业务逻辑异常
 public static final int BIZ_EXCEPTION = 3;
 // 未知异常->系统异常
 public static final int UNKNOWN_EXCEPTION = 4;
 // 异常码
 private int code;

 // 异常信息
 private String message;

 public TmallBaseException(int code, String message)
 {
  super(message);
  this.code = code;
  this.message = message;
 }

 public TmallBaseException(String message, Throwable cause)
 {
  super(message, cause);
  this.message = message;
 }

 public TmallBaseException(int code, String message, Throwable cause)
 {
  super(message, cause);
  this.code = code;
  this.message = message;
 }
}

OK,我们定义好了基类之后可以先进行测试一番:服务接口controller:

//显示某个商家合作的店铺
 @RequestMapping(value="/store")
 public ResultDTO<Collection<BrandDTO>>findStoreOperatedBrands(@RequestParam("storeId")Long storeId)
 {
        为了测试,先直接抛出异常
  throw new TmallBaseException(TmallBaseException.BIZ_EXCEPTION, "ceshi");
    }

接口:

@RequestMapping(value="/auth/brand/store",method=RequestMethod.POST,produces=MediaType.APPLICATION_JSON_UTF8_VALUE)
ResultDTO<List<BrandDTO>>findStoreOperatedBrands(@RequestParam("storeId")Long storeId);

其余的先不贴了,然后我们发起rest调用的时候发现,抛出异常之后并没有被异常处理器处理,这是因为我们是通过fegin,而我又配置了feign的fallback类,抛出异常的时候会自动调用这个类中的方法.

有两种解决方法:

1.直接撤除hystrix ,很明显its not a good idea

2.再封装一层异常类,具体为何,如下

AbstractCommand#handleFallback 函数是处理异常的函数,从方法后缀名可以得知,当exception 是HystrixBadRequestException的时候是直接抛出的,不会触发fallback,也就意味着不会触发降级

final Func1<Throwable, Observable<R>> handleFallback = new Func1<Throwable, Observable<R>>() {
            @Override
            public Observable<R> call(Throwable t) {
                circuitBreaker.markNonSuccess();
                Exception e = getExceptionFromThrowable(t);
                executionResult = executionResult.setExecutionException(e);
                if (e instanceof RejectedExecutionException) {
                    return handleThreadPoolRejectionViaFallback(e);
                } else if (t instanceof HystrixTimeoutException) {
                    return handleTimeoutViaFallback();
                } else if (t instanceof HystrixBadRequestException) {
                    return handleBadRequestByEmittingError(e);
                } else {
                    /*
                     * Treat HystrixBadRequestException from ExecutionHook like a plain HystrixBadRequestException.
                     */
                    if (e instanceof HystrixBadRequestException) {
                        eventNotifier.markEvent(HystrixEventType.BAD_REQUEST, commandKey);
                        return Observable.error(e);
                    }

                    return handleFailureViaFallback(e);
                }
            }
        };

既然如此,那一切都明了了,修改类的继承结构即可:

public class TmallBaseException extends HystrixBadRequestException
{

 /**
  *
  * @author joker
  * @date 创建时间:2018年8月18日 下午4:46:54
  */
 private static final long serialVersionUID = -5076254306303975358L;
 // 未认证
 public static final int UNAUTHENTICATED_EXCEPTION = 0;
 // 未授权
 public static final int FORBIDDEN_EXCEPTION = 1;
 // 超时
 public static final int TIMEOUT_EXCEPTION = 2;
 // 业务逻辑异常
 public static final int BIZ_EXCEPTION = 3;
 // 未知异常->系统异常
 public static final int UNKNOWN_EXCEPTION = 4;
 // 异常码
 private int code;

 // 异常信息
 private String message;
}

至于怎么从服务器中获取异常然后进行转换,就是通过上面所讲的ErrorHandler:

public class TmallErrorDecoder implements ErrorDecoder
{

 @Override
 public Exception decode(String methodKey, Response response)
 {
  System.out.println(methodKey);
  Exception exception=null;
  try
  {
   String json = Util.toString(response.body().asReader());
   exception=JsonUtils.json2Object(json,TmallBaseException.class);
  } catch (IOException e)
  {
   e.printStackTrace();
  }
  return exception!=null?exception:new TmallBaseException(TmallBaseException.UNKNOWN_EXCEPTION, "系统运行异常");
 }
}

最后微服务下的全局异常处理就ok了,当然这个ErrorDdecoder 和BaseException推荐放在common模块下,所有其它模块都会使用到它。

以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。

(0)

相关推荐

  • 详解Spring Cloud Feign 熔断配置的一些小坑

    1.在使用feign做服务调用时,使用继承的方式调用服务,加入Hystrix的熔断处理fallback配置时,会报错,已解决. 2.使用feign默认配置,熔断不生效,已解决. 最近在做微服务的学习,发现在使用feign做服务调用时,使用继承的方式调用服务,加入Hystrix的熔断处理fallback配置时,会报错,代码如下: @RequestMapping("/demo/api") public interface HelloApi { @GetMapping("user/

  • 详解springcloud 基于feign的服务接口的统一hystrix降级处理

    springcloud开发微服务时,基于feign来做声明式服务接口,当启用hystrix服务熔断降级时,项目服务众多,每个Feign服务接口都得写一些重复问的服务降级处理代码,势必显得枯燥无味: Feign服务接口: @FeignClient(name="springcloud-nacos-producer", qualifier="productApiService", contextId="productApiService", fallb

  • Spring Cloud Hystrix异常处理方法详解

    这篇文章主要介绍了Spring Cloud Hystrix异常处理方法详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 在调用服务执行HsytrixCommand实现的run()方法抛出异常时,除HystrixBadRequestException之外,其他异常都会认为是Hystrix命令执行失败并触发服务降级处理逻辑. 异常处理 当Hystrix命令因为异常(除了HystrixBadRequestException异常)进入服务降级逻辑之后

  • SpringCloud feign微服务调用之间的异常处理方式

    如何优雅地处理微服务间调用的异常 现在微服务架构盛行,其中spring cloud方案就很具有代表. 那么在微服务之间进行调用,如果被调用的服务挂了,调用方如何感知呢? 一.加上hystrix熔断 在定义feignClient的地方指定熔断,如下图 当被调用服务不可用或者被调用方发生错误的时候,会触发熔断,但是,如果被调用方抛出异常,调用方怎么知道究竟是出了什么问题呢? 那,这就出现了 二.feign全局异常处理 我们不得不提到feign提供的一个接口叫做ErrorDecoder, 是用来处理f

  • SpringCloud feign服务熔断下的异常处理操作

    今天做项目的时候,遇到一个问题,如果我调用某个服务的接口,但是这个服务挂了,同时业务要求这个接口的结果是必须的,那我该怎么办呢,答案是通过hystrix,但是又有一点,服务不是平白无故挂的(排除服务器停电等问题),也就是说有可能是timeout or wrong argument 等等,那么我该如何越过hystrix的同时又能将异常成功抛出呢 第一点:先总结一下异常处理的方式: 1):通过在controller中编写@ExceptionHandler 方法 直接在controller中编写异常处

  • SpringCloud Feign请求头删除修改的操作代码

    Feign请求头修改删除操作 @Configuration public class ClientConfiguration { @Bean public RequestInterceptor headerInterceptor() { return new RequestInterceptor() { @Override public void apply(RequestTemplate template) { HttpServletRequest httpServletRequest = (

  • Springcloud hystrix服务熔断和dashboard如何实现

    服务在经过一定负荷之后,如果达到一定上限之后会中断进行报错,而服务调用的方法也会报错等等,一旦整体服务停下,别的客户端再来访问就会无法调用.对此需要进行另外一种服务熔断模式. 不同于现实中的熔断保险丝,服务熔断是在系统服务达到一定错误之后,自动熔断降级,采取备用方法,但是在一定时间后客户端再次调用成功后,一定时间内成功率上去,系统的熔断机制会慢慢的关闭,恢复到正常请求的状态. 本篇接上一章直接改动. 1.主启动类加上新的注解. @EnableCircuitBreaker 2.service写入新

  • springcloud feign服务之间调用,date类型转换错误的问题

    目录 feign服务之间调用,date类型转换错误 自定义feign请求头 通过判断是否为feign请求 OpenFeign服务间调用时日期格式异常 异常为 原因 解决方法 feign服务之间调用,date类型转换错误 最近尝试换springcloud开发,原先是springboot,每次的返回值的Date类型都通过@ControllerAdvice格式化yyyy-MM-dd HH:mm:ss然后返回的.这次用feign之后,2个服务之间调用,一直报错查了好久百度都搞不定,后面灵光一闪...不多

  • SpringCloud Feign 服务调用的实现

    前言 前面我们已经实现了服务的注册与发现(请戳:SpringCloud系列--Eureka 服务注册与发现),并且在注册中心注册了一个服务myspringboot,本文记录多个服务之间使用Feign调用. Feign是一个声明性web服务客户端.它使编写web服务客户机变得更容易,本质上就是一个http,内部进行了封装而已. GitHub地址:https://github.com/OpenFeign/feign 官方文档:https://cloud.spring.io/spring-cloud-

  • SpringCloud Feign服务调用请求方式总结

    前言 最近做微服务架构的项目,在用feign来进行服务间的调用.在互调的过程中,难免出现问题,根据错误总结了一下,主要是请求方式的错误和接参数的错误造成的.在此进行一下总结记录.以下通过分为三种情况说明,无参数,单参数,多参数.每种情况再分get和post两种请求方式进行说明.这样的话,6种情况涵盖了feign调用的所有情况. 有个建议就是为了保证不必要的麻烦,在写feign接口的时候,与我们的映射方法保持绝对一致,同时请求方式,请求参数注解也都不偷懒的写上.如果遵循这种规范,可以避开90%的调

  • SpringCloud微服务之Hystrix组件实现服务熔断的方法

    一.熔断器简介 微服务架构特点就是多服务,多数据源,支撑系统应用.这样导致微服务之间存在依赖关系.如果其中一个服务故障,可能导致系统宕机,这就是所谓的雪崩效应. 1.服务熔断 微服务架构中某个微服务发生故障时,要快速切断服务,提示用户,后续请求,不调用该服务,直接返回,释放资源,这就是服务熔断. 熔断生效后,会在指定的时间后调用请求来测试依赖是否恢复,依赖的应用恢复后关闭熔断. 2.服务降级 服务器高并发下,压力剧增的时候,根据当业务情况以及流量,对一些服务和页面有策略的降级(可以理解为关闭不必

  • 记一次线上SpringCloud Feign请求服务超时异常排查问题

    由于近期线上单量暴涨,第三方反馈部分工单业务存在查询处理失败现象,经排查是当前系统通过FeignClient调用下游系统出现部分超时失败(异常代码贴在下方). Caused by: feign.RetryableException: Read timed out executing POST http://xxxx        at feign.FeignException.errorExecuting(FeignException.java:84) ~[feign-core-10.1.0.j

  • SpringCloud Feign实现微服务之间相互请求问题

    目录 Feign简介 Spring Cloud 组件依赖版本 Feign实现服务之间访问 ☘创建nacos-consumer-feign微服务 创建feign client ☘nacos-provider微服务 Feign微服务之间访问测试 ☘Feign容错机制 上篇文章说了通过RestTemplate实现微服务之间访问:https://www.jb51.net/article/252981.htm,这篇文章将通过Feign实现微服务之间访问.代码基于RestTemplate实现微服务之间访问基

  • 解决在微服务环境下远程调用feign和异步线程存在请求数据丢失问题

    目录 一.无异步线程得情况下feign远程调用: 1.登录拦截器: 2.问题示例图: 3.解决方法: 解决方式(高亮部分):从总线中获取request数据放入子线程中 二.异步情况下丢失上下文问题: 一.无异步线程得情况下feign远程调用: 1.登录拦截器: @Component public class LoginUserInterceptor implements HandlerInterceptor { public static ThreadLocal<MemberResVo> lo

随机推荐