[发明专利]插件加载系统的构建方法、插件加载系统及计算设备

说明书

本发明公开了一种插件加载系统的构建方法、插件加载系统及计算设备，其中方法包括：构建一个或多个插件服务，基于一个或多个插件服务构建插件服务层；在所述插件服务层的下层构建一个或多个插件模块，基于一个或多个插件模块形成插件层，其中，插件层的每个插件模块动态链接于所述插件服务层，且所述一个或多个插件模块之间相互隔离；以及在所述插件层的下层构建执行程序，所述执行程序适于加载一个或多个插件模块，以便调用与所述插件模块动态链接的插件服务层的插件服务。根据本发明的技术方案，实现了各个插件模块之间的物理隔离特性，能够从根源上解决插件隔离丢失的问题，并且可以灵活扩展插件服务。

技术领域

本发明涉及计算机技术领域，尤其涉及一种插件加载系统的构建方法、插件加载系统及计算设备。

背景技术

目前，由于传统开发下的单体应用程序，往往随着新的业务开发，和无数次的版本的迭代，导致代码膨胀，对开发人员维护工作难度造成指数级的增长，再去开发一个新功能，就会需要维护之前所有老功能，开发人员在这样的环境下进行开发，高昂的开发成本，以至于到后期重构所有代码。而现有的实现单体应用为采用OSGi(Open Service GatewayInitiative，面向Java的动态模型系统)技术进行插件化动态组合。而基于传统OSGi插件开发模式会因为插件层级划分与模块划分问题导致组合软件时引发业务关联逻辑混乱、物理隔离特性丢失等问题。本专利将提出插件层架划分与模块划分的优化方法，最终解决软件关联逻辑混乱、物理隔离特性丢失等问题。

现有技术中的C++插件框架分层架构通常采用传统的OSGi思想，基于OSGi层级划分结构的插件框架包括CTK、CppMicroServices等，其内部指导思想是将Service(插件服务)封装在的Bundle(插件)内部。基于这种插件框架的插件加载原理示意图参见图1所示。OSGi中每个Bundle闭包插件层都拥有发布Service插件服务的能力，而Bundle不但拥有业务逻辑代码闭包，还具有对外提供接口的能力。在加载Bundle C时，需要预先加载BundleA、B。而Bundle C使用BundleA、B中的接口，Bundle C将直接依赖于Bundle A、B。

以现有插件CTK或CppMicroServices为例，现有插件化技术存在如下缺点：物理隔离丢失导致模块耦合度较高，具体地，由于Bundle会依赖Service，存在逻辑的强关联，而Service定义为与Bundle一致的类型，导致后续开发内部耦合度不断叠加。在常用做法中通常将Service统一打包为单一动态库，更改内部逻辑源码后，只能重新构建生成动态库，随着动态库业务功能的增加，源码将不断膨胀，导致更改一行代码需要重新编译的时间较长，编译效率低。由于Bundle与Service闭包为一个插件，扩展Service必将改动Bundle，导致Service的扩展方式不灵活。

为此，需要一种插件加载系统的构建方法，以解决现有技术中存在的问题。

发明内容

为此，本发明提供一种插件加载系统的构建方法、插件加载系统及计算设备，以解决或至少缓解上面存在的问题。

根据本发明的一个方面，提供一种插件加载系统的构建方法，构建一个或多个插件服务，基于一个或多个插件服务构建插件服务层；在所述插件服务层的下层构建一个或多个插件模块，基于一个或多个插件模块形成插件层，其中，插件层的每个插件模块动态链接于所述插件服务层，且所述一个或多个插件模块之间相互隔离；以及在所述插件层的下层构建执行程序，所述执行程序适于加载一个或多个插件模块，以便调用与所述插件模块动态链接的插件服务层的插件服务。

可选地，在根据本发明的插件加载系统的构建方法中，所述插件服务适于发布服务接口，并通过服务接口与一个或多个插件模块通信，以便一个或多个插件模块通过服务接口访问所述服务模块。

可选地，在根据本发明的插件加载系统的构建方法中，所述插件服务包括文件读取服务。