插件系统的制作方法

本发明涉及计算机技术领域，特别涉及一种插件系统。

背景技术：

目前，对于一个集群平台而言，一般就具有较强的专业性，其代码的耦合度会比较高，例如，代码A和代码B之间可能耦合度达到50％以上，因此，对代码的学习和维护会比较困难，同时，相互之间也会存在很多重复的代码，在对系统进行更新部署的时候，往往需要停止服务还进行，且更新周期比较长。

如果更新周期特别长，有时还会影响业务的正常进行。

针对上述问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种插件系统，以达到在不影响业务进行的情况下，对系统进行更新的技术效果，该系统包括：

多个插件接口；

多个插件，每个插件通过匹配对应的插件接口接入系统中，以提供服务；

其中，所述多个插件中的各个插件被模块化地部署到所述插件系统中，所述多个插件之间通过插件接口进行信息交互。

在一个实施方式中，所述多个插件中的各个插件被定义为最小的功能集合。

在一个实施方式中，所述多个插件中的各个插件仅向外提供以下至少之一：该插件可被调用的类、该插件所能提供的服务、该插件需要依赖的类和该插件需要依赖的服务。

在一个实施方式中，所述多个插件中的各个插件是一个C++模块。

在一个实施方式中，上述插件系统还包括：监测模块，用于在应用系统启动之前，判断所述插件系统中的各个插件之间的类的依赖关系是否满足，并在确定存在不满足的依赖关系的情况下，识别出不满足的依赖关系。

在一个实施方式中，所述多个插件包括：基础插件、业务插件和应用插件，其中：

所述基础插件，用于对所述插件系统中的业务插件和应用插件进行管理；

所述业务插件和应用插件，用于提供服务。

在一个实施方式中，所述业务插件和所述应用插件可在应用程序运行的过程中被安装、更新或卸载。

在一个实施方式中，所述基础插件，具体用于对所述插件系统中的业务插件和应用插件进行生命周期的维护，其中，所述生命周期包括：安装、更新和卸载。

在一个实施方式中，所述插件系统为集群渲染插件系统。

在本发明实施例中，提供了一种插件系统包括：多个插件接口；多个插件，每个插件通过匹配对应的插件接口接入系统中，以提供服务；其中，多个插件中的各个插件被模块化地部署到插件系统中，多个插件之间通过插件接口进行信息交互。因为插件是模块化的方式部署到系统中的，因此插件可以实现热部署，在对系统进行更新时候，只需要对某些插件进行更新，无需停止业务，从而可以解决现有的方式中对系统进行更新时候，需要停止业务的问题，达到了在不影响业务进行的情况下，对系统进行更新的技术效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是根据本发明实施例的插件系统的架构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。

为了使得对本申请进行更清楚地理解，先对插件解释如下：插件，是由开发人员编写系统框架，并预先定义好系统的扩展接口。插件由其他开发人员根据系统预定的接口编写的扩展功能，实际上就是系统的扩展功能模块，一般插件都是以一个独立文件的形式出现，对于系统来说并不知道插件的具体功能，仅仅是为插件留下预定的接口，系统启动的时候根据插件的配置寻找插件，根据预定的接口把插件挂接到系统中。

在本例中，提供了一种插件系统，如图1所示，可以包括：

多个插件接口(如图1中的11、12、13…1n)；

多个插件(如图1中的21、22、23…2n)，每个插件通过匹配对应的插件接口接入系统中，以提供服务，所述多个插件之间通过插件接口进行信息交互，所述多个插件中的各个插件被模块化地部署到所述插件系统中。

因为，插件是模块化的方式部署到系统中的，因此插件可以实现热部署，在对系统进行更新时候，只需要对某些插件进行更新，无需停止业务，从而可以解决现有的方式中对系统进行更新时候，需要停止业务的问题，达到了在不影响业务进行的情况下，对系统进行更新的技术效果。

为了尽量减少插件之间的耦合度，在一个实施方式中，多个插件中的各个插件被定义为最小的功能集合，即将每个插件都定义为最小的功能集也就是不能继续拆分的功能集，例如：日志插件、配置操作插件、maya渲染插件，从而可以避免插件与插件之间的耦合，同时可以提高插件的重用，可以有效提高开发效率，降低开发成本。

对于每个插件而言，仅向外声明自身对外提供的类和接口，即，每个插件都设置自己的类路径，可以精确规定哪些类可以被调用，以及该插件需要调用其他插件的哪些类，从而明确各个插件之间的依赖关系，对于插件自身而言，仅需要向外声明自己可以提供的业务，而代码和插件本身是完全模块化的，即，多个插件中的各个插件仅向外提供以下至少之一：该插件可被调用的类、该插件所能提供的服务、该插件需要依赖的类和该插件需要依赖的服务。

上述的各个插件可以分别是一个C++模块。

在上述提到了各个插件之间因为存在类与类之间的引用和交互，因此，可以在插件系统中设置监测模块，通过该监测模块在应用系统启动之前，判断插件系统中的各个插件之间的类的依赖关系是否满足，并在确定存在不满足的依赖关系的情况下，识别出不满足的依赖关系。即，在应用程序启动之前，插件系统就可以检测出来是否所有的依赖关系都被满足，并在不满足的情况下，精确报出是哪些依赖关系没有被满足。

进一步的，在该框架下，类实例可以共享也可以按要求独立，通过这种方式可以有效提高插件之间直接的交互。

插件系统中的插件可以以下几类：基础插件、业务插件、和应用插件，其中，基础插件是整个插件系统的核心，主要用于插件的管理和插件生命周期的维护等。插件之间可以通过插件接口、或信号进行交互，从而有效降低彼此之前的耦合度，由于充分封装了插件管理和生命周期维护，从而使得业务插件和应用插件只需要聚焦在功能的开发，同时在更新部署时，根据版本可以自动进行升级的热部署，并且将业务插件剥离，对于负责业务的学习也可以有效的通过接口学习获得。

