CN111327691A - 业务处理方法、装置及电子设备 - Google Patents

Abstract

本申请提供了一种业务处理方法、装置及计算机设备，对于分布式系统的新增业务发起的目标业务请求，本申请不需要针对该目标业务请求生成独立的请求报文，而是确定与其相匹配的待合并业务请求后，直接将该目标业务请求更新至待合并业务请求的请求报文中，发送至服务器，不需要针对目标业务请求生成独立的请求报文，也就不会增加客户端与服务器之间的报文数量，保证了系统性能的稳定性；且不会影响待合并业务请求的正常通信，避免了新增业务对运行中业务的影响。

Description

业务处理方法、装置及电子设备

技术领域

本申请主要涉及通信技术领域，更具体地说是涉及一种业务处理方法、装置及电子设备。

背景技术

C/S(Client/Server，客户端/服务器)结构是一种常用的网络架构，在实际应用中，通常由客户端向服务器发送请求，服务器响应请求，执行请求所要求的操作，并将执行结果反馈至客户端。

目前分布式系统所实现的大部分业务都是依赖C/S结构运行，对于分布式系统的新增业务发起的业务请求，通常是生成独立的请求报文发送至服务器，以实现新增业务，这将会导致客户端和服务器之间的报文数量增多，影响系统性能稳定性。

发明内容

有鉴于此，为了实现发明目的，本申请提供了一种业务处理方法，所述方法包括：

获得目标业务请求，所述目标业务请求是针对新增业务发起的业务请求；

检测与所述目标业务请求相匹配的待合并业务请求，所述待合并业务请求是针对已有业务发起的业务请求；

将所述目标业务请求更新至所述待合并业务请求的请求报文，得到目标请求报文，将所述目标请求报文发送至服务器。

在一些实施例中，所述检测与所述目标业务请求相匹配的待合并业务请求，包括：

获得所述目标业务请求及已有业务请求各自的请求类型；

将与所述目标业务请求属于同一请求类型的已有业务请求确定为待合并业务请求；或者，

确定与所述目标业务请求所属请求类型相关联的待合并请求类型，将属于所述待合并请求类型的已有业务请求确定为待合并业务请求。

在一些实施例中，所述将所述目标业务请求更新至所述待合并业务请求的请求报文，得到目标请求报文，包括：

利用所述目标业务请求的请求属性信息，更新所述待合并业务请求的请求报文的报文头；

将所述目标业务请求的请求内容作为报文请求内容，添加至所述待合并业务请求的请求报文，得到目标请求报文。

在一些实施例中，所述方法还包括：

获取业务注册请求，所述业务注册请求包含请求注册的新增业务的业务注册信息，所述业务注册信息表明与所述新增业务的目标业务请求相匹配的至少一个已有业务的业务请求；

响应所述业务注册请求，依据所述业务注册信息，实现对所述新增业务的注册，以使所述新增业务与所述至少一个已有业务共享一个报文结构。

在一些实施例中，所述将所述目标业务请求更新至所述待合并业务请求的请求报文，得到目标请求报文，包括：

确定所述待合并业务请求的请求报文的报文结构；

按照所述报文结构，利用所述目标业务请求和所述待合并业务请求各自的请求属性信息，生成报文头；

按照所述报文结构，利用所述目标业务请求和所述待合并业务请求各自的请求内容，生成相应的报文请求内容；

利用所述报文头和生成的各报文请求内容，生成目标请求报文。

在一些实施例中，所述方法还包括：

接收所述服务器反馈的针对所述目标业务请求的回应报文；

检测所述回应报文包含多个业务请求的业务响应结果，拆分所述回应报文，得到多个业务响应结果，其中，所述多个业务响应结果包括：针对所述目标业务请求的目标业务响应结果，以及针对所述待合并业务请求的业务响应结果；

调用所述多个业务响应结果各自对应的处理函数，对相应的业务响应结果进行处理。

又一方面，本申请还提出了一种业务处理方法，所述方法包括：

接收客户端发送的目标请求报文，所述目标请求报文是通过将目标业务请求更新至待合并业务请求的请求报文得到的，所述目标业务请求是针对新增业务发起的业务请求，所述待合并业务请求是针对已有业务发起的与所述目标业务请求相匹配的业务请求；

对所述目标请求报文进行拆分，得到所述目标业务请求和所述待合并业务请求；

调用所述目标业务请求和所述待合并业务请求各自对应的处理函数，响应相应的业务请求，得到业务响应结果；

利用得到的多个业务响应结果，生成至少一个回应报文；

将所述至少一个回应报文反馈至所述客户端。

在一些实施例中，所述由得到的多个业务响应结果，生成至少一个回应报文，包括：

由得到的多个业务响应结果生成各自的回应报文；或者，

获取得到的多个业务响应结果各自的生成时间；

依据所述生成时间，将满足条件的多个业务响应结果合并生成一个回应报文，所述满足条件的多个业务响应结果中任意两个业务响应结果对应的生成时间的时间差小于特定阈值；

如果存在不满足所述条件的业务响应结果，由不满足所述条件的各业务响应结果，生成相应的回应报文。

又一方面，本申请还提出了一种业务处理装置，所述装置包括：

获得模块，用于获得目标业务请求，所述目标业务请求是针对新增业务发起的业务请求；

检测模块，用于检测与所述目标业务请求相匹配的待合并业务请求，所述待合并业务请求是针对已有业务发起的业务请求；

更新模块，用于将所述目标业务请求更新至所述待合并业务请求的请求报文，得到目标请求报文，将所述目标请求报文发送至服务器。

又一方面，本申请还提出了一种业务处理装置，所述装置包括：

接收模块，用于接收客户端发送的目标请求报文，所述目标请求报文是通过将目标业务请求更新至待合并业务请求的请求报文得到的，所述目标业务请求是针对新增业务发起的业务请求，所述待合并业务请求是针对已有业务发起的与所述目标业务请求相匹配的业务请求；

拆分模块，用于对所述目标请求报文进行拆分，得到所述目标业务请求和所述待合并业务请求；

处理模块，用于调用所述目标业务请求和所述待合并业务请求各自对应的处理函数，响应相应的业务请求，得到业务响应结果；

