dubbo框架梳理

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

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:

另对于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。