Dubbo源码分析(2),Dubbo中采用的设计模式

一、工厂模式  java

     ServiceConfig中有个字段,代码是这样的: app

private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

  Dubbo里有不少这种代码。这也是一种工厂模式,只是实现类的获取采用了jdkspi的机制。这么实现的优势是可扩展性强,想要扩展实现,只须要在classpath下增长个文件就能够了,代码零侵入。另外,像上面的Adaptive实现,能够作到调用时动态决定调用哪一个实,可是因为这种实现采用了动态代理,会形成代码调试比较麻烦,须要分析出实际调用的实现类。ide

 

二、装饰器模式  测试

       Dubbo在启动和调用阶段都大量使用了装饰器模式。以Provider提供的调用链为例,具体的调用链代码是在ProtocolFilterWrapper的buildInvokerChain完成的,具体是将注解中含有group=provider的Filter实现,按照order排序,最后的调用顺序是 ui

   EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》  spa

   TimeoutFilter-》MonitorFilter-》TraceFilter。  线程

       更确切地说,这里是装饰器和责任链模式的混合使用。例如,EchoFilter的做用是判断是不是回声测试请求,是的话直接返回内容,这是一种责任链的体现。而像ClassLoaderFilter则只是在主功能上添加了功能,更改当前线程的ClassLoader,这是典型的装饰器模式。代理

 

三、观察者模式  调试

      Dubbo的provider启动时,须要与注册中心交互,先注册本身的服务,再订阅本身的服务,订阅时,采用了观察者模式,开启一个listener。注册中心会每5秒定时检查是否有服务更新,若是有更新,向该服务的提供者发送一个notify消息,provider接受到notify消息后,即运行NotifyListener的notify方法,执行监听器方法。 code

 

四、动态代理模式 

      Dubbo扩展jdkspi的类ExtensionLoader的Adaptive实现是典型的动态代理实现。Dubbo须要灵活地控制实现类,即在调用阶段动态地根据参数决定调用哪一个实现类,因此采用先生成代理类的方法,可以作到灵活的调用。生成代理类的代码是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理类的主要逻辑是,获取URL参数中指定参数的值做为获取实现类的key。

相关文章
相关标签/搜索