SpringBoot 插件化开发模式，强烈推荐！

插件化开发模式正在很多编程语言或技术框架中得以广泛的应用实践，比如大家熟悉的jenkins，docker可视化管理平台rancher，以及日常编码使用的编辑器idea，vscode等，随处可见的带有热插拔功能的插件，让系统像插了翅膀一样，大大提升了系统的扩展性和伸缩性，也拓展了系统整体的使用价值，那么为什么要使用插件呢？,实现服务模块之间解耦的方式有很多，但是插件来说，其解耦的程度似乎更高，而且更灵活，可定制化、个性化更好。,举例来说，代码中可以使用设计模式来选择使用哪种方式发送短信给下单完成的客户，问题是各个短信服务商并不一定能保证在任何情况下都能发送成功，怎么办呢？这时候设计模式也没法帮你解决这个问题，如果使用定制化插件的方式，结合外部配置参数，假设系统中某种短信发送不出去了，这时候就可以利用插件动态植入，切换为不同的厂商发短信了。,以spring来说，之所以具备如此广泛的生态，与其自身内置的各种可扩展的插件机制是分不开的，试想为什么使用了spring框架之后可以很方便的对接其他中间件，那就是spring框架提供了很多基于插件化的扩展点。,插件化机制让系统的扩展性得以提升，从而可以丰富系统的周边应用生态。,有了插件之后，第三方应用或系统如果要对接自身的系统，直接基于系统预留的插件接口完成一套适合自己业务的实现即可，而且对自身系统的侵入性很小，甚至可以实现基于配置参数的热加载，方便灵活，开箱即用。,以java为例，这里结合实际经验，整理一些常用的插件化实现思路：,serviceloader是java提供的spi模式的实现。按照接口开发实现类，而后配置，java通过ServiceLoader来实现统一接口不同实现的依次调用。而java中最经典的serviceloader的使用就是Java的spi机制。,SPI全称 Service Provider Interface ，是JDK内置的一种服务发现机制，SPI是一种动态替换扩展机制，比如有个接口，你想在运行时动态给他添加实现，你只需按照规范给他添加一个实现类即可。比如大家熟悉的jdbc中的Driver接口，不同的厂商可以提供不同的实现，有mysql的，也有oracle的，而Java的SPI机制就可以为某个接口寻找服务的实现。,下面用一张简图说明下SPI机制的原理,图片,如下工程目录，在某个应用工程中定义一个插件接口，而其他应用工程为了实现这个接口，只需要引入当前工程的jar包依赖进行实现即可，这里为了演示我就将不同的实现直接放在同一个工程下；,图片,定义接口,定义两个不同的实现,在resources目录按照规范要求创建文件目录，并填写实现类的全类名,图片,自定义服务加载类,运行上面的程序后，可以看到下面的效果，这就是说，使用ServiceLoader的方式可以加载到不同接口的实现，业务中只需要根据自身的需求，结合配置参数的方式就可以灵活的控制具体使用哪一个实现。,图片,serviceloader其实是有缺陷的，在使用中必须在META-INF里定义接口名称的文件，在文件中才能写上实现类的类名，如果一个项目里插件化的东西比较多，那很可能会出现越来越多配置文件的情况。所以在结合实际项目使用时，可以考虑下面这种实现思路：,在上文中案例基础上，我们做如下调整；,在配置文件中，将具体的实现类配置进去,通过这个类，将上述配置文件中的实现类封装到类对象中，方便后续使用；,使用上述的封装对象通过类加载的方式动态的在程序中引入,启动工程代码后，调用接口：localhost:8081/sendMsg，在控制台中可以看到下面的输出信息，即通过这种方式也可以实现类似serviceloader的方式，不过在实际使用时，可以结合配置参数进行灵活的控制；,图片,更进一步，在很多场景下，可能我们并不想直接在工程中引入接口实现的依赖包，这时候可以考虑通过读取指定目录下的依赖jar的方式，利用反射的方式进行动态加载，这也是生产中一种比较常用的实践经验。,具体实践来说，主要为下面的步骤：,在上述的基础上，按照上面的实现思路来实现一下；,在当前工程下创建一个lib目录，并将依赖的jar放进去,图片,添加一个工具类，用于读取指定目录下的jar，并通过反射的方式，结合配置文件中的约定配置进行反射方法的执行；,添加如下测试接口,以上全部完成之后，启动工程，测试一下该接口，仍然可以得到预期结果；,图片,在上述的实现中还是比较粗糙的，实际运用时，还需要做较多的优化改进以满足实际的业务需要，比如接口传入类型参数用于控制具体使用哪个依赖包的方法进行执行等；,在大家使用较多的springboot框架中，其实框架自身提供了非常多的扩展点，其中最适合做插件扩展的莫过于spring.factories的实现；,在Spring中也有一种类似与Java SPI的加载机制。它在META-INF/spring.factories文件中配置接口的实现类名称，然后在程序中读取这些配置文件并实例化，这种自定义的SPI机制是Spring Boot Starter实现的基础。,spring-core包里定义了SpringFactoriesLoader类，这个类实现了检索META-INF/spring.factories文件，并获取指定接口的配置的功能。在这个类中定义了两个对外的方法：,上面的两个方法的关键都是从指定的ClassLoader中获取spring.factories文件，并解析得到类名列表，具体代码如下：,从代码中我们可以知道，在这个方法中会遍历整个ClassLoader中所有jar包下的spring.factories文件，就是说我们可以在自己的jar中配置spring.factories文件，不会影响到其它地方的配置，也不会被别人的配置覆盖。,spring.factories的是通过Properties解析得到的，所以我们在写文件中的内容都是安装下面这种方式配置的：,如果一个接口希望配置多个实现类，可以使用’,’进行分割,接下来看一个具体的案例实现来体验下Spring Factories的使用；,自定义一个接口，里面添加一个方法；,实现类1,实现类2,在resources目录下，创建一个名叫：META-INF的目录，然后在该目录下定义一个spring.factories的配置文件，内容如下，其实就是配置了服务接口，以及两个实现类的全类名的路径；,添加一个自定义的接口，有没有发现，这里和java 的spi有点类似，只不过是这里换成了SpringFactoriesLoader去加载服务；,启动工程之后，调用一下该接口进行测试，localhost:8087/sendMsgV3?msg=hello，通过控制台，可以看到，这种方式能够正确获取到系统中可用的服务实现；,图片,利用spring的这种机制，可以很好的对系统中的某些业务逻辑通过插件化接口的方式进行扩展实现；,结合上面掌握的理论知识，下面基于Java SPI机制进行一个接近真实使用场景的完整的操作步骤；,1、biz-pp，插件化接口工程；,2、bitpt，aliyun短信发送实现；,3、miz-pt，tencent短信发送实现；,本案例完整的实现思路参考如下：,这一步比较简单就不展开了,这个类，可以理解为在真实的业务编码中，可以根据业务定义的规则，具体加载哪个插件的实现类进行发送短信的操作；,在该模块中，需要引入对具体实现的两个工程的jar依赖（也可以通过启动加载的命令方式）,biz-pp的核心代码实现就到此结束了，后面再具体测试的时候再继续；,接下来就是插件化机制中具体的SPI实现过程，两个模块的实现步骤完全一致，挑选其中一个说明，工程目录结构如下：,图片,将上面biz-app工程打出来的jar依赖过来,按照前文的方式，在resources目录下创建一个文件，注意文件名称为SPI中的接口全名，文件内容为实现类的全类名,完成实现类的编码后，通过maven命令将jar安装到仓库中，然后再在上一步的biz-app中引入即可；,启动biz-app服务，调用接口：localhost:8087/sendMsg?msg=sendMsg，可以看到如下效果,图片,为什么会出现这个效果呢？因为我们在实现类配置了具体使用哪一种方式进行短信的发送，而加载插件的时候正好能够找到对应的服务实现，这样的话就给当前的业务提供了一个较好的扩展点。,图片,从当前的趋势来看，插件化机制的思想已经遍布各种编程语言，框架，中间件，开源工具等领域，因此掌握插件化的实现机制对于当下做程序实现，或架构设计方面都有着很重要的意义，值得深入研究，本篇到此结束，感谢观看！