对 2.7.5 版本之前的 Dubbo 应用,尤其是一些消费端应用,当面临需要消费大量服务且并发数比较大的大流量场景时(典型如网关类场景),经常会出现消费端线程数分配过多的问题,具体问题讨论可参见 Need a limited Threadpool in consumer side #2013
改进后的消费端线程池模型,通过复用业务端被阻塞的线程,很好的解决了这个问题。
老的线程池模型
我们重点关注 Consumer 部分:
当前线程池模型
这样,相比于老的线程池模型,由业务线程自己负责监测并解析返回结果,免去了额外的消费端线程池开销。
Dubbo协议的和Triple协议目前的线程模型还并没有对齐,下面分开介绍Triple协议和Dubbo协议的线程模型。
介绍Dubbo协议的Provider端线程模型之前,先介绍Dubbo对channel上的操作抽象成了五种行为:
Dubbo框架的线程模型与以上这五种行为息息相关,Dubbo协议Provider线程模型可以分为五类,也就是AllDispatcher、DirectDispatcher、MessageOnlyDispatcher、ExecutionDispatcher、ConnectionOrderedDispatcher。
线程模型 | 配置值 |
---|---|
All Dispatcher | all |
Direct Dispatcher | direct |
Execution Dispatcher | execution |
Message Only Dispatcher | message |
Connection Ordered Dispatcher | connection |
拿 application.yaml 的配置方式举例:在protocol下配置dispatcher: all,即可把dubbo协议的线程模型调整为All Dispatcher
下图是All Dispatcher的线程模型说明图:
下图是Direct Dispatcher的线程模型说明图:
下图是Execution Dispatcher的线程模型说明图:
在Provider端,Message Only Dispatcher和Execution Dispatcher的线程模型是一致的,所以下图和Execution Dispatcher的图一致,区别在Consumer端。见下方Consumer端的线程模型。
下图是Message Only Dispatcher的线程模型说明图:
下图是Connection Ordered Dispatcher的线程模型说明图:
下图为Triple协议 Provider端的线程模型
Triple协议Provider线程模型目前还比较简单,目前序列化和反序列化操作都在Dubbo线程上工作,而IO线程并没有承载这些工作。
一种新的线程池管理方式,使得提供者应用内各个服务的线程池隔离开来,互相独立,某个服务的线程池资源耗尽不会影响其他正常服务。支持线程池可配置化,由用户手动指定。
使用线程池隔离来确保 Dubbo 用于调用远程方法的线程与微服务用于执行其任务的线程是分开的。可以通过防止线程阻塞或相互竞争来帮助提高系统的性能和稳定性。
目前可以以 API、XML、Annotation 的方式进行配置
配置参数
ApplicationConfig
新增 String executor-management-mode
参数,配置值为 default
和 isolation
,默认为 default
。executor-management-mode = default
使用原有 以协议端口为粒度、服务间共享 的线程池管理方式executor-management-mode = isolation
使用新增的 以服务三元组为粒度、服务间隔离 的线程池管理方式ServiceConfig
新增 Executor executor
参数,用以服务间隔离的线程池,可以由用户配置化、提供自己想要的线程池,若没有指定,则会根据协议配置(ProtocolConfig
)信息构建默认的线程池用以服务隔离。
ServiceConfig
新增Executor executor
配置参数只有指定executor-management-mode = isolation
才生效。
dubbo 通过 Jstack 自动导出线程堆栈来保留现场,方便排查问题。
默认策略
当业务线程池满时,我们需要知道线程都在等待哪些资源、条件,以找到系统的瓶颈点或异常点。