CN112822115B - 一种基于插件式引擎的服务框架构建方法和系统 - Google Patents

Abstract

本发明提出了一种基于插件式引擎的服务框架构建方法和系统，构建至少一个进程，每个进程中加载有至少一个插件，同时构建本地转发路由表、网络转发路由表、虚基类和实体类，其中实体类继承于虚基类，在实体类中提供包含进程或插件发送信息的接口参数，在虚基类中提供作为信息载体的业务参数，根据接口参数实现进程与插件的通信连接；根据所述业务参数选择所述本地转发路由表或所述网络转发路由表实现插件与进程之间所述信息载体的传递。此方法和系统可以快速响应业务需求提高开发效率及增强系统的可伸缩性，框架方式有利于动态扩容，不影响原有业务功能，且能够分布式或集群部署，增强服务的横向扩展能力。

Description

一种基于插件式引擎的服务框架构建方法和系统

技术领域

本发明涉及通信技术领域，尤其是一种基于插件式引擎的服务框架构建方法和系统。

背景技术

伴随新型智能终端的加速普及，以5G为代表的移动通信技术有力地推动了人工智能、物联网、大数据、云计算等技术蓬勃发展，连接服务的内容正在从人与人通信延伸到人与物、物与物的智能连接。海量数据需要接入到后端平台进行存储和计算。

在万物互联的时代，多业务场景及多种类的资源汇聚成了系统的基本形态，系统的可伸缩性是新一代信息技术的重要组成部分。通过射频识别、红外感应器、全球定位系统、激光扫描器等信息传感设备，按约定的协议，把任何物品与互联网相连接，进行信息交换和通信，以实现对物品的智能化识别、定位、跟踪、监控和管理的一种网络。

在传统的开发方式中存在：兼容性差，多样化的接入协议场景下，没有统一的思想进行设计，适配性不友好，对接新业务造成不便；由于接口及参数设计的通用性问题，导致无法快速响应项目的及时需求，接口设计可复用性低，导致工程项目中需要重新变更依赖文件，同步项目工程需要修改接口信息及重新编译等；接口耦合性高，开发效率低。

因此，提出一种基于插件式引擎的服务框架构建方法和系统，来解决请求接口耦合性高和开发效率低的问题亟待解决。

发明内容

为了解决现有技术中的请求接口耦合性高和开发效率低的技术问题，本发明提出了一种基于插件式引擎的服务框架构建方法和系统，用以解决上述技术问题。

在一个方面，本发明提出了一种基于插件式引擎的服务框架构建方法，包括以下步骤：

构建包括多个插件的插件池，多个插件包括具有不同业务功能属性的业务功能模块，

构建至少一个进程，每个进程中加载有至少一个插件，同时构建本地转发路由表以实现同一进程中的不同插件之间的通信，若构建多个进程时，还构建不同进程之间的网络转发路由表以实现不同进程的插件之间的通信，其中根据插件的加载和卸载实时更新本地转发路由表和网络转发路由表；

构建虚基类和实体类，其中实体类继承于虚基类，在实体类中提供包含进程或插件发送信息的接口参数，在虚基类中提供作为信息载体的业务参数，

根据接口参数实现进程与插件的通信连接；

根据业务参数选择本地转发路由表或网络转发路由表实现插件与进程之间信息载体的传递。

进一步的，虚基类包括响应类和请求类。虚基类抽象了一个方法。本方案中提到的响应类和请求类就是这两个虚基类的具体继承实现，其中响应类和请求类都有各自的抽象方法，该方法就是进程与插件交互的接口。

进一步的，所述接口参数包括供所述响应类继承的响应类实例参数和供所述请求类继承的请求类实例参数。

进一步的，本地转发路由表具体构建方式为：

S1：进程构建响应类实例参数进程获取插件发送的请求类实例参数；

S2：进程获取插件自身的唯一ID；

S3：将唯一ID与初始化时的请求类实例参数进行绑定生成本地转发路由表。

进一步的，网络转发路由表具体构建方式为：

S21：获取进程的唯一标识，进程通过唯一标识路由到另一个进程；

S22：将另一个进程中与其所加载的插件的唯一ID进行映射；

S23：基于映射关系路由到另一个进程中所加载的插件形成网络转发路由表。

