总体上分成Business层、RPC层、Remoting层。
(1)Business层是写的业务逻辑的接口和实现类。
(2)RPC层
- config配置层,使用这一层提供的@注解,xml配置等方法来暴露写好的接口实现类为服务 和 生成远程服务代理类。
- proxy服务代理层,服务接口透明代理,可以像调本地一样调远程服务。
- registry注册中心层,完成服务地址的注册与发现。
- cluster路由层,负载均容错处理。
- monitor监制层:rpc调用次数的调用时间监控,发送数据到monitor监控中心
- protocol远程调用层:封装RPC调用。
(3)Remoting层,实现dubbo协议,底层使用其他协议,就不会用到这一层。
- exchange信息交换层,封装请求响应模式、同步转异步,封装Request-Response语义。
- transport网络传输层,对Mina、Netty、Grizzly的抽象,Socket TCP UDP编程。
- serialize数据序列化层
解析服务
在ServiceConfig.export或者ReferenceConfig.get初始化时,将Bean对象转换暴露服务或请求服务URL,所有Bean属性转成URL的参数。然后将URL传给Protocol扩展点,基于扩展点的Adaptive机制,根据URL的协议头,进行不同协议的服务暴露或引用。
url参数的group、interface、version决定是不是同一个服务,其它配置项均为调优和治理参数。
暴露服务
有注册中心配置:<dubbo:registry address="zookeeper://10.20.143.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方法,打开服务端口等待请求。
ServiceConfig.export
Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url);
Exporter<?> exporter = protocol.export(invoker);
使用JavassisProxyFactory把服务实现类包装成一个Invoker,它的getInvoker里使用Wrapper包装服务实现类。ProtocolFilterWrapper为invoker添加filter链,ProtocolListenerWrapper为Exporter包装成一个带监听服务暴露的监听器的Exporter。远程请求服务时,就会通过Exporter调用Invoker的invoker。
引用服务
注册中心配置:<dubbo:registry address="zookeeper://10.21.134.10:2181" />
ReferenceConfig解析出的URL格式为:
regisry://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方法,得到提供者引用。
RerenceConfig.createProxy
invoker = refprotocol.refer(interfaceClass, urls.get(0));
(T) proxyFactory.getProxy(invoker)
然后RegistryProtocol将多个提供者引用,通过Cluster扩展点,伪装成单个提供者引用返回。
拦截服务
基于ProtocolFilterWrapper类,将所有Filter组装成链,在链的最后一节调用真实的引用。
基于ProtocolListenerWrapper类,将所有InvokerListener和ExporterListener组装,在暴露和引用前后,进行回调。
- 用户自定义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均会生效。
几个预置拦截器介绍
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)Protocl远程调用层,封装RPC调用,以Invocation、Result为中心,扩展接口为Protocol、Invoker、Exporter
(3)只要有Protocol+Invoker+Exporter就可以完成非透明的RPC调用,然后在Invoker的主过程上Filter拦截点。Proxy层封装了所有接口的透明化代理,而在其它层都以Invoker为中心,只有到了暴露给用户使用时,才用Proxy将Invoker转成接口,或将接口实现转成Inovker。
服务注册和订阅过程
registry,注册中心层,封装服务地址与发现,以服务URL为中心,扩展接口为RegistryFactory、 Registry、RegistryService。
负载容错
cluster、路由层,封装多个提供者的路由及负载均衡,并桥接注册中心,以Invoker为中心,扩展接口为Cluster Directory Router LoadBalance。
(1)Invoker是Provider的一个可调用Service的抽象,Invoker封装了Provider地址及Service接口信息。
(2)Directory代表多个Invoker,可以把它看成List<Invoker>,但与List不同的是,它的值可能是动态变化的。
(3)Cluster将Directory中的多个Invoker伪装成一个Invoker,对上层透明,伪装过程包括了容错逻辑,调用失败后,重试另一个。
(4)Router负责从多个Invoker中按路由规则选出子集。
(5)LoadBalance负责从多个Invoker中选出具体的一个用于本次调用 。
监控
monitor监控层,以Statistics为中心,扩展接口为MonitorFactory Monitor MonitorService
领域模型
(1)Protocol是服务域,它是Invoker暴露和引用的主功能入口,它负责Invoker的生命周期管理。
(2)Invoker是实体域,它是Dubbo的核心模型,其它模型都向它靠拢,或转换成它,它代表一个可执行体,可向它发起invoke调用,它有可能是一个本地的实现,也可能是一个远程的实现,也可能是一个集群的实现。
(3)Invocation是会话域,它持有调用过程的变量。
Microkernel+Plugin模式
(1)自动Wrap扩展点的Wrapper类
如果扩展实现类中有拷贝构造函数,则为人扩展实现类为扩展实现Wrapper类。
(2)扩展点自动装配
加载扩展点时,如果实现类的成员为其它扩展点类型 ,ExtensionLoader会自动注入依赖的扩展点。
(3)扩展点自适应
ExtensionLoader注入的依赖扩展点是一个Adaptive实例,直到扩展点方法执行时才决定调用的扩展实现。
(4)扩展点自动激活
对于集合类扩展点,比如:Filter、InvokerListener、ExportListener、TelnetHandler、StatusChecker等,可以同时加载多个实现,此进可以用自动激活来简化配置@Activate()
最后欢迎大家访问我的个人网站:1024s