CN112527248A - 请求处理方法、装置及电子设备 - Google Patents

Abstract

本申请实施例公开了请求处理方法、装置及电子设备，所述方法包括：应用系统获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；确定支持所述目标业务身份标识信息的目标插件包；在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。通过本申请实施例，能够实现业务与平台代码的隔离，更好的实现业务对功能扩展点实现逻辑的定制。

Description

请求处理方法、装置及电子设备

技术领域

本申请涉及请求处理技术领域，特别是涉及请求处理方法、装置及电子设备。

背景技术

在一些平台化的应用系统中，通常会需要支持多个不同的业务系统。例如，商品对象信息服务系统中的交易应用系统、购物车应用系统等都属于这类应用系统，需要支持男装、女装、票务、家居等多个不同的业务系统的接入。而不同的业务系统通常会按照行业及市场的不同，要求平台的应用系统能够提供在不同的业务模式下支持不同的业务逻辑定制，实现业务独有的功能特性。这就要求同一个应用系统中，既有平台通用逻辑，同时又有各种不同的业务定制逻辑。

现有技术中，业务代码和平台代码混杂在一起。例如，在交易系统的下单流程中，通常会存在下单后如果未及时付款则订单关闭的功能，而不同的业务系统对于该功能的超时时间可能有不同的需求。例如，对于票务业务的付款时间，需要将超时时间定为30分钟，家居业务则需要将超时时间定为2小时，等等。在现有技术中，这种针对不同业务系统的不同需求，通常需要写在平台代码中。例如，在交易系统的平台代码中需要写入某段逻辑，该逻辑中，首先可以获取超时时间信息，然后执行判断逻辑，如果是票务业务，则超时时间为30分钟，如果是家居业务，则超时时间为2小时，然后再进行是否已经超时的判断，等等。

但是，在同一应用系统中，可定制的部分通常有很多，例如，简单如交易流程而言，除了前述的超时时间信息可以定制之外，关于最多可购买的数量，是否可用优惠券等多个环节上都可能可以定制。而在现有技术的实现方式中，这些不同业务系统的不同定制信息散落在数百万行的平台代码中。如果需要修改，则工作量会比较大，并且，一个业务的定制信息修改，可能会对其他业务的正常运行造成影响。

发明内容

本申请提供了请求处理方法、装置及电子设备，能够实现业务与平台代码的隔离，更好的实现业务对功能扩展点实现逻辑的定制。

本申请提供了如下方案：

一种请求处理方法，包括：

应用系统获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；

接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；

确定支持所述目标业务身份标识信息的目标插件包；

在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

一种业务配置信息发布方法，包括：

接收针对目标业务身份标识提交的配置信息，所述配置信息包括所述目标业务身份标识叠加的服务信息；

根据所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑，确定所述目标业务身份标识与所述服务是否在目标功能扩展点上存在冲突；

如果是，则提供用于对所述目标功能扩展点上所使用的实现逻辑的优先级进行配置的操作选项；

在接收到优先级配置结果后，将所述优先级信息添加到配置信息中进行发布。

一种请求处理装置，包括：

插件包信息获得单元，用于获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；

业务身份确定单元，用于接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；

插件包确定单元，用于确定支持所述目标业务身份标识信息的目标插件包；

执行单元，用于在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

一种业务配置信息发布装置，包括：

配置信息接收单元，用于接收针对目标业务身份标识提交的配置信息，所述配置信息包括所述目标业务身份标识叠加的服务信息；

冲突判断单元，用于根据所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑，确定所述目标业务身份标识与所述服务是否在目标功能扩展点上存在冲突；

优先级配置单元，用于如果是，则提供用于对所述目标功能扩展点上所使用的实现逻辑的优先级进行配置的操作选项；

配置信息发布单元，用于在接收到优先级配置结果后，将所述优先级信息添加到配置信息中进行发布。

一种请求处理方法，包括：

客户端接收目标请求；

将所述目标请求提交到应用系统服务端，以便所述应用系统服务端确定所述目标请求关联的目标业务身份标识信息，以及支持所述目标业务身份标识信息的目标插件包，并在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果；

接收所述服务端返回的执行结果并进行展示。

一种请求处理装置，包括：

请求接收单元，用于接收目标请求；

请求提交单元，用于将所述目标请求提交到应用系统服务端，以便所述应用系统服务端确定所述目标请求关联的目标业务身份标识信息，以及支持所述目标业务身份标识信息的目标插件包，并在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果；

执行结果接收单元，用于接收所述服务端返回的执行结果并进行展示。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；

接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；

确定支持所述目标业务身份标识信息的目标插件包；

在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收针对目标业务身份标识提交的配置信息，所述配置信息包括所述目标业务身份标识叠加的服务信息；

根据所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑，确定所述目标业务身份标识与所述服务是否在目标功能扩展点上存在冲突；

如果是，则提供用于对所述目标功能扩展点上所使用的实现逻辑的优先级进行配置的操作选项；

在接收到优先级配置结果后，将所述优先级信息添加到配置信息中进行发布。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

客户端接收目标请求；

将所述目标请求提交到应用系统服务端，以便所述应用系统服务端确定所述目标请求关联的目标业务身份标识信息，以及支持所述目标业务身份标识信息的目标插件包，并在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果；

接收所述服务端返回的执行结果并进行展示。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以将具体流程中的功能扩展点抽象成标准SDK，这样，具体的业务方可以基于这种标准SDK提供具体功能扩展点的定制化实现逻辑，这种实现逻辑可以以插件包的形式引入到具体的应用系统中，并且还可以对插件包所支持的业务身份标识进行声明。这样，在应用系统接收到具体的请求后，便可以首先确定出请求关联的业务身份标识，然后再确定出支持该业务身份标识的插件包，在执行具体请求对应的流程的过程中，在流程中的具体功能扩展点上，如果插件包中定制了具体的实现逻辑，则可以执行该插件包中定制的实现逻辑来获得执行结果，以此实现将具体的执行路径向目标插件包中的定制化实现逻辑的路由。通过这种方式，可以使得具体业务的定制化实现逻辑能够通过在插件包中定义的业务代码来实现，而不必与应用系统的平台代码混杂在一起，另外，不同业务方之间的插件包可以实现相互隔离，因此，还可以实现业务与业务的隔离，避免一个业务在需要修改实现逻辑时对其他业务造成影响。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统架构的示意图；