进一步的，业务参数包括消息头和消息体，消息头的内容包括协议版本、会话ID、源地址和目的地址，协议版本为插件之间的通信协议的版本，会话ID是插件每次请求产生的唯一标识符，该标识具有请求的唯一性可作为消息流的跟踪线索方便问题的排查和定位，源地址代表插件的外部请求来源的唯一标识，目的地址代表接收外部请求的唯一标识；消息体存储有插件所要进行交互的具体可变业务参数内容。消息头主要是作为基础信息使用不涉及业务内容。消息体定义了应用于结构化数据的JSON格式数据及非结构化数据的流式数据，这部分内容就是插件与插件间交互的具体业务数据。同时将消息头和消息体两者数据封装在一个数据结构体中作为接口参数使用。

进一步的，的具体可变业务参数由JSON格式封装。响应类和请求类的方法是固定不变的，它不会因为业务需求的改变而改变，唯一需要变更的是请求的业务参数。

进一步的，业务参数中的目的地址作为进程的主键索引，进程在主键索引下于本地转发路由表和网络转发路由表寻找消息路由路径。

根据本发明的第二方面，提出了一种计算机可读存储介质，其上存储有一或多个计算机程序，该一或多个计算机程序被计算机处理器执行时实施上述方法。

根据本发明的第三方面，提出了一种基于插件式引擎的服务框架构建系统，该系统包括：

插件池构建单元：配置为构建包括多个插件的插件池，多个插件包括具有不同业务功能属性的业务功能模块，

路由表构建单元：配置为构建至少一个进程，每个进程中加载有至少一个插件，同时构建本地转发路由表以实现同一进程中的不同插件之间的通信，若构建多个进程时，还构建不同进程之间的网络转发路由表以实现不同进程的插件之间的通信，其中根据插件的加载和卸载实时更新本地转发路由表和网络转发路由表；

信息传递单元：配置为构建虚基类和实体类，其中实体类继承于虚基类，在实体类中提供包含进程或插件发送信息的接口参数，在虚基类中提供作为信息载体的业务参数，

根据接口参数实现进程与插件的通信连接；

根据业务参数选择本地转发路由表或网络转发路由表实现插件与进程之间信息载体的传递。

本发明提出了一种基于插件式引擎的服务框架构建方法和系统，通过构建虚基类继承实体类的方式，使得插件和进程之间请求和响应的通信方式不变，只需改变虚基类中的业务参数来通过进程实现插件和插件之间的通信：

1、框架接口定义方式有利于避免接口或参数变更的风险，提高开发效率；

2、框架方式有利于动态扩容，不影响原有业务功能；

3、高可用的设计框架，封装业务简易；

4、框架设计的解耦性高；

5、分布式或集群部署，增强服务的横向扩展能力。

附图说明

包括附图以提供对实施例的进一步理解并且附图被并入本说明书中并且构成本说明书的一部分。附图图示了实施例并且与描述一起用于解释本发明的原理。将容易认识到其它实施例和实施例的很多预期优点，因为通过引用以下详细描述，它们变得被更好地理解。通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是本申请可以应用于其中的示例性系统架构图；

图2是本申请的一个实施例的一种基于插件式引擎的服务框架构建方法的流程图；

图3是本申请的一个具体的实施例的一种服务框架构建的主体示意图；

图4是本申请的一个实施例的一种进程加载插件前的进程初始化流程图；

图5是本申请的一个实施例中一种进程初始加载插件交互流程图；

图6是本申请的一个实施例中本地转发路由表构建流程图；

图7是本申请的一个实施例中网络转发路由表构建流程图；

图8是本申请的一个实施例中基于插件式引擎的服务框架构建系统；

图9是适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1示出了可以应用本申请实施例的一种基于插件式引擎的服务框架构建方法的示例性系统架构100。

如图1所示，系统架构100可以包括数据服务器101，网络102和主服务器103。网络102用以在数据服务器101和主服务器103之间提供通信链路的介质。网络102可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

主服务器103可以是提供各种服务的服务器，例如对数据服务器101上传的信息进行处理的数据处理服务器。数据处理服务器可以进行基于插件式引擎的服务框架构建。

需要说明的是，本申请实施例所提供的基于插件式引擎的服务框架构建方法一般由主服务器103执行，相应地，基于一种基于插件式引擎的服务框架构建方法的装置一般设置于主服务器103中。

需要说明的是，数据服务器和主服务器可以是硬件，也可以是软件。当为硬件时，可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器。当为软件时，可以实现成多个软件或软件模块(例如用来提供分布式服务的软件或软件模块)，也可以实现成单个软件或软件模块。

应该理解，图1中的数据服务器、网络和主服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参照图2，图2示出了根据本申请的实施例的一种基于插件式引擎的服务框架构建方法的流程图。如图2所示，该方法包括以下步骤：

