某厂面试：如何优雅使用 SPI 机制（一）

代码不多，文章可能有点长。朋友面试某厂问到的 SPI 机制，联想到自己项目最近写到的 SPI 场景，文章简要描述下 SPI 机制的发展历程

产出背景

因为最近项目中使用分库分表以及数据加密使用到了 ShardingSphere，所以决定这段时间看看源码实现。问我为什么要读源码？不看源码怎么提高逼格嘞，就是这么朴实无华～

考虑到自己看微信文章的习惯，不喜欢代码太多的，看着逻辑有点不清晰。所以，以后的文章风格就是，少贴代码，画图 + BB

 
Sharding-Jdbc SPI
看源码的历程，往往从点开 Jar 包的瞬间开始。好巧不巧，就看到源代码包下有个 SPI 包，处于好奇心就点了一点，嗯～ 代码果然很熟悉，还是那个配方原来的味道

 
看了许久，陷入深深的沉思。内心小九九：这玩意好像之前看过，但是在哪我忘了，这到底是个啥？

代码还是那个代码，只是它认识我，我不认识它了

这一块的 SPI 接口是 shrding-jdbc 预留自定义加密器的接口
看到这里相信就遇到过绝大多数技术同学都会遇到的一个问题，那就是 认为自己会了，实际情况呢？不一定。所以，学习一门技术，一定要多看几遍，尝试去理解记忆。千万不要看一遍之后，眼高手低认为技术 so easy，然后隔十天半个月就啥都不记的

 
继续回过头来说说今天的主角：SPI。首先回答这么一个问题，什么是 SPI 机制

SPI 全称为 Service Provider Interface，是一种服务发现机制。为了被第三方实现或扩展的 API，它可以用于实现框架扩展或组件替换

SPI 机制本质是将 接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载文件中的实现类，这样运行时可以动态的为接口替换实现类

看文字描述介绍总是枯燥无味且空洞的。简单一点来说，就是你在 META-INF/services 下面定义个文件，然后通过一个特殊的类加载器，启动的时候加载你定义文件中的类，这样就能扩展原有框架的功能

就这么简单，那可能有读者会问：我不定义在 META-INF/services 下面行不行？就想定义在别的地方

 
不行滴，请遏制住这么危险的想法，人家怎么定义你就怎么实现。这是 JDK 规定好的配置路径，你随便定义，类加载器怎么知道去哪里加载

 
看到这个 PREFIX 常量之后，想法比较活跃的小伙子不知道清醒点了么。简单画张图来描述下 SPI 的运行机制

 
有点 SPI 基础的同学看到图之后应该又开始自信了，这不就是我之前看过的那玩意么？是的，技术还是那个技术，可以继续往下看看，有没有自己不知道的

文章转自公众号：龙台的技术笔记