我们在之前的文章中已经稍微了解过 SOFA 的扩展机制,我们也说过,一个好的框架,必然是易于扩展的。那么 SOFA 具体是怎么实现的呢?
一起来看看。
看官方的 demo:
1.定义扩展点。
@Extensible public interface Person { void getName(); }
2.定义扩展实现
@Extension("A") public class PersonA implements Person{ @Override public void getName() { System.out.println("li wei"); } }
3.编写扩展描述文件:META-INF/services/sofa-rpc/com.alipay.sofa.rpc.extension.Person。文件内容如下:
A=com.alipay.sofa.rpc.extension.PersonA
4.加载扩展点,获取到扩展实现类使用。
Person person = ExtensionLoaderFactory.getExtensionLoader(Person.class).getExtension("A");
很简单对不对,只需要 2 个注解,一个配置文件,然后使用工厂方法通过接口名称和扩展点名称就能够获取到实例。So,我们今天要看的就是这些东西,其实挺简单的,如果用过 Java 自带的 SPI 就会很熟悉了。
从哪里下手呢?当然是这个工厂方法。
源码如下:
public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> clazz) { return getExtensionLoader(clazz, null); }
调用的是重载的另一个方法:
public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> clazz, ExtensionLoaderListener<T> listener) { ExtensionLoader<T> loader = LOADER_MAP.get(clazz); if (loader == null) { synchronized (ExtensionLoaderFactory.class) { loader = LOADER_MAP.get(clazz); if (loader == null) { loader = new ExtensionLoader<T>(clazz, listener); LOADER_MAP.put(clazz, loader); } } } return loader; }
很简单,从 Map 中取出,如果没有,创建一个,放入缓存。这里使用了双重检查锁。
注意,这里有个参数,ExtensionLoaderListener ,作用是当加载完毕的的时候,回调他的 onLoad 方法,通常是在异步的时候使用。
所以,看出来了吧,关键过程在 new ExtensionLoader()。
构造方法:
public ExtensionLoader(Class<T> interfaceClass, ExtensionLoaderListener<T> listener) { this(interfaceClass, true, listener); }
重载:
protected ExtensionLoader(Class<T> interfaceClass, boolean autoLoad, ExtensionLoaderListener<T> listener) { if (RpcRunningState.isShuttingDown()) { this.interfaceClass = null; this.interfaceName = null; this.listener = null; this.factory = null; this.extensible = null; this.all = null; return; } // 接口为空,既不是接口,也不是抽象类 if (interfaceClass == null || !(interfaceClass.isInterface() || Modifier.isAbstract(interfaceClass.getModifiers()))) { throw new IllegalArgumentException("Extensible class must be interface or abstract class!"); } this.interfaceClass = interfaceClass; this.interfaceName = ClassTypeUtils.getTypeStr(interfaceClass); this.listener = listener; Extensible extensible = interfaceClass.getAnnotation(Extensible.class); if (extensible == null) { throw new IllegalArgumentException( "Error when load extensible interface " + interfaceName + ", must add annotation @Extensible."); } else { this.extensible = extensible; } // 非单例则是空 this.factory = extensible.singleton() ? new ConcurrentHashMap<String, T>() : null; this.all = new ConcurrentHashMap<String, ExtensionClass<T>>(); if (autoLoad) { List<String> paths = RpcConfigs.getListValue(RpcOptions.EXTENSION_LOAD_PATH); for (String path : paths) { loadFromFile(path); } } }
这里有个地方需要注意,autoLoad 属性默认是 ture,也就是默认自动加载。当然,基本上都是自动加载的,这里的参数用于测试用的。
来看这个构造方法。首先是一波赋值操作。
然后检查参数。检查是否是抽象类或者接口,检查是否有 Extensible 注解。
如果是单例,创建一个 Map 保存这个对象,如果不是,Map 就是 null,每次都创建新的。
其中,会有一个 RpcConfigs.getListValue(RpcOptions.EXTENSION_LOAD_PATH)
的操作,用于从获取配置好的路径,通过全局搜索,找到 rpc-config-default.json。包含以下内容:
// 扩展点加载的路径 "extension.load.path": [ "META-INF/services/sofa-rpc/", "META-INF/services/" ],
两个路径。所以返回值是个 List。
for 循环解析 list 中的 path,即调用 loadFromFile 方法。
方法内容如下:
protected synchronized void loadFromFile(String path) { // 默认如果不指定文件名字,就是接口名 String file = StringUtils.isBlank(extensible.file()) ? interfaceName : extensible.file().trim(); String fullFileName = path + file; ClassLoader classLoader = ClassLoaderUtils.getClassLoader(getClass()); loadFromClassLoader(classLoader, fullFileName); }
首先判断注解的 file 属性是否为空,如果是空,则使用接口名,否则使用 file 指定的名称。
然后,将配置文件中 path 和 file 属性拼接。这里其实可以使用 StringBuilder。
然后呢?获取 ClassLoader,默认使用当下线程的 ClassLoader,如果为空,使用当前 ExtensionLoader 的 ClassLoader ,若给定的 class 是空,则使用 SystemClassLoader。
从这里可以看出 SPI 设计的好处,如果使用策略模式实现的话,那么 ClassLoader 必定相同,而类似 SPI 的设计,可以让上层应用和下层应用的 ClassLoader 隔离开来。
拿到 ClassLoader 和 全路径的接口名后,开始加载文件。
代码如下:
protected void loadFromClassLoader(ClassLoader classLoader, String fullFileName) throws Throwable { Enumeration<URL> urls = classLoader != null ? classLoader.getResources(fullFileName) : ClassLoader.getSystemResources(fullFileName); // 可能存在多个文件。 if (urls != null) { while (urls.hasMoreElements()) { // 读取一个文件 URL url = urls.nextElement(); BufferedReader reader = null; try { reader = new BufferedReader(new InputStreamReader(url.openStream(), "UTF-8")); String line; while ((line = reader.readLine()) != null) { readLine(url, line); } } finally { if (reader != null) { reader.close(); } } } } }
首先通过 ClassLoader 获取 classpath 下的文件 URL 集合。然后遍历这些 URL,通过流读取文件,并通过 readLine 方法解析每一行读取出的字符串。这里的字符串就是 SPI 配置文件中的,类似下面的:
文件名称: com.alipay.sofa.rpc.extension.Person
A=com.alipay.sofa.rpc.extension.PersonA
通过加载指定路径 + 接口名(或 Extensible 指定 file),得到文件名,然后读取文件中的文本。由于按行读取,可能读取多次。
然后看 readLine 方法处理解析出来的字符串。
这个方法就比较长了,主要是数据校验,就不贴出来了,说说逻辑。
首先解析该行的数据,parseAliasAndClassName 方法,如果是 # 号,就是注释之类的处理。根据 = 号分割,得到 ClassName,创建一个数据,下标 0 是别名,例如上面的 A,下标 1 是全类名。
使用 Class.forName 反射加载该类。
获取该类的 Extension 注解,
如果没有老的,直接加载新的实现类,创建一个 extensionClass 对象。
如果加载创建成功,检查是否有互斥的扩展点,循环该接口中缓存的所有的实现。
排除扩展
是个别名数组,如果有,循环删除缓存中的 extensionClass。 排除扩展
是否包含当前扩展点,如果包含,就不会放入到缓存中了。 关闭流。
到这里,一个完整的扩展点就加载完毕了!!!
回到 ExtensionLoaderFactory 的 getExtesionLoader 方法,构造方法结束,通过接口名称,成功从SPI 文件中加载了实现类,然后呢?将接口和对应的 ExtensionLoader 对象放入到缓存中,下次使用。
最后,返回 ExtensionLoader 对象。
通常,紧接着就会调用这个对象的 getExtension 方法。类似下面这样的:
Person person = ExtensionLoaderFactory.getExtensionLoader(Person.class).getExtension("A");
通过别名获取实例。
可以猜到,肯定是从这个实例的缓存中获取别名对应的 ExtensionClass 对象。如果没有,则抛出 Not Found 异常.
代码:
public T getExtension(String alias) { ExtensionClass<T> extensionClass = getExtensionClass(alias); if (extensionClass == null) { throw new SofaRpcRuntimeException("Not found extension of " + interfaceName + " named: /"" + alias + "/"!"); } else { if (extensible.singleton() && factory != null) { T t = factory.get(alias); if (t == null) { synchronized (this) { t = factory.get(alias); if (t == null) { t = extensionClass.getExtInstance(); factory.put(alias, t); } } } return t; } else { return extensionClass.getExtInstance(); } } }
如果接口标识是单例的且缓存不是空,则从缓存中取出,这里使用双重检查锁,拿到 ExtensionClass 对象后,对应他的 getExtInstance 方法,方法内容就是使用反射创建一个对象实例。并将别名和对应的对象放入到缓存中。
注意:ExtensionLoader 有 2 个缓存,一个是 ConcurrentHashMap<String, ExtensionClass<T>> all
缓存是别名和对应的 ExtensionClass,表示一个接口可以有多个实现。另一个是 ConcurrentHashMap<String, T>, 这个 Map 保存的是对应别名的单例对象。
如果不是单例的,使用反射创建一个新的。
好了,到这里,一个完整的对象就创建出来了。
借用一下 SOFA 官方对扩展点的介绍:
为了对 SOFARPC 各个环节的都有充足的可扩展性,SOFA-RPC定义了一套十分灵活的扩展机制,所有扩展实现都是平等的。 ========================================================== 这套机制不管是对SOFA-RPC本身的开发者其使用者而言都是非常有用的。SOFA-RPC将其自身抽象为了多个模块,各个模块之间无显式依赖,通过SPI的方式进行交互。
SOFA 的扩展点没有使用 Java 的 SPI ,而是使用了 Java 的设计进行了扩展。比如:
相比较 JDK 的 SPI ,功能强大了太多。值得借鉴。
好了。关于 SOFA 扩展点的设计分析就到这里。