插件化技术调研

Time: 2018.12.04

最近实验室的项目有插件化的需求，所以让我对插件化相关技术进行调研。

这篇文章对调研报告稍加修改，作为自己对这次调研的记录。

背景与问题描述 如果你的软件是传统销售模式，即将一套软件完整卖给不同客户。

那么不同客户对系统的需求会有所不同，通常会有一定的定制化需求，例如增加一些新功能、完善原有功能、修改皮肤样式等。

因此面对不同客户时，需要在原有系统的基础上进行不同程度的修改和二次开发。

而随着客户的增多，将导致系统在版本、功能、需求等方面的管理变得愈加繁杂，其中也可能存在重复开发、功能无法重用、开发工作量过大等问题。

因此需要寻求一种解决方案使得系统的开发更加灵活，即实现可定制化的目标，实现以更少的开发工作量应对变化的需求。

目标 实现可定制化的目标，实现以更少的开发工作量应对变化的需求。

实现路径 主要实现路径：系统插件化

附录：对可定制化的理解

从上面的思考来看，实现可定制化也可有其它路径：

当然关键在于系统的 分 和 合 上是否合理和优雅。其实思想就是只要系统的功能模块划分的足够合理，耦合度足够低，就已经完成可定制化的一半了，之后再利用动态加载等技术可很容易完成可定制化。如果划分的这一步不够合理，那加上插件化框架其实也就是多加了个壳而已。

Plug-in (computing) From Wikipedia In computing, a plug-in (or plugin, add-in, addin, add-on, addon, or extension) is a software component that adds a specific feature to an existing computer program. When a program supports plug-ins, it enables customization. 译：即插件是一种软件组件，该组件主要用来在原有系统上添加一些扩展功能。插件将使得系统具有定制化的能力。

当一个软件系统开发完成后，可能需要添加一些额外的新功能（有时这些新功能也被称为扩展），我们通常希望能够在不影响原有系统的条件下完成新功能的添加，实现这一目标的并是所谓的插件化，新增加的功能模块就叫插件。

插件化有利于降低模块间的耦合度，有利于各模块和项目的维护更新。

典型的插件例如 Chrome、Firefox 浏览器插件、Eclipse 插件、Vscode 等各种 IDE 插件，各种软件提供的主题或皮肤也是一种插件。

关于组件、插件与控件，以及组件化、插件化、模块化这些概念可参见本文末尾的附录。

不论是自己设计实现系统的插件化还是直接应用现成的插件化框架，都会涉及到一些基本的基础技术。下面对这些技术做一下基本介绍和整理。

插件化系统的特点之一就是实现各个插件的可插拔，系统可灵活的动态拆分与组合。要实现这一特点就离不开动态加载的概念。

Dynamic loading From Wikipedia Dynamic loading is a mechanism by which a computer program can, at run time, load a library (or other binary) into memory, retrieve the addresses of functions and variables contained in the library, execute those functions or access those variables, and unload the library from memory. 译：动态加载是一种让系统在运行时加载并使用其他软件的机制。

动态加载在不同系统、平台有不同的具体实现，如果你的系统主要运行在 Java 平台之上，那么就要着重关注 Java 的动态加载。

Java 的动态加载主要依靠 ClassLoader。

Java 源码编译成字节码 class 文件，class 文件是 JVM 平台上的基本程序单位，而 ClassLoader 的作用就是加载 class 文件。Java 类加载的完整生命周期包括加载、验证、准备（连接）、解析、初始化、使用、卸载。

并且 Java 的 ClassLoader 在加载类时采用的是双亲委派机制（实现类加载的共享和隔离），如下图所示：

Java 具有四种类型的 ClassLoader:

但是在具体实现中有可能为特定需求（如顶层 ClassLoader 调用底层 ClassLoader 负责的类）破坏双亲委派模型。

既然已经实现类的动态加载，那么为了访问以及使用动态加载类中的属性、方法就必须应用到反射技术，所以反射也是实现插件化过程中会频繁涉及到的技术之一。

反射技术可讲的内容很多，自己在实验室读研期间做的几个核心项目都与反射息息相关，所以估计以后会专门写一篇详细介绍反射的文章。

而文本主要集中在插件化技术，所以反射在这里就不做过多介绍了。

这里只稍微提及一下反射最重要的核心思想和关键：获取类的元信息。

Java 中类的元信息编译到了 class 文件中，运行时加载至内存模型的元空间区域，所以 Java 本身可以很容易的支持反射技术。

而 Python 这样的动态语言就更容易记录和使用类的元信息，所以反射的实现也很自然。

而 c/c++ 因为其编译结果只有变量、函数地址偏移、函数关系，所以只能在运行时构建函数名称等元信息与地址之间的映射关系，以此实现反射，而 c/c++ 在语言层面并未帮我们做这一工作，所以需要程序自己实现，例如 ProtoBuf 的反射实现。

在实现插件化的过程中，有时需要拿到系统或平台层面方法的控制权，从而获得更为强大的能力。典型的就是在 android 平台上实现插件化，有时候需要 hook 部分系统方法才能实现对资源的动态加载。

