前言
书接上回，本文主要研究DUBBO SPI机制中的IOC和自适应扩展
上文中我们定义了一个抽象的汽车接口 Car，并提供两个实现别克(Buick)和奥迪(Audi)
// 车
@SPI
public interface Car {
void run();
}
// 奥迪车
public class Audi implements Car {
@Override
public void run() {
System.out.println("Audi is running");
}
}
// 别克车
public class Buick implements Car {
@Override
public void run() {
System.out.println("Buick is running");
}
}
// Car全限定名文件配置内容
Buick=com.xxx.Buick
Audi=com.xxx.Audi
通过SPI机制，可以轻松的在运行时根据配置选取某一个实现
// 初始化Car接口的扩展类加载器
ExtensionLoader<Car> extensionLoader = ExtensionLoader.getExtensionLoader(Car.class);
// 获取名为"Buick"的扩展实现
Car buick = extensionLoader.getExtension("Buick");
// 运行
buick.run();
IOC
IOC即控制翻转，依赖注入或者叫自动装配，即在某个容器中存在多个单例对象，当某个对象的属性是容器中另一个对象时，自动给属性赋值为这个依赖对象，大家都在用Spring，就不多做解释了
回到上例，假如我们要给车上加一个导航，而导航也有很多种实现：比如高德地图、百度地图等，所以导航我们也用SPI机制使其可以配置并扩展
// 抽象导航
@SPI
public interface Navigation {
void start();
}
// 高德导航
public class AmapNavigation implements Navigation {
@Override
public void start(URL url) {
System.out.println("高德地图开始导航...");
}
}
// 谷歌导航
public class GoogleNavigation implements Navigation {
@Override
public void start(URL url) {
System.out.println("谷歌地图开始导航...");
}
}
META-INF/dubbo目录下，Navigation全限定名配置如下
Amap=com.xxx.AmapNavigation
Google=com.xxx.GoogleNavigation
到此我们也可以运行时选择某个实现执行导航了
ExtensionLoader<Navigation> navigationExtensionLoader = ExtensionLoader.getExtensionLoader(Navigation.class);
Navigation amap = navigationExtensionLoader.getExtension("Amap");
amap.start(); // 高德地图开始导航...
问题来了，如果现在想给奥迪汽车加上一个导航，并在汽车跑起来时自动开启导航，怎么办？
Dubbo SPI可以支持自动装配，官方文档：
加载扩展点时，自动注入依赖的扩展点。加载扩展点时，扩展点实现类的成员如果为其它扩展点类型，ExtensionLoader 在会自动注入依赖的扩展点。ExtensionLoader 通过扫描扩展点实现类的所有 setter 方法来判定其成员。即 ExtensionLoader 会执行扩展点的拼装操作。
回到例子，所以只要给Car的实现Audi加上类型为Navigation的成员变量，并提供setter方法即可自动检测自动装配，如下
@Setter
public class Audi implements Car {
// 导航
private Navigation navigation;
@Override
public void run() {
// 汽车启动
System.out.println("Audi is running");
// 开启内置导航
this.navigation.start(url);
}
}
此时再运行一下会发现红红的一篇报错。。。
问题出在，我们只是说要给奥迪车配导航，并没有指定具体是什么导航，再牛逼的框架也不知道该给你注入什么对象
问题在于缺少一个配置(指定使用什么实现)，可问题在于dubbo再运行时才会知道具体的配置，不同的请求可能配置使用的实现不一样，比如负载均衡:
@DubboReference(loadbalance = "random")
每个服务可以配置不同的负载均衡策略，所以只有在实际调用时才能知道具体策略
URL配置
Dubbo每次请求发起，信息会封装在URL对象中，包含protocol(网络协议),ip,port(端口)等信息
除此之外，本次请求的配置信息，包含某个个扩展点具体使用哪个实现，也会以(Key-Value)的形式存在URL里，因此URL对象就包含了上面所需要的配置信息
URL
而这个URL对象，作为单次请求的配置，在每个扩展点的方法上以参数的形式传递，因此我们把扩展点代码加上URL参数
导航
//抽象导航
@SPI
public interface Navigation {
void start(URL url);
}
// Google导航
public class GoogleNavigation implements Navigation {
@Override
public void start(URL url) {
System.out.println("谷歌地图开始导航...");
}
}
// 高德导航
public class AmapNavigation implements Navigation {
@Override
public void start(URL url) {
System.out.println("高德地图开始导航...");
}
}
汽车
// 车
@SPI
public interface Car {
void run(URL url);
}
// 装配导航的奥迪车
@Setter
public class Audi implements Car {
// 装配导航
private Navigation navigation;
@Override
public void run(URL url) {
// 汽车启动
System.out.println("Audi is running");
// 开启内置导航
this.navigation.start(url);
}
}
// 别克车
public class Buick implements Car {
@Override
public void run(URL url) {
System.out.println("Buick is running");
}
}
使用时传入配置，规定使用的导航
public static void main(String[] args) {
// 配置使用高德导航
Map<String, String> parameters = new HashMap<String, String>() {{
put("navigation", "Amap");
}};
// 协议端口就随便写了
URL url = new URL("protocol", "ip", 0, parameters);
ExtensionLoader<Car> extensionLoader = ExtensionLoader.getExtensionLoader(Car.class);
// 获取 奥迪 的实现
Car buick = extensionLoader.getExtension("Audi");
// 运行
buick.run(url);
}
自适应机制
有了URL配置，我们Car运行时就知道要使用什么导航，但还是有问题
- 只有运行时才能知道需要什么导航，难道车跑起来现场加载导航吗？
- 如果真的是运行时加载导航，那就不是自动装配了，而且用户还得自己在run方法实现，很不友好
综上所述，自动装配是肯定要装配的，但问题是到底装配哪个导航，高德or谷歌？
答案是二者都不对，因为无论装配任何一个，运行时URL的配置不是该导航名都会出问题
而实际上装配的是一个新导航，这个导航有这样的特点，它可以获取到两种导航，并且运行时根据URL配置，内部使用不同的导航，相当于给两种导航包了壳子，也就是代理
有了这个新导航，即完成了自动装配，又可以在配置不同时切换不同的实际导航实现，这种可以根据运行时配置切换实际实现的机制即为自适应机制
我们可以代码实现一下这个新导航，即自适应扩展
// 标志是一个自适应扩展
@Adaptive
public class AdaptiveNavigation implements Navigation {
@Override
public void start(URL url) {
// 获取配置中的名称
String name = url.getParameter("navigation");
// 导航实现加载器
ExtensionLoader<Navigation> extensionLoader = ExtensionLoader.getExtensionLoader(Navigation.class);
// 按配置名称获取实现
Navigation impl = extensionLoader.getExtension(name);
// 使用实际实现的start方法
impl.start(url);
}
}
代码使用了@Adaptive注解标志其为自适应扩展，代码中读取配置key "navigation"来获取实际扩展实现的名字，同时配置文件中也要加入该扩展
Adaptive=com.pq.pure.spi.navigation.AdaptiveNavigation
运行一下
public static void main(String[] args) {
// 配置使用高德导航
Map<String, String> parameters = new HashMap<String, String>() {{
put("navigation", "Amap");
}};
// 协议端口就随便写了
URL url = new URL("protocol", "ip", 0, parameters);
ExtensionLoader<Car> extensionLoader = ExtensionLoader.getExtensionLoader(Car.class);
// 获取 奥迪 的实现
Car buick = extensionLoader.getExtension("Audi");
// 运行
buick.run(url);
}
输出如下
Audi is running
高德地图开始导航...
到此，真正的实现了自动装配~
自动生成的自适应扩展
上面这个自适应扩展如果自己写真的很麻烦，而且还得懂ExtensionLoader的使用才可以，实际上这个自适应扩展可以自动生成出来
这个仅凭抽象接口造出自适应扩展的技术也很简单：JDK动态代理，写法如下：
1.首先删除手写的自适应扩展，以免干扰测试
2.在扩展类接口Navigation方法上加上@Adaptive注解，并指明所参照的的参数key
@SPI
public interface Navigation {
// 标记可以创建自适应扩展，配置key为navigation
@Adaptive({"navigation"})
void start(URL url);
}
这个@Adaptive是加在方法上而不是类上，估计是为了不同方法使用不同的配置key
再次测试一下，效果一样
到底，彻底实现了简单的自动装配~
自动装配源码
回到Dubbo源码层面证实一下上面所说的，setter注入/自适应扩展/JDK动态代理等逻辑
setter注入
来到核心类ExtensionLoader(扩展加载器)的createExtension(创建扩展)中执行的injectExtension方法，该方法专门处理依赖注入
private T injectExtension(T instance) {
...
// 循环所有方法
for (Method method : instance.getClass().getMethods()) {
// 是否是setter方法
if (!isSetter(method)) {
continue;
}
...
// 获取setter属性类型
Class<?> pt = method.getParameterTypes()[0];
try {
String property = getSetterProperty(method);
// 获取依赖对象
Object object = objectFactory.getExtension(pt, property);
// 反射调用setter方法注入对象
if (object != null) {
method.invoke(instance, object);
}
} catch (Exception e) {
...
}
}
return instance;
}
可以看到Dubbo检查setter方法的逻辑，如果有则依赖注入
ExtensionFactory
其中获取依赖对象的方法为objectFactory.getExtension(pt, property)，而objectFactory的类型是ExtensionFactory
ExtensionFactory即是一个加载依赖对象的工厂，并且支持扩展，它只有一个方法，即根据类型和名称获取依赖对象
@SPI
public interface ExtensionFactory {
<T> T getExtension(Class<T> type, String name);
}
objectFactory在构造方法中被初始化
private ExtensionLoader(Class<?> type) {
this.type = type;
objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
}
实例化的结果是一个ExtensionFactory(可扩展接口)的自适应扩展，其中getAdaptiveExtension为获取自适应扩展的方法，看一下其扩展配置
spring=org.apache.dubbo.config.spring.extension.SpringExtensionFactory
adaptive=org.apache.dubbo.common.extension.factory.AdaptiveExtensionFactory
spi=org.apache.dubbo.common.extension.factory.SpiExtensionFactory
其中有一个adaptive实现，打开看一下
AdaptiveExtensionFactory
首先该扩展有@Adaptive注解，标识这是一个自适应扩展，这种情况下getAdaptiveExtension方法获取的扩展就是这个类，而不是jdk自动生成，而这个自适应扩展的获取逻辑简单粗暴： 从所有普通扩展中获取依赖，哪个能加载到就返回
而普通扩展有两个SpiExtensionFactory和SpringExtensionFactory
SpiExtensionFactory
SpiExtensionFactory就是从其它扩展实现加载，实现方法就是根据type获取自适应扩展(没有就通过动态代理生成)
public class SpiExtensionFactory implements ExtensionFactory {
@Override
public <T> T getExtension(Class<T> type, String name) {
// 是接口且携带@SPI注解
if (type.isInterface() && type.isAnnotationPresent(SPI.class)) {
// 获取该类型扩展类加载器
ExtensionLoader<T> loader = ExtensionLoader.getExtensionLoader(type);
if (!loader.getSupportedExtensions().isEmpty()) {
// 获取自适应扩展
return loader.getAdaptiveExtension();
}
}
return null;
}
}
SpringExtensionFactory
SpringExtensionFactory从spring容器加载bean，这个很实用
public <T> T getExtension(Class<T> type, String name) {
//SPI should be get from SpiExtensionFactory
if (type.isInterface() && type.isAnnotationPresent(SPI.class)) {
return null;
}
//从ApplicationContext中获取bean
for (ApplicationContext context : CONTEXTS) {
T bean = BeanFactoryUtils.getOptionalBean(context, name, type);
if (bean != null) {
return bean;
}
}
return null;
}
比如当我们自定义一些扩展，扩展的一些参数有依赖于数据库配置，这种注入就非常方便了
网友评论