在一个实施方式中，多个插件可以包括：基础插件、业务插件和应用插件，其中，基础插件，用于对插件系统中的业务插件和应用插件进行管理；所述业务插件和应用插件，用于提供服务。

为了实现对插件的热部署，业务插件和应用插件可在应用程序运行的过程中被安装、更新或卸载。基础插件，具体可以用于对插件系统中的业务插件和应用插件进行生命周期的维护，其中，生命周期可以包括：安装、更新和卸载。

在上述各个实施方式中，插件系统可以是集群渲染插件系统。

下面结合一具体实施例对上述插件系统进行说明，然而，值得注意的是，该具体实施例仅是为了更好地说明本发明，并不构成对本发明的不当限定。

以插件框架是一个动态的C++模块系统为例进行说明，预定规定了如何定义一个模块以及这些模块之间如何交互。每个插件都是一个C++模块，每个插件都有自己的类路径，可以精确规定哪些类可以被调用，需要调用哪些其它插件的哪些类，并从而指明插件之间的依赖关系。另外，插件可以被在运行时候被安装、更新和卸载，且不会影响整个应用。通过这种方式，将分层的类加载机制变成了网状的类加载机制。在应用程序启动之前，插件系统就可以检测出来是否所有的依赖关系被满足，并在不满足时精确报出是哪些依赖关系没被满足。同时在这个框架下，类实例可以共享也可以按要求独立，从而有效提高插件直接的交互。

可以将上述插件系统分层为三部分：基础插件、业务插件、应用插件，其中，基础插件为整个插件技术的核心，包含：插件管理、生命周期维护等。所有插件又可以分为功能插件、服务插件、和界面插件等。所有插件通过插件接口、或信号进行交互，有效地降低了彼此之前的耦合度，由于充分封装了插件管理、生命周期维护，使得业务插件和应用插件只需要聚焦在功能的开发，同时在更新部署时，根据版本可以自动进行升级的热部署，并且将业务插件剥离，对于负责业务的学习也可以有效地通过接口学习来获得。

即，为了最小化耦合度和促使这些耦合度可管理，提供了一种面向服务的架构，从而使得这些组件动态地发现对方。也可以预先开发出例如：HTTP服务器、配置、日志、安全、用户管理、XML等很多公共功能的标准组件接口。这些组件的兼容性插件实现可以从进行了不同优化和使用代价的不同计算机服务提供商得到。

因为是通过C++实现的，因此都是抽象类，里面只提供接口，具体功能交给插件实现。

下面以一个执行实例进行说明，主要包括以下几个部分：

1)所有插件通过Controller插件进行生命周期管理，通过调用LoadAllPlugins接口加载所有插件；

2)插件都有一个MANIFEST.MF文件，用于存储插件信息：名字、版本等；

3)插件的数输出名称格式为com.lht.<插件名>_<三位版本>.dll，例如：com.lht.logger_1.0.0.dll；

4)所有的插件继承至LHBaseInterface基类，如果是应用类插件则会继承至LHBaseAppInterface基类；

5)基础接口有Init、Uninit、CreateInstance、DestoryInstance、Launch和Close接口，应用类接口有CreateMenu、CreateToolBar、CreatePopupMenu、CreateSystemTrayMenu和CreateDockArea接口；

6)插件使用的一般调用顺序为：Init->CreateInstance->Launch，如果退出，则顺序为：Close->DestoryInstance->Uninit；

7)每个插件通过Init来初始化数据、加载其他相关插件获取插件实例，调用CreateInstance获取插件实例，以用与后续插件调研；

8)Controller会实时监测插件目录的变化，如果存在新版本的插件，则会调用并加载该插件，如果加载成功，则抛出插件升级信号，具体插件可以根据插件名及版本进行升级处理。

具体地，插件可以以模块化的方式(例如：C++文件等)动态地部署至框架中，从而增加、扩展或改变系统的功能。为了以模块化的方式部署到插件系统中，必须遵循预设的规则编写插件，或者使用工具将工程打包成符合规则的模块化插件文件。

因为支持模块化的部署，可以将系统按照模块或其他方式划分为不同的插件类型，从而使得插件模块可以从物理级别上隔离，也就不可能从这个模块直接调用另外模块的接口或类了。进一步的，每个插件可以声明对外提供访问此插件中的类和接口，也可通过将要对外提供的功能声明为实现面向接口、面向服务式的设计。

可以通过提供管理插件服务来实现模块的动态配置和统一管理，基于此服务各模块的配置可在运行期间进行增加、修改和删除，所有对于模块配置的管理统一调用管理插件来实现。

为了保持系统的动态性，在设计时，可以遵循不要静态化地依赖任何服务的原则，从而避免服务不可用时造成的系统崩溃，保证了插件可以“即接入即用，即卸载即无”。

从以上的描述中，可以看出，本发明实施例实现了如下技术效果：提供了一种插件系统包括：多个插件接口；多个插件，每个插件通过匹配对应的插件接口接入系统中，以提供服务；其中，多个插件中的各个插件被模块化地部署到插件系统中，多个插件之间通过插件接口进行信息交互。因为插件是模块化的方式部署到系统中的，因此插件可以实现热部署，在对系统进行更新时候，只需要对某些插件进行更新，无需停止业务，从而可以解决现有的方式中对系统进行更新时候，需要停止业务的问题，达到了在不影响业务进行的情况下，对系统进行更新的技术效果。

显然，本领域的技术人员应该明白，上述的本发明实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明实施例不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明实施例可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。