dubbo官网文档+一点笔记

 总体介绍

分层

 

 

 

左边是“服务消费者”使用的接口和类，

右边是“服务提供者”使用的接口和类，

在中间的是双方都用到的接口和类。

 

总体分成Business层，RPC层，Remoting层

其中，

1）Business层是平时写的业务逻辑的接口和实现类；

2）RPC层是这次的重点：里面又分：

       A）config配置层：使用这一层提供的@注解，xml配置等方法来  暴露写好的接口实现类成服务  和   生成远程服务代理类，

       B）proxy服务代理层：服务接口透明代理，可以像调本地服务一样调远程服务

       C）registry注册中心层：完成服务地址的注册与发现

       D）cluster路由层：负载均衡容错处理

       E）monitor监控层：RPC调用次数和调用时间监控，发送数据到monitor监控中心

       F）protocol远程调用层：封将RPC调用

3）Remoting层：实现dubbo协议，底层使用hessian或其他协议，就不会用到这一层

A）exchange信息交换层：封装请求响应模式，同步转异步，封装Request-Response语义

B）transport网络传输层：对Mina,Netty,Grizzly的抽象，socket TCP，UDP编程

C）serialize数据序列化层：

分模块

 

 

1）common公共逻辑模块：包括Util类和通用模型，包括serialize层

2）remoting远程通讯模块：Dubbo协议的实现，包括tansport层和exchange层

3）rpc远程调用模块：抽象各种协议，以及动态代理，包括proxy和protocol层

4）cluster集群模块：处理负载均衡, 容错，路由等

5）registry注册中心模块

6）monitor监控模块

7）config配置模块：对应config层，是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。

8）container容器模块：一个Standlone的容器，以简单的Main加载Spring启动、启动开源服务器，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。

 

模块-config配置

3配置方式来开发分布式应用

1）提供xml

在spring bean使用<dubbo:service> <dubbo:reference>来暴露服务和获得远程代理。

<dubbo:registry> <dubbo:protocol>配置注册中心和提供服务的协议等等

2）注解

注解方式则是@Service和@Reference。[@Service不行，Service service = bean.getClass().getAnnotation(Service.class);]有的时候bean是JdkDynamicAopProxy，不能识别到@Service。

3）properties文件配置方式，用于全局配置：

dubbo.service.xxx;

dubbo.reference.xxx

dubbo.application.xxxx;

dubbo.protocol.xxx;

dubbo.registry.xxxx;

dubbo.monitor.xxx

 

注解配置说明 ServiceConfig,ReferenceConfig

 

 

<dubbo:annotation> 生成AnnotationBean类实例，AnnotationBean实现了BeanPostProcessor接口。

Spring创建每个bean过程中：

1）AnnotationBean的postProcessAfterInitialzation会检验bean是否有@service注解，有就创建组装一个ServiceBean，并注入这个bean对象。最后再用ServiceConfig的export()来注册和暴露服务。

2）AnnotationBean的postProcessBeforeInitialzation会检测bean是否有@Reference注解的field或setter方法。有就创建一个组装一个ReferenceBean。并使用referenceConfig的get()获得对应field接口类的远程代理对象，并注入到这个bean的field。

 

其他dubbo定义的标签<dubbo:protocol> <dubbo:registry> 是对应namespace注册的DubboBeanDefinitionParser生成对应的ProtocolConfig，registryConfig等Config类，然后在组装ServiceBean和ReferenceBean时通过applicationContext注入。[大概是这样]

 

 

Dubbo的配置覆盖策略[abstractConfig.appendProperties]

JVM启动-D参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。

@和XML次之，如果在XML中有配置，则dubbo.properties中的相应配置项无效。

Properties最后，相当于缺省值，只有XML没有配置时，dubbo.properties的相应配置项才会生效，通常用于共享公共配置，比如应用名。

 

 

模块-rpc远程调用

解析服务

在ServiceConfig.export()或ReferenceConfig.get()初始化时，将Bean对象转换暴露服务或请求服务的URL，所有Bean属性转成URL的参数。