图2-1是本申请实施例的第一应用示意图；

图2-2是本申请实施例的第二应用示意图；

图2-3是本申请实施例的第三应用示意图；

图3是本申请实施例提供的第一方法的流程图；

图4是本申请实施例提供的功能扩展点的示意图；

图5是本申请实施例提供的第二方法的流程图；

图6是本申请实施例提供的发布平台的界面示意图；

图7是本申请实施例提供的第一装置的示意图；

图8是本申请实施例提供的第二装置的示意图；

图9是本申请实施例提供的第三方法的流程图；

图10是本申请实施例提供的第三装置的示意图；

图11是本申请实施例提供的电子设备的示意图。

具体实施方式

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

在本申请实施例中，为了能够更好的支持业务逻辑定制，避免不同的业务之间相互影响，或者业务逻辑的改变对平台代码的影响，提供了相应的解决方案。在该方案中，首先可以将具体应用系统中目标流程上可定制的部分功能(为便于描述，可以称为“功能扩展点”)进行抽象，生成标准SDK(软件开发工具包)，其中可以对函数方法名，输入输出参数等进行定义，然后，可以将这种SDK提供给具体的业务方。业务方则可以基于这种标准SDK提供具体功能扩展点的实现逻辑，并生成插件包。另外，应用系统还可以根据业务对象之间的业务共性信息，划分成多个业务类别，为每个业务类别提供对应的业务身份标识信息(可以采用全局唯一的编码进行表达)，这样，业务方在生成插件包的过程中，还可以提供一份描述文件，用于表明具体的插件包所支持的业务身份标识信息。

也就是说，通过本申请实施例所提供的方案，对于目标流程中的功能扩展点，具体的业务方可以自行进行定义，然后通过插件包的形式引入到应用系统中。这样，使得具体业务方所需的功能扩展点的实现逻辑与应用系统的平台代码相隔离，在业务方需要对某个功能扩展点的实现逻辑进行修改时，只需要对具体插件包中的业务代码进行修改，而不需要修改应用系统的平台代码。另外，不同业务方提供的不同的插件之间也可以是相互独立且隔离的，这样，也可以实现不同业务之间的相互隔离，其中一个业务方的实现逻辑需要修改时，只需要修改自己的插件包中的业务代码，不会对其他业务方造成影响。

在上述提供了标准SDK、业务身份标识信息，并且能够将业务方基于上述信息定义的插件包引入到应用系统中的基础上，本申请实施例还可以提供将业务管理域与运行域分离的框架，基于此框架定义的规范实施的各领域系统，最终可形成业务全链路管理视角并支撑业务经营管理。具体的，具体的框架实现逻辑可以以依赖包等形式存在，并内嵌到具体的应用系统中，这样，使得应用系统可以按照该框架对具体的外部请求进行处理。具体在该框架下对请求进行处理时，可以首先扫描应用系统内已经引入的全部插件包，解析获得其中包括的扩展点对应的实现逻辑，以及支持的业务身份标识信息。在接收到具体的请求后，首先可以确定出具体的业务身份标识信息，然后，确定出支持该业务身份标识信息的插件包，这样，在执行具体流程的过程中，对于所述目标插件包中实现的功能扩展点，就可以通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。也就是说，上述框架的存在，在处理具体请求的过程中，如果涉及到的目标业务身份标识对应有已实现的插件包，则可以通过上述框架将执行路径路由到该插件包中定义的实现逻辑中，这样，可以在不影响应用系统中平台代码的基础上，支持具体业务方对功能扩展点的功能定制，并且可以实现不同业务之间的相互隔离。

从系统实现架构角度而言，如图1所示，可以由平台方发布各个功能扩展点对应的SDK，并统一维护业务身份标识信息定义规则。这些SDK以及规则可以提供给业务方，业务方可以有多个，例如，在具体的商品对象信息服务系统中，业务方也可以根据具体业务对象的共性来确定，例如，根据是否为独立的核算实体，可以分为票务类，男装类，女装类，等等。各业务方可以根据各自的需求定义各自的插件包，并引入到平台中具体的应用系统中。其中，应用系统也可以有多个，例如，同样是在商品对象信息服务系统中，具体的应用系统可以包括商品发布、商品导购、交易下单、交易履约、电商优惠、资金结算等等。每个应用系统中都可以内嵌前述框架依赖包，这样，在具体的请求进入应用系统后，可以通过调用这种依赖包，实现向具体插件包的路由。当然，具体实现时，具体的实现框架也可以直接在应用系统的平台代码中实现，而不以依赖包的形式存在，等等。

如图2-1所示，为本申请实施例提供的第一应用示意图，其中，服务器的某个业务逻辑210包括若干步骤及子过程，其中的部分功能可以作为功能扩展点。对于不同的业务对象、业务类别等，同一个功能扩展点可以有不同的实现，以满足不同的业务对象或者业务类别的不同实现需求，例如对于未付款订单的周期控制及处理，对于在不同的产品分类中可以有不同的实现。在本申请实施例提供的方法中，在实现对于同一功能扩展点的不同需求时，可以由平台提供标准SDK，由业务方基于平台提供的标准SDK进行定制实现，例如，对于需求中涉及的参数，流程，服务对象，活动配置等等都可以根据不同的实际业务需求进行定制实现。图2-1中的业务逻辑210中，包括了功能扩展点2101，在该示例中，功能扩展点2101可以用于实现业务逻辑上的订单延时控制功能。在提供该功能扩展点的功能时，可以提供包括方法集合220中的各种具体实现，具体的方法实现可以是插件包的形式，其中包括由业务方230基于平台提供的SDK定制实现的插件包。业务方230对于该功能扩展点的定制分别以插件包的形式提供了不同的业务实现逻辑，如业务A001.Delay()。其中，插件包中可以声明其所支持的业务身份标识。

当收到一个外部请求后，可以根据请求的信息确定业务身份标识，例如图2-1中所示的请求包括了参数：

(...pid＝123456789abcmjt...)；