生成模块，用于利用得到的多个业务响应结果，生成至少一个回应报文；

反馈模块，用于将所述至少一个回应报文反馈至所述客户端。

由此可见，与现有技术相比，本申请提供了一种业务处理方法、装置及计算机设备，对于分布式系统的新增业务发起的目标业务请求，本申请不需要针对该目标业务请求生成独立的请求报文，而是确定与其相匹配的待合并业务请求后，直接将该目标业务请求更新至待合并业务请求的请求报文中，发送至服务器，不需要针对目标业务请求生成独立的请求报文，也就不会增加客户端与服务器之间的报文数量，保证了系统性能的稳定性；且不会影响待合并业务请求的正常通信，避免了新增业务对运行中业务的影响。

附图说明

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

图1示出了本申请提出的适用于客户端的业务处理方法的一可选示例的流程示意图；

图2示出了本申请提出的适用于客户端的业务处理方法的又一可选示例的流程示意图；

图3示出了本申请提出的业务处理方法中，请求报文的结构示意图；

图4示出了本申请提出的适用于客户端的业务处理方法的又一可选示例的流程示意图；

图5示出了本申请提出的适用于客户端的业务处理方法的又一可选示例的流程示意图；

图6示出了本申请提出的适用于服务器的业务处理方法的一可选示例的流程示意图；

图7a示出了本申请提出的业务处理方法中，回应报文的一种处理方式示意图；

图7b示出了本申请提出的业务处理方法中，回应报文的一种处理方式示意图；

图8示出了本申请提出的适用于服务器的业务处理方法的又一可选示例的流程示意图；

图9示出了实现本申请提出的业务处理方法的系统结构示意图；

图10示出了本申请提出的适用于客户端的业务处理装置的一可选示例的结构示意图；

图11示出了本申请提出的适用于客户端的业务处理装置的又一可选示例的结构示意图；

图12示出了本申请提出的适用于服务器的业务处理装置的一可选示例的结构示意图；

图13示出了本申请提出的适用于服务器的业务处理装置的又一可选示例的结构示意图

图14示出了本申请实施例提出的一种计算机设备的硬件结构示意图。

具体实施方式

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

需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

应当理解，本申请中使用的“系统”、“装置”、“单元”和/或“模块”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换该词语。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。以下术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。

另外，本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

参照图1，示出了本申请提出的业务处理方法的一可选示例的流程示意图，该方法可以适用于终端设备，具体可以适用于分布式系统中任一节点(如该终端设备)包含的客户端，本申请对该客户端的应用类型不做限定，可以根据该分布式系统的具体业务需求确定。如图1所示，本实施例提出的业务处理方法可以包括但并不局限于以下步骤：

步骤S11，获得目标业务请求；

其中，目标业务请求是针对新增业务发起的业务请求，本申请对系统新增业务的业务类型不做限定。

步骤S12，检测与目标业务请求相匹配的待合并业务请求；

本实施例中，待合并业务请求是针对已有业务发起的业务请求。为了减少客户端与服务器之间通信的报文数量，避免新增业务请求影响系统性能的稳定性，本申请提出将新增业务发起的目标业务请求，与已有业务发起的业务请求进行合并为一个请求报文，以使该请求报文携带多个业务请求，减少客户端与服务器之间的报文数量。

基于上述分析，本申请可以在系统中注册新增业务时，配置针对该新增业务发起的目标业务请求期望合并的请求报文，即该目标业务请求能够合并到针对已有业务发起的业务请求的请求报文中，具体配置内容及实现方法本申请不做限定。

具体的，在一些实施例中，对于针对不同业务发起的业务请求，本申请可以综合发送/回应业务请求的频率等信息，将频率相近的业务请求合并到一个请求报文中处理，不再针对每一个业务，生成独立的请求报文发送至服务器。所以，本申请可以据此确定针对新增业务配置的业务注册信息，以预先确定该新增业务的目标业务请求需要与哪一个或多个已有业务的业务请求合并生成一个请求报文。需要说明，关于新增业务的业务注册信息的配置方式并不局限于本实施例描述的方式，可以根据实际需求确定，本申请不做一一详述。

基于上述分析，本申请可以依据新增业务的业务注册信息，对针对系统中各已有业务发起的业务请求检测，得到与该目标业务请求相匹配的业务请求为待合并业务请求，即能够与目标业务请求合并到一个请求报文传输的业务请求。需要说明，本申请对步骤S12的具体实现方法不做限定，并不局限于本申请给出的实现方式。

在一种可能的实现方式中，按照上文描述的确定能够与新增业务的业务请求合并的已有业务请求的实现方式，本申请也可以直接从新增业务的业务注册信息中，获得该新增业务的请求报文的发送频率(为了方便描述，其可以记为第一发送频率)，统计针对已有业务发送的请求报文的发送频率(其可以记为第二发送频率)，之后，计算第一发送频率与第二发送频率的差值，选择差值绝对值小于频率阈值的针对已有业务发送的请求报文为待合并请求报文，即目标业务请求所要合并到的请求报文。

同理，对于待合并业务请求的获取方式，与上述待合并请求报文的获取方式类似，可以依据业务请求的发送频率，按照上述比较选择方式，得到新增业务对应的待合并请求业务，再执行步骤S13，以得到合并后的目标请求报文。

步骤S13，将目标业务请求更新至待合并业务请求的请求报文，得到目标请求报文；

步骤S14，将目标请求报文发送至服务器。

继上述分析，本申请确定当前存在的业务请求中，有目标业务请求能够合并的待合并业务请求后，为了减少客户端与服务器之间的报文数量，本实施例不再由目标业务请求生成独立的请求报文，而是将该目标业务请求与其他业务请求合并生成一个请求报文，再发送至服务器，相对于传统业务处理中，针对每一个业务请求生成一个请求报文发送至服务器，减少了客户端与服务器之间的报文数量，提高了系统性能的稳定性。

参照图2，示出了本申请提出的业务处理方法的又一可选示例的流程示意图，本实施例可以是对上述实施例描述的业务处理方法的一种可选的细化实现方式，如图2所示，该方法可以包括：

步骤S21，获得针对新增业务发起的目标业务请求；

