dubbo的代码很久之前看过一遍,个人比较懒,没有做笔记总结,很多都忘了。最近抽时间仔细学习了下源码,记录总结下,加深印象。
环境:
源码版本: 2.7.3-SNAPSHOT
IDE: idea Intelij
1. 扩展机制 与 ExtensionLoader 类
Dubbo 采用 的微内核+扩展的优秀设计,扩展点设计借鉴了JDK 的ServiceLoader 机制, 核心实现落在 ExtensionLoader.class ,理解这个类,对读懂、调试代码非常关键。
ExtensiionLoader 类的成员变量如下:
// ===============基础数据=============== private String cachedDefaultName; //SPI 默认扩展名称 private final Class<?> type; //当前加载的SPI class 类型 private final ExtensionFactory objectFactory; //对象工厂的SPI 的扩展, 用于对Extension 注入属性(set方法对象) // =========Class 缓存========= private volatile Class<?> cachedAdaptiveClass = null; private final Holder<Map<String, Class<?>>> cachedClasses = new Holder<>(); private Set<Class<?>> cachedWrapperClasses; //Warp扩展 class集合。 如果一个扩展的构造函数参数类型为当前扩展,则这个扩展为Wrap型 // ==========Instance 缓存================= private final Holder<Object> cachedAdaptiveInstance = new Holder<>(); //Adaptive 实例缓存 private final ConcurrentMap<String, Holder<Object>> cachedInstances = new ConcurrentHashMap<>(); //生成的扩展实例缓存 private final Map<String, Object> cachedActivates = new ConcurrentHashMap<>(); //Activate 扩展实例缓存 // =============运行时产生内容============= private final ConcurrentMap<Class<?>, String> cachedNames = new ConcurrentHashMap<>(); //缓存的扩展点Class-名称 映射 private volatile Throwable createAdaptiveInstanceError; private Map<String, IllegalStateException> exceptions = new ConcurrentHashMap<>(); private ExtensionLoader(Class<?> type) { this.type = type; //每个ExtensionLoader (除了ExtensionFactory)都需要一个 factory, 依然采用扩展机制加载 objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension()); }
将成员变量分成基础数据, Class缓存,Instance缓存, 运行时产生的其他数据四种。
当执行 loadExtensionClasses() 方法,遍历所有的扩展实现后,在loadClass()方法里,
一个扩展必会被 划分为adaptive、普通实现、wrap 扩展中的一种:
1. Adaptive扩展 ,在class上面带有Adaptive注解,至多1个(如没有,在调用getAdaptiveExtension()时自动生成一个), 例如:AdaptiveExtensionFactory 类
2. 普通扩展 , 扩展点的具体实现,例如Protocol 扩展的 DubboProtocol 扩展。
3. wrap 扩展, 该类型的扩展,有个该扩展点的构造函数,例如 ProtocolFilterWrapper 为Protocol的扩展,有个 构造函数,需要Protocol类型的参数。 wrap扩展,是对普通扩展的包装,当生成普通扩展时,都会循环一遍wrap class,全部包装一遍。
2. 重要方法:
ExtensionLoader 有2个重要的方法:getAdaptiveExtension()与 getActivateExtension()
getAdaptiveExtension :
adaptive扩展, 是一个包装(代理)类,会根据运行时传入url里面的key-value 值,确定最终调用的实际扩展。
内部逻辑如下:
如有成员变量 adaptiveClass 有值,则直接用class.newInstance() 一个实例出来,
如果 无值,则 用String 构造一个adaptiveClass 的源码,用complier 实时编译,生成adaptive 实例。
getActivateExtension:
activate 扩展,是一个有条件的扩展,当分组 && 值满足条件时,才会被加载到。
例如调用Invokcation的 Fitler,Group分为 provider 与consumer, 当Filter 分组取值为privider时,会被server 端构建。
//group 为provider,仅用于发布服务 //value 有值,需要在配置里面, accesslog 属性配置项有值 @Activate(group = PROVIDER, value = ACCESS_LOG_KEY) public class AccessLogFilter implements Filter {
3. 扩展的实例化
在dubbo里面,扩展一般都是无参构造函数,除了wrap扩展,是有个本扩展点的构造函数。
扩展点实例化后,会注入属性。 遍历set开头的方法,查找方法的参数类型, 然后通过objectFactory 去获取对应类型的对象,完成注入。
属性注入,在ExchangeServer、Transporter 里面比较容易看到,在最开始Debug跟踪源码的时候,经常不知道这个属性是什么时候来的,感觉莫名其妙。
以上几个点,基本就是ExtensionLoader方法里面比较关键的部分,弄清楚以上几个点,对于微内核的运行机制,就能很清楚了。 后续就是流程组装了。