经过解析可以确定该请求关联的目标业务身份标识信息，当响应该请求执行业务逻辑210时，对于功能扩展点2101的实现逻辑，则可以根据相应的目标业务身份标识，检索或扫描实现方法集合220中的各插件包，确定支持目标业务身份标识信息的目标插件包，例如确定目标插件包2201，执行其中的“业务G001.Delay()”的功能扩展点实现逻辑，获得执行结果。在检索没有获得业务方相应的插件包支持时，还可以执行系统提供的通用的缺省逻辑，例如图2-1中的“默认方法.Delay()”。

通过上述逻辑组织和执行过程，可以对不同业务方之间的插件包实现相互隔离，同时，业务代码与平台代码之间的组织和执行也是隔离进行的，从而实现了业务与业务的隔离，避免在加入新业务，或者在业务在需要修改实现逻辑时对其他业务造成影响，以及业务逻辑的改变对平台代码的影响。功能扩展点不仅可以包括简单步骤的逻辑抽象，也可以包括对相对复杂的子过程的逻辑抽象的实现，例如图2-1中的子过程2102，使平台系统的业务组织更加灵活，提高了系统的健壮性和可重用性。

如图2-2所示，为本申请实施例提供的第二应用示意图，从另一个角度描述了请求处理方法的实现。对于不同的业务对象/业务类别等，同一个功能扩展点可以有不同的实现，以满足不同的业务对象/业务类别的不同实现需求。实现对于同一功能扩展点的不同需求时，可以由平台提供标准SDK，由业务方基于平台提供的标准SDK进行定制，例如对于同一功能扩展点中涉及的参数，流程，服务对象，活动配置等等都可以根据不同实际需求进行定制实现。图2-2中的业务逻辑210中，包括了功能扩展点2101，功能扩展点2101可以示例性的用于实现业务逻辑上的订单延时控制功能。在提供该功能扩展点的功能时，可以提供包括方法集合220中的各种具体实现，具体的方法实现可以是插件包的形式，其中包括由业务方230基于平台提供的SDK定制实现的插件包：“业务方A插件包”，其中包括为实现响应业务请求A而执行业务逻辑210时，业务逻辑210中的功能扩展点2101响应实现业务请求A而实际执行的代码或逻辑。不同业务方对于同一功能扩展点的定制，分别以插件包的形式提供了不同的业务实现逻辑，例如对于功能扩展点2101，不同的业务方提供了不同的插件包，例如还包括了“业务方B插件包”以及“业务方B插件包”等。其中，插件包中可以声明其所支持的业务身份标识。

服务器端可以接收来自不同业务方的业务请求，当收到一个业务请求后，可以根据请求的信息确定业务身份标识，例如图2-2中“业务请求A”中包括了“pid”等信息，可以根据这些信息计算或查询得到相应的业务身份标识，同样，对于“业务请求B”以及“业务请求C”，也可以通过业务身份识别确定相应的业务身份标识。当响应业务请求而执行业务逻辑210时，对于其中的功能扩展点2101的实现逻辑，则可以根据相应的目标业务身份标识，检索或扫描实现方法集合220中的各插件包，确定支持目标业务身份标识信息的目标插件包。例如，为响应“业务请求A”，服务器端在执行业务逻辑210中的功能扩展点2101时，根据业务身份标识确定“业务方A插件包”为响应“业务请求A”执行功能扩展点2101所使用的目标插件包。通常，业务请求标识与业务方插件包具有对应关系，例如，为响应“业务请求B”，服务器端在执行业务逻辑210中的功能扩展点2101时，则可以加载执行“业务方B插件包”的代码，以实现相应业务方提供的该功能扩展点的定制实现，获得执行结果。在检索没有获得业务方相应的插件包支持时，还可以执行系统提供的通用的缺省逻辑，例如图2-2中由系统提供的“默认插件包”。

除了为不同业务方用户提供功能扩展点的不同定制功能实现，也可以为终端用户提供定制功能扩展点的不同定制功能实现。在实现具体业务逻辑时，可以将其中的功能扩展点抽象成标准SDK，对于不同用户可以基于标准SDK提供具体功能扩展点的定制化实现逻辑，这种实现逻辑可以以插件包的形式引入到具体的应用系统中，并且还可以对插件包所支持的用户身份标识进行声明。这样，在应用系统接收到具体的请求后，便可以首先确定出请求的用户身份标识，然后再确定出支持该用户身份标识的插件包，在执行业务逻辑流程的过程中，对于同一功能扩展点上，如果为用户定制了具体的实现逻辑，则可以执行相应插件包中定制的实现逻辑。如图2-3所示，为本申请实施例提供的第三应用示意图，对于来着不同用户的请求，同一个功能扩展点也可以有不同的实现，以满足不同用户对于同一业务逻辑的不同实现需求。实现对于同一功能扩展点的不同需求时，可以由平台提供标准SDK，由业务方基于平台提供的标准SDK进行定制，图2-3中的业务逻辑210中，包括了功能扩展点2101，在提供该功能扩展点的功能时，可以提供包括方法集合220中的各种具体实现，具体的方法实现可以是插件包的形式，其中包括由业务方230基于平台提供的SDK为不同用户定制实现的插件包：“用户A插件包”，其中包括为实现响应用户请求A而执行业务逻辑210时，业务逻辑210中的功能扩展点2101响应用户请求A而实际执行的代码。对于同一功能扩展点的定制，分别为不同用户以插件包的形式提供了不同的业务实现逻辑，例如对于功能扩展点2101，可以为不同用户提供不同的插件包。

下面对本申请实施例提供的具体实施方案进行详细介绍。

实施例一

首先，本申请实施例一从内嵌了前述框架的依赖包，或者实现了框架代码的应用系统角度，提供了一种请求处理方法，参见图3，该方法具体可以包括：

S310：应用系统获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；

具体实现时，业务方基于平台方提供的标准SDK定义了具体功能扩展点的实现逻辑，并通过描述文件等形式显式声明了支持的业务身份标识信息后，便可以将实现逻辑对应的代码编译好，与描述文件一起生成插件包，提交到平台中。平台中的具体应用系统中便可以引入具体的插件包。

