dubbo-2

对端处理接收到的数据：
1 Processor线程处理读事件，head-tail，先decoder这个ChannelHandler，Codec2解码（如多个Request解码成MultiMessage对象）
2 走到NettyHandler（在NettyServer内生成的和在NettyClient内的基本是一致，细微差别），在MultiMessageHandler处判断
若为MultiMessage则对象分解开交由下层handler
3 HeartbeatHandler判断为心跳请求给与应答，为心跳响应不处理，其它交由下层handler
4 Dispatcher生成的Handler：处理移交到其他线程了（线程池），direct不移交，all全部移交，message只对接收到数据事件进行移交，内部线程池由ThreadPool 生成（根据URL参数），客户端一个连接一个ChannelHandler一个线程池（默认使用的是cached），服务端accept的连接的ChannelHandler是同一个，每个连接有自己的pipeline，但是最终引用了相同的ChannelHandler（使用fixed线程池）
5 DecodeHandler：接收到的Request或Response内数据实现了Decodeable，或接收到一个Decodeable，调用其decode方法
6 HeaderExchangeHandler：接收到Request，调用下层处理，封装Response并发送给对端（twoWay），接收到Response，
根据ID找到future，设置future内的应答，唤醒等待线程（若有），调用callback（若有），移除相应数据，接收到String，调用下层telnet方法，结果发给对端
7 底层Handler：找到Protocol内的Exporter（根据serviceKey：如dubbo.DemoService:8010），调用Exporter内的Invoker的invoke方法，考虑stubService（传来的dubbo.stub.event为true）和callbackService（非stub且自己是客户端）

服务暴露：可能向多个注册中心注册和多个协议下暴露（一个协议暴露需一个port），如2注册中心2协议，那么ServiceConfig应该有4个Exporter
同时Protocol内部维护了serviceKey-Exporter的映射，方便服务端找到Exporter进行调用
举例：某服务在A协议维护了1个底层Exporter，在B协议维护了1个底层Exporter，2注册中心情况下，ServiceConfig应该有4个Exporter(DestroyableExporter，通过RegistryProtocol获得，封装了底层Exporter)
创建服务端的Invoker（通过ProxyFactory），通过protocol的export方法创建Exporter（封装Invoker）
本地暴露(injvm protocol 本地refer本地export的服务)，这种没有端口

RegistryFactory根据URL找到（没有创建） Registry（RegistryService），可向Registry进行register和unregister和subscribe和unsubscribe操作，提供者需注册自己，提供者需订阅override数据，消费者需注册自己，消费者需订阅providers，routers，configurators信息，订阅需要传入NotifyListener作为接收到订阅消息后的callback，RegistryDirectory本身就是NotifyListener

像loadbalance这样的参数客户端和服务端都可以配置，客户端获取到服务端配置（NotifyListener），ClusterUtils.mergeUrl方法合并客户端和服务端配置，放在InvokerDelegate内（providerUrl代表服务端原始配置，url代表合并后配置）

客户端没有接口可以泛化调用，服务端没有接口可以泛化实现

隐式传参：RpcContext的attachments放参数，封装进RpcInvocation传递过去（AbstractInvoker内），对端取出attachments放到自己的RpcContext内（ContextFilter内）

服务默认本地暴露（除非scope为none或remote），引用服务默认优先引用本地服务(只要InjvmProtocol含此服务的Exporter)

callback：服务端调用客户端（类似客户端暴露服务了）
stub
accepts：控制服务端每个如NettyServer能接收的连接上限，AbstractServer.connected方法判断新加此连接后总连接是否超过accepts，超过关闭此新连接
路由：客户端订阅了category为routers的内容，当注册中心配置了路由规则后，客户端接收到相应URL,通过RouterFactory创建Router，如将rule参数解析为ConditionRouter内的规则，常见的条件路由通过=>分隔consumer和provider的匹配条件，还有脚本，标签路由
容器：我们自己启动应用就自己写个类启动ApplicationContext并保证主线程阻塞，其实还可以通过dubbo的Main类启动，传入参数表明需要启动的容器（默认spring容器，加载classpath*:META-INF/spring/*.xml的配置），还可以传入log4j等
ReferenceConfigCache 用于缓存ReferenceConfig，避免在API编程时重复创建ReferenceConfig
ThreadPool生成的线程池自定义了AbortPolicyWithReport，拒绝任务时会通过jstack导出线程堆栈
DubboProtocol的optimizeSerialization方法可以看到：optimizer参数指定了SerializationOptimizer的类名，SerializationOptimizer含很多可序列化类，这些类可以注册进SerializableClassRegistry，用dubbo协议并使用Kryo, FST进行序列化时，会加入SerializableClassRegistry所含类以优化序列化性能