中台建设利器 -SPI 插件机制

一、什么是 SPI？

SPI ，全称为 Service Provider Interface，是一种服务发现机制。它通过在 ClassPath 路径下的 META-INF/services 文件夹查找文件，自动加载文件里所定义的类。它实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的本地化服务发现机制。

系统设计的各个抽象，往往有很多不同的实现方案，在面向的对象的设计里，一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。本质上就是解耦。

二、API 与 SPI 的区别

API 与 SPI 实际上也是都是一样的面向接口编程，但本质其实就是上下游间话语权的争夺。话不多说上图。

作为客户端，特别是有实力的平台来说用 SPI 的好处是不言而喻的，上游的改造只是在 META-INF/services/下面加入对应的要调用的全限定类名，通过实时加载的时候进行调用，不用则弃，实现全面的无代码入侵。

三、JDK SPI 如何实现动态加载

这里我画了一个大致的调用链图，方便大家理解。一切一切的源头还是 ServiceLoader.load()，话不多说上图。

再细想一下，其实这样做跟平时直接调用对方系统/服务的一个接口没太多的区别和难度，只是一个是强绑定的实现，另一个是解耦的实现而已，但是更多体现的就是插件式架构的设计思想的区别（经典代表就是 IDEA 的这种基于 OSGi 的插件）。

这种插件式架构在中台中可是大有用处。我可以举一个比较常见的例子作为说明。在所谓的渠道系统（例如会员中心、移动商城）都免不了在大促期间要发各种优惠券，但是企业的 IT 系统建设过程中，一定会存在这样一种现象：就是会员中心或移动商城建设在前，应该已经有对应的发券/管券的功能模块，但是集团或公司的 IT 部门开始要建设各种中台针对核心 IT 能力进行统一管理，因此一定会要求渠道系统要统一接入某某某管理平台，但是各自渠道又各有自己的渠道特性，你的中台也不可能把我渠道的个性化功能整合进中台啊，那这个矛盾怎么解决。

这个时候就要靠这个 SPI 机制作为缓冲剂进行完美解决。

1）针对可以使用中台功能的，直接通过SPI配置或者直接调用；
2）针对有个性化需求的，也可以通过SPI的机制以服务标准或契约进行约束。

但是，这里有个 tricky point，就是这个 SPI 机制必须由中台团队（下游）负责封装并提供给各渠道（上游）系统进行集成，这样的话你看看，上游系统可以通过热插拔技术自由使用自身（个性）或中台（共性）服务的能力都是通过中台团队进行统一的封装跟管理，因此，券码服务的服务标准（我喜欢称为契约）均为中台进行统一管理或控制。正所谓得标准者得天下，你看看美丽国就知道啦。

我画个图方便大家理解。

四、JDK SPI 如何使用

具体如何使用 SPI，这里我画个脑图方便大家了解。

五、JDK SPI 的增强版

对于 JDK 自带的 SPI，其缺点也是很明显，就是

1）其类加载机制只能全量加载，无法做到按需加载，这会极大消耗系统资源；
2）非线程安全；
3）实例化后的对象只能通过Iterator获取，而不能像Map.get()的方式按Key获取。

因此，为了解决上面的问题，Dubbo 和 Spring 同样也做了二次封装支持 SPI 的机制。今天先写这么多，稍后再补充 Dubbo SPI 的吧。