其中，所述目标流程可以是具体应用系统中具体提供的服务流程，例如，在交易下单这一应用系统中，具体的目标流程便可以包括下单流程等等。其中，所述目标流程中可以包括多个功能扩展点，例如，在付款超时时间这一功能上，可以提供扩展点(也即，业务方可以定制具体的超时逻辑，包括对具体超时时间的设定等)，在最大可购买数量这一功能上，也可以提供扩展点，等等。具体实现时，具体的业务方可以针对目标流程中一个或多个功能扩展点提供具体的实现逻辑。例如，如图4所示，某流程中存在功能扩展点1、2、3……，某业务方可以对其中的功能扩展点1、3等的实现逻辑进行定制。另一个业务方则可以对功能扩展点1、4、6等的实现逻辑进行定制，两者在同一功能扩展点上可以定制不同的实现逻辑。

同一业务方为功能扩展点的实现逻辑则可以打包在同一个插件包中，并引入到应用系统中。这样，该插件包所支持的业务，便可以利用该插件包中提供的具体功能扩展点上的实现逻辑，来获得具体的执行结果。

其中，所述功能扩展点对应的标准SDK可以是根据所述目标流程中可定制的部分功能进行抽象而成的，不同插件包中针对同一功能扩展点可定义不同的实现逻辑，不同的业务方可以根据自己的需求提供不同的实现逻辑，以此实现对具体功能的定制。并且，不同的插件包在引入到应用系统中之后，可以是相互隔离且独立的，其中一个业务方是否实现了插件包，以及插件包内具体的实现逻辑，对其他业务方都不会有影响，这样，可以避免不同的业务之间相互影响。当一个业务方需要修改某功能扩展点的实现逻辑时，只需要对自己发布的插件包中的业务代码进行修改，在此期间，不会影响应用系统中平台代码以及其他业务的业务代码的正常运行。

一个插件包所支持的业务方可以有一个或多种，也就是说，如果多个业务方能够复用同一插件包中所定制的实现逻辑，则在该插件包的描述文件中，可以声明，该插件包支持多个业务，并将各个业务的业务身份标识信息进行显式声明即可。

在本申请实施例中，关于所述业务身份标识信息，具体可以是根据业务对象的业务共性确定的，其中，具有相同业务共性的业务对象对应相同的业务身份标识信息。也就是说，在本申请实施例中，可以由平台方的运营人员等根据业务经验知识等，对业务对象进行分类，将具有业务共性的业务对象分为一类。其中，所谓的业务共性，在商品对象信息服务系统中，可以通过判断具体的业务对象类目是否为独立的核算实体等来进行体现。例如，在某系统中，男装与女装业务是独立核算，则可以将男装与女装业务作为不同的业务，赋予不同的业务身份标识。当然，在另一些系统中，男装与女装可能统一作为服饰业务进行统一核算，则可以将男装与女装业务视为统一的服饰类业务，分配相同的业务身份标识即可，等等。总之，可以根据具体系统中业务对象的业务共性，对业务对象进行分类，然后，分别对不同的业务对象类别分配不同的业务身份标识信息。

上述关于对业务对象的分类以及业务身份标识信息的分配可以由平台方进行统一的维护，另外，平台还可以根据业务身份标识信息与业务对象信息之间的对应关系，维护一份业务身份标识信息解析规则，这样，在具体的应用系统接收到一个请求后，便可以根据请求中携带的参数等信息，确定出业务对象的信息，进而确定出具体所属的业务身份标识。

平台方定义并分配的业务身份标识信息也可以提供给业务方，业务方则可以根据具体的需要，从中选择具体的业务身份标识，并为其定义具体功能扩展点上的实现逻辑。

也就是说，在本申请实施例中，平台方可以预先将各种可能出现的业务身份标识进行定义，具体业务方需要为哪些业务身份提供插件包，则可以由业务方自行决定。业务方在选择为具体的业务身份标识提供插件包时，如果实际业务方认为某些业务身份标识对应的业务可以共用同一份实现逻辑，则可以在描述文件中声明该插件包可以同时支持这些业务身份标识。如果某些业务身份没有被定义插件包，也不影响其他业务身份的运行，在某业务方需要为某业务身份标识定义具体功能扩展点上的实现逻辑时，可以随时定义新的插件包，并引入到具体的应用系统中。

总之，在业务方实现了具体的插件包，并引入到应用系统中之后，应用系统在启动时，便可以首先对已经引入的各个插件包进行扫描，识别出其支持的业务身份标识，另外还可以基于具体业务代码所使用的编程语言的解析机制，获取所有插件包定义的所有功能扩展点的编码和具体实现。这样，当具体的目标请求到来时，就可以首先对请求关联的业务身份标识进行识别，然后，获取到支持该业务身份标识的插件包，进而获取到该插件包中定义的所有功能扩展点编码和实现，这些信息可以维护在内存中，具体在根据请求执行具体应用系统中的目标流程的过程中，便可以在这些功能扩展点上，执行具体插件包中定义的实现，以获得执行结果。

S320：接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；

其中，目标请求可以是相对于应用系统的外部请求，具体可以是通过http、RPC等方式访问软件系统特定的数据接口时发起的请求。这种请求中通常会携带一些参数，并且这些参数与请求所需的业务对象相关，因此，可以通过对请求中的参数进行分析的方式，来从中获得请求所关联的业务对象的信息。例如，在商品对象信息服务系统中的下单请求中，可以从请求中解析出请求参数中的商品对象(属于业务对象的一种)ID，根据商品ID可以查询商品服务得到商品对象基本信息，根据商品对象基本信息再进一步调用其他基础服务可以得到商品对象的类目信息、商家信息、优惠信息等等。可以将这些信息作为上下文，执行前述维护的业务身份标识解析规则，根据命中结果得到该请求关联的目标业务身份标识信息。

当然，在实际应用中，还可以通过其他方式来确定目标请求关联的业务身份标识信息，例如，可以要求请求发起方直接在请求的参数中携带业务身份标识，等等。

S330：确定支持所述目标业务身份标识信息的目标插件包；

在确定出请求关联的目标业务身份标识后，可以根据之前在应用系统启动过程中所获得的插件包的信息，确定出支持该目标业务身份标识的目标插件包。进而还可以将该目标插件包中定义的各个功能扩展点对应的编码以及实现等维护在内存中，以便于被调用。