步骤S22，获得目标业务请求以及当前存在的针对已有业务发起的已有业务请求各自的请求类型；

步骤S23，确定与目标业务请求所属请求类型相关联的待合并请求类型；

步骤S24，将属于待合并请求类型的已有业务请求确定为待合并业务请求；

结合上述对新增业务的描述，本申请在客户端注册新增业务，获得的业务注册信息能够表征该新增业务期望与哪一个或多个已有业务的请求报文合并，本申请对该业务注册信息的内容不做限定。本实施例以通过业务请求的请求类型，来确定目标业务请求能够与哪一个或多个已有业务的业务请求合并为例，介绍说明新增业务的目标业务请求向服务器的发送方式。需要说明，对于上述实施例步骤S12的实现，并不局限于本实施例描述的实现方式。

本实施例中，在系统中注册新增业务时，所获取的该新增业务的业务注册信息可以包括：能够与该新增业务的目标业务请求合并的已有业务的已有业务请求的请求类型，与该目标业务请求的请求类型之间的关联关系等，本申请对该关联关系的表示方式不做限定。

基于此，本实施例检测到当前存在的针对新增业务发起的目标业务请求，以及针对已有业务发起的已有业务请求后，可以先确定各业务请求对应的请求类型，再依据新增业务的业务注册信息包含的请求类型的关联关系，确定与该目标业务请求所属请求类型相关联的待合并请求类型，即能够与目标业务请求合并的其他业务请求所属的请求类型，之后，可以将当前存在的已有业务请求中，选择属于待合并请求类型的已有业务请求为待合并业务请求，具体实现过程不做详述。

需要说明的是，对于检测目标业务请求对应的待合并业务请求的实现方式，并不局限于本实施例上文描述的方式，对于依据业务请求的请求类型的实现方式，本申请也可以将能够合并的业务请求确定为同一请求类型，这样，在得到客户端当前存在的目标业务请求以及已有业务请求各自的请求类型后，可以将与该目标业务请求属于同一请求类型的已有业务请求确定为待合并业务请求。

当然，对于上述检测与目标业务请求相匹配的待合并业务请求的实现方式，并不局限于上文列举的几种实现方式，还可以预先指定能够与新增业务的目标业务请求能够合并的已有业务的业务类型，该预先指定的信息可以包含在新增业务的业务注册信息中，该预先指定的信息的内容及其表现方式不作限定，且对于预先指定的已有业务的业务类型，可以结合本行业的行业要求、具体业务需求、历史数据等多方面的内容综合确定，本申请不限定具体确定方式。

步骤S25，利用目标业务请求的请求属性信息，更新待合并业务请求的请求报文的报文头；

步骤S26，将目标业务请求的请求内容作为报文请求内容，添加至待合并业务请求的请求报文，得到目标请求报文；

实际应用中，报文作为网络中交换与传输的数据单元，可以包含将要发送的完整的数据信息，其长短往往不一致，长度不限且可变。基于报文的结构，本申请客户端向服务器发送的请求报文通常报告报文头和报文内容，该报文头包含有相应业务请求的请求属性，报文内容包含了相应业务请求的请求内容等，本申请对报文的组成结构不做限定。

基于此，针对已有业务发起的已有业务请求，生成相应的请求报文的报文头，该报文头所包含的字段类型及内容可以根据实际需求确定，本申请对该报文头包含的字段类型不做限定。本实施例中，该报文头可以包括该已有业务请求的请求属性信息，该如该业务请求的长度等信息。

在该已有业务请求确定为待合并业务请求的情况下，需要将获得的目标业务请求更新至该已有业务请求的请求报文中，具体的，可以将该目标业务请求的请求属性信息更新至该请求报文的报文头中，以使更新后的报文头能够包含合并的多个业务请求的请求属性信息，进而使得服务器能够检测该请求报文的报文头，能够得知该请求报文是否包含多个业务请求。但本申请对该报文头的具体更新方式不作限定，如直接将目标业务请求的请求属性信息，添加至待合并报文请求的请求报文中的报文头中，并更新该报文头中相应的字段数值等等。

相应地，对于目标业务请求的请求内容，可以作为该待合并业务请求的请求报文的报文内容的新增部分，添加至该请求报文中，实现对待合并业务请求的请求报文的更新，得到目标请求报文。

以分布式文件系统中的SetAttr操作和客户端请求Qos授权的操作这两种业务为例进行说明，SetAttr语句为一个文件设置属性信息，分布式文件系统中的SetAttr操作可以指文件设置属性操作，本申请对SetAttr操作的操作内容和方式，以及对Qos(Quality ofService，服务质量)授权的操作内容及方式均不作详述。

在该举例中，分布式文本系统在读写文件时，客户端通常会定时向服务器更新文件的属性，而在支持Qos特性的分布式文件系统中，客户端会定时向MDS(MultipointDistribution System，多点分布系统)申请其可读写文件的权限，为了实现这两种业务，客户端发起的相应的业务请求的请求频率差值小于频率阈值(其往往是较小的数值，但并不限定该频率阈值的具体数值大小)，为了减少客户端与服务器之间的请求报文的数量，本申请的客户端可以将这两种业务请求合并到同一个请求报文中发送至服务器。

按照上文描述的合并处理，参照图3所示的请求报文结构示意图，报文头head可以记录该请求报文包含的业务请求的数量，以及每个业务请求的长度等信息；报文内容部分可以包括通过SetAttr操作产生的业务请求setattr的请求内容，以及上述申请可读写文件权限的业务请求req_qos的请求内容。以此类推，若该请求报文还可以合并针对其他业务发起的业务请求，可以按照上述方式继续对报文头head的内容进行更新，并在报文内容中添加相应业务请求的请求内容，本申请不再一一详述。

需要说明，对于如何依据目标业务请求的请求属性，更新待合并业务请求的请求报文，得到目标请求报文的实现方法，并不局限于本实施例上文描述的实现方式，可以依据该请求报文的报文结构及其生成原理或预设更新规则确定，本申请不做一一详述。

步骤S27，将目标请求报文发送至服务器。

