Dubbo应用与异常记录

结合项目里使用暴露出的问题，对并发较多的核心业务或者对请求失败等敏感的业务场景不太建议使用Dubbo，

如电商的购买等行为，使用Dubbo就必须阅读源码，熟悉相关机制，或者直接自己造轮子。

1.使用Dubbo踩过的坑

（1）Spring Cache在Service层对消费者不起作用
原因是：Spring容器还未加载完，就在Dubbo中暴露服务导致Cache的AOP不可用。因此需要将服务放在Spring容器加载完后再暴露。

（2）Dubbo对方法重载支持有问题

如果让hessian支持调用重载方法需要isOverloadEnabled()设为false。

2.Dubbo常见异常和错误

（1）调用超时com.alibaba.dubbo.remoting.TimeoutException异常
通常是业务处理太慢，可在服务提供方执行：jstack PID > jstack.log 分析线程都卡在哪个方法调用上，这里就是慢的原因。
如果不能调优性能，请将timeout设大。

（2）出现java.util.concurrent.RejectedExecutionException或者Thread pool exhausted

RejectedExecutionException表示线程池已经达到最大值，并且没有空闲连，拒绝执行了一些任务。
Thread pool exhausted通常是min和max不一样大时，表示当前已创建的连接用完，进行了一次扩充，创建了新线程，但不影响运行。
原因可能是连接池不够用，请调整dubbo.properites中的：

3.dubbo如何正确关闭Spring容器

Dubbo是通过JDK的ShutdownHook来完成优雅停机的，所以如果用户使用"kill -9 PID"等强制关闭指令，是不会执行优雅停机的，只有通过"kill PID"时，才会执行。
服务提供方停止时，先标记为不接收新请求，新请求过来时直接报错，让客户端重试其它机器。
然后，检测线程池中的线程是否正在运行，如果有，等待所有线程执行完成，除非超时，则强制关闭。
服务消费方停止时，不再发起新的调用请求，所有新的调用在客户端即报错。
然后，检测有没有请求的响应还没有返回，等待响应返回，除非超时，则强制关闭。
设置优雅停机超时时间，缺省超时时间是10秒：(超时则强制关闭)

看一下源码实现：