SOFA 源码分析 — 扩展机制

前言

我们在之前的文章中已经稍微了解过 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（）。

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 方法处理解析出来的字符串。

这个方法就比较长了，主要是数据校验，就不贴出来了，说说逻辑。

1. 首先解析该行的数据，parseAliasAndClassName 方法，如果是 # 号，就是注释之类的处理。根据 = 号分割，得到 ClassName，创建一个数据，下标 0 是别名，例如上面的 A，下标 1 是全类名。

2. 使用 Class.forName 反射加载该类。

3. 获取该类的 Extension 注解，

• 如果是 null，抛出异常，
• 如果不是，获取 value 值，value 值不能是空。
• 如果 SPI 文件中没有配置别名，使用注解上的。
• 如果SPI 文件配置了，则校验和注解上的是否一致，
• 如果不一致，抛出异常。
• 如果接口的注解声明需要编码，而实现类没有配置，抛出异常。
• 如果别名是 default 或者 * ，抛出异常。

1. 检查当前系统中，是否已经含有相同的别名的类，注意：这里是一个接口对应一个 Map，因此这里的校验是相对于这个接口，也就是检查当前接口的同名（别名）实现。

• 如果有同名的，且当前实现类扩展 override 是 ture（可以覆盖），且新的实现类的优先级没有老的高，忽略这个新的，反之，加载这个新类。
• 如果当前实现类扩展 不能覆盖，判断，如果旧的实现类扩展可覆盖，且旧优先级大于等于新的。忽略新的，反之，如果旧的扩展类不能覆盖或者优先级小于新的，抛出已存在异常，因为系统不知道该怎么办（新的不能覆盖，老的也不能覆盖且优先级低）。

1. 如果没有老的，直接加载新的实现类，创建一个 extensionClass 对象。

2. 如果加载创建成功，检查是否有互斥的扩展点，循环该接口中缓存的所有的实现。

• 如果当前的实现类的优先级大于等于已存在的，检查新的扩展是否排除老的扩展，这个排除扩展是个别名数组，如果有，循环删除缓存中的 extensionClass。
• 如果当前的实现类的优先级小于已存在的，则检查已存在的排除扩展 是否包含当前扩展点，如果包含，就不会放入到缓存中了。

1. 调用 loadSuccess 方法，将刚刚创建的 extensionClass 和对应的别名放入到 all map 中，也就是缓存中。如果配置了监听器，调用监听器的 onLoad 方法，告知监听器：加载完毕，请指示！

关闭流。

到这里，一个完整的扩展点就加载完毕了！！！

回到 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 扩展点的设计分析就到这里。