综上，本实施例中，对于新增业务发起的目标业务请求，不是直接生成相应的请求报文，而是要从当前存在的已有业务请求中，依据各业务请求的请求类型，确定出能够与目标业务请求合并的待合并业务请求，从而将目标业务请求的请求属性，更新至待合并业务请求的请求报文的报文头中，并将目标业务请求的请求内容添加至该请求报文中，以使得到的目标请求报文不再是携带一个业务请求，而是携带针对不同业务发起的多个业务请求，这样，在系统新增业务的情况下，也不会增加客户端与服务器之间的报文数量，避免了报文数量的增加，对系统性能稳定性的不利影响。

对于上述实施例描述的分布式系统中的新增业务，本申请希望在客户端上在线注册新增业务时，尽量降低对已有业务的运行可靠性的影响，对此，本申请提出了以下实施例描述的新增业务的注册过程，即分布式系统的业务扩展过程，但并不局限于以下实施例描述的实现方式。

参照图4，示出了本申请提出的适用于客户端的业务处理方法的又一可选示例的流程示意图，该方法可以包括但并不局限于以下步骤：

步骤S31，获取业务注册请求；

其中，该业务注册请求可以包含请求注册的新增业务的业务注册信息，业务注册信息能够表明与新增业务的目标业务请求相匹配的至少一个已有业务的业务请求，即能够与目标业务请求合并的至少一个已有业务的业务请求，本申请对该业务注册信息的配置过程及包含的内容不做限定。

在一些实施例中，若分布式系统需要新增业务(如新增功能)，需要在相应客户端和服务器中完成新增业务的注册，在客户端注册新增业务时，用户可以对客户端的功能配置界面，点击如“新增业务”功能按钮或选项，客户端响应用户操作，可以输出新增业务注册界面，用户可以在该新增业务注册界面中输入新增业务的名称、需要发送的请求报文的发送频率、期望合并的已有业务的请求报文的属性信息(如报文发送频率、报文标识、报文类型等等)或业务请求的属性信息(如请求类型、请求发送频率等)，以及消息回应的处理函数等信息，之后，用户可以点击如“注册”按钮或选项，生成包含用户在新增业务注册界面配置的这些内容(记为业务注册信息)的业务注册请求。

需要说明，关于本申请针对分布式系统中新增业务的业务注册请求的生成方式及其获取方式，并不局限于上文描述的实现方式，可以根据新增业务的功能以及客户端业务配置方式等因素，灵活实现相应业务注册信息的配置，本申请在此不做一一详述。

在一些实施例中，基于上述对新增业务的业务注册信息的获取方式，在上述实施例描述的新增业务的目标业务请求发送过程中，客户端获得该目标业务请求以及当前存在的已有业务的请求报文后，可以依据该新增业务的业务注册信息，检测当前已生成的已有业务的请求报文中，是否有该新增业务的目标业务请求能够合并的待合并请求报文，若有，可以按照上述方式将该目标业务请求，更新至该待合并请求报文中。

可见，在该实施例中，若新增业务的业务注册信息包含新增业务期望合并的已有业务的请求报文，可以直接按照上段描述的方式，直接对客户端当前已生成的请求报文进行检测，并将目标业务请求合并至检测到的待合并请求报文中的实现方式，相对于上述实施例对当前存在的已有业务请求进行检测，确定检测到的待合并业务请求所属请求报文，再将目标业务请求合并至该请求报文中的实现方式，进一步简化了业务处理步骤，提高了工作效率。

基于上述发明构思可见，在新增业务注册过程中，客户端配置的新增业务的业务注册信息包含的内容不同，后续针对新增业务发起目标业务请求，对目标业务请求的处理过程会相应改变，并不局限于上文列举的几种业务处理方式。

步骤S32，响应业务注册请求，依据业务注册信息，实现对新增业务的注册，以使新增业务与该至少一个已有业务共享一个报文结构；

本实施例中，可以在分布式系统中的已有业务运行过程中，实现新增业务的注册，在响应针对新增业务的业务注册请求时，通过解析该业务注册请求，得到新增业务的业务注册信息，从而依据该业务注册信息，将新增业务的发起的目标业务请求的请求内容注册到，与该目标业务请求相匹配的至少一个已有业务的报文结构中，这样，在新增业务后续发起目标业务请求后，不会再单独生产一个请求报文，而是由于该新增业务与该至少一个已有业务共享一个报文结构，使得该目标业务请求与相应已有业务发起的已有业务请求或请求报文合并，这样，系统即便新增业务，客户端与服务器之间也不会因此而增加报文数量，避免了报文数量过多而影响系统性能稳定性。

可见，相应现有技术中，需要针对新增业务，开发相应客户端新版本，需要停止客户端所有的业务，升级客户端版本，以使客户端支持新增业务的业务处理方案，本申请提出的如上描述的新增业务的注册过程，不需要进行系统升级、重新部署等操作，即不需要做很复杂的前期准备工作，降低了操作风险，避免了重新部署或升级新版本容易导致已有业务运作出错的情况发生，也就是说，本申请提出的这种在线扩展分布式系统的功能，即客户端在线注册新增业务的过程，不会影响该客户端运行中的业务，注册结束后新增业务即可使用。

步骤S33，获得针对新增业务发起的目标业务请求；

步骤S34，依据新增业务的业务注册信息，从针对已运行的业务发起的已有业务请求中，检测与该目标业务请求相匹配的待合并业务请求；

关于步骤S33和步骤S34的具体实现，可以参照上述实施例相应部分的描述，本实施例不再赘述。

步骤S35，确定待合并业务请求的请求报文的报文结构；

本实施例中，可以依据新增业务的业务注册信息，实现步骤S35，具体实现过程不做详述。该报文结构可以包括相应请求报文的组成部分，以及各组成部分所包含的字段类型等，如请求报文的报文头所要包含的字段类型及内容，报文内容所要包含的字段类型及内容，以及该请求报文的报文长度、所遵循的通信协议等信息，本申请对确定的报文结构的内容不做限定。

步骤S36，按照该报文结构，利用目标业务请求和待合并业务请求各自的请求属性信息，生成报文头；

步骤S37，按照报文结构，利用目标业务请求和待合并业务请求各自的请求内容，生成相应的报文请求内容；

步骤S38，利用报文头和生成的各报文请求内容，生成目标请求报文；

