CN103297381B - 一种基于插件的业务访问方法及其系统 - Google Patents

Abstract

本申请提供一种基于插件的业务访问方法及其系统，应用于基于插件的业务访问系统进行业务访问处理的过程，所述业务访问系统在系统初始化时，根据插件配置文件为该系统中的插件统一配置输入输出接口，该方法包括：所述业务访问系统接收业务请求，获取其中携带的业务参数；所述业务访问系统根据所述业务请求，确定需要调用的插件；所述业务访问系统将所述业务参数作为输入参数，并通过调用所述需要调用的插件进行业务处理，得到业务处理结果；其中，插件间根据统一配置的输入输出接口交互信息；所述业务访问系统输出所述业务处理结果。

Description

一种基于插件的业务访问方法及其系统

技术领域

本申请涉及通信技术领域，尤其涉及一种基于插件的业务访问方法及其系统。

背景技术

目前的业务访问系统，例如，竞价系统、质量分析系统等，采用插件算法模型，将各类算法整合并基于插件和WEB服务器统一提供服务。插件系统是支持功能扩展的宿主系统，能够在不更改系统本身的前提下，灵活扩展各类功能，也有利于模块化的开发方式。

由于用户访问的业务千差万别，而现有的插件算法模型是基于模块化的方式存在的，其功能已经固定，一种插件算法模型很难满足不同的访问业务，因此，目前的业务访问系统大都通过集成插件算法模型模块的方式，选择与用户访问的业务所实现功能相同或近似的插件，根据访问业务的具体情况对插件进行修改，即更改插件的代码，重新构建业务流程。

但是，这种业务访问系统需要针对不同的业务类型对插件重新编码，生成的业务访问系统的耦合性大，适应性差。

发明内容

本申请实施例提供了一种基于插件的业务访问方法及其系统，用以降低业务访问系统中的插件之间的耦合性。

本申请实施例提供的一种基于插件的业务访问方法，应用于基于插件的业务访问系统进行业务访问处理的过程，其特征在于，所述业务访问系统在系统初始化时，根据插件配置文件为该系统中的插件统一配置输入输出接口，该方法包括：

所述业务访问系统接收业务请求，获取其中携带的业务参数；

所述业务访问系统根据所述业务请求，确定需要调用的插件；

所述业务访问系统将所述业务参数作为输入参数，并通过调用所述需要调用的插件进行业务处理，得到业务处理结果；其中，插件间根据统一配置的输入输出接口交互信息；

所述业务访问系统输出所述业务处理结果。本申请实施例提供的一种基于插件的业务访问系统，包括：

插件模块，用于进行业务处理；

初始化模块，用于在系统初始化时，根据插件配置文件为系统中的插件模块统一配置输入输出接口；

接收模块，用于接收业务请求，获取其中携带的业务参数；

处理模块，用于根据所述业务请求，确定需要调用的插件模块；以及，将所述业务参数作为输入参数，并通过调用所述需要调用的插件模块进行业务处理，得到业务处理结果；其中，插件模块间根据统一配置的输入输出接口交互信息；

输出模块，用于输出所述业务处理结果。

与现有技术相比，本申请的上述实施例具有以下有益技术效果：

本申请实施例通过根据所述业务请求，确定需要调用的插件，并将业务参数作为输入参数，通过调用现有的插件进行业务处理，得到业务处理结果，其中，插件间根据统一配置的输入输出接口交互信息，令业务访问系统与插件更加独立，降低插件与业务访问系统的耦合性，使得业务访问系统更易推广，具有更广泛的适用性。

附图说明

图1为本申请实施例提供的基于插件的业务访问系统架构图；

图2为本申请实施例提供的基于插件的业务访问的流程示意图；

图3为本申请实施例提供的基于插件的业务访问系统的结构示意图。

具体实施方式

下面结合附图对本申请的技术方案进行清楚、完整的描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请的保护范围。

参见图1所示，为本申请实施例提供的基于插件的业务访问系统架构图，该业务访问系统主要划分为基础模块层11、应用模块层12和组合服务层13。其中：

