dubbo实践1..异常处理

本文介绍了Dubbo框架下的异常处理机制,包括如何处理传递异常、自定义异常类、异常拦截器设计等内容,并提供了具体的代码示例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 使用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.youkuaiyun.com/article/uploadimg2" frameborder="0" scrolling="no" style="list-style: none; word-break: break-all; word-wrap: break-word; width: 390px; height: 24px; float: left;">中间水印 右下水印 无水印
    <think>我们正在分析SpringBoot应用中使用Dubbo时,ReferenceConfig创建失败并抛出BeanCreationException,具体异常信息为"配置异常:Nosuchextensionactivelimitforfilter"。这通常表示Dubbo在创建引用时找不到名为"activelimit"的filter扩展点。根据Dubbo的扩展机制,filter可以通过SPI(ServiceProviderInterface)方式进行扩展。异常信息表明在ReferenceConfig初始化过程中,尝试加载一个名为"activelimit"的filter,但Dubbo在classpath下没有找到对应的实现类。可能的原因及解决方案:1.**缺少Dubbo扩展依赖**:-检查项目中是否引入了包含"activelimit"filter的依赖。在Dubbo中,很多扩展点(包括filter)都包含在单独的jar包中。例如,"activelimit"filter可能属于`dubbo-filter`模块中的某个子模块。常见的做法是引入完整的filter集合依赖:```xml<dependency><groupId>org.apache.dubbo</groupId><artifactId>dubbo-filter</artifactId><version>${dubbo.version}</version></dependency>```-如果使用的是DubboSpringBootStarter,通常也会包含一些默认的filter。但如果是自定义的filter或者特定于某些功能的filter,可能需要单独引入。2.**Dubbo的SPI配置文件缺失或错误**:-Dubbo的扩展点通过SPI配置文件进行声明,配置文件路径为`META-INF/dubbo/org.apache.dubbo.rpc.Filter`。在该配置文件中,需要有一行配置指定扩展名和实现类的映射,例如:```activelimit=org.apache.dubbo.rpc.filter.ActiveLimitFilter```-检查项目中是否存在该文件,并且文件内是否包含"activelimit"的配置项。如果缺失,可以手动添加或检查是否被其他依赖覆盖。3.**版本不匹配**:-使用的Dubbo版本与所依赖的扩展包版本不一致,导致扩展点实现类不存在或者路径发生变化。应确保所有Dubbo相关依赖使用相同的版本。4.**配置错误**:-在Dubbo的配置中(如`application.properties`或`application.yml`)可能错误地配置了filter属性。检查相关配置,例如:```propertiesdubbo.consumer.filter=activelimit,...```或```propertiesdubbo.reference.filter=activelimit,...```检查是否确实需要"activelimit"这个filter,或者是否拼写错误(可能是"activelimit"的拼写错误,实际应为"activelimit",注意大小写敏感)。5.**自定义Filter未正确打包**:-如果"activelimit"filter是自定义实现的,确保该实现类已经正确打包到项目中,并且SPI配置文件也正确放置在`META-INF/dubbo`目录下。6.**检查错误堆栈**:-查看完整的异常堆栈,确定是哪个组件的初始化导致了该问题。可能不仅是filter的问题,还可能是其他配置问题导致的连锁反应。针对上述异常,首先推荐按以下步骤排查:步骤1:检查依赖树,确认是否引入了包含"org.apache.dubbo.rpc.filter.ActiveLimitFilter"类的依赖。可以使用Maven命令:```shellmvndependency:tree```查找是否有相应的依赖。步骤2:检查项目中(包括依赖的jar包)是否存在`META-INF/dubbo/org.apache.dubbo.rpc.Filter`文件,并查看其中是否有`activelimit`的配置。步骤3:如果确认不需要使用"activelimit"filter,则移除配置中对该filter的引用。如果确实需要,则添加相应的依赖。另外,关于Dubbo的filter机制,可以参考官方文档[^1]。如果以上步骤没有解决问题,可以考虑升级Dubbo版本到最新稳定版,或者查看社区是否有类似问题的讨论。总结:该问题通常由依赖缺失或配置错误引起,重点检查依赖和SPI配置文件。相关问题:1.如何调试Dubbo的SPI扩展机制?2.Dubbo的filter执行顺序是怎样的?3.在SpringBoot中如何自定义Dubbo的filter?4.如何避免Dubbo扩展配置被多个jar包覆盖?[^1]:Dubbo官方文档:https://dubbo.apache.org/zh/docs/references/spis/filter/</think> ### Spring Boot Dubbo ReferenceConfig BeanCreationException 分析及解决方案 #### 异常分析:`No such extension activelimit for filter` 该异常通常出现在Dubbo消费者启动时,核心问题是**Dubbo无法找到名为`activelimit`的过滤器(Filter)扩展点**,导致`ReferenceConfig`创建失败。常见原因: 1. **扩展声明缺失**: - Dubbo的SPI机制要求过滤器扩展需在`META-INF/dubbo/org.apache.dubbo.rpc.Filter`文件中声明 - `activelimit=com.xxx.ActiveLimitFilter`格式的注册信息缺失或配置错误[^1] 2. **依赖冲突**: - Dubbo核心库版本与Spring Boot Starter版本不兼容 - 多模块项目中子模块的Dubbo依赖版本不一致 3. **错误配置触发加载**: ```yaml dubbo: consumer: filter: activelimit,otherFilter # 错误引用了不存在的filter ``` --- #### 解决方案 ##### 1. 修正SPI扩展声明 在**资源目录**创建文件: `src/main/resources/META-INF/dubbo/org.apache.dubbo.rpc.Filter` ```properties activelimit=org.apache.dubbo.rpc.filter.ActiveLimitFilter ``` > Dubbo 3.x默认已包含此Filter,若使用2.x需确保引入`dubbo-filter`模块 ##### 2. 处理依赖冲突 检查依赖树: ```xml <!-- 示例:统一Dubbo版本 --> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>3.0.12</version> <!-- 与dubbo-core版本保持一致 --> </dependency> ``` 执行诊断命令: ```bash mvn dependency:tree | grep dubbo ``` ##### 3. 配置排查 - **移除无效filter引用**: ```yaml dubbo: consumer: filter: -activelimit # 排除无效过滤器 ``` - **显式设置默认过滤器**(Dubbo 3.x+): ```java @DubboReference(filter = {"default"}) private DemoService demoService; ``` ##### 4. 异常处理兜底 ```java @Configuration public class DubboConfig { @Bean public ReferenceConfigPostProcessor referenceConfigPostProcessor() { return referenceConfig -> { referenceConfig.setOnreturn((res) -> { if (res.hasException() && res.getException() instanceof IllegalStateException) { // 重置filter配置逻辑 } }); }; } } ``` --- #### 验证流程 1. 检查启动日志: ``` [DUBBO] Loaded extension filter: [activelimit, ...] ``` 2. 调用`ExtensionLoader.getExtensionLoader(Filter.class).getSupportedExtensions()`验证加载结果 > 典型成功日志:`Successfully registered dubbo service URL...` --- #### 相关问题 1. 如何诊断Dubbo SPI扩展加载失败的根本原因? 2. Dubbo 3.x与Spring Boot 3的兼容性配置有哪些注意事项? 3. ReferenceConfig动态配置的最佳实践是什么? 4. Dubbo过滤器链的执行顺序如何控制? [^1]: Dubbo SPI机制文档:https://dubbo.apache.org/zh/docs3-v2/java-sdk/reference-manual/spi/
    评论 2
    添加红包

    请填写红包祝福语或标题

    红包个数最小为10个

    红包金额最低5元

    当前余额3.43前往充值 >
    需支付:10.00
    成就一亿技术人!
    领取后你会自动成为博主和红包主的粉丝 规则
    hope_wisdom
    发出的红包
    实付
    使用余额支付
    点击重新获取
    扫码支付
    钱包余额 0

    抵扣说明:

    1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
    2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

    余额充值