S201：构建包括多个插件的插件池，多个插件包括具有不同业务功能属性的业务功能模块，

S202：构建至少一个进程，每个进程中加载有至少一个插件，同时构建本地转发路由表以实现同一进程中的不同插件之间的通信，若构建多个进程时，还构建不同进程之间的网络转发路由表以实现不同进程的插件之间的通信，其中根据插件的加载和卸载实时更新本地转发路由表和网络转发路由表；

S203：构建虚基类和实体类，其中实体类继承于虚基类，在实体类中提供包含进程或插件发送信息的接口参数，在虚基类中提供作为信息载体的业务参数，根据接口参数实现进程与插件的通信连接；根据业务参数选择本地转发路由表或网络转发路由表实现插件与进程之间信息载体的传递。

插件池负责具体功能模块功能的实现，进程负责动态加载插件池的插件及消息转发，服务框架整体上以插件引擎为基础，实现了插件间消息的互联互通，互联是进程之间的连接，互通是插件间的通信，其依赖于进程的路由表实现，通信方式有在单进程中内存交互和在多进程中网络转发两种形式。

在具体的实施例中，虚基类包括响应类和请求类。虚基类抽象了一个方法。本方案中提到的响应类和请求类就是这两个虚基类的具体继承实现，其中响应类和请求类都有各自的抽象方法，该方法就是进程与插件交互的接口。

假设定义了虚基类RequestHelper和ResponseHelper,其中RequestHelper虚基类中定义了一个方法为Request函数，ResponseHelper定义了一个Response方法，且Request和Response的参数为上述参数定义的类型，假定为类型A，那么当插件有消息要往外发送时就调用了ResponseHelper虚基类的Response方法加上A类型的参数信息向外传递，同理进程通过RequestHelper的Request函数加上A类型的参数信息向插件内部传递内容。

基于上述描述可以有效的解决因业务变更带来的接口变更风险。因此当业务变更时，无需改变框架代码只需要调整参数信息就可以解决业务需求。

传统定义接口的方式是依据业务功能定义多个供外部访问的接口，组合使用接口的方式实现业务功能。与其不同的是本设计中定义的外部接口只有一个可供访问，在业务变更的情况下接口文件无需重新提供给调用者进行重新编译，只需调整协议即可满足需求，本设计可理解为将多接口转换为多协议的方式，提高了可移植性。

下面参照图3，图3为本发明提供的服务框架构建的主体示意图，图中有三个进程相互连接，其中A-T代表的是插件S301。每个进程S302周边都有对应的“插件池”，形成了三个“插件池”的分布式互联互通。每个插件间都可以通过进程进行相互访问，构成了一个网状的服务拓扑结构S303，表达了基于一种插件引擎服务框架的核心思想。

插件池是插件引擎的基础是由不同种类能力集的插件汇聚而成，其中各个独立的插件是根据业务功能属性封装不同的业务功能模块。插件的框架设计主要包括了对插件接口及参数抽象，方便业务功能的插件化开发。

进程是插件与插件间通信的桥梁，不同插件在同一进程中可以选择高效的内存交户,多个进程间的不同插件选择网络转发，即通信方式主要分为内存和网络两个部分。通信消息依据进程的转发路由表信息进行路径的选择。因此依据网络转发功能可以将插件模块进行分布式部署提高服务的整体能力。

下面参照图4，图4所示为本发明提供的进程加载插件前的进程初始化流程图，具体步骤如下：

S401：读取进程初始启动时需要的基本配置信息，比如监听端口、插件池的加载路径以及需要连接的ip地址和端口信息等；

S402：构建互联通的基础，通过读取配置的监听端口并启动监听服务等待其他进程的连接；

S403：通过插件池的路径，动态的将多个插件模块加载到进程中，其中每个插件在配置文件中都有对应项的属性配置，这个可以提供插件的动态加载和卸载；

S404：进程加载完成插件后会启动定时器定时检测插件信息是否变更，有变更时会自动更新插件列表，可实现热启动和热停止；

S405：进程启动时需要判断的一个连接条件，当有配置连接地址和端口时，表示需要连接到其他进程，实现插件间的网络转发通信；

S406：进程启动成功，此时就可以依据插件的业务功能开始业务数据的交互提供服务。

S407：当服务群中每增加一个进程，新增的进程通过配置的连接ip和端口连接到旁邻的进程上时，所连接上的进程会将当前的所有的进程ip地址和端口同步给新增加的进程，此时新增的进程会依据ip地址和端口分别发起连接动作。

