微内核插件架构从原理到实践( 二 ) _微内核

常见的微内核插件架构案例在Web浏览器领域，谷歌的Chrome浏览器之所以被认为功能强大，一个很重要的原因是它有着丰富的插件类型；在开发工具领域，微软的VS Code初始安装后还只是个简单的文本编辑器，但用户可以安装各种插件，从而让它摇身一变成为功能强大的IDE 。

Chrome和VS Code以及Eclipse、IDEA都是微内核架构的典型应用例子，它们提供一个具备最基础能力的核心系统，并定义好插件的开发接口。至于需要开发或安装哪种类型的插件，则完全由普通开发者和用户决定，这样的设计让系统具备了极强的可定制化和可扩展能力。

常见的一些开源框架比如Dubbo、ShardingSphere、Skywalking以及Apache ShenYU网关都支持插件化架构，每个开源软件的微内核插件设计核心思想都是一致的，其具体技术实现略有不同。在dubbo中，SPI的使用几乎是疯狂。dubbo针对JAVA SPI的局限性，自己重写了一套加载机制。可以针对不同的需求使用不同的实现类以及提供一些高级特性。

阿里巴巴的星环TMF框架其核心思想也是基于微内核插件架构，TMF2.0框架改造的交易平台支持了淘宝、天猫、聚划、盒马、大润发等一系列集团交易业务，通过业务管理域与运行域分离、业务与业务的隔离架构，大幅度提高了业务在可扩展性、研发效率以及可维护性问题，同时以更好的开放模式，让业务方能自助进行无侵入的需求开发。
微内核插件架构设计微内核插件架构包含两个核心组件：系统核心(Core System)和插件化组件(Plug-in component) 。Core System负责管理各种插件，当然Core System也会包含一些重要功能，如插件注册管理、插件生命周期管理、插件之间的通讯、插件动态替换等。整体结构如下：

文章插图

微内核插件架构设计需要考虑如下四点：
插件管理

核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。常见的实现方法是插件注册表机制。
核心系统提供插件注册表（可以是配置文件，也可以是代码，还可以是数据库），插件注册表含有每个插件模块的信息，包括它的名字、位置、加载时机（启动就加载，还是按需加载）等。

插件连接

插件连接指插件如何连接到核心系统。通常来说，核心系统必须制定插件和核心系统的连接规范，然后插件按照规范实现，核心系统按照规范加载即可。
常见的连接机制有 OSGi（Eclipse 使用）、消息模式、依赖注入（Spring 使用），甚至使用分布式的协议都是可以的，比如 RPC 或者 HTTP Web 的方式。

插件通信

插件通信指插件间的通信。虽然设计的时候插件间是完全解耦的，但实际业务运行过程中，必然会出现某个业务流程需要多个插件协作，这就要求两个插件间进行通信。
微内核的核心系统也必须提供类似的通信机制，各个插件之间才能进行正常的通信。

事实上， Java中已经为我们提供了一种微内核架构的实现方式，就是JDK SPI 。这种实现方式针对如何设计和实现 SPI 提出了一些开发和配置上的规范，ShardingSphere、Dubbo 使用的就是这种规范，只不过在这基础上进行了增强和优化。另外Java中提供了OSGI，也可以作为插件化架构设计，早期淘宝HSF组件中间版本做过OSGi的尝试，最终还是因为它的使用它的代价大于好处而放弃。

SPISPI主要用于框架设计。在框架设计中可能会有不同的实现类。如果所有的实现类都放入代码中的话，代码的耦合程度就太高了。SPI就是为了降低代码耦合度的，但是如果不知道SPI机制在看一些源码的时候就感觉云里雾里的。SPI简单来说就是使用配置文件来决定使用哪个实现类。将原来可能要在代码里面直接引用的实现类，写入到配置文件中，然后通过一个加载器去加载。
SPI优势很明显就是简单易用，如果对于只有一个实现类，比如JDBC 。每个厂商都去实现但是每个厂商都只有自己一个实现类。针对这种上游接口Java SPI是合理的。

可以看到Java SPI是将文件里面的所有接口都去实现。在系统的实际开发中一个接口的实现类可能很多，在不同的场景下使用的也不一样。Java SPI这个时候就不太适用了。

如果有些实现类在运行时没有使用，并且加载比较繁琐，必然会耗费整个系统的资源。