关于上述报文头及请求报文的报文内容的更新方式，可以参照上述实施例相应部分的描述，但并不局限于本申请描述的更新方式，所生成的目标请求报文可以如图3所示的请求报文示意图，但并不局限于此。

需要说明，关于目标请求报文的组成结构，包括但并不局限于上文给出的报文头和报文请求内容，可以根据报文结构的内容确定。

步骤S39，将目标请求报文发送至服务器。

综上，本申请实现了对分布式系统业务(其可以是一种功能)的灵活扩展，具体的，当系统需要添加新增业务的情况下，可以直接在服务器和客户端注册新增业务，在客户端注册新增业务时，采用将新增业务的信息扩展到已有业务的信息中的方式，实现新增业务的在线注册，即将新增业务的业务注册信息，直接注册到能够与其业务请求合并的已有业务的报文结构中，这样，针对新增业务发起的目标业务请求，可以直接依据业务注册信息，将该目标业务请求更新至相匹配的已生成的请求报文中，必须要在生成新的请求报文，解决了增加客户端与服务器之间的报文数量，影响系统性能的稳定性的技术问题。

对于上述从客户端角度描述的业务处理方法，将得到的携带有多个业务请求的目标请求报文发送至服务器后，服务器可以利用相应的处理函数进行处理，得到回应报文并反馈至客户端，下面将对客户端接收到回应报文后的处理过程进行描述，关于对目标请求报文的生成过程可以参照上述实施例相应部分的描述，本实施例不再详述，参照图5，为本申请提出的适用于客户端的业务处理方法的又一可选示例的流程示意图，在上述各实施例描述的业务处理方法的基础上，该方法还可以包括：

步骤S41，接收服务器反馈的针对目标业务请求的回应报文；

应该理解，该回应报文是服务器对包含目标业务请求的目标请求报文进行处理，利用得到的相应的业务响应结构生成的，具体生成过程可以参照下文从服务器角度描述的实施例的相应部分的描述。

步骤S42，检测回应报文包含多个业务请求的业务响应结果，拆分回应报文，得到多个业务响应结果；

本申请中，服务器响应多个业务请求(其包含目标业务请求及相匹配的待合并业务请求)，采用相应的处理函数对其进行处理，得到相应的业务响应结果后，由于服务器可以将得到的多个业务响应结果合并到一个回应报文反馈至客户端，也可以针对每一个业务响应结果生成一个回应报文反馈至客户端，但并不局限于这两种反馈方式，可以根据实际情况确定。

本实施例主要对回应报文包含多个业务响应结果的情况进行说明，且这种情况下，这多个业务响应结果可以包括：针对目标业务请求的目标业务响应结果，以及针对待合并业务请求的业务响应结果。本申请对不同业务请求的业务响应结果的内容不做限定，具体依据该业务请求的请求内容及业务类型确定，本实施例在此不做一一详述。

关于对回应报文的拆分方式，可以依据多个业务响应结果的合并方式，或者说多个业务请求的合并方式确定，具体实现过程不做限定。

步骤S43，调用多个业务响应结果各自对应的处理函数，对相应的业务响应结果进行处理。

其中，对于不同业务的处理函数，可以是在业务注册过程中实现的，对于新增业务来说，如上述分析，其业务注册信息包含了相应的处理函数，这样，客户端得到新增业务发起的目标业务请求的目标业务响应结果后，可以利用该新增业务的处理函数，对目标业务响应结果进行处理，以使客户端实现新增业务，本申请对客户端调用处理函数进行处理的实现过程不做详述。

综上，对于系统新增业务，在注册、发起目标业务请求，并通过合并至相匹配的请求报文中发送至服务器，以及接收服务器反馈的回应报文，调用相应的处理函数进行处理的整个业务处理过程，不会影响客户端已运行的业务，保证了系统的性能稳定性。

下面将从服务器角度描述，本申请提出的业务处理方法，其包括但并不局限于下文实施例描述的实现方式。

参照图6，为本申请提出的适用于服务器的业务处理方法的一可选示例的流程示意图，该方法可以包括：

步骤S51，接收客户端发送的目标请求报文；

其中，目标请求报文可以是通过将目标业务请求更新至待合并业务请求的请求报文得到的，该目标业务请求可以是针对新增业务发起的业务请求，待合并业务请求可以是针对已有业务发起的与目标业务请求相匹配的业务请求。

需要说明，关于客户端如何得到目标请求报文，并发送至服务器的实现过程，可以参照上述从客户端角度描述的方法实施例相应部分的介绍，本实施例不再赘述。

步骤S52，对目标请求报文进行拆分，得到目标业务请求和待合并业务请求；

结合上述实施例描述的目标请求报文的生成过程可知，该目标请求报文携带有多个业务请求，所以，服务器接收到客户端发送的该目标请求报文，并检测到其包含多个业务请求的情况下，可以该目标请求报文拆分成不同的业务请求，即拆分得到针对新增业务的目标业务请求，以及针对已有业务的待合并业务请求，具体拆分方法本申请不做限定。

步骤S53，调用目标业务请求和待合并业务请求各自对应的处理函数，响应相应的业务请求，得到业务响应结果；

需要说明，对于服务器能够支持的各业务，在业务注册过程中，会注册相应的处理函数，所以，对于系统的新增业务，客户端侧可以按照上述方式进行注册，相应的，服务器侧也会注册该新增业务的处理函数，以使服务器能够支持新增业务的实现，具体注册过程不做详述。

基于此，服务器得到新增业务的目标业务请求，以及已有业务的待合并业务请求后，可以调用各自的处理函数进行处理，得到相应的业务响应结果，关于如何调用处理函数进行处理过程，本申请不作详述。

步骤S54，利用得到的多个业务响应结果，生成至少一个回应报文；

步骤S55，将至少一个回应报文反馈至客户端。

本实施例中，服务器得到各业务请求的业务响应结果后，可以采用但并不局限于如图7a和图7b所示的回应方式，生成回应报文反馈至客户端，具体的，如图7a所示，服务器可以将多个业务响应结果合并生成一个回应报文反馈至客户端；如图7b所示，服务器可以将不同的业务请求的业务响应结果生成各自的回应报文，再将得到的多个回应报文反馈至客户端等等。之后，客户端可以按照上述方式对得到的回应报文进行处理。

