23.IO线程与业务线程的合与分，以及提供的策略选择实现分析io线程与业务线程合在一个线程上，还是把业务线程拆成单独的线程(线程池)去处理，一般来讲，取决于业务线程是否比较耗时。 如果业务线程比较耗时，就可以拆成单独的线程池处理，这样可以提升io吞吐。 如果业务线程不怎么耗时，处理非常快，那么就可以不拆成单独线程，因为这样可以降低上下文切换cs带来的开销。 这种方式在多个中间件都会有涉

22.业务侧共享线程池还是隔离线程池区别与实现分析接下来两篇文章要讨论下线程隔离的问题，有两个维度： 一个节点上多个provider之间的隔离。即下图的4 5 6线程是否要隔离在不同的线程池。 一个节点上io线程与server handler线程的隔离。即下图的1与4(或者2和5，3和6)是否在同一个线程上执行。 I/O

21.服务分组实现分析服务分组的test case我们假设的场景是，多idc机房，一个zk注册中心，我们通过分组设置达到，本机房的consumer调用本机房的provider。为了分析，我们假设了两个idc机房idc001和idc002 provider端的节点1服务配置上加上group： <dubbo:service interface="com.code260.ss.dubbo.de

20.反射调用是如何优化的？Wrapper的作用是什么？反编译生成的代码对于动态代码生成的class可以写出到本地，办法是： 在com.alibaba.dubbo.common.bytecode.ClassGenerator.mCtc这个实例有 javassist.CtClass.writeFile(String)方法，可以在com.alibaba.dubbo.common.bytecode.

19.被consumer端调用时的线程模型与链路provider侧 线程模型 +-----------------+ +-----------------+ +-----------------+ +------> boss/ +-------->+ worker/ +-------

18.重试、provider下线、网络断开等容错怎么实现case构造的方式可以在DubboInvoker.doInvoke打断点，然后让provider下线，然后再继续执行刚才断点停住的地方等等构造异常场景。 如果有provider服务停掉， consumer端如何感知？再次启动刚停掉的provider呢provider停掉会触发zk客户端的监听，监听对客户端的invoker列表进行刷新。再次

17.负载均衡如何实现分析负载均衡的test case起两个provider，前面文章中有现成的provider，起来就好。 用HelloClientTest testSayHello调用几次，观察落在哪个provider上。 分析负载均衡对于客户端调用过程中的逻辑，比如上篇的路由，这一篇的负载均衡等等机制，都可以通过观察调用前的调用栈来分析发现。 在 com.alibaba.dubb

16.路由如何实现com.alibaba.dubbo.rpc.cluster.directory.AbstractDirectory.list(Invocation) 中织入了路由的逻辑； 使用路由的test casepackage com.code260.ss.dubbo.demov.client.routeruler; import org.junit.BeforeClass; import

15.多个provider如何在客户端体现，即集群如何实现多provider的test case为了分析多个provider，我们在demo中再加一个node，代码如下： package com.code260.ss.dubbo.demov.server.registercenter.zookeeper; import java.io.IOException; import org.junit

14.consumer端调用链示意图 +----------------------+ +----------------+ +---------------------------+ | helloService | | proxy | | InvokerInvocationHandler | | sayHello