S340：在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

在确定出具体的目标插件包后，便可以执行具体请求对应的目标流程，在该过程中，由于流程中包括多个功能扩展点，因此，每执行到一个扩展点时，都可以判断目标插件包中是否存在关于对应扩展点的实现逻辑，如果存在则可以通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

需要说明的是，在实际应用中，应用系统的平台代码中也会存在对各个功能扩展点的通用实现逻辑，但是，在目标插件包中针对某功能扩展点提供了定制化的实现逻辑后，在本申请实施例中，可以利用该目标插件包中为所述功能扩展点定义的实现逻辑覆盖所述应用系统为所述功能扩展点定义的通用实现逻辑，这样，便可以执行所述目标插件包中定义的功能扩展点实现逻辑。

而对于所述目标插件包中未定制的功能扩展点，则可以执行所述应用系统为该功能扩展点定义的通用实现逻辑获得执行结果。也就是说，某插件包中可能仅对一个目标流程中的部分功能扩展点进行了实现逻辑的定制，此时，其他未定制的功能扩展点，则可以使用平台代码中的通用实现逻辑来获得执行结果。也就是说，对于这些功能扩展点而言，具体的业务方认为不需要进行特殊的定制，直接使用通用实现逻辑即可，因此，就可以不必在插件包中提供定制化的实现逻辑。

另外，如前文所述，可能存在部分业务没有定义对应的插件包，也就是说，在确定出目标请求关联的目标业务身份标识后，可能会发现不存在与所述目标业务身份标识信息对应的插件包，此时，则可以通过执行所述应用系统中为各功能扩展点定义的通用实现逻辑，获得执行结果。

再者，在实际应用中，还可能存在一些特殊情况：平台中可能会提供一些活动产品等类型的服务，例如，一些限时团购类的优惠活动，等等。通常，各个业务方都可以参加这种优惠活动，这就会出现业务叠加产品的情况。例如，某商品对象信息服务系统中，男装业务参加了某限时优惠活动，使得该男装业务与该限时优惠活动之间出现了叠加，等等。此时，不仅具体的业务方会定制具体的功能扩展点的实现逻辑，对于活动产品等类型的服务也定制了功能扩展点的实现逻辑。例如，男装业务针对下单后未及时付款则订单关闭这一功能扩展点定制的下单超时支付时间为30分钟，而该男装业务所参加的限时优惠活动的服务中定义的下单超时支付时间为15分钟。此时，会存在同一功能扩展点上，业务与服务定制的实现逻辑发生冲突的情况。

因此，为了解决上述问题，在本申请实施例中，还可以提供一统一的发布平台，当具体某个业务需要叠加某个活动产品等类型的服务时，可以通过该发布平台发布相关的叠加关系信息，以及业务身份标识对应的功能扩展点实现逻辑与所述目标服务对应的功能扩展点实现逻辑的优先级信息。例如，在前述男装业务叠加限时优惠活动的情况下，可以对优先使用男装业务定制的扩展点实现逻辑，还是限时优惠活动定制的扩展点实现逻辑，在上述发布平台中进行发布。

这样，具体的应用系统在启动时或者运行过程中，可以从该发布平台拉取业务配置信息，业务配置信息中就可以包括：业务身份标识与目标服务的叠加关系信息，以及在存在叠加关系时，业务身份标识对应的功能扩展点实现逻辑与目标服务对应的功能扩展点实现逻辑的优先级信息。这样，在确定出所述目标业务身份标识信息后，可以通过查询所拉取到的业务配置信息判断所述目标业务身份标识信息是否存在叠加关系，如果存在，则可以根据优先级信息确定所述目标流程中对应功能扩展点上的实现逻辑。例如，在前述例子中，如果发布平台中的配置信息显示需要优先使用男装业务定制的实现逻辑，则可以将超时时间确定为30分钟，如果需要优先使用优惠活动定制的实现逻辑，则可以将超时时间确定为15分钟，等等。

需要说明的是，在实际应用中同一业务可能会同时叠加多个服务，如果多个服务分别定制了相同功能扩展点的实现逻辑，则可以在发布平台中分别对各自的优先级进行定义。另外，如果某应用系统在启动时拉取了发布平台中的业务配置信息，在应用系统运行期间，该业务配置信息发生了更新，例如，出现了新的业务与活动的叠加关系，或者，某已有的叠加关系中，优先级发生变化，则发布系统可以将更新后的业务配置信息推送到应用系统，以便应用系统及时更新业务配置信息。

另外需要说明的是，在本申请实施例提供的具体实现框架以依赖包的形式内嵌到应用系统的情况下，可以由应用系统接收具体的请求，并通过对请求中的参数等进行分析的方式，确定出关联的目标业务身份标识信息。然后，可以以该业务身份标识信息为参数，调用实现框架的依赖包，由该依赖包确定出支持该业务身份标识的插件包，并将具体的执行路径路由到该插件包中，获得该插件包中为具体功能扩展点定制的实现逻辑的执行结果，并返回给应用系统。最后，应用系统则可以根据获得的执行结果生成具体的请求执行结果。其中，如前文所述，同一流程中通常包括多个功能扩展点，如果某插件包中仅对其中部分功能扩展点进行了定制，则对于未定制的功能扩展点，可以通过应用系统的平台代码中定义的通用实现逻辑获得执行结果。之后，可以将具体业务定制以及未定制的各功能扩展点上的执行结果进行组装，得到完整的执行结果，之后便可以返回给外部请求，并结束整个流程。

