对于Dubbo的服务提供者，主要有两种线程池，一种是IO处理线程池，另一种是服务调用线程池。由于Dubbo基于Mina、Grizzly和Netty框架做IO组件，IO线程池都是基于这些框架来配置，比如Netty中的boss和worker线程池，Dubbo选择的是“无边界”的CachedThreadPool，这意味着对所有服务请求先做到“来者不拒”，但它进一步限制了IO处理的线程数，默认是核数+1
当请求到达Dubbo的提供者端，请求处理会包含三部分：请求解析、服务调用和应答。
1. 请求解析：确认请求的正确性，比如请求解码（比如协议是否正确）、请求是否合法（提供者端是否有该服务；该服务是否需要token验证来防止绕过注册中心 直连）；
2. 服务调用过程：提供者作为服务端的一个服务处理过程，这个过程需要用到前面说到的第二种服务调用线程池来执行。
该过程通过线程池来和请求解析过程分开，这样做的目的一是过程解耦，二是可以做到服务提供者超时返回，为了让用户能对该过程进行拦截，Dubbo特意通过SPI实现了Filter机制，用户可以通过自定义Filter来对服务调用进行日志记录和监控，当然前提是服务调用线程池还没被请求打满；
3.. 应答过程：对结果进行编码并返回。
IO处理线程池，是用来处理客户端访问请求。
服务调用线程池，服务消费者调用服务提供者时使用。