下面参照图5，图5所示为本发明进程初始加载插件交互流程图，具体步骤如下：

S501：进程通过调用动态加载实体接口，将插件加载到进程的内存中运行；

S502：进程构造好实体类的响应类参数；

S503：插件被加载到进程内存中，并调用插件实体接口，传入响应类的参数；

S504：是插件内部需要构造好返回请求类的参数，进程会将其保存起来，当需要请求消息时将会用到该参数；

S505：进程与插件交换成功。

响应类和请求类分别对应一个响应方法和请求方法，两个方法的业务参数采用了灵活的数据结构参数作为消息传递的格式，可以满足任何结构化数据的传输要求，增强了系统的灵活性。通过固化接口+可变参数的方式可以使得模块与模块间的耦合降低，灵活响应业务需求同时又不会影响到原有的业务功能点，所说的固化接口由虚基类继承实体类的方式定义。

下面参照图6，图6是本发明本地转发路由表构建流程图，具体步骤如下：

S601：进程构建响应类实例参数进程获取插件发送的请求类实例参数；

S602：进程获取插件自身的唯一ID；

S603：将唯一ID与初始化时的请求类实例参数进行绑定生成本地转发路由表。

下面参照图7，图7是本发明网络转发路由表构建流程图，具体步骤如下：

S701：获取进程的唯一标识，进程通过唯一标识路由到另一个进程；

S702：将另一个进程中与其所加载的插件的唯一ID进行映射；

S703：基于映射关系路由到另一个进程中所加载的插件形成网络转发路由表。

路由表的生成是在进程进行加载插件时就会形成，同时进程与进程间会实时同步路由表信息。路由表分为两个层面，第一层面是进程路由到进程，第二层面是进程路由给插件模块；因此在设计路由主键标识时，应将插件唯一ID作为主键索引，并在进程中形成了两张路由表信息，一张是内部的进程本地的路由表信息，另一张是网络转发的路由表信息，消息路由时会分别从本地路由表和网络路由表中进行查找。进程在收到插件的消息时会通过插件唯一索引到路由表中查找然后将消息分发出去，其对消息通信模式的选择是内存交互还是网络转发是依据消息的目的地址字段是否有查找到本地标识对象，若存在就选择内存交互否则就通过网络转发。路由表中存储的路由信息是实时更新的最新路由表数据。因为每个进程都有存储了一份最新的路由表，那么消息的路由转发是直接发送给目的地址，无需进行路由跳数的统计。同时插件节点进行增删时，路由表的信息也会自动进行更新调整。

下面参照图8，图8是本发明基于插件式引擎的服务框架构建系统，具体步骤如下：

S801：插件池构建单元：配置为构建包括多个插件的插件池，多个插件包括具有不同业务功能属性的业务功能模块，

S802：路由表构建单元：配置为构建至少一个进程，每个进程中加载有至少一个插件，同时构建本地转发路由表以实现同一进程中的不同插件之间的通信，若构建多个进程时，还构建不同进程之间的网络转发路由表以实现不同进程的插件之间的通信，其中根据插件的加载和卸载实时更新本地转发路由表和网络转发路由表；

S803：信息传递单元：配置为构建虚基类和实体类，其中实体类继承于虚基类，在实体类中提供包含进程或插件发送信息的接口参数，在虚基类中提供作为信息载体的业务参数，根据接口参数实现进程与插件的通信连接；根据业务参数选择本地转发路由表或网络转发路由表实现插件与进程之间信息载体的传递。

下面参考图9，其示出了适于用来实现本申请实施例的电子设备的计算机系统900的结构示意图。图9示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分508加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM903中，还存储有系统900操作所需的各种程序和数据。CPU501、ROM502以及RAM903通过总线504彼此相连。输入/输出(I/O)接口905也连接至总线904。

以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本申请的方法中限定的上述功能。需要说明的是，本申请的计算机可读存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读存储介质，该计算机可读存储介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：构建包括多个插件的插件池，所述多个插件包括具有不同业务功能属性的业务功能模块，构建至少一个进程，每个所述进程中加载有至少一个插件，同时构建本地转发路由表以实现同一进程中的不同插件之间的通信，若构建多个进程时，还构建不同进程之间的网络转发路由表以实现不同进程的插件之间的通信，其中根据插件的加载和卸载实时更新所述本地转发路由表和网络转发路由表；构建虚基类和实体类，其中实体类继承于虚基类，在实体类中提供包含进程或插件发送信息的接口参数，在虚基类中提供作为信息载体的业务参数，根据接口参数实现进程与插件的通信连接；根据业务参数选择本地转发路由表或网络转发路由表实现插件与进程之间信息载体的传递。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (10)