总之，通过本申请实施例，可以将具体流程中的功能扩展点抽象成标准SDK，这样，具体的业务方可以基于这种标准SDK提供具体功能扩展点的定制化实现逻辑，这种实现逻辑可以以插件包的形式引入到具体的应用系统中，并且还可以对插件包所支持的业务身份标识进行声明。这样，在应用系统接收到具体的请求后，便可以首先确定出请求关联的业务身份标识，然后再确定出支持该业务身份标识的插件包，在执行具体请求对应的流程的过程中，在流程中的具体功能扩展点上，如果插件包中定制了具体的实现逻辑，则可以执行该插件包中定制的实现逻辑来获得执行结果，以此实现将具体的执行路径向目标插件包中的定制化实现逻辑的路由。通过这种方式，可以使得具体业务的定制化实现逻辑能够通过在插件包中定义的业务代码来实现，而不必与应用系统的平台代码混杂在一起，另外，不同业务方之间的插件包可以实现相互隔离，因此，还可以实现业务与业务的隔离，避免一个业务在需要修改实现逻辑时对其他业务造成影响，另外，在需要满足大量数据的计算需求时，例如在平台提供诸如秒杀，限时优惠团购等活动时，短时间内通过不同的业务方应用可能产生大量的业务需求，而对于业务逻辑上的功能扩展点实现针对不同业务的定制，也可以使功能扩展点上相应的数据处理根据不同的业务进行分流，从而有利于在相应的功能处理排除瓶颈，从请求计算到响应都可以根据不同业务进行梳理，也便于根据业务方的不同对功能扩展点进行统计，维护等功能的实现。

实施例二

如前述实施例一中所述，本申请实施例还可以提供一种统一的发布平台，以用于对业务叠加服务时，例如对于某产品可以参加限时优惠团购、限时秒杀等在一定时间段内进行优惠活动，相应的，在平台中这些活动的服务对于功能扩展点的实现逻辑也可以进行定制，此时，相当于在原有业务方提供的功能扩展点的实现逻辑的同时，又由活动的服务定制了另外的实现逻辑，可以对发生冲突的功能扩展点的优先级信息进行配置以及发布。因此，本申请实施例二就是从该发布平台的角度，提供了一种业务配置信息发布方法，参见图5，该方法具体可以包括：

S510：接收针对目标业务身份标识提交的配置信息，所述配置信息包括所述目标业务身份标识叠加的服务信息；

具体关于叠加关系的配置信息可以是由具体的业务方提交的，也即，具体的业务方可以根据其实际的业务身份标识与服务的叠加情况，向发布平台中提交叠加关系配置信息。具体的，可以将业务身份标识与服务的标识信息提交到发布平台中。

S520：根据所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑，确定所述目标业务身份标识与所述服务是否在目标功能扩展点上存在冲突；

发布平台接收到叠加关系配置信息后，可以对所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑进行查询，判断所述目标业务身份标识与所述服务是否在某个或者某些目标功能扩展点上存在冲突。所谓的存在冲突就是指，业务与服务都对相同的功能扩展点定制了实现逻辑，但是，两者定制的实现逻辑不同。具体实现时，发布平台可以通过与应用系统等进行打通等方式，获得具体业务以及服务对应的插件包信息，并从中获得具体的实现逻辑后进行冲突判断。

S530：如果是，则提供用于对所述目标功能扩展点上所使用的实现逻辑的优先级进行配置的操作选项；

如果发现存在冲突，则可以提供用于对实现逻辑的优先级进行配置的操作选项。例如，如图6所示，“在线医生”业务叠加了“无付款交易”以及“0元主订单”这两个服务，三者在“关单时是否跳过支付平台检查”这一功能扩展点上分别定制了不同的实现逻辑，于是发生冲突。因此，可以提供用于对三者之间的优先级进行调整的操作选项，例如，具体的操作选项可以如图6中的61处所示，用户可以通过点击相应的“箭头”等方式对各自的优先级进行调整。

S540：在接收到优先级配置结果后，将所述优先级信息添加到配置信息中进行发布。

在完成优先级配置后，则可以将所述优先级信息添加到配置信息中进行发布。这样，在具体的应用系统启动时，便可以拉取这种配置信息。也即，发布平台在接收到应用系统拉取所述配置信息的请求后，可以将所述配置信息提供给所述应用系统，以便所述应用系统在根据所接收到的业务请求确定出目标业务身份标识后，根据所述配置信息确定对应功能扩展点上所需使用的实现逻辑。另外，如果所述配置信息发生更新，则还可以将更新后的配置信息推送给所述应用系统。

通过该实施例二所提供的方法，可以使得业务方在需要叠加具体的服务时，能够通过该发布平台判断业务与服务之间是否在关于某功能扩展点定制的实现逻辑上存在冲突，如果存在冲突，则可以对各自的优先级进行配置，并进行发布。这样，具体的应用系统在发现业务叠加了服务时，便可以根据这种配置信息确定具体使用的实现逻辑。

与实施例一相对应，本申请实施例还提供了一种请求处理装置，参见图7，该装置具体可以包括：

插件包信息获得单元710，用于获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；

业务身份确定单元720，用于接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；

插件包确定单元730，用于确定支持所述目标业务身份标识信息的目标插件包；

执行单元740，用于在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

其中，所述目标流程中可以包括多个功能扩展点，所述插件包中可以包括所述目标流程中至少一个功能扩展点的实现逻辑。

所述功能扩展点对应的标准SDK可以是根据所述目标流程中可定制的部分功能进行抽象而成的，不同插件包中针对同一功能扩展点可定义不同的实现逻辑，不同的插件包之间相互隔离且独立。

所述业务身份标识信息是根据业务对象的业务共性确定的，其中，具有相同业务共性的业务对象对应相同的业务身份标识信息。

具体实现时，该装置还可以包括：

解析规则获得单元，用于根据业务身份标识信息与业务对象信息之间的对应关系，获得业务身份标识信息解析规则；

所述业务身份确定单元具体可以用于：

根据所述目标请求中携带的参数查询对应的基础服务获取业务对象信息；以所述业务对象信息作为上下文，执行各业务身份标识信息对应的解析规则，根据命中结果确定所述目标请求对应的目标业务身份标识信息。

另外，该装置还可以包括：

业务配置信息获得单元，用于从预置的发布平台拉取业务配置信息，所述业务配置信息包括：业务身份标识与目标服务的叠加关系信息，以及在存在叠加关系时，业务身份标识对应的功能扩展点实现逻辑与所述目标服务对应的功能扩展点实现逻辑的优先级信息；

叠加关系判断单元，用于在确定出所述目标业务身份标识信息后，通过查询所拉取到的业务配置信息判断所述目标业务身份标识信息是否存在所述叠加关系；

优先级确定单元，用于如果存在，则根据所述优先级信息确定所述目标流程中对应功能扩展点上的实现逻辑。

