某厂面试：如何优雅使用 SPI 机制( 二 ) _小知识

文章插图

【某厂面试：如何优雅使用 SPI 机制】通过 SPI 的方式，就可以将客户端提供的加密算法加载到 sharding-jdbc 加密规则中，这样就可以在项目运行中选择自定义算法来对数据进行加密存储
通过 sharding-jdbc 的例子，可以很好的看出来，上面提到的 SPI 优点，都体现了出来

客户端（自己的项目）提供了服务端（sharding-jdbc）的接口自定义实现，但是与服务端状态分离，只有在客户端提供了自定义接口实现时才会加载，其它并没有关联；客户端的新增或删除实现类不会影响服务端
如果客户端不想要 RSA 算法，又想要使用内置的 AES 算法，那么可以随时删掉实现类，可扩展性强，插件化架构

配合实际案例理解 SPI 是不是很简单。为了防止有些小伙伴没有理解 sharding-jdbc 的例子，这里再举一个真实的例子
对象存储举例假如你是一家集团公司里做公共架构开发的（可以把这个集团想大一点，几百家子公司的那种 ? ），领导给你安排了个开发任务，需要你开发一个对象存储服务，让其它业务线的团队使用，统一集团内部的对象存储
OK ，开发诉求明白了，这个时候就该想想怎么去完成这个需求（主要想给领导留个好印象，升官发财 ing...）。首先应该考虑的是要兼容多套对象存储供应商，比如阿里 OSS、腾讯 COS、华为云 OBS ，最基本的三连对吧
高高兴兴的封装了个 starter ，告诉领导封装完成了，然后就下发到各项目组去用了。但是这个时候其中一个子公司负责人告诉你，说他们之前用的七牛云 Kodo
心态炸了呀，难道要给他再适配一个七牛云么？万一适配完这个，又一位大哥说项目自建 HDFS 咋整
聊到这，大家就明白了吧， SPI 的场景可不就出现了么。就是身为服务提供者，在你无法形成绝对规范强制的时候， "放权" 往往是比较明智的选择，适当让客户端去自定义实现
这个时候，回过头想一想最初的一个问题。为什么 sharding-jdbc 不多实现几套算法，而是提供出一个 SPI 接口呢
因为开发者明白，不论提供多少接口，总有个别用户因各方面因素导致的个性化需求。个性化这个事情是追摸不透的，就像女生的心思一样，永远不知道在想什么...（重点都加黑加粗了，剩下的全靠自己领悟）

实战讲解都说到这了，不来个实战，感觉有点说不过去。吹过的牛逼，负责到底！就实现上面说的统一对象存储服务的代码
最简单的对象存储，只需要两个接口就可以实现功能，分别是上传和下载

文章插图

定义好上传、下载接口后，我们就要考虑，如何让客户端项目可以选择底层的对象存储服务器，以及如何通过 SPI 的方式将客户端自定义的文件存储组件加载到服务端
我们可以定义个对象存储容器，存放可以使用的对象存储服务，然后再使用 SPI 的机制加载客户端自定义组件放到容器。对象存储服务放到容器中自然需要一个标识，那么就需要给文件接口加一个获取类型接口

文章插图

定义好了接口，就要写具体的代码了。我们为对象存储服务提供出一个对外的门面，所有访问对象存储的服务，必须访问门面对象进行文件的上传下载操作
下面这段代码将对象服务 bean 存储至容器，并提供根据客户端的自定义配置，选择合适的对象存储服务
代码里用到的关键字 var 是 lombok 的注解，可以自动识别对象类型