基础模块层11中包括插件(或插件模块)，插件为一个或多个，用于执行业务功能，多个插件的组合调用和执行可以实现某一特定业务。插件包括但不限于Java算法插件、第三方算法插件、搜索算法插件、个性化算法插件等，可根据业务需要增减。

应用模块层12中包括业务处理模块，例如质量分析模块、竞价算法模块等，每个业务处理模块用于实现对应的业务功能，可通过调用基础模块层的插件实现业务处理。

组合服务层13用于提供通用服务，例如包括用于对登录用户进行身份认证的认证模块，还可以提供与用户交互的界面，例如，提供用户登录界面，以供用户登录该系统，还可提供业务处理界面，以接收用户提交的业务处理请求和业务参数等。

此外，本申请实施例提供的业务访问系统还可包括一些常规管理功能模块，如插件管理模块、服务均衡调度模块以及安全及配额管理模块等。其中，插件管理模块用于管理各插件，例如，为各插件分配存储空间、记录增加、删除插件的信息以及插件调用信息等；服务均衡调度模块用于确定从哪个服务器上调用插件，以实现服务器的负载均衡(在集群服务器中，各服务器上均可部署插件)；安全及配额管理模块用于管理用户权限，以及设置各业务的可用的服务和请求的并发量，保证系统的可用性。

此外，本申请实施例还可进一步在上述常规管理功能模块的基础上，增加更新模块，用于针对用户行为的更新，实时更新索引文件。

上述业务访问系统中还配置有系统配置文件，在系统初始化过程中，该系统根据系统配置文件进行系统初始化操作。系统配置文件可包括全局配置文件、插件配置文件等。通常，系统配置文件为XML(Extensible Markup Language，可扩展标记语言)格式。

全局配置文件中定义有服务端口、日志文件的目录位置、请求并发数、超时设置参数等，系统初始化时，可将全局配置文件中定义的参数读取到系统内存中，以便在业务处理过程中参考。

每个插件对应设置有插件配置文件。插件配置文件用于指示该插件的执行路径以及输出参数格式。具体的，插件配置文件中可包括以下之一或组合：插件名称、插件路径、插件索引、插件配置、插件类名、授权用户信息、依赖的其他插件信息、插件的分层信息以及插件输出格式信息等。其中，插件路径表示实现对应业务所需要的插件以及插件的执行顺序；插件索引为插件本身需要的数据文件，例如某个词的点击率、点击量等；插件配置为该插件的配置信息，包括插件算法用到的阈值以及日志的存储位置等信息；授权用户信息用于指示允许调用该插件的授权用户的信息；依赖的其他插件信息用于指示实现该插件功能需要调用的其他插件的信息；插件的分层信息用于标识该插件应用于业务访问系统架构中的哪层(基础模块层、应用模块层还是组合服务层)；插件输出格式信息包括：输出字段的名称及属性值。

基于上述插件配置文件，本申请实施例提供的基于插件的业务访问系统进行系统初始化时，进行如下插件初始化操作：读取插件配置文件，并实例化插件，然后根据配置文件内容进行插件初始化。插件初始化操作可包括但不限于：

(1)根据插件配置文件中定义的输入输出接口，为插件配置统一的输入输出接口。插件配置文件中定义的输入/输出接口用于规定插件的输入、输出接口信息，即系统运行时插件的输入/输出参数格式信息。输出接口用于规定插件输出参数的输出样式，输入接口用于规定插件输入参数的解析方法。

(2)根据插件配置文件中定义的索引，将相应日志文件载入内存。

(3)根据插件配置文件对插件列表进行初始化。在初始化插件列表的过程中，业务访问系统还需要检测插件的依赖完整性，即，在实现过程中，对于那些需要其他插件的参与才能实现自身功能的插件，在初始化插件列表的过程中，检测该插件与相关插件的连接是否正常。

在系统初始化完成后，该系统即可接收用户的业务请求，并进行相应处理。

参见图2，为本申请实施例提供的基于插件的业务访问流程示意图，该流程可包括：

步骤201，业务访问系统接收业务请求，获取其中携带的业务参数。