具体实现时，所述执行单元具体可以用于：利用该目标插件包中为所述功能扩展点定制的实现逻辑覆盖所述应用系统为所述功能扩展点定义的通用实现逻辑，以便执行所述目标插件包中定义的功能扩展点实现逻辑。

另外，该装置还可以包括：

第一通用逻辑执行单元，用于对于所述目标插件包中未定制的功能扩展点，则执行所述应用系统为该功能扩展点定义的通用实现逻辑获得执行结果；

执行结果组装单元，用于将所述目标插件包定制的功能扩展点对应的执行结果以及未定制的功能扩展点对应的执行结果进行组装，将组装后的执行结果返回给请求发起方。

另外，该装置还可以包括：

第二通用逻辑执行单元，用于如果不存在所述目标业务身份标识信息对应的插件包，则通过执行所述应用系统中为各功能扩展点定义的通用实现逻辑，获得执行结果。

与实施例二相对应，本申请实施例还提供了一种业务配置信息发布装置，参见图8，该装置可以包括：

配置信息接收单元810，用于接收针对目标业务身份标识提交的配置信息，所述配置信息包括所述目标业务身份标识叠加的服务信息；

冲突判断单元820，用于根据所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑，确定所述目标业务身份标识与所述服务是否在目标功能扩展点上存在冲突；

优先级配置单元830，用于如果是，则提供用于对所述目标功能扩展点上所使用的实现逻辑的优先级进行配置的操作选项；

配置信息发布单元840，用于在接收到优先级配置结果后，将所述优先级信息添加到配置信息中进行发布。

具体实现时，该装置还可以包括：

配置信息提供单元，用于接收到应用系统拉取所述配置信息的请求后，将所述配置信息提供给所述应用系统，以便所述应用系统在根据所接收到的业务请求确定出目标业务身份标识后，根据所述配置信息确定对应功能扩展点上所需使用的实现逻辑。

配置信息推送单元，用于如果所述配置信息发生更新，则将更新后的配置信息推送给所述应用系统。

实施例三

该实施例三主要从面相消费者用户的客户端角度，提供了一种请求处理方法，也即，具体消费者用户在使用对应的客户端的过程中，可能会涉及到一些请求的处理，这些请求具体可以包括支付请求，订单处理请求，等等，客户端在接收到具体的请求后，可以提交到服务端，由服务端进行处理。在本申请实施例中，服务端在处理的过程中，需要执行对应的流程，而流程中可能会存在一些功能扩展点，因此可以首先确定请求关联的目标业务身份标识，再根据支持该业务身份标识的插件包中为具体的功能扩展点定义的实现逻辑，获得具体的执行结果信息。然后，客户端对执行结果进行展示即可。具体的，参见图9，该方法具体可以包括：

S910：客户端接收目标请求；

S920：将所述目标请求提交到应用系统服务端，以便所述应用系统服务端确定所述目标请求关联的目标业务身份标识信息，以及支持所述目标业务身份标识信息的目标插件包，并在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果；

S930：接收所述服务端返回的执行结果并进行展示。

与实施例三相对于，本申请实施例还提供了一种请求处理装置，参见图10，该装置可以包括：

请求接收单元1010，用于接收目标请求；

请求提交单元1020，用于将所述目标请求提交到应用系统服务端，以便所述应用系统服务端确定所述目标请求关联的目标业务身份标识信息，以及支持所述目标业务身份标识信息的目标插件包，并在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果；

执行结果接收单元1030，用于接收所述服务端返回的执行结果并进行展示。

另外，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；

接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；

确定支持所述目标业务身份标识信息的目标插件包；

在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

以及另一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收针对目标业务身份标识提交的配置信息，所述配置信息包括所述目标业务身份标识叠加的服务信息；

根据所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑，确定所述目标业务身份标识与所述服务是否在目标功能扩展点上存在冲突；

如果是，则提供用于对所述目标功能扩展点上所使用的实现逻辑的优先级进行配置的操作选项；

在接收到优先级配置结果后，将所述优先级信息添加到配置信息中进行发布。

另一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收目标请求；

将所述目标请求提交到应用系统服务端，以便所述应用系统服务端确定所述目标请求关联的目标业务身份标识信息，以及支持所述目标业务身份标识信息的目标插件包，并在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果；

接收所述服务端返回的执行结果并进行展示。

其中，图11示例性的展示出了电子设备的架构，具体可以包括处理器1110，视频显示适配器1111，磁盘驱动器1112，输入/输出接口1113，网络接口1114，以及存储器1120。上述处理器1110、视频显示适配器1111、磁盘驱动器1112、输入/输出接口1113、网络接口1114，与存储器1120之间可以通过通信总线1130进行通信连接。

其中，处理器1110可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器1120可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1120可以存储用于控制电子设备1100运行的操作系统1121，用于控制电子设备1100的低级别操作的基本输入输出系统(BIOS)。另外，还可以存储网页浏览器1123，数据存储管理系统1124，以及请求处理系统1125等等。上述请求处理系统1125就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器1120中，并由处理器1110来调用执行。

输入/输出接口1113用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口1114用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1130包括一通路，在设备的各个组件(例如处理器1110、视频显示适配器1111、磁盘驱动器1112、输入/输出接口1113、网络接口1114，与存储器1120)之间传输信息。

另外，该电子设备1100还可以从虚拟资源对象领取条件信息数据库1141中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器1110、视频显示适配器1111、磁盘驱动器1112、输入/输出接口1113、网络接口1114，存储器1120，总线1130等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的请求处理方法、装置及电子设备，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (19)

1.一种请求处理方法，其特征在于，包括：

应用系统获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；

接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；

确定支持所述目标业务身份标识信息的目标插件包；

在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

2.根据权利要求1所述的方法，其特征在于，

所述目标流程中包括多个功能扩展点，所述插件包中包括所述目标流程中至少一个功能扩展点的实现逻辑。

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

所述功能扩展点对应的标准SDK是根据所述目标流程中可定制的部分功能进行抽象而成的，不同插件包中针对同一功能扩展点可定制不同的实现逻辑，不同的插件包之间相互隔离且独立。

4.根据权利要求1所述的方法，其特征在于，

