使用dubbo有几年了,最近开始在博客上分享自己的一些实际工作经验,今天就先说下dubbo的异常处理,请大家多加指正。
dubbo有自己的异常处理机制,当服务端抛出一个dubbo可以处理传递的异常时,会直接在客户端上再次抛出,由开发者自己去处理。注意:这里说的不是所有异常,而是dubbo可以处理传递的异常,具体这个后边再说。
先看两段代码,接口代码:
public interface IPersonService {
public Person getPerson(long id);
/**
* 根据名称获取
*
* @param name
* @return
*/
public Person getByNick(String name);
}
简单实现:
public class PersonServiceImpl implements IPersonService {
private final static AtomicInteger ID = new AtomicInteger();
@Override
public Person getPerson(long id) {
Person person = new Person();
person.setId(id);
person.setName("某某");
try {
Thread.sleep(2000l);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return person;
}
@Override
public Person getByNick(String name) {
name = name.trim();
Person person = new Person();
person.setId(ID.getAndIncrement());
person.setName(name);
return person;
}
}
这两段代码很简答,先看getByNick方法,根据用户名称获取用户信息,里面有一个去空格的操作(主要为了触发异常),正常调用是没有问题的,但如果传入null,就会抛出很常见且低级的空指针异常。我们看下调用代码:
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
new String[] { "app-dubbo-consumer.xml" });
context.start();
IPersonService personService = context.getBean(IPersonService.class);
// 正常输入参数
outString(personService.getByNick("某某"));
// 输入null
outString(personService.getByNick(null));
运行后,首先会打印{"id":0,"name":"某某"},然后出现java.lang.NullPointerException,一切在我们的预料内,dubbo把服务端的空指针异常传递给客户端了。
正常来说,空指针异常是不应该出现的,而且客户端遇到这个错误肯定直接懵了,所以我们做下简单的修改,服务端代码:
@Override
public Person getByNick(String name) {
if (name == null) {
throw new RuntimeException("亲你咋没输入昵称呢");
}
name = name.trim();
Person person = new Person();
person.setId(ID.getAndIncrement());
person.setName(name);
return person;
}
客户端再次调用结果:
Exception in thread "main" java.lang.RuntimeException: 亲你咋没输入昵称呢
at org.dubbo.provider.PersonServiceImpl.getByNick(PersonServiceImpl.java:28)
at com.alibaba.dubbo.common.bytecode.Wrapper1.invokeMethod(Wrapper1.java)
结果友好了多,甚至你可以直接对exception获取异常信息作为输出。
上边提到过当服务端抛出一个dubbo可以处理传递的异常时,会直接在客户端上再次抛出,但不是所有的异常都是dubbo可以处理传递的,如下边的代码:
@Override
public Person getByNick(String name) {
if (name == null) {
// 第三方异常
throw new PersistenceException("mybatis插入异常");
}
name = name.trim();
Person person = new Person();
person.setId(ID.getAndIncrement());
person.setName(name);
return person;
}
这里我们模拟抛出了一个mybatis的异常,在客户端调用会像上边的结果一样吗?答案是否定的,看下输出结果:
Exception in thread "main" java.lang.RuntimeException: org.apache.ibatis.exceptions.PersistenceException: mybatis插入异常
org.apache.ibatis.exceptions.PersistenceException: mybatis插入异常
at org.dubbo.provider.PersonServiceImpl.getByNick(PersonServiceImpl.java:32)
at com.alibaba.dubbo.common.bytecode.Wrapper1.invokeMethod(Wrapper1.java)
不要感觉奇怪,这个也是在可以接受的范围内,因为PersistenceException异常类在客户端是不存在的,所以不可能接收到PersistenceException异常,dubbo把他进行了封装。
针对这点,在接口包中里面定义了一个全局的异常类,注意一定是接口所在的工程中,如:UicException(用户模块异常),这种方案也是官方建议的,服务端代码如下:
@Override
public Person getByNick(String name) {
if (name == null) {
// 自定义异常
throw new UicException("mybatis插入异常", 0);
}
name = name.trim();
Person person = new Person();
person.setId(ID.getAndIncrement());
person.setName(name);
return person;
}
错误信息如下
Exception in thread "main" org.dubbo.api.exception.UicException: mybatis插入异常
at org.dubbo.provider.PersonServiceImpl.getByNick(PersonServiceImpl.java:30)
这个正是我们想要的异常信息,上边特别提到异常一定要在接口所在的工程中,如果异常类不在接口工程中,而是在另一个服务端和客户端都引入的包中呢?我们曾经碰到这样一个情况,有一个common的异常类放在一个很底层的工具包内,接口工程引入了这个包,在服务端抛出的异常都都是这个commonexception,一厢情愿的认为客户端会正常去捕获处理commonexception。
但结果很意外,客户端出现的异常跟上边抛出的PersistenceException情况一样,dubbo用RuntimException进行了包装,我们无法从异常中获取有效的信息!遇到这种情况有点发懵,这个异常类在客户端和服务端都有呀,为啥不能正确接收呢。还好之前看dubbo源码的时候大概记得异常处理的位置,很好找到了目标代码:
if (result.hasException() && GenericService.class != invoker.getInterface()) {
try {
Throwable exception = result.getException();
// 如果是checked异常,直接抛出
if (! (exception instanceof RuntimeException) && (exception instanceof Exception)) {
return result;
}
// 在方法签名上有声明,直接抛出
try {
Method method = invoker.getInterface().getMethod(invocation.getMethodName(), invocation.getParameterTypes());
Class<?>[] exceptionClassses = method.getExceptionTypes();
for (Class<?> exceptionClass : exceptionClassses) {
if (exception.getClass().equals(exceptionClass)) {
return result;
}
}
} catch (NoSuchMethodException e) {
return result;
}
// 未在方法签名上定义的异常,在服务器端打印ERROR日志
logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost()
+ ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()
+ ", exception: " + exception.getClass().getName() + ": " + exception.getMessage(), exception);
// 异常类和接口类在同一jar包里,直接抛出
String serviceFile = ReflectUtils.getCodeBase(invoker.getInterface());
String exceptionFile = ReflectUtils.getCodeBase(exception.getClass());
if (serviceFile == null || exceptionFile == null || serviceFile.equals(exceptionFile)){
return result;
}
// 是JDK自带的异常,直接抛出
String className = exception.getClass().getName();
if (className.startsWith("java.") || className.startsWith("javax.")) {
return result;
}
// 是Dubbo本身的异常,直接抛出
if (exception instanceof RpcException) {
return result;
}
// 否则,包装成RuntimeException抛给客户端
return new RpcResult(new RuntimeException(StringUtils.toString(exception)));
} catch (Throwable e) {
logger.warn("Fail to ExceptionFilter when called by " + RpcContext.getContext().getRemoteHost()
+ ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()
+ ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);
return result;
}
}
看完源码以后,做出了新的设计,CommonException不变,各个接口模块(maven工程为单位)单独定义异常对象继承CommonException,每个模块抛出自己的模块异常(如用户模块抛出UicException),客户端中用CommonException统一捕获处理。
这里还要定义两个拦截器,首先是服务端,保证所有抛出的异常是当前模块的异常,代码如下:
public class UICExceptionAspect {
private static Log log = LogFactory.getLog(UICExceptionAspect.class);
public void afterThrowing(Exception ex) {
if (ex instanceof UICException) {
throw (UICException) ex;
} else if (ex instanceof DayimaException) {
DayimaException de = (DayimaException) ex;
throw new UICException(de.getErrCode(), de.getErrMsg());
} else {
log.error(ex.getMessage(), ex);
throw new UICException("1", ex.getMessage());
}
}
}
其次是客户端的,保证异常可以正确的友好的输出,所有CommonException可以直接输出(获取根据错误码获取错误信息),非CommonException异常根据自己需要去处理,如果是dubbo自带异常肯定要屏蔽异常信息,如打印日志后输出“网络异常”。
还有另一种dubbo调用方案,普通service层外边嵌套一层用来做dubbo的服务,普通service层处理了事务之类,dubbo服务层每一个方法都是客户端要引用的,直接调用普通service层方法,但做了手动的try catch处理,封装自己的返回码,客户端只需要根据返回码去做处理,这种开发成本和文档成本有点高,没太深入去考虑。
以上是我自己工作中的dubbo异常实践,以后会继续写些其他的心得,记录自己的成长。
|
1、图片大小不能超过2M 2、支持格式:.jpg .gif .png .bmp |
id="frm_img_2" name="frm_img_2" src="http://write.blog.csdn.net/article/uploadimg2" frameborder="0" scrolling="no" style="list-style: none; word-break: break-all; word-wrap: break-word; width: 390px; height: 24px; float: left;">中间水印 右下水印 无水印 |