1.一种基于插件式引擎的服务框架构建方法，其特征在于，包括以下步骤：

构建包括多个插件的插件池，所述多个插件包括具有不同业务功能属性的业务功能模块，

构建至少一个进程，每个所述进程中加载有至少一个插件，同时构建本地转发路由表以实现同一进程中的不同插件之间的通信，若构建多个进程时，还构建不同进程之间的网络转发路由表以实现不同进程的插件之间的通信，其中根据插件的加载和卸载实时更新所述本地转发路由表和网络转发路由表；

构建虚基类和实体类，其中所述实体类继承于所述虚基类，在所述实体类中提供包含所述进程或所述插件发送信息的接口参数，在所述虚基类中提供作为信息载体的业务参数，

根据所述接口参数实现所述进程与所述插件的通信连接；

根据所述业务参数选择所述本地转发路由表或所述网络转发路由表实现插件与进程之间所述信息载体的传递。

2.根据权利要求1所述的基于插件式引擎的服务框架构建方法，其特征在于，所述虚基类包括响应类和请求类。

3.根据权利要求2所述的基于插件式引擎的服务框架构建方法，其特征在于，所述接口参数包括供所述响应类继承的响应类实例参数和供所述请求类继承的请求类实例参数。

4.根据权利要求3所述的基于插件式引擎的服务框架构建方法，其特征在于，所述本地转发路由表具体构建方式为：

S1:所述进程构建响应类实例参数所述进程获取所述插件发送的所述请求类实例的参数；

S2:所述进程获取插件自身的唯一ID；

S3:将所述唯一ID与初始化时的所述请求类实例参数进行绑定生成本地转发路由表。

5.根据权利要求4所述的基于插件式引擎的服务框架构建方法，其特征在于，所述网络转发路由表具体构建方式为：

S21：获取所述进程的唯一标识，所述进程通过所述唯一标识路由到另一个所述进程；

S22：将所述另一个进程中与其所加载的所述插件的唯一ID进行映射；

S23：基于所述映射关系路由到所述另一个进程中所加载的插件形成网络转发路由表。

6.根据权利要求1所述的基于插件式引擎的服务框架构建方法，其特征在于，所述业务参数包括消息头和消息体，所述消息头的内容包括协议版本、会话ID、源地址和目的地址，所述协议版本为所述插件之间的通信协议的版本，所述会话ID是所述插件每次请求产生的唯一标识符，该标识具有请求的唯一性可作为消息流的跟踪线索方便问题的排查和定位，所述源地址代表所述插件的外部请求来源的唯一标识，所述目的地址代表接收所述外部请求的唯一标识；所述消息体存储有所述插件所要进行交互的具体可变业务参数内容。

7.根据权利要求6所述的基于插件式引擎的服务框架构建方法，其特征在于，所述的具体可变业务参数由JSON格式封装。

8.根据权利要求6所述的基于插件式引擎的服务框架构建方法，其特征在于，所述业务参数中的目的地址作为所述进程的主键索引，所述进程在所述主键索引下于所述本地转发路由表和所述网络转发路由表寻找所述消息路由路径。

9.一种计算机可读存储介质，其上存储有一或多个计算机程序，其特征在于，该一或多个计算机程序被计算机处理器执行时实施权利要求1至8中任一项所述的方法。

10.一种基于插件式引擎的服务框架构建系统，其特征在于，包括插件池构建单元、路由表构建单元和信息传递单元，其中，

所述插件池构建单元：配置为构建包括多个插件的插件池，所述多个插件包括具有不同业务功能属性的业务功能模块；

所述路由表构建单元：配置为构建至少一个进程，每个所述进程中加载有至少一个插件，同时构建本地转发路由表以实现同一进程中的不同插件之间的通信，若构建多个进程时，还构建不同进程之间的网络转发路由表以实现不同进程的插件之间的通信，其中根据插件的加载和卸载实时更新所述本地转发路由表和网络转发路由表；

所述信息传递单元：配置为构建虚基类和实体类，其中所述实体类继承于所述虚基类，在所述实体类中提供包含所述进程或所述插件发送信息的接口参数，在所述虚基类中提供作为信息载体的业务参数，

根据所述接口参数实现所述进程与所述插件的通信连接；

根据所述业务参数选择所述本地转发路由表或所述网络转发路由表实现插件与进程之间所述信息载体的传递。

Images