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 方法处理解析出来的字符串。
这个方法就比较长了,主要是数据校验,就不贴出来了,说说逻辑。
首先解析该行的数据,parseAliasAndClassName 方法,如果是 # 号,就是注释之类的处理。根据 = 号分割,得到 ClassName,创建一个数据,下标 0 是别名,例如上面的 A,下标 1 是全类名。
使用 Class.forName 反射加载该类。
获取该类的 Extension 注解,
- 如果是 null,抛出异常,
- 如果不是,获取 value 值,value 值不能是空。
- 如果 SPI 文件中没有配置别名,使用注解上的。
- 如果SPI 文件配置了,则校验和注解上的是否一致,
- 如果不一致,抛出异常。
- 如果接口的注解声明需要编码,而实现类没有配置,抛出异常。
- 如果别名是 default 或者 * ,抛出异常。
- 检查当前系统中,是否已经含有相同的别名的类,注意:这里是一个接口对应一个 Map,因此这里的校验是相对于这个接口,也就是检查当前接口的同名(别名)实现。
- 如果有同名的,且当前实现类扩展 override 是 ture(可以覆盖),且新的实现类的优先级没有老的高,忽略这个新的,反之,加载这个新类。
- 如果当前实现类扩展 不能覆盖,判断,如果旧的实现类扩展可覆盖,且旧优先级大于等于新的。忽略新的,反之,如果旧的扩展类不能覆盖或者优先级小于新的,抛出已存在异常,因为系统不知道该怎么办(新的不能覆盖,老的也不能覆盖且优先级低)。
如果没有老的,直接加载新的实现类,创建一个 extensionClass 对象。
如果加载创建成功,检查是否有互斥的扩展点,循环该接口中缓存的所有的实现。
- 如果当前的实现类的优先级大于等于已存在的,检查新的扩展是否排除老的扩展,这个
排除扩展
是个别名数组,如果有,循环删除缓存中的 extensionClass。 - 如果当前的实现类的优先级小于已存在的,则检查已存在的
排除扩展
是否包含当前扩展点,如果包含,就不会放入到缓存中了。
- 调用 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 扩展点的设计分析就到这里。
SOFA 源码分析 — 扩展机制的更多相关文章
- SOFA 源码分析 —— 服务引用过程
前言 在前面的 SOFA 源码分析 -- 服务发布过程 文章中,我们分析了 SOFA 的服务发布过程,一个完整的 RPC 除了发布服务,当然还需要引用服务. So,今天就一起来看看 SOFA 是如何引 ...
- springMVC源码分析--异常处理机制HandlerExceptionResolver执行原理(二)
上一篇博客springMVC源码分析--异常处理机制HandlerExceptionResolver简单示例(一)中我们简单地实现了一个异常处理实例,接下来我们要介绍一下HandlerExceptio ...
- MyBatis 源码分析 - 插件机制
1.简介 一般情况下,开源框架都会提供插件或其他形式的拓展点,供开发者自行拓展.这样的好处是显而易见的,一是增加了框架的灵活性.二是开发者可以结合实际需求,对框架进行拓展,使其能够更好的工作.以 My ...
- 鸿蒙内核源码分析(调度机制篇) | 任务是如何被调度执行的 | 百篇博客分析OpenHarmony源码 | v7.07
百篇博客系列篇.本篇为: v07.xx 鸿蒙内核源码分析(调度机制篇) | 任务是如何被调度执行的 | 51.c.h .o 任务管理相关篇为: v03.xx 鸿蒙内核源码分析(时钟任务篇) | 触发调 ...
- SOFA 源码分析 — 自动故障剔除
前言 集群中通常一个服务有多个服务提供者.其中部分服务提供者可能由于网络,配置,长时间 fullgc ,线程池满,硬件故障等导致长连接还存活但是程序已经无法正常响应.单机故障剔除功能会将这部分异常的服 ...
- SOFA 源码分析 — 调用方式
前言 SOFARPC 提供了多种调用方式满足不同的场景. 例如,同步阻塞调用:异步 future 调用,Callback 回调调用,Oneway 调用. 每种调用模式都有对应的场景.类似于单进程中的调 ...
- SOFA 源码分析 — 预热权重
前言 SOFA-RPC 支持根据权重对服务进行预热功能,具体地址:预热权重. 引用官方文档: 预热权重功能让客户端机器能够根据服务端的相应权重进行流量的分发.该功能也常被用于集群内少数机器的启动场景. ...
- SOFA 源码分析— 事件总线
前言 大部分框架都是事件订阅功能,即观察者模式,或者叫事件机制.通过订阅某个事件,当触发事件时,回调某个方法.该功能非常的好用,而 SOFA 内部也设计了这个功能,并且内部大量使用了该功能.来看看是如 ...
- SOFA 源码分析 —— 服务发布过程
前言 SOFA 包含了 RPC 框架,底层通信框架是 bolt ,基于 Netty 4,今天将通过 SOFA-RPC 源码中的例子,看看他是如何发布一个服务的. 示例代码 下面的代码在 com.ali ...
随机推荐
- android的PackageManagerService详解
PackageManagerService主要是一个包的管理服务,在开机的时候会解析以前保存的一些安装包的相关数据,android运行过程中新安装的apk也会保存到PackageManagerServ ...
- 显示 Ubuntu 11.10 的 终端窗口
显示 Ubuntu 11.10 的 终端窗口 一.点击左上角的图标 -> 在search框里搜索termial . 二.快捷键:Ctrl+Alt+t.
- 谈谈Ext JS的组件——组件基类:Ext.Component
概述 Ext.Component是所有Ext组件的基类,这在Ext.Component的API中第一句话就提到了.然后第二段说明了它包含的基本功能:隐藏/显示.启用/禁用以及尺寸控制等.除了以上这些基 ...
- 12.1、Libgdx的图像之持续性和非持续性渲染
(官网:www.libgdx.cn) Libgdx在默认情况下,渲染现成调用render()方法进行持续性渲染.频率取决于你的硬件设备. 有时候有些游戏中并不需要持续性的渲染,为了省电,可以关掉持续性 ...
- maven settings 配置文件
maven settings 配置文件 <?xml version="1.0" encoding="UTF-8"?> <settings xm ...
- Linux管道编程实例
/*管道 可以把管道想象为两个实体之间的单向连接器.注意,管道是半双工的, 如果需要全双工通讯,应该转而考虑套接字. 匿名管道又称管道,提供了一个进程与它的兄弟进程通讯的方法,只存在于父进程中: 命名 ...
- libevent之Reactor模式
通过前边的一篇博文轻量级网络库libevent初探,我们知道libevent实际上是封装了不同操作系统下的/dev/poll.kqueue.event ports.select.poll和epoll事 ...
- Android listView异步下载和convertView复用产生的错位问题
1:Item图片显示重复 这个显示重复是指当前行Item显示了之前某行Item的图片. 比如ListView滑动到第2行会异步加载某个图片,但是加载很慢,加载过程中ListView已经滑动到了第14行 ...
- 【面试笔试算法】Program 5 : 推箱子 (网易游戏笔试题)
时间限制:10000ms 单点时限:1000ms 内存限制:256MB 描述 推箱子是一款经典游戏.如图所示,灰色格子代表不能通过区域,蓝色方格是箱子,黑色圆形代表玩家,含有圆点的格子代表目标点. 规 ...
- Android ORM 框架之 greenDAO
前言 我相信,在平时的开发过程中,大家一定会或多或少地接触到 SQLite.然而在使用它时,我们往往需要做许多额外的工作,像编写 SQL 语句与解析查询结果等.所以,适用于 Android 的ORM ...