1.背景

dubbo由alibaba开源，2018年又升级为apache顶级项目维护。很多互联网公司选择使用，历史使用最多的版本是2.7.4，后续逐步往3.0+版本升级。过程中踩到不少小坑，接下来与大家一起分享一下。

2.踩过的一些坑

问题描述	解决方案	相关解释
Too many DubboClientHandler threads in consumer-消费者中建立了太多DubboClientHandler 线程	github.com/apache/dubb… dubbo在2.7.5以后版本修复	provider 默认共用同一个线程池，在有些情况下也会根据protocol划分多个线程池，Consumer端是每个链接共享一个线程池，如有consumer到3个provider分别有一个长链接，则每个长链接各自使用独立的线程池。可以查看dubbo的WrappedChannelHandler。
dubbo3.0 不能优雅停机 close client immediately when destroy unused invoke	github.com/apache/dubb… 目前在最新的版本已经升级	dubbo早期设计是基于接口维度的，所以dubbo在运行时维护了一个基于接口维度的计数器，注册一个接口计数器就+1。但是在dubbo2.7.5以后，dubbo的设计中增加了一个MetadataService，类似于Spring的Endpoint。MetadataService也是一个接口维度的service，MetadataService的注册也会使接口计数器+1。在Provider下线的时候，每一个接口都会触发销毁流程，销毁流程中，接口计数器-1。正常情况下，所有接口都销毁后，正常触发Provider在Consumer缓存节点的销毁。但是由于MetadataService没有正常被销毁，计数器永远>=1，从而导致Consumer中缓存的Provider节点没有被正常close掉。
dubbo3.0 服务端超时DecodeableRpcResult.decode(Channel channel, InputStream input)抛NPE异常	github.com/apache/dubb… 升级到3.4
dubbo one way 配置	@Reference(methods = {@Method(name = "sendMessage", isReturn = false)})	项目中不需要等对方回应，只需要发送给对方处理即可.性能很高

3.总结

dubbo是一个万金油，使用好它。还是需要多去关注官方的issues,建议先使用2.7.4+版本的dubbo。 3.0+版本有坑，慎用。