面试官问：使用Dubbo有没有遇到一些坑？我笑了

根据我的面试经验而言,能在简历上写上 原理 、 源码 等关键词的,是非常具备核心竞争力的.上周和一个公众号粉丝交流面试情况如下

面试的时候,把源码一波分析,令面试官 虎躯一震 !在一阵前戏过后,以为接下来无非就是身体的一顿抽搐一切变得索然无味,不料面试官来了句令剧情发生了反转

“你对Dubbo源码这么熟悉,那请问你使用的时候,有没有遇到什么坑”

我擦,毫无准备的他, 菊花顿时一紧! 此时就面临 唬住了50K,唬不住就只能15K 的局面，我开始慌了!

论如何反杀

相信大家面试都遇到过类似问题,因为源码解析网上很多,很多人”考前突击”一下,但是遇到喜欢问细节的面试官,终究难逃法眼,无处遁形.遇到这个问题,我们如何反杀一波?那么我就从一次聊天记录说起,拥有 真实 场景的源码实战( 非常重要 ),遇到这类问题,才不至于出现 猛虎落泪 的情形：

真实场景描述

那么我们把业务相关去掉,抽取一个最简模型.我们在公司,一般都会有自己的自定义异常,然后这个自定义异常一般放在 common.jar 给其他模块依赖,比如我这里定义一个 HelloException

 1public class HelloException extends RuntimeException {
 2
 3    public HelloException() {
 4    }
 5
 6    public HelloException(String message) {
 7        super(message);
 8    }
 9
10}

然后我们写一个最简单的Dubbo的demo,如下

interface：

1public interface DemoService {
2
3    String sayHello(String name);
4
5}

provider：

1public class DemoServiceImpl implements DemoService {
2
3    public String sayHello(String name) {
4        throw new HelloException("公众号:肥朝");
5    }
6
7}

consumer：

 1public class DemoAction {
 2
 3    private DemoService demoService;
 4
 5    public void setDemoService(DemoService demoService) {
 6        this.demoService = demoService;
 7    }
 8
 9    public void start() throws Exception {
10        try {
11            String hello = demoService.sayHello("公众号:肥朝");
12        } catch (HelloException helloException) {
13            System.out.println("这里捕获helloException异常");
14        }
15    }
16
17}

按照聊天记录的描述，此时consumer调用provider，provider抛出 HelloException .但是consumer捕获到的，却不是 HelloException .

那么我们运行看看：

果然如该同事所言.为什么会这样呢?不要慌， 九浅一深直入源码。出现异常我们首先看一下异常栈：

除非撸多了看不清，否则这行异常能很直接的定位到问题所在：

1com.alibaba.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:108)

接下来让我们一探究竟：

 1    public Result invoke(Invoker invoker, Invocation invocation) throws RpcException {
 2        try {
 3            Result result = invoker.invoke(invocation);
 4            if (result.hasException() && GenericService.class != invoker.getInterface()) {
 5                try {
 6                    Throwable exception = result.getException();
 7
 8                    // 如果是checked异常，直接抛出
 9                    if (! (exception instanceof RuntimeException) && (exception instanceof Exception)) {
10                        return result;
11                    }
12                    // 在方法签名上有声明，直接抛出
13                    try {
14                        Method method = invoker.getInterface().getMethod(invocation.getMethodName(), invocation.getParameterTypes());
15                        Class[] exceptionClassses = method.getExceptionTypes();
16                        for (Class exceptionClass : exceptionClassses) {
17                            if (exception.getClass().equals(exceptionClass)) {
18                                return result;
19                            }
20                        }
21                    } catch (NoSuchMethodException e) {
22                        return result;
23                    }
24
25                    // 未在方法签名上定义的异常，在服务器端打印ERROR日志
26                    logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost()
27                            + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()
28                            + ", exception: " + exception.getClass().getName() + ": " + exception.getMessage(), exception);
29
30                    // 异常类和接口类在同一jar包里，直接抛出
31                    String serviceFile = ReflectUtils.getCodeBase(invoker.getInterface());
32                    String exceptionFile = ReflectUtils.getCodeBase(exception.getClass());
33                    if (serviceFile == null || exceptionFile == null || serviceFile.equals(exceptionFile)){
34                        return result;
35                    }
36                    // 是JDK自带的异常，直接抛出
37                    String className = exception.getClass().getName();
38                    if (className.startsWith("java.") || className.startsWith("javax.")) {
39                        return result;
40                    }
41                    // 是Dubbo本身的异常，直接抛出
42                    if (exception instanceof RpcException) {
43                        return result;
44                    }
45
46                    // 否则，包装成RuntimeException抛给客户端
47                    return new RpcResult(new RuntimeException(StringUtils.toString(exception)));
48                } catch (Throwable e) {
49                    logger.warn("Fail to ExceptionFilter when called by " + RpcContext.getContext().getRemoteHost()
50                            + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()
51                            + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);
52                    return result;
53                }
54            }
55            return result;
56        } catch (RuntimeException e) {
57            logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost()
58                    + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()
59                    + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);
60            throw e;
61        }
62    }

