中台建设利器-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的吧。

六、中台系列文章

数字化转型中平台思维的十大要素－《数字化转型的道与术》_尘世间一名迷途小码农的博客-CSDN博客## 前言企业数字化转型的关键在于以平台思维构建系统，意思就是要给存在相互影响和依赖的双边和多边群体提供一个空间（或系统），满足不同群体在这个空间的利益。在这个转型过程中，以下十大要素是这个平台思维的重要组成部分。## 要素一：业务全局视角贯穿业务链首先，各个业务系统都是从系统所属业务主导方的视角构建的，缺乏全局视野，容易由于数据标准、格式不一致导致出现数据孤岛现象。另外，因为业务系统本质上还是不同业务部门从自己局部角度出发而建设的产物，因此系统间所产生的联动成本高本身也是“部门墙”的直观体https://blog.csdn.net/justyman/article/details/122300690?spm=1001.2014.3001.5502中台建设落地浅谈_尘世间一名迷途小码农的博客-CSDN博客一、前言近一段时间有篇文章在讲阿里在拆自己的中台，反正说的是中台扼杀创新云云。刀本没有善恶？关键在于使用的人。用在厨师身上可以整出人间美味，用在杀人犯手里那当然产生悲剧啦。曾经从thoughtworks上面看过关于中台的第一性原理的文章，觉得挺在理的，文中讲到根据Cynefin认知模型，通过演绎法可以推论出：中台所代表的企业架构向平台型演进的过程，本质上就是企业在发展过程中，随着对于市场信息认知不断提升，在不确定性中寻找确定性，持续在跨业务线探索通用最佳实践（Best Practice），并以.https://blog.csdn.net/justyman/article/details/114477257?spm=1001.2014.3001.5502共享服务中心建设原则-《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》_尘世间一名迷途小码农的博客-CSDN博客一、前言今天重看了《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》的第4章-共享服务体系搭建。书中所描述的共享服务中心，提到的实际上包含两个层次。其一，底层的PaaS能力，它用于解决企业中整体系统群的架构在分布式、可用性、高可用性、实时监控等方面上的需求；其二，通用的业务能力，我的理解实际上就是建设SaaS，目的在于将企业核心能力下沉共享，加速企业创新速度。这里也想针对第二个：通用的业务能力的建设聊一下对它的一个理解。二、共享服务中心建设历程...https://blog.csdn.net/justyman/article/details/108952497?spm=1001.2014.3001.5502【读书笔记一】《企业 IT 架构转型之道 - 阿里巴巴中台战略思想与架构实战》_尘世间一名迷途小码农的博客-CSDN博客目录第一章阿里巴巴集团中台战略引发的思考一、思考二、共享事业部发展史三、企业信息中心发展的症结1、“烟囱式”系统建设模式2、业务支持一直是企业信息中心的组织职能第二章、构建业务中台的基础-共享服务体系一、服务需要重用和业务滋养二、共享服务体系是培育业务创新的土壤三、共享服务体系赋予业务快速创新和试错能力四、组织矩阵改变会带来组织效能的提升第一章阿里巴巴集团中台战略引发的思考一、思考Supercell这家游戏公司真的是“神奇”的公司...https://blog.csdn.net/justyman/article/details/108319029?spm=1001.2014.3001.5502【读书笔记二】《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》_尘世间一名迷途小码农的博客-CSDN博客目录第三章分布式服务框架的选择一、淘宝服务化历程二、“中心化”与“去中心化”服务第三章分布式服务框架的选择一、淘宝服务化历程截止到2007年，淘宝已经拥有超过500人的技术团队规模，整个淘宝网站是一个几百兆字节的WAR包，功能模块超过200个。几百人维护一个WAR包的模式,带来了以下几个主要问题：项目团队间协同成本高,业务响应越来越慢。应用复杂度已超出人的认知负载。各种业务互相交错，已经没有一个人能完全清楚每个功能或流程的细节，毕竟人的认知...https://blog.csdn.net/justyman/article/details/108906152?spm=1001.2014.3001.5502分布式服务框架的选择-《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》_尘世间一名迷途小码农的博客-CSDN博客一、淘宝服务化历程截止到2007年，淘宝已经拥有超过500人的技术团队规模，整个淘宝网站是一个几百兆字节的WAR包，功能模块超过200个。几百人维护一个WAR包的模式,带来了以下几个主要问题：项目团队间协同成本高,业务响应越来越慢。应用复杂度已超出人的认知负载。各种业务互相交错，已经没有一个人能完全清楚每个功能或流程的细节，毕竟人的认知负载是有极限的；错误难于隔离。因为淘宝平台是一个WAR包，其核心功能和非核心功能的代码都运行在同一个环境（同一个JVM)中，任何一个小的问题都可能引发全局问题；https://blog.csdn.net/justyman/article/details/111427825?spm=1001.2014.3001.5502