1.dubbo整体架构图2.线程模型官网地址：https://dubbo.apache.org/zh/d...3.本地dubbo测试记录（1))踩坑在使用SpringBoot搭建dubbo服务时，我们不仅使用注解配置，还忘记关闭xml文件配置，导致应用无法启动。(2)在consumer端配置dubbo.consumer.timeout=3000，控制consumer等待服务端返回消息的最长时间，默认1秒；【默认配置下，部分服务器有慢速方法，容易导致请求超时报错；】（3）在服务提供者上配置dubbo.protocol.threadpool=cached，配置业务线程池类型；其他线程池类型如下：【如果不配置，线程池默认使用SynchronousQueue队列（eager线程池除外），SynchronousQueue不Capacity是unbuffered等待队列，不存储元素的阻塞队列，会直接把任务交给消费者。必须等待队列中添加的元素被消耗完才能继续添加新元素]fixed固定大小线程池，start线程随时创建，不关闭，一直持有；(默认)缓存缓存线程池，空闲一分钟后自动删除，需要时重建；线程池的可扩展性有限，但池中的线程数只会增加不会减少。只增长不收缩的目的是为了避免收缩时突然大流量带来的性能问题；eager优先级被赋予创建一个Worker线程池。当任务数大于corePoolSize但小于maximumPoolSize时，首先创建worker来处理任务。当任务数大于maximumPoolSize时，将任务放入阻塞队列。当阻塞队列已满时抛出RejectedExecutionException。（相对于cached，cached在任务数超过maximumPoolSize时直接抛出异常，而不是将任务放入阻塞队列）。dubbo.protocol.threads=10，限制业务线程池最大线程数；等于并发访问量，超过线程数的请求直接触发拒绝策略；（默认固定线程池最大200个线程）dubbo.protocol.dispatcher=message，配置dispatcher调度方式；【一般情况下建议配置调度方式为消息】，其他调度方式如下：所有的消息都派发到线程池，包括请求、响应、连接事件、断开事件、心跳等；direct所有的消息都不分发到线程池，全部直接在IO线程上执行；message只有请求响应消息被派发到线程池，其他连接断开事件、心跳等消息直接在IO线程上执行；execution只有request消息被派发到线程池，不包括response、response等连接断开事件、heartbeat等消息，直接在IO线程上执行；IO线程上的connection，将连接断开事件放入队列中，有序的一个一个执行，其他消息派发到线程池中。dubbo.provider.actives=10，每个服务消费者，一个方法的最大并发调用数；从消费者端控制，并发数是业务线程池大小的子集。dubbo.provider.executes=10，每个服务提供者的每个方法可以并行执行的最大请求数；从提供者控制，并发数是业务线程池大小的子集（小于或等于业务线程池大小）。4.自动堆栈转储?当业务线程池已满时，我们需要知道线程在等待哪些资源和条件，以便发现系统的瓶颈或异常点。Dubbo通过Jstack自动导出线程栈，保持现场，方便排错。默认策略：导出路径，user.home标识的用户主目录的导出间隔，最短允许10分钟导出一次指定导出路径：配置dubbo.properties文件，修改dubbo.application.dump。目录=/tmp
