dubbo 2.7配置最佳实践（持续更新中）

sunny8zhou

于 2024-07-29 17:05:40 发布

阅读量623

点赞数 13

分类专栏：研发规范文章标签： dubbo java

本文链接：https://blog.csdn.net/sunny8zhou/article/details/140674902

版权

研发规范专栏收录该内容

4 篇文章 0 订阅

订阅专栏

背景

由于部分dubbo配置影响内存占用计算，加上其默认配置有些不合理，这里持续更新我们在日常项目中的最佳实践，以供大家参考

参考资料

dubbo官方推荐用法：https://cn.dubbo.apache.org/zh-cn/docsv2.7/user/recommend/

dubbo线程模型：https://cn.dubbo.apache.org/zh-cn/docsv2.7/user/examples/thread-model/

通用配置

线程模型配置

派发策略

dubbo.protocol.dispatcher

all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
execution 只有请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

建议配置：dubbo.protocol.dispatcher = message

好处：

高性能：消息模式的消息分发器通常比连接模式的消息分发器具有更好的性能，特别是在高并发场景下。
低延迟：消息模式可以减少消息传递的延迟，提高系统的响应速度。
异步处理：消息模式的消息分发器通常支持异步处理，可以更好地利用系统资源，提高系统吞吐量。

坏处：

复杂性：消息模式的消息分发器通常比连接模式的消息分发器更复杂，需要更多的配置和调优。
可靠性：消息模式可能会引入一些消息丢失或消息重复的风险，需要额外的处理和保障机制。
调试困难：由于消息模式的复杂性，可能会增加系统的调试难度，定位问题可能会更加困难。

线程池配置

dubbo.protocol.threadpool

fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
cached 缓存线程池，空闲一分钟自动删除，需要时重建。
limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
eager 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)

建议配置

● dubbo.protocol.corethreads = 2 * CPU核数 + 1
● dubbo.protocol.threads = 500
● dubbo.protocol.threadpool = cached

好处：

动态调整线程池大小：使用缓存线程池可以根据系统的负载情况动态调整线程池的大小，以适应不同的请求量。
节省资源：缓存线程池会根据需要动态创建新线程或重用空闲线程，避免了固定线程池可能存在的资源浪费问题。
提高性能：缓存线程池能够更快地响应突发的请求，提高系统的性能和响应速度。

坏处：

线程创建和销毁开销：频繁创建和销毁线程可能会带来一定的性能开销，尤其在高并发场景下。
可能存在线程饥饿：由于线程池是动态调整的，可能会导致某些任务长时间等待线程执行，造成线程饥饿现象。
需要谨慎调优：使用缓存线程池需要谨慎调优，避免出现线程爆炸、资源耗尽等问题

端口配置

dubbo.protocol.port = 20500

指定端口，可用于健康检查

注册名称

dubbo.registry.simplified = true

防止因注册名过长导致注册失败

provider配置

在 Provider 端尽量多配置 Consumer 端属性

作服务的提供方，比服务消费方更清楚服务的性能参数，如调用的超时时间、合理的重试次数等
在 Provider 端配置后，Consumer 端不配置则会使用 Provider 端的配置，即 Provider 端的配置可以作为 Consumer 的缺省值。否则，Consumer 会使用 Consumer 端的全局设置，这对于 Provider 是不可控的，并且往往是不合理的

Provider 端尽量多配置 Consumer 端的属性，让 Provider 的实现者一开始就思考 Provider 端的服务特点和服务质量等问题。

建议在 Provider 端配置的 Consumer 端属性有：

timeout：方法调用的超时时间
retries：失败重试次数，缺省是 2 [2]
loadbalance：负载均衡算法 [3]，缺省是随机 random。还可以配置轮询 roundrobin、最不活跃优先 [4] leastactive 和一致性哈希 consistenthash 等
actives：消费者端的最大并发调用限制，即当 Consumer 对一个服务的并发调用到上限后，新调用会阻塞直到超时，在方法上配置 dubbo:method 则针对该方法进行并发限制，在接口上配置 dubbo:service，则针对该服务进行并发限制

建议配置：