手机上阅读源码或许并不友好,但是没关系,上面都有完善的中文注释,他想表达的意思如下:

1.如果是checked异常，直接抛出。很明显，我们的 HelloException 是 RuntimeException ,不符合；

2.在方法签名上有声明，直接抛出。很明显,我们接口并未声明该异常,不符合；

3.异常类和接口类在同一jar包里，直接抛出。很明显，我们的异常类是在common.jar的,接口是在api.jar的，不符合；

4.是JDK自带的异常，直接抛出。很明显,这个 HelloException 是我们自定义的，不符合；

5.是Dubbo本身的异常(RpcException)，直接抛出。很明显,这个 HelloException 是我们自定义的，和 RpcException 几乎没有半毛钱关系，不符合；

6.否则，包装成RuntimeException抛给客户端.因为以上5点均不满足,所以该异常会被包装成 RuntimeException 异常抛出( 重要 )；

这也就是为什么我们catch HelloException 是catch不到的,因为他包装成 RuntimeException 了

Dubbo为什么这么设计

也许你看到这里会觉得这个判断好坑.Dubbo为什么要这么设计?我们看源码, 最重要的是知道作者为什么这么设计 ,只有知道 为什么这么设计 才是经过了深度的思考,否则看时高潮,看后就忘。

其实Dubbo的这个考虑，是基于序列化来考虑的。你想想,如果provider抛出一个仅在provider自定义的一个异常,那么该异常到达consumer,明显是无法序列化的。所以你注意看Dubbo的判断.我们来看下他的判断：

1.checked异常和RuntimeException是不同类型,强行包装可能会出现类型转换错误,因此不包,直接抛出

2.方法签名上有声明.方法签名上有声明,如果这个异常是provider.jar中定义的,因为consumer是依赖api.jar的,而不是依赖provider.jar.那么编译都编译不过,如果能编译得过,说明consumer是能依赖到这个异常的,因此序列化不会有问题,直接抛出

3.异常类和接口类在同一jar包里.provider和consumer都依赖api,如果异常在这个api,那序列化也不会有问题,直接抛出

4.是JDK自带的异常，直接抛出.provider和consumer都依赖jdk,序列化也不会有问题,直接抛出

5.是Dubbo本身的异常(RpcException)，直接抛出.provider和consumer都依赖Dubbo,序列化也不会有问题,直接抛出

6.否则，包装成RuntimeException抛给客户端.此时,就有可能出现我说的那种,这个异常是provider.jar自定义的,那么provider抛出的时候进行序列化,因为consumer没有依赖provider.jar,所以异常到达consumer时,根本无法反序列化.但是包装成了 RuntimeException 异常则不同,此时异常就是JDK中的类了,到哪都能序列化.

如何解决

既然都知道了原理了,那么问题就很好解决了。比如从规范上要求业务方接口声明 HelloException。