具体实施时，业务访问系统可支持post和get请求方式。业务访问系统可根据系统初始化后的统一输入接口解析接收到的业务请求，识别出其中携带的业务参数。

步骤202，业务访问系统根据该业务请求，确定需要调用的插件。

具体实施时，业务访问系统可根据业务请求中携带的业务参数，如业务标识，或者根据业务请求中携带的其它参数以及统一输入接口的规定，识别出本次所请求的业务的类型。

步骤203，业务访问系统将业务参数作为输入参数，并通过调用需要调用的插件，得到业务处理结果；其中，插件间根据配置的统一接口交互信息。

步骤204，业务访问系统输出业务处理结果。

具体实施时，业务访问系统根据全局配置文件调用输出接口，将业务处理结果返回给用户，如输出XML文件或者json数据流。

进一步的，业务访问系统在接收到用户提交的业务请求后，可先对该用户的身份进行认证，若认证通过，则允许该用户访问该系统，否则拒绝为该用户提供访问服务。具体的，业务访问系统通过安全及配额管理模块对用户进行身份验证，例如，在安全及配额管理模块中预先存储有允许访问该业务访问系统的用户身份信息，当用户登录业务访问系统时，系统将该用户身份与存储于安全及配额管理模块中的用户身份信息进行匹配，若匹配，则说明该用户具有访问该系统的权限，身份验证通过。

在上述流程的步骤203中，业务访问系统目前采用基于编译依赖的插件交互方式。基于编译依赖的插件交互是通过插件指针指示调用public(公共)开放的接口函数，通过编译依赖的方式获取接口函数的执行方法。例如，假设存在4个插件，插件3分别调用插件1，2，4，插件3可以通过编译联编的方式，获取已初始化的插件指针，调用插件1，2，4的API(Application Programming Interface，应用程序编程接口)函数来完成需要的功能。

除此以外，本申请实施例还可采用以下两种方式实现插件之间的信息交互。根据所采用的交互方式不同，下面分别以不同的实施例进行详细描述。

实施例一

本实施例描述了基于上下文信息的插件交互方式。

在本实施例中，在业务访问系统进行系统初始化时，除了进行前述的初始化操作，还需要根据插件配置文件中定义的插件路径生成业务执行链，并在系统初始化完成后将该业务执行链配置为全局业务执行链。一个业务执行链对应一种业务，根据执行链对应的业务处理逻辑，在业务执行链上包含一个或一系列有序的插件标识(如插件名称)，通过按照执行链的顺序调用其上的插件，可以实现该业务执行链所对应的业务。业务执行链可以与业务标识对应，表示该业务执行链可以实现相应业务标识所标识的业务。

在业务处理过程中，业务访问系统依据用户发起的业务访问请求确定所请求的业务后，根据该业务的标识确定对应的业务执行链，然后，业务访问系统根据该业务执行链调用并执行插件，以完成用户所请求的业务。在业务执行链中包括多个插件的情况下，若某一业务需要调用多个插件实现，则对于调用的每个插件，在输出参数时，按照统一配置的输出接口的规定，将本插件的输出参数格式化为该输出接口规定的格式，并存储到内存中的上下文信息区域，该上下文信息区域为该系统中的内存区域，该区域可被各插件所共享；在获取输入参数时，根据当前执行的业务执行链，确定本插件关联的上一个插件，然后按照统一配置的输入接口的规定，从上下文信息区域中读取和解析该上一个插件的输出参数，作为本插件的输入参数。其中，对于当前业务执行链中的第一个插件，在获取输入参数时，按照统一配置的输入接口的规定读取和解析从用户提交的业务访问请求中解析出的业务参数，作为该插件的输入参数。

具体的，为了方便插件间的信息交互，可在上下文信息区域中存储全局变量。相应的，插件可利用addFilterContext命令将需要交互的信息添加到系统上下文信息区域，如将其输出参数赋值给该上下文信息区域中的全局变量，以便与该插件关联的其它插件从该上下文信息区域中读取该全局变量作为输入参数。具体的，需要获取信息的插件利用业务执行链找到该需要交互的插件，通过GetFilterContext命令得到上下文信息区域中相应插件对应的信息，作为本插件的输入参数。

