Par exemple, nous avons maintenant conçu un nouveau framework de journalisation : 「super-logger」. Par défaut, le fichier XML est utilisé comme fichier de configuration de notre journal, et une interface pour l'analyse du fichier de configuration est conçue :
package com.github.kongwu.spisamples;
public interface SuperLoggerConfiguration {
void configure(String configFile);
}Ensuite, un XML par défaut Implémentation :
package com.github.kongwu.spisamples;
public class XMLConfiguration implements SuperLoggerConfiguration{
public void configure(String configFile){
......
}
}Ensuite, lorsque nous initialisons et analysons la configuration, il nous suffit d'appeler cette XMLConfiguration pour analyser le fichier de configuration XML
package com.github.kongwu.spisamples;
public class LoggerFactory {
static {
SuperLoggerConfiguration configuration = new XMLConfiguration();
configuration.configure(configFile);
}
public static getLogger(Class clazz){
......
}
}Ceci complète un le modèle de base semble bien. Cependant, l'évolutivité n'est pas très bonne, car si je souhaite personnaliser/étendre/réécrire la fonction d'analyse, je dois redéfinir le code d'entrée et réécrire le LoggerFactory. Ce n'est pas assez flexible et trop intrusif.
Par exemple, si l'utilisateur souhaite maintenant ajouter un fichier yml en tant que fichier de configuration du journal, il lui suffit alors de créer un nouveau YAMLConfiguration et d'implémenter SuperLoggerConfiguration. Mais... comment l'injecter, comment utiliser la configuration YAML nouvellement créée dans LoggerFactory ? Est-il possible que même LoggerFactory ait été réécrit ?
Si vous utilisez le mécanisme SPI, cette affaire sera très simple et la fonction d'expansion de cette entrée pourra être facilement complétée.
Voyons d'abord comment utiliser le mécanisme SPI du JDK pour résoudre le problème d'évolutivité ci-dessus.
JDK fournit une fonction SPI et la classe principale est java.util.ServiceLoader. Sa fonction est d'obtenir plusieurs fichiers d'implémentation de configuration sous "META-INF/services/" via le nom de la classe.
Afin de résoudre le problème d'expansion ci-dessus, nous créons maintenant un com.github.kongwu.spisamples.SuperLoggerConfiguration sous META-INF/services/</code > fichier (sans suffixe). Il n'y a qu'une seule ligne de code dans le fichier, qui est notre <code>com.github.kongwu.spisamples.XMLConfiguration par défaut (notez que plusieurs implémentations peuvent également être écrites dans un seul fichier, séparées par des retours chariot) # 🎜🎜#
META-INF/services/com.github.kongwu.spisamples.SuperLoggerConfiguration: com.github.kongwu.spisamples.XMLConfiguration
META-INF/services/下创建一个com.github.kongwu.spisamples.SuperLoggerConfiguration文件（没有后缀）。文件中只有一行代码，那就是我们默认的com.github.kongwu.spisamples.XMLConfiguration（注意，一个文件里也可以写多个实现，回车分隔）ServiceLoader<SuperLoggerConfiguration> serviceLoader = ServiceLoader.load(SuperLoggerConfiguration.class);
Iterator<SuperLoggerConfiguration> iterator = serviceLoader.iterator();
SuperLoggerConfiguration configuration;
while(iterator.hasNext()) {
//加载并初始化实现类
configuration = iterator.next();
}
//对最后一个configuration类调用configure方法
configuration.configure(configFile);然后通过 ServiceLoader 获取我们的 SPI 机制配置的实现类：
package com.github.kongwu.spisamples;
public class LoggerFactory {
static {
ServiceLoader<SuperLoggerConfiguration> serviceLoader = ServiceLoader.load(SuperLoggerConfiguration.class);
Iterator<SuperLoggerConfiguration> iterator = serviceLoader.iterator();
SuperLoggerConfiguration configuration;
while(iterator.hasNext()) {
configuration = iterator.next();//加载并初始化实现类
}
configuration.configure(configFile);
}
public static getLogger(Class clazz){
......
}
}最后在调整LoggerFactory中初始化配置的方式为现在的SPI方式：
META-INF/services/com.github.kongwu.spisamples.SuperLoggerConfiguration: com.github.kongwu.spisamples.ext.YAMLConfiguration
「等等，这里为什么是用 iterator ? 而不是get之类的只获取一个实例的方法？」
试想一下，如果是一个固定的get方法，那么get到的是一个固定的实例，SPI 还有什么意义呢？
SPI 的目的，就是增强扩展性。将固定的配置提取出来，通过 SPI 机制来配置。那既然如此，一般都会有一个默认的配置，然后通过 SPI 的文件配置不同的实现，这样就会存在一个接口多个实现的问题。要是找到多个实现的话，用哪个实现作为最后的实例呢？
所以这里使用iterator来获取所有的实现类配置。刚才已经在我们这个 「super-logger」 包里增加了默认的SuperLoggerConfiguration 实现。
为了支持 YAML 配置，现在在使用方/用户的代码里，增加一个YAMLConfiguration的 SPI 配置：
java -cp super-logger.jar:a.jar:b.jar:main.jar example.Main
此时通过iterator方法，就会获取到默认的XMLConfiguration和我们扩展的这个YAMLConfiguration两个配置实现类了。
在上面那段加载的代码里，我们遍历iterator，遍历到最后，我们**使用最后一个实现配置作为最终的实例。
「再等等？最后一个？怎么算最后一个？」
使用方/用户自定义的的这个 YAMLConfiguration 一定是最后一个吗？
这个真的不一定，取决于我们运行时的 ClassPath 配置，在前面加载的jar自然在前，最后的jar里的自然当然也在后面。所以「如果用户的包在ClassPath中的顺序比super-logger的包更靠后，才会处于最后一个位置；如果用户的包位置在前，那么所谓的最后一个仍然是默认的XMLConfiguration。」
举个栗子，如果我们程序的启动脚本为：
java -cp main.jar:super-logger.jar:a.jar:b.jar example.Main
默认的XMLConfiguration SPI配置在super-logger.jar，扩展的YAMLConfiguration SPI配置文件在main.jarEnsuite, récupérez la classe d'implémentation de la configuration de notre mécanisme SPI via ServiceLoader :
optimusPrime = org.apache.spi.OptimusPrime bumblebee = org.apache.spi.Bumblebee
Enfin, ajustez la manière d'initialiser la configuration dans LoggerFactory à la méthode SPI actuelle :
@SPI
public interface Robot {
void sayHello();
}
public class OptimusPrime implements Robot {
@Override
public void sayHello(){
System.out.println("Hello, I am Optimus Prime.");
}
}
public class Bumblebee implements Robot {
@Override
public void sayHello(){
System.out.println("Hello, I am Bumblebee.");
}
}
public class DubboSPITest {
@Test
public void sayHello() throws Exception {
ExtensionLoader<Robot> extensionLoader =
ExtensionLoader.getExtensionLoader(Robot.class);
Robot optimusPrime = extensionLoader.getExtension("optimusPrime");
optimusPrime.sayHello();
Robot bumblebee = extensionLoader.getExtension("bumblebee");
bumblebee.sayHello();
}
}"Attendez, pourquoi l'itérateur est-il utilisé ici ? Au lieu d'une méthode comme get qui n'obtient qu'une seule instance ?" ##🎜🎜 #Imaginez, s'il s'agit d'une méthode get fixe, alors ce qui est obtenu est une instance fixe. Quelle est la signification de SPI ?
Le but de SPI est d'améliorer l'évolutivité. Extrayez la configuration fixe et configurez-la via le mécanisme SPI. Dans ce cas, il existe généralement une configuration par défaut, puis différentes implémentations sont configurées via des fichiers SPI, il y aura donc un problème de plusieurs implémentations d'une même interface. Si plusieurs implémentations sont trouvées, quelle implémentation est utilisée comme instance finale ? #🎜🎜##🎜🎜#L'itérateur est donc utilisé ici pour obtenir toutes les configurations de classe d'implémentation. L'implémentation par défaut de SuperLoggerConfiguration vient d'être ajoutée à notre package #🎜🎜#『super-logger』#🎜🎜#. #🎜🎜##🎜🎜##🎜🎜#Afin de prendre en charge la configuration YAML, ajoutez maintenant une configuration YAMLConfiguration SPI dans le code utilisateur/utilisateur : #🎜🎜##🎜🎜#@SPI("dubbo")
public interface Protocol {
......
}filter=com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper listener=com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper mock=com.alibaba.dubbo.rpc.support.MockProtocol dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol injvm=com.alibaba.dubbo.rpc.protocol.injvm.InjvmProtocol rmi=com.alibaba.dubbo.rpc.protocol.rmi.RmiProtocol hessian=com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol com.alibaba.dubbo.rpc.protocol.http.HttpProtocol com.alibaba.dubbo.rpc.protocol.webservice.WebServiceProtocol thrift=com.alibaba.dubbo.rpc.protocol.thrift.ThriftProtocol memcached=com.alibaba.dubbo.rpc.protocol.memcached.MemcachedProtocol redis=com.alibaba.dubbo.rpc.protocol.redis.RedisProtocol rest=com.alibaba.dubbo.rpc.protocol.rest.RestProtocol registry=com.alibaba.dubbo.registry.integration.RegistryProtocol qos=com.alibaba.dubbo.qos.protocol.QosProtocolWrapper
main.jar, alors le dernier élément obtenu par l'itérateur doit être YAMLConfiguration. #🎜🎜##🎜🎜#Mais que se passe-t-il si l'ordre des chemins de classe est inversé ? main.jar est devant, super-logger.jar est à l'arrière #🎜🎜#Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getDefaultExtension(); //protocol: DubboProtocol
Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。如果大家想要学习 Dubbo 的源码，SPI 机制务必弄懂。接下来，我们先来了解一下 Java SPI 与 Dubbo SPI 的用法，然后再来分析 Dubbo SPI 的源码。
Dubbo 中实现了一套新的 SPI 机制，功能更强大，也更复杂一些。相关逻辑被封装在了 ExtensionLoader 类中，通过 ExtensionLoader，我们可以加载指定的实现类。Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下，配置内容如下（以下demo来自dubbo官方文档）。
optimusPrime = org.apache.spi.OptimusPrime bumblebee = org.apache.spi.Bumblebee
与 Java SPI 实现类配置不同，Dubbo SPI 是通过键值对的方式进行配置，这样我们可以按需加载指定的实现类。另外在使用时还需要在接口上标注 @SPI 注解。
下面来演示 Dubbo SPI 的用法：
@SPI
public interface Robot {
void sayHello();
}
public class OptimusPrime implements Robot {
@Override
public void sayHello(){
System.out.println("Hello, I am Optimus Prime.");
}
}
public class Bumblebee implements Robot {
@Override
public void sayHello(){
System.out.println("Hello, I am Bumblebee.");
}
}
public class DubboSPITest {
@Test
public void sayHello() throws Exception {
ExtensionLoader<Robot> extensionLoader =
ExtensionLoader.getExtensionLoader(Robot.class);
Robot optimusPrime = extensionLoader.getExtension("optimusPrime");
optimusPrime.sayHello();
Robot bumblebee = extensionLoader.getExtension("bumblebee");
bumblebee.sayHello();
}
}「Dubbo SPI 和 JDK SPI 最大的区别就在于支持“别名”」，可以通过某个扩展点的别名来获取固定的扩展点。就像上面的例子中，我可以获取 Robot 多个 SPI 实现中别名为“optimusPrime”的实现，也可以获取别名为“bumblebee”的实现，这个功能非常有用！
通过 @SPI 注解的 value 属性，还可以默认一个“别名”的实现。比如在Dubbo 中，默认的是Dubbo 私有协议：「dubbo protocol - dubbo://」**
来看看Dubbo中协议的接口：
@SPI("dubbo")
public interface Protocol {
......
}在 Protocol 接口上，增加了一个 @SPI 注解，而注解的 value 值为 Dubbo ，通过 SPI 获取实现时就会获取 Protocol SPI 配置中别名为dubbo的那个实现，com.alibaba.dubbo.rpc.Protocol文件如下：
filter=com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper listener=com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper mock=com.alibaba.dubbo.rpc.support.MockProtocol dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol injvm=com.alibaba.dubbo.rpc.protocol.injvm.InjvmProtocol rmi=com.alibaba.dubbo.rpc.protocol.rmi.RmiProtocol hessian=com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol com.alibaba.dubbo.rpc.protocol.http.HttpProtocol com.alibaba.dubbo.rpc.protocol.webservice.WebServiceProtocol thrift=com.alibaba.dubbo.rpc.protocol.thrift.ThriftProtocol memcached=com.alibaba.dubbo.rpc.protocol.memcached.MemcachedProtocol redis=com.alibaba.dubbo.rpc.protocol.redis.RedisProtocol rest=com.alibaba.dubbo.rpc.protocol.rest.RestProtocol registry=com.alibaba.dubbo.registry.integration.RegistryProtocol qos=com.alibaba.dubbo.qos.protocol.QosProtocolWrapper
然后只需要通过getDefaultExtension，就可以获取到 @SPI 注解上value对应的那个扩展实现了
Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getDefaultExtension(); //protocol: DubboProtocol
还有一个 Adaptive 的机制，虽然非常灵活，但……用法并不是很“优雅”，这里就不介绍了
Dubbo 的 SPI 中还有一个“加载优先级”，优先加载内置（internal）的，然后加载外部的（external），按优先级顺序加载，「如果遇到重复就跳过不会加载」了。
所以如果想靠classpath加载顺序去覆盖内置的扩展，也是个不太理智的做法，原因同上 - 加载顺序不严谨
Spring 的 SPI 配置文件是一个固定的文件 - META-INF/spring.factories，功能上和 JDK 的类似，每个接口可以有多个扩展实现，使用起来非常简单：
//获取所有factories文件中配置的LoggingSystemFactory List<LoggingSystemFactory>> factories = SpringFactoriesLoader.loadFactories(LoggingSystemFactory.class, classLoader);
下面是一段 Spring Boot 中 spring.factories 的配置
# Logging Systems org.springframework.boot.logging.LoggingSystemFactory=\ org.springframework.boot.logging.logback.LogbackLoggingSystem.Factory,\ org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.Factory,\ org.springframework.boot.logging.java.JavaLoggingSystem.Factory # PropertySource Loaders org.springframework.boot.env.PropertySourceLoader=\ org.springframework.boot.env.PropertiesPropertySourceLoader,\ org.springframework.boot.env.YamlPropertySourceLoader # ConfigData Location Resolvers org.springframework.boot.context.config.ConfigDataLocationResolver=\ org.springframework.boot.context.config.ConfigTreeConfigDataLocationResolver,\ org.springframework.boot.context.config.StandardConfigDataLocationResolver ......
Spring SPI 中，将所有的配置放到一个固定的文件中，省去了配置一大堆文件的麻烦。至于多个接口的扩展配置，是用一个文件好，还是每个单独一个文件好这个，这个问题就见仁见智了（个人喜欢 Spring 这种，干净利落）。
Spring的SPI 虽然属于spring-framework(core)，但是目前主要用在spring boot中……
和前面两种 SPI 机制一样，Spring 也是支持 ClassPath 中存在多个 spring.factories 文件的，加载时会按照 classpath 的顺序依次加载这些 spring.factories 文件，添加到一个 ArrayList 中。由于没有别名，所以也没有去重的概念，有多少就添加多少。
但由于 Spring 的 SPI 主要用在 Spring Boot 中，而 Spring Boot 中的 ClassLoader 会优先加载项目中的文件，而不是依赖包中的文件。所以如果在你的项目中定义个spring.factories文件，那么你项目中的文件会被第一个加载，得到的Factories中，项目中spring.factories里配置的那个实现类也会排在第一个
如果我们要扩展某个接口的话，只需要在你的项目（spring boot）里新建一个META-INF/spring.factories文件，「只添加你要的那个配置，不要完整的复制一遍 Spring Boot 的 spring.factories 文件然后修改」**
比如我只想添加一个新的 LoggingSystemFactory 实现，那么我只需要新建一个META-INF/spring.factories文件，而不是完整的复制+修改：
org.springframework.boot.logging.LoggingSystemFactory=\ com.example.log4j2demo.Log4J2LoggingSystem.Factory
JDK SPI
DUBBO SPI
Spring SPI
文件方式 |
每个扩展点单独一个文件 |
每个扩展点单独一个文件 |
所有的扩展点在一个文件 |
获取某个固定的实现 |
Non pris en charge, vous ne pouvez obtenir toutes les implémentations que dans l'ordre |
Il y a le concept "alias", vous pouvez obtenir une implémentation fixe du point d'extension par son nom, il est très pratique de coopérer avec les annotations Dubbo SPI |
Non pris en charge, toutes les implémentations ne peuvent être obtenues que dans l'ordre. Cependant, étant donné que Spring Boot ClassLoader donnera la priorité au chargement des fichiers dans le code utilisateur, il peut garantir que le fichier spring.factoires défini par l'utilisateur est le premier et que l'extension personnalisée peut être obtenue de manière fixe en obtenant la première usine |
Autres |
Aucun |
Prend en charge l'injection de dépendances dans Dubbo, distingue le SPI intégré de Dubbo et le SPI externe via des répertoires, charge les internes en premier et s'assure que les internes ont la priorité la plus élevée |
Aucun |
| Exhaustivité du document |
Les articles et les documents tiers sont suffisamment riches |
Les documents et les documents tiers sont suffisamment riches |
Les documents ne sont pas assez riches, mais en raison du peu de fonctions, il est très simple à utiliser |
Support IDE | Aucun |
Aucun |
Support parfait IDEA, avec des invites de syntaxe |
Par rapport aux trois Mécanismes SPI, le JDK construit -in est le plus faible, mais comme il est intégré au JDK, il existe encore certains scénarios d'application. Après tout, aucune dépendance supplémentaire n'est nécessaire. Dubbo a les fonctions les plus riches, mais le mécanisme est un peu compliqué et il ne peut que le faire. être utilisé avec Dubbo et ne peut pas être complètement considéré comme un module indépendant ; les fonctions de Spring sont presque les mêmes que celles du JDK, et la plus grande différence est que tous les points d'extension sont écrits dans un fichier spring.factories, ce qui est également une amélioration , et IDEA prend parfaitement en charge les invites de syntaxe.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