在一些实施例中，服务器可以依据得到的不同业务响应结果的生成时间的差值，来确定采用如上描述的不同的回应方式，生成回应报文。具体可以采用如图8所示的本申请提出的适用于服务器的业务处理方法的又一可选示例的流程示意图，其主要对上述步骤S54的实现过程进行描述，该生成过程可以包括：

步骤A1，获取得到的多个业务响应结果各自的生成时间；

步骤A2，依据生成时间，将满足条件的多个业务响应结果合并生成一个回应报文；

本实施例中，对应几乎同时处理完成的业务请求后得到的业务响应结果，服务器可以将这些业务响应结果合并成一个回应报文，发送给客户端，如图上图7a所示的方式；若不同业务请求在服务器侧处理时间差距较大，为了给客户端及时响应，避免用户等待时间过长，服务器可以将不同业务请求对应的业务响应结果，分别生成各自的回应报文反馈至客户端，即通过多个回应报文反馈至客户端，如图上述图7b所示的方式。

基于此，上述满足条件的多个业务响应结果是指：满足条件的多个业务响应结果中任意两个业务响应结果对应的生成时间的时间差小于特定阈值，也就是说，这多个业务响应结果差不多是同一时间生成的，该特定阈值是相对较小的数值，其所指的具体数值大小不做限定。

关于将多个业务响应结果合并生成一个回应报文的实现方式，与上述多个业务请求合并生成一个请求报文的实现方式类似，该回应报文的报文头可以包括其携带的多个业务响应结果的数量，以及每个业务响应结果的长度等信息，报文内容包含了各业务响应结果的内容。可见，客户端可以通过检测回应报文的报文头，来确定该回应报文是否携带多个业务响应结果。本申请对上述合并得到的回应报文的实现方式不做限定。

步骤A3，如果存在不满足条件的业务响应结果，由不满足条件的各业务响应结果，生成相应的回应报文。

继上述分析，不满足条件的业务响应结果可以是这些业务响应结果的生成时间的差距较大，为了避免客户端侧用户等待时间过长，提高请求响应速度，本实施例将直接依据每一个业务响应结果生成一个回应报文，反馈至客户端。举例说明，服务器可以先对针对业务1的业务请求进行处理，将得到的该业务1的业务响应结果反馈至客户端；待业务2的业务请求处理完后，将业务2对应的业务响应结果反馈至客户端，依次类推，保证客户端能够及时得到业务请求的响应结果。

综上所述，本实施例中，服务器得到客户端经过合并生成的目标请求报文后，可以对其拆分处理，就能够得到针对新增业务的目标业务请求，及针对已有业务的业务请求，也就是说，服务器解析一个请求报文，可以得到多个业务请求，相对于现有技术解析多个请求报文，才能够得到这多个业务请求的方案，减少了服务器的处理工作量，提高了工作效率，且避免了客户端与服务器之间因报文数量增大，影响系统性能的稳定性。

之后。服务器调用各业务请求对应的处理函数进行处理后，得到多个业务响应结果后，还可以根据实际情况，选择合并生成一个回应报文反馈至客户端，或者分别生成相应的一个回应报文反馈至客户端，以使得客户端实现相应的业务，提高了业务处理方法的灵活性及多样性，保证了业务请求响应效率。

综合上述从客户端角度和服务器角度分别描述的业务处理方法，参照图9，示出了实现该业务处理方法的系统架构示意图，该系统可以包括客户端100和服务器200，以客户端100包含已有业务(如图9所示的业务1、业务、但并不局限于此)和新增业务(如图9所示的新增业务1)为例进行说明，其可以配置有业务处理模块110以及报文发送及回应处理模块120。

结合上述从客户端侧描述的业务处理方法可知，本申请的业务处理模块110中相对于传统方案添加了如图9所示的业务注册模块111，用于实现对新增业务的注册过程，具体实现过程可以参照上述实施例相应部分的描述，不再赘述；报文合并模块112，用于将新增业务1发起的目标业务请求，与相匹配的待合并业务请求(如业务1和/或业务2发起的业务请求)合并生成目标请求报文，具体实现过程可以参照上述实施例相应部分的描述，不再赘述。

而对于上述报文发送及回应处理模块120，不再是仅用于实现请求报文与回应报文的接收，结合上述实施例的描述，在其接收到的回应报文包含多个业务响应结果的情况下，该报文发送及回应处理模块120需要对该回应报文进行拆分，得到多个业务响应结果，再发送至业务注册模块111，使其调用相应的处理函数进行处理。

相应地，在服务器200侧，其可以包括报文接收模块210、报文拆分及分配模块220、各业务处理模块230及报文回应处理模块240，可见，其相对于传统的服务器，增加了报文拆分及分配模块220和报文回应处理模块240。

本实施例实际应用中，服务器侧注册新增业务后，会生成相应的业务处理模块，以使其调用相应的处理函数进行处理，仍以相对于上述客户端包含的业务类型的举例，该服务器包含可以配置有业务1处理模块、业务2处理模块和新增业务1处理模块.

其中，报文接收模块210可以用于接收客户端发送的请求报文，将其发送至报文拆分及分配模块220，若该请求报文是上述目标请求报文，即携带有多个业务请求，该报文拆分及分配模块220可以用于拆分该请求报文，将得到的多个业务请求，如新增业务1的目标请求，待合并业务请求分别发送至相应的业务处理模块进行处理，将得到的业务响应结果发送至报文回应处理模块240，报文回应处理模块240可以按照上述方式，由得到的多个业务响应结果，生成至少一个回应报文，发送至客户端的报文发送及回应处理模块120。

需要说明，关于上述系统实施例描述的客户端和服务器包含的各功能模块，实现相应功能的具体实现过程，可以参照上述方法实施例相应部分的描述，本实施不再详述。

参照图10，示出了本申请提出的业务处理装置的一可选示例的结构示意图，该装置可以适用于终端设备中的客户端，如图10所示，该装置可以包括：

获得模块31，用于获得目标业务请求，所述目标业务请求是针对新增业务发起的业务请求；