例如，假设一个业务需要调用4个插件，其中插件3分别调用插件1，2，4的内容，则业务执行链只要满足插件1、2、4在插件3之前执行即可，插件1、2、4的执行顺序不做限制。插件1、2、4执行完后，分别将输出结果放到上下文信息区域中，插件3在执行前，可以到上下文信息区域中取出插件1、2、3的输出结果，作为插件3的输入，从而实现插件间的信息交互。

通过以上流程可以看出，基于上下文信息的插件交互方式降低了插件之间的耦合性，模块间依赖性低，使用方式简单，交互插件透明。

实施例二

本申请实施例描述了基于反射机制的插件交互方式。

基于反射机制的插件交互，类似于反射的类型无关的插件交互方式，如JAVA反射机制。反射机制支持创建灵活的代码，代码可以在运行时装配，无需在模块间进行编译和链接。反射机制的交互方式允许在编写与执行程序时，使插件模块代码能够灵活接入其他插件模块类的内部信息，而不是通过编译选定的类代码，这使得反射机制的交互方式能够构建灵活的应用和类型无关的运行机制。

在系统配置文件中，包括业务逻辑配置文件，该业务逻辑配置文件中定义了各业务的业务执行逻辑，其中包括相应业务需要调用的插件名称。

具体的，以某个业务(以下表示为业务A)例如用户输入请求中携带了需要执行的业务ID，该业务ID对应业务A，根据该业务ID查找业务逻辑文件，可以得到执行该业务需要调用的插件名称。以需要执行插件1、2、3、4，且插件3需要调用插件1、2、4为例，本申请实施例中，首先针对插件1、2、4设计公用函数(以下以doAPI表示该公用函数)，并对doAPI进行注册。doAPI函数中包含有插件1、2、4的开放接口，可供插件3调用。插件1，2，4分别完成不同的doAPI的逻辑，在自己的doAPI代码中实现需要提供给其他插件的业务逻辑，即，插件1，2，4分别完成自己的doAPI接口。依赖其他插件逻辑的插件3，根据业务A的业务逻辑，将需要调用的插件的doAPI接口写入其插件代码中，主动调用插件1、2、4开放的接口，从而实现各个插件的逻辑功能。对于基于反射机制的插件交互方式，被调用的各个插件(例如，插件1、2、4)之间无调用顺序，即，一个插件的调用不依赖于其他插件的调用结果。

在业务处理过程中，业务访问系统依据用户发起的业务访问请求确定所请求的业务后，插件3可以基于统一的doAPI的方式，直接调用插件1，2，4提供的公用函数(doAPI函数)实现需要的功能，无需对插件1、2、4进行编译和链接，解决了编译依赖的问题。

本申请的上述实施例可采用目前常用的编程语言实现。优选的，本申请实施例在C++语言编写的插件系统中应用反射机制实现插件之间的交互。

通过以上描述可以看出，与基于编译依赖的插件交互方式不同的是，基于反射机制的插件交互方式不需要编译依赖，而是通过统一的doAPI接口即可访问。反射机制支持创建灵活的代码，代码可以在运行时装配，无需在插件间进行编译和链接，在执行代码时，一个插件代码能够灵活接入其他插件的类代码，而不是通过编译选定类代码，因而与现有基于编译依赖的交互方式相比，基于反射机制的插件交互方式能够在不进行编译依赖的情况下，可以直接调用到其他插件的已注册的开放的接口函数，降低了插件之间的耦合性，使得插件调用的灵活性更高，而且，基于反射机制的插件交互方式能够准确控制需要开放的接口，需求插件统一通过doAPI进行交互，不需要了解太多交互插件的细节，保证了接口安全。相比前两种插件交互方式，基于反射机制的插件交互不需要依据全局变量以及编译依赖等实现，在灵活性以及耦合性方面优势明显，这使得反射机制能够构建灵活的应用和类型无关的插件运行方式。