然后将URL传给Protocol扩展点，基于扩展点的Adaptive机制，根据URL的协议头，进行不同协议的服务暴露或引用。

 

url参数列只有group，interface，version是服务的匹配条件，三者决定是不是同一个服务，其它配置项均为调优和治理参数

暴露服务

有注册中心配置：<dubbo:registry address="zookeeper://10.20.153.10:2181" />

ServiceConfig解析出的URL的格式为：

registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode("dubbo://service-host/com.foo.FooService?version=1.0.0")

1）基于扩展点的Adaptive机制，通过URL的"registry://"协议头识别，就会调用RegistryProtocol的export()方法，将export参数中的提供者URL，先注册到注册中心，再重新传给Protocol扩展点进行暴露：

dubbo://service-host/com.foo.FooService?version=1.0.0

2）基于扩展点的Adaptive机制，通过提供者URL的"dubbo://"协议头识别，就会调用DubboProtocol的export()方法，打开服务端口。

 

Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url);

Exporter<?> exporter = protocol.export(invoker);

具体服务àInvoker àExporter  Exporter是负载打开服务端口等待请求。

 

 

 

把服务实现类使用JavassisProxyFactory包装成一个invoker。它的getInvoker里使用Wrapper代码生成具体的类，包装服务实现类，通过方法名，参数类型，参数值直接调用对应的服务实现类方法。

接着使用扩展机制得到protocol串，protocolFilterWrapper先包装代理生成的一条每个节点都带filter的invoker链

到protocolListenrWrapper会把最终生成的Exporter包装成一个带监听服务暴露的监听器的Exporter。

到RegistryProtocol，它会先根据服务url的参数暴露服务，使用到HessianProtocol，最后再使用Registry注册服务。

 

远程请求服务时，就会通过Exporter调用Invoker的invoker，这时就会经过一层层filter，最后调用服务实现类的方法。

HessianSkelen和HessianProxyFactory

 

 

引用服务

注册中心配置：<dubbo:registry address="zookeeper://10.20.153.10:2181" />

ReferenceConfig解析出的URL的格式为：

registry://registry-host/com.alibaba.dubbo.registry.RegistryService?refer=URL.encode("consumer://consumer-host/com.foo.FooService?version=1.0.0")

基于扩展点的Adaptive机制，通过URL的"registry://"协议头识别，就会调用RegistryProtocol的refer()方法，基于refer参数中的条件，查询提供者URL，如：

dubbo://service-host/com.foo.FooService?version=1.0.0

基于扩展点的Adaptive机制，通过提供者URL的"dubbo://"协议头识别，就会调用DubboProtocol的refer()方法，得到提供者引用。

然后RegistryProtocol将多个提供者引用，通过Cluster扩展点，伪装成单个提供者引用返回。

invoker = refprotocol.refer(interfaceClass, urls.get(0));

(T) proxyFactory.getProxy(invoker);

 

  

拦截服务

基于ProtocolFilterWrapper类，将所有Filter组装成链，在链的最后一节调用真实的引用。

基于ProtocolListenerWrapper类，将所有InvokerListener和ExporterListener组装集合，在暴露和引用前后，进行回调。

包括监控在内，所有附加功能，全部通过Filter拦截实现。

• 用户自定义filter默认在内置filter之后。
• 特殊值default，表示缺省扩展点插入的位置。
• 比如：filter="xxx,default,yyy"，表示xxx在缺省filter之前，yyy在缺省filter之后。
• 特殊符号-，表示剔除。
• 比如：filter="-foo1"，剔除添加缺省扩展点foo1。
• 比如：filter="-default"，剔除添加所有缺省扩展点。
• provider和service同时配置的filter时，累加所有filter，而不是覆盖。
• 比如：<dubbo:provider filter="xxx,yyy"/>和<dubbo:service filter="aaa,bbb" />，则xxx,yyy,aaa,bbb均会生效。
• 如果要覆盖，需配置：<dubbo:service filter="-xxx,-yyy,aaa,bbb" />

 