检测模块32，用于检测与所述目标业务请求相匹配的待合并业务请求，所述待合并业务请求是针对已有业务发起的业务请求；

更新模块33，用于将所述目标业务请求更新至所述待合并业务请求的请求报文，得到目标请求报文；

传输模块34，用于将所述目标请求报文发送至服务器。

在一些实施例中，如图11所示，上述检测模块32可以包括：

请求类型获得单元321，用于获得所述目标业务请求及已有业务请求各自的请求类型；

第一确定单元322，用于将与所述目标业务请求属于同一请求类型的已有业务请求确定为待合并业务请求；或者，

第二确定单元323，用于确定与所述目标业务请求所属请求类型相关联的待合并请求类型，将属于所述待合并请求类型的已有业务请求确定为待合并业务请求。

在一些实施例中，上述更新模块33可以包括：

报文头更新单元，用于利用所述目标业务请求的请求属性信息，更新所述待合并业务请求的请求报文的报文头；

目标请求报文得到单元，用于将所述目标业务请求的请求内容作为报文请求内容，添加至所述待合并业务请求的请求报文，得到目标请求报文。

在上述各实施例的基础上，本申请提出的业务处理装置还可以包括：

业务注册请求获取模块，用于获取业务注册请求，所述业务注册请求包含请求注册的新增业务的业务注册信息，所述业务注册信息表明与所述新增业务的目标业务请求相匹配的至少一个已有业务的业务请求；

业务注册模块，用于响应所述业务注册请求，依据所述业务注册信息，实现对所述新增业务的注册，以使所述新增业务与所述至少一个已有业务共享一个报文结构。

相应地，在一些实施例中，上述更新模块33可以包括：

报文结构确定单元，用于确定所述待合并业务请求的请求报文的报文结构；

报文头生成单元，用于按照所述报文结构，利用所述目标业务请求和所述待合并业务请求各自的请求属性信息，生成报文头；

报文请求内容生成单元，用于按照所述报文结构，利用所述目标业务请求和所述待合并业务请求各自的请求内容，生成相应的报文请求内容；

目标请求报文生成单元，用于利用所述报文头和生成的各报文请求内容，生成目标请求报文。

在上述各实施例的基础上，本申请提出的业务处理装置还可以包括：

回应报文接收模块，用于接收所述服务器反馈的针对所述目标业务请求的回应报文；

回应报文拆分模块，用于检测所述回应报文包含多个业务请求的业务响应结果，拆分所述回应报文，得到多个业务响应结果，其中，所述多个业务响应结果包括：针对所述目标业务请求的目标业务响应结果，以及针对所述待合并业务请求的业务响应结果；

处理函数调用模块，用于调用所述多个业务响应结果各自对应的处理函数，对相应的业务响应结果进行处理。

需要说明的是，关于上述各装置实施例中的各种模块、单元等，均可以作为程序模块存储在存储器中，由处理器执行存储在存储器中的上述程序模块，以实现相应的功能，关于各程序模块及其组合所实现的功能，以及达到的技术效果，可以参照上述从客户端侧描述的方法实施例相应部分的描述，本实施例不再赘述。

上文描述的业务处理装置是从客户端侧角度描述的，下面将从服务器侧角度描述业务处理装置的组成结构。

如图12所示，为本申请提出的适用于服务器的业务处理装置的一可选示例的结构示意图，该装置可以包括：

接收模块41，用于接收客户端发送的目标请求报文；

其中，所述目标请求报文是通过将目标业务请求更新至待合并业务请求的请求报文得到的，所述目标业务请求是针对新增业务发起的业务请求，所述待合并业务请求是针对已有业务发起的与所述目标业务请求相匹配的业务请求；

拆分模块42，用于对所述目标请求报文进行拆分，得到所述目标业务请求和所述待合并业务请求；

处理模块43，用于调用所述目标业务请求和所述待合并业务请求各自对应的处理函数，响应相应的业务请求，得到业务响应结果；

生成模块44，用于利用得到的多个业务响应结果，生成至少一个回应报文；

在一些实施例中，如图13所示，该生成模块44可以包括：

第一生成单元441，用于由得到的多个业务响应结果生成各自的回应报文；或者，

生成时间获取单元442，用于获取得到的多个业务响应结果各自的生成时间；

第二生成单元443，用于依据所述生成时间，将满足条件的多个业务响应结果合并生成一个回应报文，所述满足条件的多个业务响应结果中任意两个业务响应结果对应的生成时间的时间差小于特定阈值；

第三生成单元444，用于在存在不满足所述条件的业务响应结果的情况下，由不满足所述条件的各业务响应结果，生成相应的回应报文。

反馈模块45，用于将所述至少一个回应报文反馈至所述客户端。

需要说明的是，关于上述各装置实施例中的各种模块、单元等，均可以作为程序模块存储在存储器中，由处理器执行存储在存储器中的上述程序模块，以实现相应的功能，关于各程序模块及其组合所实现的功能，以及达到的技术效果，可以参照上述从服务器侧描述的方法实施例相应部分的描述，本实施例不再赘述。

本申请还提供了一种存储介质，其上可以存储计算机程序，该计算机程序可以被处理器调用并加载，以实现上述实施例描述的业务处理方法的各个步骤。

本申请还提出了一种计算机设备，如图14所示的计算机设备的硬件结构示意图，该计算机设备可以包括通信接口51、存储器52和处理器53，其中：

通信接口51、存储器52和处理器53各自数量可以是至少一个，且通信接口51、存储器52和处理器53可以通过通信总线彼此相连，实现相互之间的数据交互，本申请对这几部分的具体连接方式不作限定。

通信接口51可以为有线网络和/或无线网络中的通信模块的接口，如GSM模块、WIFI模块、GPRS模块、蓝牙模块等无线通信模块的接口，可以实现与其他设备的数据交互，还可以包括如USB接口、串/并口等有线通信接口，用于实现计算机设备内部组成部件之间的数据交互，可以根据该计算机设备的产品类型确定，本申请不做一一详述。

存储器52可以用于存储实现计算机设备相应侧方法实施例描述的业务处理方法的程序；处理器53可以加载并执行存储器52中存储的程序，以实现本申请上述计算机设备相应侧提出的业务处理方法的各个步骤，具体实现过程可以参照上述相应实施例的描述，不再赘述。

