Dubbo的正确打开方式之基本接口定义及异常处理

为什么要写这篇文章呢？因为公司在使用Dubbo时并没有对Dubbo的用法做深入的了解，而是属于拿来就用，随着自己的想法来使用。这样很不好，就像天龙八部的鸠摩智练习错误的六脉神剑一样，方式不对，就容易走火入魔。下面是我近来在空闲时间对Dubbo的一些学习，也纠正了之前的一些错误用法，在此做一下记录：

接口定义及异常处理

原来错误的做法

先说说最初使用时的做法：
由于Provider和Consumer实际上就是一个服务端和一个客户端的关系。在实际应用当中，和APP直接交互的tomcat服务器就是客户端。那么在我们最初对Dubbo不了解的情况下，就照着APP接口的设计依样画葫芦，定义了一个ResponseDTO：

public class ResponseDTO<t> implements Serializable {     /**     *      */    private static final long serialVersionUID = 4082846602141879024L;     private boolean status = true;     private String msg;     private Exception exception;     private T data;}

然后在Dubbo中提供接口时，会使用try...catch的方式，将异常信息塞到ResponseDTO中去。这样一来有几点坏处：

增加了代码的重复度和复杂度 可能会造成某些Exception在客户端无法被反序列化 无法通过Dubbo提供的拦截器来处理异常

那么，其实我们应该怎么做呢？

直接就像定义普通方法那样定义接口就好了，无需关心异常情况。因为Dubbo已经默认提供了ExceptionFilter来帮助我们处理异常，这个Filter具体是用来干什么的呢？下面贴出核心代码，非常容易理解：

// 如果是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)));

还记得刚才我们提出自己定义ResponseDTO的三个弊端吗？这里我们再列一下：

增加了代码的重复度和复杂度 可能会造成某些Exception在客户端无法被反序列化 无法通过Dubbo提供的拦截器来处理异常

那么再看看Dubbo是如何通过ExceptionFilter来解决的：

在Dubbo中提供接口时，我们无需每个方法都用try...catch包裹，然后组装ResponseDTO对象。而在客户端，也可以直接像调用本地方法一样调用Dubbo的方法，无需再处理ResponseDTO对象 仔细看上面的核心代码，在解决的一个最核心的问题就是担心客户端无法反序列化，所以也就有了最后一行，将无法反序列化的Exception包装成RuntimeException 我们可以通过自己写Filter来处理异常。最典型的，可能有的公司要求监控error日志，那么并不需要打error日志的异常我们可以通过重写Filter来实现。

所以对于接口定义和异常处理来说，正确的打开方式就是：

像定义普通方法一样定义接口，客户端直接调用即可 利用好Filter来处理异常信息