几个预置拦截器介绍

accessLogFilter	Active provider before	记录每次服务调用的方法、形参、实参
ActiveLimitFilter	Active consumer around	限制同时请求一个服务方法的请求数，超过最大值就等待直到超时。默认0，没有限制
CacheFilter	Active consumer,provider,  before	获得缓存里的数据
ClassLoaderFilter	Active provider before Order=-30000	设置线程上下文的类加载器
CompatibleFilter		类型转换，泛型？
ConsumerContextFilter	Active consumer before Order=-10000	RpcContext设置调用的invoker和invocation
ContextFilter	Active provider before Order=-10000	RpcContext设置调用的invoker和invocation
deprecatedFilter	Active consumer before	调用过时服务方法检测，url有deprecate参数
Echo	Active consumer provider Order=-110000	url有echo参数时，返回参数值
exceptionFilter	Active provider before	异常处理
executerLimitFilter	Active provider before	限制同时请求一个服务方法的请求数，超过则抛错
FutureFilter	Active consumer before	异步或同步
GenericFilter	Active consumer berfore
GenericImplFilter	Active consumer berfore Order=2000
MonitorFilter	Active consumer,provider around	记录调用日志
TimeoutFilter	Active provider	服务调用超时

 

 

 

其他

1）proxy服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory

2）Protocol远程调用层，封将RPC调用，以Invocation, Result为中心，扩展接口为Protocol, Invoker, Exporter

3）只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用，然后在Invoker的主过程上Filter拦截点。Proxy层封装了所有接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，只是不那么透明，不那么看起来像调本地服务一样调远程服务。

4）参考其他人共享文档http://humn-chou.iteye.com/blog/1866272

 

 

模块-registry注册中心

服务注册和订阅过程

registry，注册中心层，封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory, Registry, RegistryService

System.getProperty("user.home") + "/.dubbo/dubbo-registry-"+ConfigUtils.getProperty("dubbo.application.name")+"-" + url.getHost() + ".cache");

 

 

  

模块-cluster集群

负载容错

cluster，路由层，封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster, Directory, Router, LoadBalance

 

 

将多个Invoker伪装成一个Invoker


 
 

 

• 这里的Invoker是Provider的一个可调用Service的抽象，Invoker封装了Provider地址及Service接口信息。
• Directory代表多个Invoker，可以把它看成List<Invoker>，但与List不同的是，它的值可能是动态变化的，比如注册中心推送变更。
• Cluster将Directory中的多个Invoker伪装成一个Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个。
• Router负责从多个Invoker中按路由规则选出子集，比如读写分离，应用隔离等。
• LoadBalance负责从多个Invoker中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选。

 
 
 

 

模块-monitor监控

 

monitor，监控层，RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory, Monitor, MonitorService

配置

dubbo.monitor.address=127.0.0.1:8080

是filter链上的一个MonitorFilter

 

 DubboMonitor是缓存请求，每隔一段时间再后台一起发送。

extension扩展点介绍

dubbo采用Microkernel + Plugin模式，提供很多SPI来扩展框架

 

如何操作增加新模块：参考官方spi手册

在扩展类的jar包内，放置扩展点配置文件：META-INF/dubbo/接口全限定名，内容为：配置名=扩展实现类全限定名，多个实现类用换行符分隔。

扩展点使用单一实例加载，扩展实现必须是线程安全性的

 

1）自动Wrap扩展点的Wrapper类

ExtensionLoader会把加载扩展点时（通过扩展点配置文件中内容），如果该实现有拷贝构造函数，则判定为扩展点Wrapper类。

通过Wrapper类可以把所有扩展点公共逻辑移至Wrapper中。新加的Wrapper在所有的扩展点上添加了逻辑，有些类似AOP（Wraper代理了扩展点）

 

2）扩展点自动装配

加载扩展点时，自动注入依赖的扩展点

