Dubbo是阿里巴巴公司开源的一个高性能优秀的 服务框架,使得应用可通过高性能的 RPC 实现服务的输 出和输入功能,可以和 Spring框架无缝集成,现在在很多Rpc项目中作为同步请求用到,现在当当网维护出Dubbox添加了一些新技能,大家可以了解一波。
Dubbo提供的注册中心有如下几种类型可供选择:
- Multicast注册中心
- Zookeeper注册中心(常用)
- Redis注册中心
- Simple注册中心
优点:
透明化的远程方法调用
- 像调用本地方法一样调用远程方法;只需简单配置,没有任何API侵入。
软负载均衡及容错机制
可在内网替代nginx lvs等硬件负载均衡器。
服务注册中心自动注册 & 配置管理
-不需要写死服务提供者地址,注册中心基于接口名自动查询提供者ip。
使用类似zookeeper等分布式协调服务作为服务注册中心,可以将绝大部分项目配置移入zookeeper集群。
服务接口监控与治理
-Dubbo-admin与Dubbo-monitor提供了完善的服务接口管理与监控功能,针对不同应用的不同接口,可以进行 多版本,多协议,多注册中心管理。
缺点:
只支持JAVA语言
今天主要是说一说使用dubbo处理异常的坑,自定义异常总是不捕获,直接上代码
上面是我的项目结构
common-exception异常处理包
dubbo-consumer消费包
dubbo-interface暴露接口包
dubbo-provider接口提供方
此时consumer调用provider,provider抛出HelloException
.但是consumer捕获到的,却不是HelloException而是RuntimeException
,怎么回事呢??
话不多说,源码走起:
我们看到控制台这个报错点击进去看一下,看看里面做了些啥
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的这个考虑,是基于序列化来考虑的.你想想,如果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