在本申请实施例中，存储器52可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。处理器53，可以为中央处理器(CentralProcessing Unit，CPU)、特定应用集成电路(application-specificintegrated circuit，ASIC)、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件等。

应该理解的是，图14所示的计算机设备的结构并不构成对本申请实施例中计算机设备的限定，在实际应用中，计算机设备可以包括比图14所示的更多或更少的部件，或者组合某些部件，本申请在此不做一一列举。

举例说明，若该计算机设备是终端设备，该计算机设备还可以包括如感应触摸显示面板上的触摸事件的触摸感应单元、键盘、鼠标、摄像头、拾音器等输入设备中的至少一个，以及如显示器(可以包括显示面板，如触摸显示面板等)、扬声器、振动机构、灯等输出设备中的至少一个，可以依据该终端设备的具体产品类型及其功能确定，并不局限于本实施例列举的组成部件。若上述计算机设备是服务器，该服务器还可以包括其他存储设备，如特定功能的数据库等，本申请不做一一详述。

最后，需要说明，本说明书中各个实施例采用递进或并列的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、计算机设备而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种业务处理方法，所述方法包括：

获得目标业务请求，所述目标业务请求是针对新增业务发起的业务请求；

检测与所述目标业务请求相匹配的待合并业务请求，所述待合并业务请求是针对已有业务发起的业务请求；

将所述目标业务请求更新至所述待合并业务请求的请求报文，得到目标请求报文，将所述目标请求报文发送至服务器。

2.根据权利要求1所述的方法，所述检测与所述目标业务请求相匹配的待合并业务请求，包括：

获得所述目标业务请求及已有业务请求各自的请求类型；

将与所述目标业务请求属于同一请求类型的已有业务请求确定为待合并业务请求；或者，

确定与所述目标业务请求所属请求类型相关联的待合并请求类型，将属于所述待合并请求类型的已有业务请求确定为待合并业务请求。

3.根据权利要求1所述的方法，所述将所述目标业务请求更新至所述待合并业务请求的请求报文，得到目标请求报文，包括：

利用所述目标业务请求的请求属性信息，更新所述待合并业务请求的请求报文的报文头；

将所述目标业务请求的请求内容作为报文请求内容，添加至所述待合并业务请求的请求报文，得到目标请求报文。

4.根据权利要求1所述的方法，所述方法还包括：

获取业务注册请求，所述业务注册请求包含请求注册的新增业务的业务注册信息，所述业务注册信息表明与所述新增业务的目标业务请求相匹配的至少一个已有业务的业务请求；

响应所述业务注册请求，依据所述业务注册信息，实现对所述新增业务的注册，以使所述新增业务与所述至少一个已有业务共享一个报文结构。

5.根据权利要求4所述的方法，所述将所述目标业务请求更新至所述待合并业务请求的请求报文，得到目标请求报文，包括：

确定所述待合并业务请求的请求报文的报文结构；

按照所述报文结构，利用所述目标业务请求和所述待合并业务请求各自的请求属性信息，生成报文头；

按照所述报文结构，利用所述目标业务请求和所述待合并业务请求各自的请求内容，生成相应的报文请求内容；

利用所述报文头和生成的各报文请求内容，生成目标请求报文。

6.根据权利要求1～5任一项所述的方法，所述方法还包括：

接收所述服务器反馈的针对所述目标业务请求的回应报文；

检测所述回应报文包含多个业务请求的业务响应结果，拆分所述回应报文，得到多个业务响应结果，其中，所述多个业务响应结果包括：针对所述目标业务请求的目标业务响应结果，以及针对所述待合并业务请求的业务响应结果；

调用所述多个业务响应结果各自对应的处理函数，对相应的业务响应结果进行处理。

7.一种业务处理方法，所述方法包括：

接收客户端发送的目标请求报文，所述目标请求报文是通过将目标业务请求更新至待合并业务请求的请求报文得到的，所述目标业务请求是针对新增业务发起的业务请求，所述待合并业务请求是针对已有业务发起的与所述目标业务请求相匹配的业务请求；

对所述目标请求报文进行拆分，得到所述目标业务请求和所述待合并业务请求；

调用所述目标业务请求和所述待合并业务请求各自对应的处理函数，响应相应的业务请求，得到业务响应结果；

利用得到的多个业务响应结果，生成至少一个回应报文；

将所述至少一个回应报文反馈至所述客户端。

8.根据权利要求7所述的方法，所述由得到的多个业务响应结果，生成至少一个回应报文，包括：

由得到的多个业务响应结果生成各自的回应报文；或者，

获取得到的多个业务响应结果各自的生成时间；

依据所述生成时间，将满足条件的多个业务响应结果合并生成一个回应报文，所述满足条件的多个业务响应结果中任意两个业务响应结果对应的生成时间的时间差小于特定阈值；

如果存在不满足所述条件的业务响应结果，由不满足所述条件的各业务响应结果，生成相应的回应报文。

9.一种业务处理装置，所述装置包括：

获得模块，用于获得目标业务请求，所述目标业务请求是针对新增业务发起的业务请求；

检测模块，用于检测与所述目标业务请求相匹配的待合并业务请求，所述待合并业务请求是针对已有业务发起的业务请求；

更新模块，用于将所述目标业务请求更新至所述待合并业务请求的请求报文，得到目标请求报文；

传输模块，用于将所述目标请求报文发送至服务器。

10.一种业务处理装置，所述装置包括：

接收模块，用于接收客户端发送的目标请求报文，所述目标请求报文是通过将目标业务请求更新至待合并业务请求的请求报文得到的，所述目标业务请求是针对新增业务发起的业务请求，所述待合并业务请求是针对已有业务发起的与所述目标业务请求相匹配的业务请求；

拆分模块，用于对所述目标请求报文进行拆分，得到所述目标业务请求和所述待合并业务请求；

处理模块，用于调用所述目标业务请求和所述待合并业务请求各自对应的处理函数，响应相应的业务请求，得到业务响应结果；

生成模块，用于利用得到的多个业务响应结果，生成至少一个回应报文；

反馈模块，用于将所述至少一个回应报文反馈至所述客户端。

Images