所述业务身份标识信息是根据业务对象的业务共性确定的，其中，具有相同业务共性的业务对象对应相同的业务身份标识信息。

5.根据权利要求4所述的方法，其特征在于，还包括：

根据业务身份标识信息与业务对象信息之间的对应关系，获得业务身份标识信息解析规则；

所述确定所述目标请求关联的目标业务身份标识信息，包括：

根据所述目标请求中携带的参数查询对应的基础服务获取业务对象信息；

以所述业务对象信息作为上下文，执行各业务身份标识信息对应的解析规则，根据命中结果确定所述目标请求对应的目标业务身份标识信息。

6.根据权利要求1所述的方法，其特征在于，还包括：

从预置的发布平台拉取业务配置信息，所述业务配置信息包括：业务身份标识与目标服务的叠加关系信息，以及在存在叠加关系时，业务身份标识定制的功能扩展点实现逻辑与所述目标服务定制的功能扩展点实现逻辑的优先级信息；

在确定出所述目标业务身份标识信息后，通过查询所拉取到的业务配置信息判断所述目标业务身份标识信息是否存在所述叠加关系；

如果存在，则根据所述优先级信息确定所述目标流程中对应功能扩展点上的实现逻辑。

7.根据权利要求1至6任一项所述的方法，其特征在于，

所述通过执行所述目标插件包中定制的功能扩展点实现逻辑，获得执行结果，包括：

利用该目标插件包中为所述功能扩展点定制的实现逻辑覆盖所述应用系统为所述功能扩展点提供的通用实现逻辑，以便执行所述目标插件包中定制的功能扩展点实现逻辑。

8.根据权利要求1至6任一项所述的方法，其特征在于，还包括：

对于所述目标插件包中未定制的功能扩展点，则执行所述应用系统为该功能扩展点定义的通用实现逻辑获得执行结果；

将所述目标插件包定制的功能扩展点对应的执行结果以及未定制的功能扩展点对应的执行结果进行组装，将组装后的执行结果返回给请求发起方。

9.根据权利要求1至6任一项所述的方法，其特征在于，还包括：

如果不存在所述目标业务身份标识信息对应的插件包，则通过执行所述应用系统中为各功能扩展点提供的通用实现逻辑，获得执行结果。

10.一种业务配置信息发布方法，其特征在于，包括：

接收针对目标业务身份标识提交的配置信息，所述配置信息包括所述目标业务身份标识叠加的服务信息；

根据所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑，确定所述目标业务身份标识与所述服务是否在目标功能扩展点上存在冲突；

如果是，则提供用于对所述目标功能扩展点上所使用的实现逻辑的优先级进行配置的操作选项；

在接收到优先级配置结果后，将所述优先级信息添加到配置信息中进行发布。

11.根据权利要求10所述的方法，其特征在于，还包括：

接收到应用系统拉取所述配置信息的请求后，将所述配置信息提供给所述应用系统，以便所述应用系统在根据所接收到的业务请求确定出目标业务身份标识后，根据所述配置信息确定对应功能扩展点上所需使用的实现逻辑。

12.根据权利要求11所述的方法，其特征在于，还包括：

如果所述配置信息发生更新，则将更新后的配置信息推送给所述应用系统。

13.一种请求处理装置，其特征在于，包括：

插件包信息获得单元，用于获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；

业务身份确定单元，用于接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；

插件包确定单元，用于确定支持所述目标业务身份标识信息的目标插件包；

执行单元，用于在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

14.一种业务配置信息发布装置，其特征在于，包括：

配置信息接收单元，用于接收针对目标业务身份标识提交的配置信息，所述配置信息包括所述目标业务身份标识叠加的服务信息；

冲突判断单元，用于根据所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑，确定所述目标业务身份标识与所述服务是否在目标功能扩展点上存在冲突；

优先级配置单元，用于如果是，则提供用于对所述目标功能扩展点上所使用的实现逻辑的优先级进行配置的操作选项；

配置信息发布单元，用于在接收到优先级配置结果后，将所述优先级信息添加到配置信息中进行发布。

15.一种请求处理方法，其特征在于，包括：

客户端接收目标请求；

将所述目标请求提交到应用系统服务端，以便所述应用系统服务端确定所述目标请求关联的目标业务身份标识信息，以及支持所述目标业务身份标识信息的目标插件包，并在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果；

接收所述服务端返回的执行结果并进行展示。

16.一种请求处理装置，其特征在于，包括：

请求接收单元，用于接收目标请求；

请求提交单元，用于将所述目标请求提交到应用系统服务端，以便所述应用系统服务端确定所述目标请求关联的目标业务身份标识信息，以及支持所述目标业务身份标识信息的目标插件包，并在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果；

执行结果接收单元，用于接收所述服务端返回的执行结果并进行展示。

17.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

获得所引入的至少一个插件包的信息，其中，所述插件包中包括基于目标流程中的功能扩展点对应的标准软件开发工具包SDK进行定制的功能扩展点实现逻辑，以及所述插件包支持的业务身份标识信息；

接收到目标请求后，确定所述目标请求关联的目标业务身份标识信息；

确定支持所述目标业务身份标识信息的目标插件包；

在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果。

18.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收针对目标业务身份标识提交的配置信息，所述配置信息包括所述目标业务身份标识叠加的服务信息；

根据所述目标业务身份标识以及所述服务分别针对应用系统目标流程中的功能扩展点定制的实现逻辑，确定所述目标业务身份标识与所述服务是否在目标功能扩展点上存在冲突；

如果是，则提供用于对所述目标功能扩展点上所使用的实现逻辑的优先级进行配置的操作选项；

在接收到优先级配置结果后，将所述优先级信息添加到配置信息中进行发布。

19.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令，所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

接收目标请求；

将所述目标请求提交到应用系统服务端，以便所述应用系统服务端确定所述目标请求关联的目标业务身份标识信息，以及支持所述目标业务身份标识信息的目标插件包，并在执行所述目标请求对应的目标流程的过程中，对于所述目标插件包中实现的功能扩展点，通过执行所述目标插件包中定义的功能扩展点实现逻辑，获得执行结果；

接收所述服务端返回的执行结果并进行展示。

Images