加载扩展点时，扩展点实现类的成员如果为其它扩展点类型，ExtensionLoader在会自动注入依赖的扩展点。

ExtensionLoader通过扫描扩展点实现类的所有set方法来判定其成员。

即ExtensionLoader会执行扩展点的拼装操作。

 

3）扩展点自适应

扩展点的Adaptive实例

ExtensionLoader注入的依赖扩展点是一个Adaptive实例，直到扩展点方法执行时才决定调用是一个扩展点实现。

Dubbo使用URL对象（包含了Key-Value）传递配置信息。

扩展点方法调用会有URL参数（或是参数有URL成员）

这样依赖的扩展点也可以从URL拿到配置信息，所有的扩展点自己定好配置的Key后，配置信息从URL上从最外层传入。URL在配置传递上即是一条总线。

在Dubbo的ExtensionLoader的扩展点类开对应的Adaptive实现是在加载扩展点里动态生成。指定提取的URL的Key通过@Adaptive注解在接口方法上提供。

 

4）扩展点自动激活

对于集合类扩展点，比如：Filter, InvokerListener, ExportListener, TelnetHandler, StatusChecker等，
可以同时加载多个实现，此时，可以用自动激活来简化配置 @active

@Activate(group = "provider", value = "xxx") // 只对提供方激活，group可选"provider"或"consumer"

 

 

  

Dubbo的使用

官方文档 spi，api手册

http://code.alibabatech.com/wiki/display/dubbo/Developer+Guide-zh

http://code.alibabatech.com/wiki/display/dubbo/User+Guide-zh

 

 

其他

领域模型

在Dubbo的核心领域模型中：

• Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。
• Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
• Invocation是会话域，它持有调用过程中的变量，比如方法名，参数等。

基本原则

• 采用Microkernel + Plugin模式，Microkernel只负责组将Plugin，Dubbo自身的功能也是通过扩展点实现的，也就是Dubbo的所有功能点都可被用户自定义扩展所替换。
• 采用URL作为配置信息的统一格式，所有扩展点都通过传递URL携带配置信息。

 

 

属性配置

1）

 

 1）属性的配置查找顺序

方法级优先，接口级次之，全局配置再次之。

如果级别一样，则消费方优先，提供方次之。

  其中，服务提供方配置，通过URL经由注册中心传递给消费方。

  建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。

 

2）xml配置和properties配置映射

将XML配置的标签名，加属性名，用点分隔，多个属性拆成多行：

比如：dubbo.application.name=foo等价于<dubbo:application name="foo" />

比如：dubbo.registry.address=10.20.153.10:9090等价于<dubbo:registry address="10.20.153.10:9090" />

如果XML有多行同名标签配置，可用id号区分，如果没有id号将对所有同名标签生效：

比如：dubbo.protocol.rmi.port=1234等价于<dubbo:protocol id="rmi" name="rmi" port="1099" /> (协议的id没配时，缺省使用协议名作为id)

比如：dubbo.registry.china.address=10.20.153.10:9090等价于<dubbo:registry id="china" address="10.20.153.10:9090" />

 

 

日志部分

1）配置

Dubo.application.logger=slf4j|jcl|log4j|jdk  

 

 

 

 

 

Admin

想注册中心订阅，获得信息。

<dubbo:reference id="registryService" interface="com.alibaba.dubbo.registry.RegistryService" check="false" />

 

 

 

 
  

目前系统如何扩展dubbo和一些功能

1）  修改的dubbo

暴露“获取服务器信息”服务时的url拼接，要再通常的服务url后增加表示服务器资源信息的参数；

 

 

2）扩展功能，新增工程

Filter dispatchLog=com.alibaba.dubbo.log.support.DispatchLogFilter  日志记录

LoadBalance parameter=com.alibaba.dubbo.rpc.cluster.loadbalance.parameter.ParameterLoadBalance动态权重轮询

Cluster failfast_ext=com.alibaba.dubbo.rpc.cluster.support.parameter.FailfastClusterExt