考虑到对于某些业务访问系统，例如竞价系统中的排序、匹配等功能，对于索引数据的实时性要求较高，本申请实施例中的业务访问系统提供了实时更新功能，如有系统中的实时更新调度模块针对用户输入的参数更新，实时获取相应的算法结果。具体的，本申请实施例通过设定守护线程的方法监控用户的输入情况，守护线程采取了主动检测的方式，定期扫描监控索引文件的时间戳，若发现时间戳比当前使用的索引文件时间戳更新的索引文件，则更新当前使用的索引文件，如，索引文件2的时间戳晚于索引文件1的时间戳，则用索引文件2更新索引文件1。

本申请实施例中的业务访问系统可基于WEB服务器实现，优选的，本申请实施例采用基于Nginx的WEB服务器实现。Nginx的WEB服务器相比传统的Apache、Lighthttpd和其他WEB服务器，具有高并发能力，能够满足算法服务的高并发特殊要求；具有高鲁棒性，通过多进程设计，能够减少服务宕机；支持无缝切换等功能。基于Nginx web服务器的上述优点，本申请的业务访问系统能够较快较好的满足多个需求方的算法需求。

基于相同或相近的申请构思，本申请实施例还提供一种基于插件的业务访问系统，参见图3所示，为本申请实施例提供的基于插件的业务访问系统的结构示意图，该业务访问系统包括：

插件模块31，用于进行业务处理。

初始化模块32，用于在系统初始化时，根据插件配置文件为系统中的插件模块统一配置输入输出接口。

接收模块33，用于接收业务请求，获取其中携带的业务参数。

处理模块34，用于根据业务请求，确定需要调用的插件模块31；以及，将业务参数作为输入参数，并通过调用需要调用的插件模块进行业务处理，得到业务处理结果；其中，插件模块间根据统一配置的输入输出接口交互信息。

输出模块35，用于输出业务处理结果。

具体的，初始化模块32还用于，根据插件配置文件中配置的各业务各自对应的插件执行路径，生成对应的业务执行链。

处理模块34具体用于，根据业务请求，确定需要执行的业务执行链；以及，根据确定出的业务执行链，调用并运行相应插件；其中，两个关联的插件进行信息交互的过程中，前一个插件将其输出参数按照统一配置的输出接口存储到内存中的上下文区域，后一个插件根据所述业务执行链，并按照统一配置的输入接口，从上下文区域获取与该插件关联的前一个插件的输出参数作为本插件的输入参数；上下文区域为所述业务访问系统的内存中各插件的共享区域。

具体的，业务请求对应的业务逻辑中，有插件调用至少其它2个插件，调用该至少其它2个插件的插件代码中包含调用该至少其它2个插件的API的语句；处理模块34具体用于，通过执行该语句调用该至少其它2个插件，得到业务处理结果。

具体的，业务访问系统中设置有插件索引信息，插件配置文件中包括插件的索引信息，所述业务访问系统根据配置文件中的插件索引信息，确定需要调用的插件；

系统还包括更新模块36，用于按照设定周期检测，并当检测到时间戳更新的插件索引信息时，用检测到的时间戳更新的插件索引信息更新插件配置文件中的插件索引信息。

