Dubbo分层
Dubbo框架运行主要分如下九层：
- 配置层：config
- 服务代理层：proxy
- 注册中心层：registry
- 路由层：cluster
- 监控层：monitor
- 远程调用层：protocol
- 信息交换层：exchange
- 网络传输层：transport
- 数据序列化层：serialize
下面对于其中一些层结合provider和consumer进行讲解
1.配置层:config
Provider端：
由服务配置类ServiceConfig进行初始化工作及服务暴露
ServiceConfig.export();
Consumer端：
所有的dubbo引用服务均由ReferenceConfig进行服务的引用
ReferenceConfig.get();-->ReferenceConfig.init();
2.服务代理层：proxy
服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
Consumer端：
ReferenceConfig.get();-->ReferenceConfig.init();-->ReferenceConfig.createProxy(map)-->AbstractProxyFactory.getProxy(invoker)-->JavassistProxyFactory.getProxy(invoker,interfaces)生成客户端的代理
Provider端：
ServiceConfig.doExport();-->ServiceConfig.doExportUrls()-->ServiceConfig.doExportUrlsFor1Protocol()-->ServiceConfig.exportLocal(url)-->StubProxyFactoryWrapper.getInvoker(proxy,type,url)-->JavassistProxyFactory.getInvoker(proxy,type,url)，生成服务端的代理
3.注册中心层：registry
封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。
Provider和consumer端都会将数据注册到zookeeper上
数据目录如下：
根目录为dubbo
子目录为服务目录
服务目录下面分为4个子目录
Consumers：存储所有的消费者的信息，如下以URLEncode进行编码，包括服务接口名，组名，消费者的地址，所有的方法信息等
consumer%3A%2F%2F10.128.31.78%2Fcom.pajk.unicorn.api.service.PageService%3Fapplication%3Dteemo%26category%3Dconsumers%26check%3Dfalse%26dubbo%3D2.5.3.6%26interface%3Dcom.pajk.unicorn.api.service.PageService%26methods%3DgetPitById%2CupdatePage%2CupdatePit%2CgetModulesByNameAndType%2CgetSecKillPageById%2CgetPageByName%2CgetModuleById%2CcopyModule%2CgetModuleByIds%2CgetPitsByModuleId%2CgetPages%2CgetPageById%2CupdateModule%26pid%3D29900%26retries%3D0%26revision%3DPROD%26side%3Dconsumer%26timeout%3D5000%26timestamp%3D1471569139207%26version%3DPROD
providers：存储所有的服务提供者的信息，如下以URLEncode进行编码，包括服务接口名，组名，服务提供者的地址，所有的方法信息等
dubbo%3A%2F%2F10.128.22.36%3A20880%2Fcom.pajk.unicorn.api.service.PageService%3Fanyhost%3Dtrue%26application%3Dunicorn%26dubbo%3D2.5.3.6%26interface%3Dcom.pajk.unicorn.api.service.PageService%26methods%3DgetPitById%2CupdatePage%2CgetModulesByNameAndType%2CupdatePit%2CgetSecKillPageById%2CgetPageByName%2CgetModuleById%2CgetModuleByIds%2CcopyModule%2CgetPitsByModuleId%2CgetPageById%2CgetPages%2CupdateModule%26pid%3D23597%26retries%3D0%26revision%3D1.2.3%26side%3Dprovider%26timestamp%3D1473343882590%26version%3DPROD
routers：路由目录，是存储的所有的路由信息，同样以URLEncode进行编码
路由目前有如下两种形式分别是条件路由、脚本路由
条件路由地址如下：condition://0.0.0.0/com.pajk.unicorn.api.service.PageService
脚本路由地址如下：script://0.0.0.0/com.pajk.unicorn.api.service.PageService
Configurators：是存在的一些配置信息，比如服务接口的禁用信息，服务的降级信息等，这些信息是通过dubbo控制台进行服务治理时（服务的降级，禁用，服务的mock等）生成的一些信息会写入到该目录下
Consumer端：
ReferenceConfig.createProxy()-->RegistryProtocol.refer()-->RegistryProtocol.doRefer()-->FailbackRegistry.register(url);首先注册consumer的信息到zookeeper上
RegistryProtocol.doRefer()-->FailbackRegistry.subscribe()；向服务器发送订阅请求
Provider端：
ServiceConfig.doExport();-->ServiceConfig.doExportUrls()-->ServiceConfig.doExportUrlsFor1Protocol()-->RegistryProtocol.export(originInvoker)-->FailbackRegistry.register(url);注册provider的信息到zookeeper上
下面讲一下zookeeper的通知：
ZkclientZookeeperClient.stateChanged(state)通知所有的监听
下面以FailbackRegistry描述一下通知
FailbackRegistry.notify(url, listener, urls)-->AbstractRegistry.notify()-->RegistryDirectory.notify()；会根据的通知内容，进行router、configurator、invokerUrl的刷新
RegistryDirectory.notify()-->RegistryDirectory.refreshInvoker(invokerUrls)，该方法会判断是否需要销毁当前的调用，或者根据下发的override规则或者route规则进行引用的重新刷新，并且关闭未使用的invoker
4.路由层：cluster(集群)
封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。
首先是初始时会先从zookeeper读取路由信息
ReferenceConfig.createProxy()-->RegistryDirectory.init()-->-AbstractDirectory().init()-->AbstractDirectory.setRouters()
调用时，会进行路由匹配
MockClusterInvoker.invoker()-->AbstractClusterInvoker.invoke(invocation)-->AbstractCluster.list(invocation)
5.监控层：monitor
RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。
主要是通过filter过滤每一个请求，并且进行信息采集，并且汇总一分钟内的数据，定时发送给监控服务
6.远程调用层：protocol
封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
Provider端：
ServiceConfig.doExport();-->ServiceConfig.doExportUrls()-->ServiceConfig.doExportUrlsFor1Protocol()-->RegistryProtocol.export(originInvoker)-->RegistryProtocol.doLocalExport()-->DubboProtocol.export()-->DubboProtocol.openServer()-->DubboProtocol.createServer(url)这里会进行服务的创立
Consumer端：
ReferenceConfig.createProxy()-->RegistryProtocol.refer()-->RegistryProtocol.doRefer()-->DubboProtocol.refer()-->DubboProtocol.getClients()-->DubboProtocol.getSharedClient(),默认配置，这里是获取共享连接，公用一个通道
7信息交换层：exchange
封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
在这一层主要有两个类HeaderExchangeServer和HeaderExchangeClient，进行消息的发送和接收
8.网络传输层：transport
抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。
Provider:
ServiceConfig.doExport();-->ServiceConfig.doExportUrls()-->ServiceConfig.doExportUrlsFor1Protocol()-->RegistryProtocol.export(originInvoker)-->RegistryProtocol.doLocalExport()-->DubboProtocol.export()-->DubboProtocol.openServer()-->DubboProtocol.createServer(url)-->NettyTrasporter.bind(),生成一个NettyServer
另对于provider端的线程池是FixedThreadPool，默认线程是200
Consumer:
ReferenceConfig.createProxy()-->RegistryProtocol.refer()-->RegistryProtocol.doRefer()-->DubboProtocol.refer()-->DubboProtocol.getClients()-->DubboProtocol.getSharedClient()-->NettyTransporter.connect()，生成一个NettyClient()
另对于consumer端的线程池是CachedThreadPool，默认线程存活时间是1分钟
在这一层是利用的第三方框架netty
9.数据序列化层：serialize
可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。
序列化层统一用的是第三方序列化框架hession。