在 Java 平台上，常用的动态代理方式有：

除动态加载之外，还有其他一些调用组件的方法，同样可应用于插件化：

除上述技术之外，实现插件化过程中还需要考虑插件之间的通信（通过反射拿到引用、面向服务）、插件的描述和管理、插件的状态和生命周期等

除了上面介绍的实现插件化的基础技术，要完整的实现插件化甚至搭建一个插件化框架，还需要做很多关于插件管理、插件状态、插件生命周期定义等工作。其实也就是实现一个框架所要考虑和设计的种种细节。

借助上面介绍的动态加载、反射等技术，再做好业务系统的模块划分，那么完全可以自己动手实现系统插件化了。

但是实际情况是业界已经存在很多比较成熟和实用的框架甚至是规范了，下面是对一些框架的调研结果。

插件化框架列表：

OSGI From Wikipedia The OSGi specification describes a modular system and a service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments.

即 OSGI 是 Java 的动态模块化系统的规范。

OSGi 将使开发者能够构建动态化、模块化的 Java 系统，系统的每个模块将可以像插件一样实现“可插拔”、“即插即用”。

OSGI 框架如下图所示：

从图中可知，OSGI 框架从概念上可以划分为以下几个层次：

bundle Bundle 是 OSGi 中的基本组件，其表现形式仍然为 Java 概念中传统的 Jar 包，其中包含了代码、资源文件和元数据。 通过 META-INF 目录下的 MANIFEST.MF 文件记录 bundle 的元数据描述信息。 例如：

OSGI 为每个 bundle 创建独立的 ClassLoader，这样使得各个 bundle 的类尽可能相互隔离（包名 + 类名 + ClassLoader 才能唯一确定一个类），从而降低 bundle 之间的耦合度。

Services 主要涉及模块之间的交互和通信。 bundle 之间的交互可通过以下几种方式：

OSGI 框架即可视为实现 OSGI 规范的容器，如同 Web 开发中实现了 J2EE 规范的 Web 容器。

下面介绍几款 OSGI 框架。

felix felix 官方网站 felix 是由 Apache 基金组织开发的面向社区的 OSGi 框架实现，提供了标准的服务以及 OSGi 相关的服务实现。

Felix 项目比较成熟且在很多其他项目中得到应用，提供服务全面，涵盖了全部的 OSGi 4.2 标准。社区活跃，文档丰富。框架设计紧凑，上手简单。

Equinox Equinox 官方网站-1 Equinox 官方网站-2 Equinox 是 Eclipse 所使用的 OSGi 框架，Eclipse 使用这个框架实现了它强大的插件系统，目前是 Eclipse 项目下的子项目。

Equinox 与 Eclipse 结合紧密，Eclipse 内置大量插件、功能、操作等，且配备专门的 Debug 工具，可非常方便的创建、管理、开发、调试以及部署 Equinox 项目。

虽然 Equinox 功能也算全面，但是对比 Felix 相对较少。

其他 OSGI 框架

综上，可总结以下几种主要的、可选的插件化方案。

即利用【插件化技术基础】一节中提到的实现插件化的基础技术如动态加载、反射、动态代理等基础自己动手编写符合我们项目的插件化框架。在开发过程中，应该需要解决和设计好以下几个方面：

具体设计还可参考现有的插件化系统，详见本文附录部分的【现有插件化系统架构参考】一节。

这一方案的优点是可以根据项目系统的实际情况开发简单、完全可控、灵活、定制化、满足需求的插件化框架。而缺点就是具有一定的开发工作量且最终开发效果无法预计，预估至少需要 3 个月以上的开发、调试、整合等。

借助于 Felix 框架，可以很方便的开发插件化系统（当然重点和主要的工作量在于系统模块化的设计）。

更为详细的使用教程可参见如下文章： Felix Documentation Java Web应用集成OSGI OSGi简介与基于OSGi框架（Felix）的简单应用实现

与 Felix 类似，具体使用教程可参见如下文章： Writing a bundle-based server application OSGi as a Web Application Server 使用 Equinox 框架进行 OSGi 环境下的 Web 开发 使用 Equinox 开发 OSGi 应用程序

对上述方案总结如下表所示：

来自 https://www.zhihu.com/question/49536781/answer/117606933

组件化与模块化没有太多必要做名词上的区分，他们的目的都是实现系统的低耦合和可复用。 插件化：比起组件化和模块化，插件化更加强调对现有功能的灵活扩展。主要优点是面向需求变更时的开发灵活性。 系统实现了组件化与模块化，并不一定支持插件化。

Eclipse Plug-in Architecture Confluence Plug-in Architecture Hudson Plugin Architecture ElasticSearch Plugin joomla plugin

osgi-architecture Notes on the Eclipse Plug-in Architecture Hudson Plugin Architecture Converting an EJB JAR file to an OSGi EJB bundle Felix 官方网站 Equinox 官方网站 Introduction to Maven Plugin Development Java Web application “plugin” architecture

汪