优选的，业务访问系统为基于nginx的轻量级WEB服务系统。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备(可以是手机，个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

本领域技术人员可以理解，实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本申请的保护范围。

Claims (10)

1.一种基于插件的业务访问方法，应用于基于插件的业务访问系统进行业务访问处理的过程，其特征在于，所述业务访问系统在系统初始化时，根据插件配置文件为该系统中的插件配置统一的输入输出接口，该方法包括：

所述业务访问系统接收业务请求，获取其中携带的业务参数；

所述业务访问系统根据所述业务请求，确定需要调用的插件；

所述业务访问系统将所述业务参数作为输入参数，并通过调用所述需要调用的插件进行业务处理，得到业务处理结果；其中，插件间根据配置的统一的输入输出接口交互信息；

所述业务访问系统输出所述业务处理结果。

2.如权利要求1所述的方法，其特征在于，所述业务访问系统在初始化时，进一步根据所述插件配置文件中配置的各业务各自对应的插件执行路径，生成对应的业务执行链；

所述业务访问系统根据所述业务请求，确定需要调用的插件的步骤，具体为：所述业务访问系统根据所述业务请求，确定需要执行的业务执行链；

所述业务访问系统将所述业务参数作为输入参数，并通过调用所述需要调用的插件，进行业务处理的步骤，具体为：所述业务访问系统根据确定出的业务执行链，调用并运行相应插件；其中，两个关联的插件进行信息交互的过程中，前一个插件将其输出参数按照统一配置的输出接口存储到内存中的上下文区域，后一个插件根据所述业务执行链，并按照统一配置的输入接口，从所述上下文区域获取与该插件关联的前一个插件的输出参数作为本插件的输入参数；所述上下文区域为所述业务访问系统的内存中各插件的共享区域。

3.如权利要求1所述的方法，其特征在于，

所述业务请求对应的业务逻辑中，有插件调用至少其它2个插件，调用所述至少其它2个插件的插件代码中包含调用所述至少其它2个插件的API的语句；

所述通过调用所述需要调用的插件进行业务处理，得到业务处理结果，具体为：所述插件通过执行该语句调用所述至少其它2个插件，得到业务处理结果。

4.如权利要求1所述的方法，其特征在于，所述业务访问系统中设置有插件索引信息，所述插件配置文件中包括插件的索引信息，所述业务访问系统根据所述配置文件中的插件索引信息，确定需要调用的插件；

该方法还包括：

按照设定周期检测，并当检测到时间戳更新的插件索引信息时，用检测到的时间戳更新的插件索引信息更新所述插件配置文件中的插件索引信息。

5.如权利要求1-4之一所述的方法，其特征在于，所述业务访问系统为基于nginx的轻量级WEB服务系统。

6.一种基于插件的业务访问系统，其特征在于，包括：

插件模块，用于进行业务处理；

初始化模块，用于在系统初始化时，根据插件配置文件为系统中的插件模块配置统一的输入输出接口；

接收模块，用于接收业务请求，获取其中携带的业务参数；

处理模块，用于根据所述业务请求，确定需要调用的插件模块；以及，将所述业务参数作为输入参数，并通过调用所述需要调用的插件模块进行业务处理，得到业务处理结果；其中，插件模块间根据配置的统一的输入输出接口交互信息；

输出模块，用于输出所述业务处理结果。

7.如权利要求6所述的系统，其特征在于，所述初始化模块还用于，根据所述插件配置文件中配置的各业务各自对应的插件执行路径，生成对应的业务执行链；

所述处理模块具体用于，根据所述业务请求，确定需要执行的业务执行链；以及，根据确定出的业务执行链，调用并运行相应插件；其中，两个关联的插件进行信息交互的过程中，前一个插件将其输出参数按照统一配置的输出接口存储到内存中的上下文区域，后一个插件根据所述业务执行链，并按照统一配置的输入接口，从所述上下文区域获取与该插件关联的前一个插件的输出参数作为本插件的输入参数；所述上下文区域为所述业务访问系统的内存中各插件的共享区域。

8.如权利要求6所述的系统，其特征在于，所述业务请求对应的业务逻辑中，有插件调用至少其它2个插件，调用所述至少其它2个插件的插件代码中包含调用所述至少其它2个插件的API的语句；

所述处理模块具体用于，通过执行该语句调用所述至少其它2个插件，得到业务处理结果。

9.如权利要求6所述的系统，其特征在于，所述业务访问系统中设置有插件索引信息，所述插件配置文件中包括插件的索引信息，所述业务访问系统根据所述配置文件中的插件索引信息，确定需要调用的插件；

所述系统还包括：更新模块，用于按照设定周期检测，并当检测到时间戳更新的插件索引信息时，用检测到的时间戳更新的插件索引信息更新所述插件配置文件中的插件索引信息。

10.如权利要求6-9之一所述的系统，其特征在于，所述业务访问系统为基于nginx的轻量级WEB服务系统。