dubbo之SPI解析

xiaoxiao2021-02-28  87

一 概述

   一大早来上班,准备写博客,发现前面的文章下有人评价,有点欣喜,有点安慰。算是对我这段时间作品的回报和我前进的动力吧!继续写吧.. 前面阅读dubbo源码经常看到

Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension(); 这种类型的代码来获取一个接口的代理类,比如我这里贴的代码反馈的了一个Protocol接口的代理实现。仔细翻看dubbo中的源码,Protocol接口的实现类有很多种,   那么在程序的执行中怎么得到对应的实现类,怎么去动态的扩展接口实现,这些问题就是今天讨论的重点。

二  什么是SPI技术

         感觉自己的语言描述不是很精准,就不再自己创造了,在网上拷贝了一段描述,讲明了什么是SPI技术,为什么要用SPI,用SPI有什么好处。内如下:  SPI的全名为Service Provider Interface.大多数开发人员可能不熟悉,因为这个是针对厂商或者插件的。在java.util.ServiceLoader的文档里有比较详细的介绍。简单的总结下java spi机制的思想。我们系统里抽象的各个模块,往往有很多不同的实现方案,比如日志模块的方案,xml解析模块、jdbc模块的方案等。面向的对象的设计里,我们一般推荐模块之间基于接口编程,模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类,就违反了可拔插的原则,如果需要替换一种实现,就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明,这就需要一种服务发现机制。 java spi就是提供这样的一个机制:为某个接口寻找服务实现的机制。有点类似IOC的思想,就是将装配的控制权移到程序之外,在模块化设计中这个机制尤其重要,java spi的具体约定为:当服务的提供者,提供了服务接口的一种实现之后,在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候,就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名,并装载实例化,完成模块的注入。 基于这样一个约定就能很好的找到服务接口的实现类,而不需要再代码里制定。jdk提供服务实现查找的一个工具类:java.util.ServiceLoader

三  JDK中的SPI技术

    JDK中拥有SPI的支持,主要涉及java.util.ServiceLoader类的使用,我写了一个小的DEMO让我们初步理解下SPI的使用。首先我写了一个接口代码如下:

package spi; /** * Created by Administrator on 2017/8/28. */ public interface DubboService { public void sayHello(); }

然后写了这个接口的两个实现类

package spi; /** * Created by Administrator on 2017/8/28. */ public class RedService implements DubboService { public void sayHello() { System.out.println("我是RedService服务实现"); } } package spi; /** * Created by Administrator on 2017/8/28. */ public class YellowService implements DubboService { public void sayHello() { System.out.println("我是YellowService服务实现"); } } 然后写了一个main函数类 package spi; import java.util.Iterator; import java.util.ServiceLoader; /** * Created by Administrator on 2017/8/28. */ public class ServiceMain { public static void main(String[] args){ ServiceLoader<DubboService> spiLoader = ServiceLoader.load(DubboService.class); Iterator<DubboService> iteratorSpi=spiLoader.iterator(); while (iteratorSpi.hasNext()){ DubboService dubboService=iteratorSpi.next(); dubboService.sayHello(); } } } 然后在META-INF文件夹下创建了services文件夹,并在services文件夹下创建了一个文件,文件名以接口的全限定名来命名,我这里是spi.DubboService。然后在这个文件中填入这个接口的两个实现类,类中间以换行隔开。到这里所有准备工作已经完成,开始执行ServiceMain的主函数吧! 执行以后输出了日志打印 1.我是RedService服务实现 2.我是YellowService服务实现 分析main函数中的代码,ServiceLoader类是JDK自带的哦!调用load方法即可加载接口参数的所有实现!看到这里是不是在想在META-INF文件夹下创建services/接口全限定名是不是固定写法!好吧,我们跟进到ServiceLoader类中。第一行代码就是private static final String PREFIX = "META-INF/services/"; 是不是立马就明白了ServiceLoader类中已经将配置路径固定好了(如果感兴趣也可以自己写个类来实现ServiceLoader的功能),调用load方法,根据传入的接口参数找到该接口的对应文件,然后一行一行的读取文件中的实现类,使用java反射机制实例化接口的实现对象。到这里SPI技术的原理应该理解了。也可以看看ServiceLoader类的源码能更深入的理解!看看我的目录接口如下图:

新建的spi.DubboService中的内容如下:

四 dubbo中SPI的应用

