2019独角兽企业重金招聘Python工程师标准>>>
最近在项目开发中,使用 Feign 调用服务,当触发熔断机制时,遇到了以下问题:
TestService#addRecord(ParamVO) failed and no fallback available.
;接下来将一一解决上述问题。
对于failed and no fallback available.
这种异常信息,是因为项目开启了熔断:
abled: true
当调用服务时抛出了异常,却没有定义fallback
方法,就会抛出上述异常。由此引出了第一个解决方式。
@FeignClient
加上fallback
方法,并获取异常信息为@FeignClient
修饰的接口加上fallback
方法有两种方式,由于要获取异常信息,所以使用fallbackFactory
的方式:
@FeignClient(name = "serviceId", fallbackFactory = TestServiceFallback.class)
public interface TestService {@RequestMapping(value = "/get/{id}", method = RequestMethod.GET)Result get(@PathVariable("id") Integer id);}
在@FeignClient
注解中指定fallbackFactory
,上面例子中是TestServiceFallback
:
import feign.hystrix.FallbackFactory;
import org.apachemons.lang3.StringUtils;
@Component
public class TestServiceFallback implements FallbackFactory<TestService> {private static final Logger LOG = Logger(TestServiceFallback.class);public static final String ERR_MSG = "Test接口暂时不可用: ";@Overridepublic TestService create(Throwable throwable) {String msg = throwable == null ? "" : Message();if (!StringUtils.isEmpty(msg)) {(msg);}return new TestService() {@Overridepublic String get(Integer id) {return ResultBuilder.unsuccess(ERR_MSG + msg);}};}
}
通过实现FallbackFactory
,可以在create
方法中获取到服务抛出的异常。但是请注意,这里的异常是被Feign
封装过的异常,不能直接在异常信息中看出原始方法抛出的异常。这时得到的异常信息形如:
status 500 reading TestService#addRecord(ParamVO); content:
{"success":false,"resultCode":null,"message":"/ by zero","model":null,"models":[],"pageInfo":null,"timelineInfo":null,"extra":null,"validationMessages":null,"valid":false}
说明一下,本例子中,服务提供者的接口返回信息会统一封装在自定义类Result
中,内容就是上述的content
:
{"success":false,"resultCode":null,"message":"/ by zero","model":null,"models":[],"pageInfo":null,"timelineInfo":null,"extra":null,"validationMessages":null,"valid":false}
因此,异常信息我希望是message
的内容:/ by zero
,这样打日志时能够方便识别异常。
当调用服务时,如果服务返回的状态码不是200,就会进入到Feign
的ErrorDecoder
中,因此如果我们要解析异常信息,就要重写ErrorDecoder
:
import feign.Response;
import feign.Util;
dec.ErrorDecoder;
/*** @Author: CipherCui* @Description: 保留 feign 服务异常信息* @Date: Created in 1:29 2018/6/2*/
public class KeepErrMsgConfiguration {@Beanpublic ErrorDecoder errorDecoder() {return new UserErrorDecoder();}/*** 自定义错误*/public class UserErrorDecoder implements ErrorDecoder {private Logger logger = Logger(getClass());@Overridepublic Exception decode(String methodKey, Response response) {Exception exception = null;try {// 获取原始的返回内容String json = String(response.body().asReader());exception = new RuntimeException(json);// 将返回内容反序列化为Result,这里应根据自身项目作修改Result result = EmptyMapper().fromJson(json, Result.class);// 业务异常抛出简单的 RuntimeException,保留原来错误信息if (!result.isSuccess()) {exception = new Message());}} catch (IOException ex) {(ex.getMessage(), ex);}return exception;}}
}
上面是一个例子,原理是根据response.body()
反序列化为自定义的Result
类,提取出里面的message
信息,然后抛出RuntimeException
,这样当进入到熔断方法中时,获取到的异常就是我们处理过的RuntimeException
。
注意上面的例子并不是通用的,但原理是相通的,大家要结合自身的项目作相应的修改。
要使上面代码发挥作用,还需要在@FeignClient
注解中指定configuration
:
@FeignClient(name = "serviceId", fallbackFactory = TestServiceFallback.class, configuration = {KeepErrMsgConfiguration.class})
public interface TestService {@RequestMapping(value = "/get/{id}", method = RequestMethod.GET)String get(@PathVariable("id") Integer id);}
有时我们并不希望方法进入熔断逻辑,只是把异常原样往外抛。这种情况我们只需要捉住两个点:不进入熔断、原样。
原样就是获取原始的异常,上面已经介绍过了,而不进入熔断,需要把异常封装成HystrixBadRequestException
,对于HystrixBadRequestException
,Feign
会直接抛出,不进入熔断方法。
因此我们只需要在上述KeepErrMsgConfiguration
的基础上作一点修改即可:
/*** @Author: CipherCui* @Description: feign 服务异常不进入熔断* @Date: Created in 1:29 2018/6/2*/
public class NotBreakerConfiguration {@Beanpublic ErrorDecoder errorDecoder() {return new UserErrorDecoder();}/*** 自定义错误*/public class UserErrorDecoder implements ErrorDecoder {private Logger logger = Logger(getClass());@Overridepublic Exception decode(String methodKey, Response response) {Exception exception = null;try {String json = String(response.body().asReader());exception = new RuntimeException(json);Result result = EmptyMapper().fromJson(json, Result.class);// 业务异常包装成 HystrixBadRequestException,不进入熔断逻辑if (!result.isSuccess()) {exception = new Message());}} catch (IOException ex) {(ex.getMessage(), ex);}return exception;}}
}
为了更好的达到熔断效果,我们应该为每个接口指定fallback
方法。而根据自身的业务特点,可以灵活的配置上述的KeepErrMsgConfiguration
和NotBreakerConfiguration
,或自己编写Configuration
。
转载于:
本文发布于:2024-02-02 04:38:38,感谢您对本站的认可!
本文链接:https://www.4u4v.net/it/170681991941407.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
留言与评论(共有 0 条评论) |