[肥朝]面试官问我，使用Dubbo有没有遇到一些坑？我笑了。

前言

17年的时候,由于一时冲动没把持住(固然最近也有粉丝叫我再冲动一把再更新一波),结合面试题写了一个系列的Dubbo源码解析.目前公众号大部分粉丝都是以前的粉丝,这里不过多介绍.

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

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

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

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

论如何反杀

相信你们面试都遇到过相似问题,由于源码解析网上不少,不少人"考前突击"一下,可是遇到喜欢问细节的面试官,终究难逃法眼,无处遁形.遇到这个问题,咱们如何反杀一波?那么我就从一次聊天记录提及,毕竟只有关注肥朝公众号,拥有 真实场景的源码实战(很是重要),遇到这类问题,才不至于出现猛虎落泪的情形

真实场景描述

那么咱们把业务相关去掉,抽取一个最简模型.咱们在公司,通常都会有本身的自定义异常,而后这个自定义异常通常放在common.jar给其余模块依赖,好比我这里定义一个HelloException

public class HelloException extends RuntimeException {

    public HelloException() {
    }

    public HelloException(String message) {
        super(message);
    }

}
复制代码

而后咱们写一个最简单的Dubbo的demo,以下

interface

public interface DemoService {

    String sayHello(String name);

}
复制代码

provider

public class DemoServiceImpl implements DemoService {

    public String sayHello(String name) {
        throw new HelloException("公众号:肥朝");
    }

}
复制代码

consumer

public class DemoAction {

    private DemoService demoService;

    public void setDemoService(DemoService demoService) {
        this.demoService = demoService;
    }

    public void start() throws Exception {
        try {
            String hello = demoService.sayHello("公众号:肥朝");
        } catch (HelloException helloException) {
            System.out.println("这里捕获helloException异常");
        }
    }

}
复制代码

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

那么咱们运行看看

果真如该同事所言.为何会这样呢?以前没看过肥朝Dubbo源码解析系列的同窗这种时候每每采用最低效的解决办法,把异常栈往微信群一丢,各类求助.可是每每毫无收获,而后感叹社会为什么如此冷漠!

可是相信公众号的老粉丝们早已掌握阅读源码的技能,和肥朝同样坐怀不乱,九浅一深直入源码.出现异常咱们首先看一下异常栈

除非撸多了看不清(建议戒撸),不然这行异常和肥朝同样,就像漆黑中的萤火虫同样,那么鲜明,那么出众

com.alibaba.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:108)
复制代码

那么咱们一探究竟

public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        try {
            Result result = invoker.invoke(invocation);
            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;
                }
            }
            return result;
        } catch (RuntimeException e) {
            logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost()
                    + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()
                    + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);
            throw e;
        }
    }
复制代码

手机上阅读源码或许并不友好,可是不要紧,上面都有完善的中文注释,他想表达的意思以下:

1.若是是checked异常，直接抛出.很明显,咱们的HelloException是RuntimeException,不符合

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

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

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

5.是Dubbo自己的异常(RpcException)，直接抛出.很明显,这个HelloException是咱们自定义的,和RpcException几乎没有半毛钱关系.

6.不然，包装成RuntimeException抛给客户端.由于以上5点均不知足,因此该异常会被包装成RuntimeException异常抛出(重要)

这也就是为何咱们catchHelloException是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

写在最后

固然肥朝面试的时候,也曾经被问过相似问题,你用XXX有没有遇到过什么坑.在一波操做猛如虎的分析下,面试官说

"你真帅".

肥朝会心一笑

结果他却说

"你笑起来更帅"!

---

肥朝 是一个专一于 原理、源码、开发技巧的技术公众号，号内原创专题式源码解析、真实场景源码原理实战（重点）。扫描下面二维码关注肥朝，让本该造火箭的你，再也不拧螺丝！