dubbo框架中大量使用了SPI技术,里面有很多个组件,每个组件在框架中都是以接口的形成抽象出来!具体的实现又分很多种,在程序执行时根据用户的配置来按需取接口的实现。方便了接口的各种实现灵活应用。不过dubbo使用的SPI技术不是源用jdk的实现,但是它们的思想仍然是一样的。我这里仍然以Protocol 协议接口来讲解,还是这段代码

Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension(); 很熟悉吧!开篇就提到过它。 ExtensionLoader类有点类似JDK中的ServiceLoader类,也是用来加载指定路径下的接口实现不过实现别JDK的复杂了很多。首先看ExtensionLoader的静态方法getExtensionLoader。

public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) { if (type == null) throw new IllegalArgumentException("Extension type == null"); if(!type.isInterface()) { throw new IllegalArgumentException("Extension type(" + type + ") is not interface!"); } if(!withExtensionAnnotation(type)) { throw new IllegalArgumentException("Extension type(" + type + ") is not extension, because WITHOUT @" + SPI.class.getSimpleName() + " Annotation!"); } //根据接口对象取ExtensionLoader类 ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type); if (loader == null) { //如果为空保存接口类对应的 新建的ExtensionLoader对象 EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type)); loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type); } return loader; } 1.EXTENSION_LOADERS这个Map中以接口为key,以ExtensionLoader对象为value。 2.判断Map中根据接口get对象,如果没有就new个ExtensionLoader对象保存进去。并返回该ExtensionLoader对象。 3.注意创建ExtensionLoader对象的构造函数代码,将传入的接口type属性赋值给了ExtensionLoader类的type属性 4.创建ExtensionFactory objectFactory对象。怎么创建的,还是那个熟悉的写法,嘿嘿!出现的好频繁哇! private ExtensionLoader(Class<?> type) { this.type = type; objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension()); } 我们继续看getAdaptiveExtension()方法的实现。 /** * 动态生成接口或者点的代理类 */ public T getAdaptiveExtension() { //取里面的Value Object instance = cachedAdaptiveInstance.get(); //为null的处理 if (instance == null) { //判断是否有异常处理 if(createAdaptiveInstanceError == null) { //针对cachedAdaptiveInstance加锁处理 synchronized (cachedAdaptiveInstance) { instance = cachedAdaptiveInstance.get(); if (instance == null) { try { instance = createAdaptiveExtension();//动态生成入口 cachedAdaptiveInstance.set(instance);//设置代理对象到value中 } catch (Throwable t) { createAdaptiveInstanceError = t; throw new IllegalStateException("fail to create adaptive instance: " + t.toString(), t); } } } } else { throw new IllegalStateException("fail to create adaptive instance: " + createAdaptiveInstanceError.toString(), createAdaptiveInstanceError); } } return (T) instance; } 我们重点看createAdaptiveExtension()方法的实现,这里是动态代理生成的入口 private T createAdaptiveExtension() { try { //(T) getAdaptiveExtensionClass().newInstance()创建class对象实例 return injectExtension((T) getAdaptiveExtensionClass().newInstance());//接口的代理实现class创建一个实体对象 } catch (Exception e) { throw new IllegalStateException("Can not create adaptive extenstion " + type + ", cause: " + e.getMessage(), e); } } 我们采用由内到外的顺序来看吧,关注getAdaptiveExtensionClass().newInstance()。 private Class<?> getAdaptiveExtensionClass() { getExtensionClasses();//通过SPI加载接口延伸的所有实现到map中保存 if (cachedAdaptiveClass != null) { return cachedAdaptiveClass; } return cachedAdaptiveClass = createAdaptiveExtensionClass();//动态生成接口的代理实现class对象 } /** * 通过SPI加载当前传入接口延伸的所有实现到map中保存 * @return */ private Map<String, Class<?>> getExtensionClasses() { Map<String, Class<?>> classes = cachedClasses.get(); if (classes == null) { synchronized (cachedClasses) { classes = cachedClasses.get(); if (classes == null) { classes = loadExtensionClasses(); cachedClasses.set(classes); } } } return classes; } //通过SPI加载接口对应的所有实现类 // 此方法已经getExtensionClasses方法同步过。 private Map<String, Class<?>> loadExtensionClasses() { //解析type接口上的SPI注解 final SPI defaultAnnotation = type.getAnnotation(SPI.class); if(defaultAnnotation != null) { //获取注解标记值 String value = defaultAnnotation.value(); if(value != null && (value = value.trim()).length() > 0) { String[] names = NAME_SEPARATOR.split(value); if(names.length > 1) { throw new IllegalStateException("more than 1 default extension name on extension " + type.getName() + ": " + Arrays.toString(names)); } if(names.length == 1) cachedDefaultName = names[0]; } } Map<String, Class<?>> extensionClasses = new HashMap<String, Class<?>>(); loadFile(extensionClasses, DUBBO_INTERNAL_DIRECTORY); loadFile(extensionClasses, DUBBO_DIRECTORY); loadFile(extensionClasses, SERVICES_DIRECTORY); return extensionClasses; } private void loadFile(Map<String, Class<?>> extensionClasses, String dir) { String fileName = dir + type.getName(); try { Enumeration<java.net.URL> urls; ClassLoader classLoader = findClassLoader(); if (classLoader != null) { urls = classLoader.getResources(fileName); } else { urls = ClassLoader.getSystemResources(fileName); } if (urls != null) { while (urls.hasMoreElements()) { java.net.URL url = urls.nextElement(); try { BufferedReader reader = new BufferedReader(new InputStreamReader(url.openStream(), "utf-8")); try { String line = null; while ((line = reader.readLine()) != null) { final int ci = line.indexOf('#'); if (ci >= 0) line = line.substring(0, ci); line = line.trim(); if (line.length() > 0) { try { String name = null; int i = line.indexOf('='); if (i > 0) { name = line.substring(0, i).trim(); line = line.substring(i + 1).trim(); } if (line.length() > 0) { Class<?> clazz = Class.forName(line, true, classLoader); //判断type接口是clazz类的接口 if (! type.isAssignableFrom(clazz)) { throw new IllegalStateException("Error when load extension class(interface: " + type + ", class line: " + clazz.getName() + "), class " + clazz.getName() + "is not subtype of interface."); } //判断接口实现类是否标注了该注解 if (clazz.isAnnotationPresent(Adaptive.class)) { if(cachedAdaptiveClass == null) { cachedAdaptiveClass = clazz; } else if (! cachedAdaptiveClass.equals(clazz)) { throw new IllegalStateException("More than 1 adaptive class found: " + cachedAdaptiveClass.getClass().getName() + ", " + clazz.getClass().getName()); } } else { try { clazz.getConstructor(type); Set<Class<?>> wrappers = cachedWrapperClasses; if (wrappers == null) { cachedWrapperClasses = new ConcurrentHashSet<Class<?>>(); wrappers = cachedWrapperClasses; } wrappers.add(clazz); } catch (NoSuchMethodException e) { clazz.getConstructor(); if (name == null || name.length() == 0) { name = findAnnotationName(clazz); if (name == null || name.length() == 0) { if (clazz.getSimpleName().length() > type.getSimpleName().length() && clazz.getSimpleName().endsWith(type.getSimpleName())) { name = clazz.getSimpleName().substring(0, clazz.getSimpleName().length() - type.getSimpleName().length()).toLowerCase(); } else { throw new IllegalStateException("No such extension name for the class " + clazz.getName() + " in the config " + url); } } } String[] names = NAME_SEPARATOR.split(name); if (names != null && names.length > 0) { Activate activate = clazz.getAnnotation(Activate.class); if (activate != null) { cachedActivates.put(names[0], activate); } for (String n : names) { if (! cachedNames.containsKey(clazz)) { cachedNames.put(clazz, n); } Class<?> c = extensionClasses.get(n); if (c == null) { extensionClasses.put(n, clazz); } else if (c != clazz) { throw new IllegalStateException("Duplicate extension " + type.getName() + " name " + n + " on " + c.getName() + " and " + clazz.getName()); } } } } } } } catch (Throwable t) { IllegalStateException e = new IllegalStateException("Failed to load extension class(interface: " + type + ", class line: " + line + ") in " + url + ", cause: " + t.getMessage(), t); exceptions.put(line, e); } } } // end of while read lines } finally { reader.close(); } } catch (Throwable t) { logger.error("Exception when load extension class(interface: " + type + ", class file: " + url + ") in " + url, t); } } // end of while urls } } catch (Throwable t) { logger.error("Exception when load extension class(interface: " + type + ", description file: " + fileName + ").", t); } } 一下子罗列了好几段代码,看着比较多。其实还是比较好理解的。主要做了以下几件事情: 1.loadExtensionClasses方法判断ExtensionLoader类中的传入的type接口是否标注了SPI注解,并获取SPI注解的值,这个值为接口的默认实现标记。 2.loadFile方法用来加载配置路径下的接口的实现类。比如在调用loadFile方法时,传入的参数DUBBO_INTERNAL_DIRECTORY,DUBBO_DIRECTORY,SERVICES_DIRECTORY。他们都描述了接口实现类配置文件路径,看看3个属性的值如下: private static final String SERVICES_DIRECTORY = "META-INF/services/"; private static final String DUBBO_DIRECTORY = "META-INF/dubbo/"; private static final String DUBBO_INTERNAL_DIRECTORY = DUBBO_DIRECTORY + "internal/";

是不是感觉跟JDK里面SPI技术路径描述很类型。讲到这里我们来看看dubbo框架的接口实现配置是怎么玩的,这里我就以com.alibaba.dubbo.rpc.Protocol接口来研究!哟!是不是感觉跟JDK里面配置不太一样,它按照key=value的形式来保存的,在分析下loadFile方法中的代码,它也是按照key=value的格式来解析出接口的具体实现,将最终解析的数据保存到了传入的map参数extensionClasses中。大家应该感到好奇为什么要做个key=value的配置。打个比方Protocol协议接口在dubbo框架里实现有hession,http,rmi,webservice,dubbo等好几种实现,在程序运行中我们根据配置来使用具体的协议,比方我要使用rmi协议,那我就配置rmi,我想使用dubbo 我就配置dubbo。配置好以后会根据这个属性配置取找相关的具体协议实现。所以这里的key=value应该就是做这个事情的。我这里贴几张图看看Protocol接口的实现配置,图下几个图:

rmi协议实现:

hession协议实现:

dubbo协议实现,也就是默认的协议:

我们再次回到getAdaptiveExtensionClass方法中。继续看createAdaptiveExtensionClass方法

private Class<?> createAdaptiveExtensionClass() { String code = createAdaptiveExtensionClassCode();//创建接口的代理类实现 ClassLoader classLoader = findClassLoader();//获取当前使用的类加载器 com.alibaba.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();//获取代码编译器 return compiler.compile(code, classLoader);//加载代理 } 由于createAdaptiveExtensionClassCode方法的代码太长了,我就不贴出来啦。主要就是根据JAVA的反射机制去读出接口中的所有方法,形成该接口的代理。注意createAdaptiveExtensionClassCode方法返回的是字符串,这个字符串保存了代理类的动态生成的代码。然后经过编译加载到虚拟机中。我抓取了一个Protocol接口的代理类代码如下: //动态生成的协议代理类 public class Protocol$Adpative implements com.alibaba.dubbo.rpc.Protocol { public void destroy() {throw new UnsupportedOperationException("method public abstract void com.alibaba.dubbo.rpc.Protocol.destroy() of interface com.alibaba.dubbo.rpc.Protocol is not adaptive method!"); } public int getDefaultPort() {throw new UnsupportedOperationException("method public abstract int com.alibaba.dubbo.rpc.Protocol.getDefaultPort() of interface com.alibaba.dubbo.rpc.Protocol is not adaptive method!"); } public com.alibaba.dubbo.rpc.Exporter export(com.alibaba.dubbo.rpc.Invoker arg0) throws com.alibaba.dubbo.rpc.RpcException { if (arg0 == null) throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument == null"); if (arg0.getUrl() == null) throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument getUrl() == null"); com.alibaba.dubbo.common.URL url = arg0.getUrl(); //默认选择dubbo协议,否则根据url中带的协议属性来选择对应的协议处理对象,这样可以动态选择不同的协议 String extName = ( url.getProtocol() == null ? "dubbo" : url.getProtocol() ); if(extName == null) throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" + url.toString() + ") use keys([protocol])"); //根据拿到的协议key从缓存的map中取协议对象 com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol)ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName); return extension.export(arg0); } public com.alibaba.dubbo.rpc.Invoker refer(java.lang.Class arg0, com.alibaba.dubbo.common.URL arg1) throws com.alibaba.dubbo.rpc.RpcException { if (arg1 == null) throw new IllegalArgumentException("url == null"); com.alibaba.dubbo.common.URL url = arg1; String extName = ( url.getProtocol() == null ? "dubbo" : url.getProtocol() ); if(extName == null) throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" + url.toString() + ") use keys([protocol])"); //根据拿到的协议key从缓存的map中取协议对象 com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol)ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName); return extension.refer(arg0, arg1); } } 到这里接口的代理已经生成啦!我再回退到createAdaptiveExtension方法中。 injectExtension((T) getAdaptiveExtensionClass().newInstance()); getAdaptiveExtensionClass().newInstance()创建了这个接口代理类的实例,并传入到injectExtension方法中 private T injectExtension(T instance) { try { if (objectFactory != null) { for (Method method : instance.getClass().getMethods()) { if (method.getName().startsWith("set") && method.getParameterTypes().length == 1 && Modifier.isPublic(method.getModifiers())) { Class<?> pt = method.getParameterTypes()[0]; try { String property = method.getName().length() > 3 ? method.getName().substring(3, 4).toLowerCase() + method.getName().substring(4) : ""; Object object = objectFactory.getExtension(pt, property); if (object != null) { method.invoke(instance, object); } } catch (Exception e) { logger.error("fail to inject via method " + method.getName() + " of interface " + type.getName() + ": " + e.getMessage(), e); } } } } } catch (Exception e) { logger.error(e.getMessage(), e); } return instance; }

貌似没做什么太多的操作,只是利用反射机制判断接口代理类中是否有需要注入的属性。然后就结束啦!我们再次回退到getAdaptiveExtension方法中,最终反馈的就是该接口的代理实现。是不是有点疑惑,看了这么半天

Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

代码只是反馈了接口的代理,那我在实际使用中怎么得到接口的具体实现呢?

额! 在仔细看看Protocol接口代理的具体实现,在使用接口代理中的方法时,都会根据URL来确定接口的具体实现,因为URL中携带了用户大部分的参数配置,根据里面的属性来获取。里面关键代码 com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol)ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName); 参数extName就是用户配置的协议参数。 /** * 返回指定名字的扩展。如果指定名字的扩展不存在,则抛异常 {@link IllegalStateException}. * * @param name * @return */ @SuppressWarnings("unchecked") public T getExtension(String name) { if (name == null || name.length() == 0) throw new IllegalArgumentException("Extension name == null"); if ("true".equals(name)) { return getDefaultExtension(); } //根据传入的name参数确定接口的具体实现类 Holder<Object> holder = cachedInstances.get(name); if (holder == null) { cachedInstances.putIfAbsent(name, new Holder<Object>()); holder = cachedInstances.get(name); } //判断接口实现类是否存在 Object instance = holder.get(); if (instance == null) { synchronized (holder) { instance = holder.get(); if (instance == null) { //不存在那么创建一个接口实现类 instance = createExtension(name); holder.set(instance); } } } return (T) instance; } private T createExtension(String name) { //根据参数获取接口的Class对象 Class<?> clazz = getExtensionClasses().get(name); if (clazz == null) { throw findException(name); } try { //判断Map中是否存在改Class的实例 T instance = (T) EXTENSION_INSTANCES.get(clazz); if (instance == null) { //创建一个实例并保存到map中 EXTENSION_INSTANCES.putIfAbsent(clazz, (T) clazz.newInstance()); instance = (T) EXTENSION_INSTANCES.get(clazz); } //注入属性到实例中 injectExtension(instance); Set<Class<?>> wrapperClasses = cachedWrapperClasses; if (wrapperClasses != null && wrapperClasses.size() > 0) { for (Class<?> wrapperClass : wrapperClasses) { instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance)); } } return instance; } catch (Throwable t) { throw new IllegalStateException("Extension instance(name: " + name + ", class: " + type + ") could not be instantiated: " + t.getMessage(), t); } }

看到这里思路应该比较清晰了!所有的接口代理中,并没有给定具体的实现,全部根据用户的参数配置来动态创建接口的具体实现。这样做让程序非常的灵活,让接口的实现插拔更加方便。如果想增加一个接口的实现,只需要按照SPI的配置方式增加配置文件,xml标签配置指定新接口实现的标记即可。

五 总结

终于写完了,累死宝宝了!  从分析中,接口代理的生成是不是有点动态代理的感觉。然后用户在XML中配置的dubbo标签属性都保存在了URL中,URL携带的参数贯穿了整个dubbo架构,所有的组件调用都根据URL中配置的参数做处理。其实SPI技术在很多地方都有用到,比如数据库的驱动,日志的处理,原理不是很复杂,仔细研究下就明白了。

转载请注明原文地址: https://www.6miu.com/read-50106.html

最新回复(0)