CN116233053A - 业务请求消息的发送方法、装置及存储介质 - Google Patents

Abstract

本申请提供一种业务请求消息的发送方法、装置及存储介质，涉及通信领域，用于减小服务器的处理负载。该方法应用于中间层服务。该方法包括：接收来自客户端的M个业务请求消息，并存储M个业务请求消息，M为正整数。按照预设时间间隔从存储的M个业务请求消息中获取N个业务请求消息，并向业务服务器发送N个业务请求消息，业务服务器用于处理M个业务请求消息，预设时间间隔和N与业务服务器的处理资源相关联，N为正整数，N小于M。

Description

业务请求消息的发送方法、装置及存储介质

技术领域

本申请涉及通信领域，尤其涉及一种业务请求消息的发送方法、装置及存储介质。

背景技术

随着通信技术的发展，电子设备逐渐增多，部署于电子设备上的应用程序也逐渐增多。用户通过电子设备的客户端发出业务请求，需要客户端对应的服务器进行处理。

目前，在业务请求的传输过程中，客户端可以接收来自用户的业务请求。然后，客户端会即时向客户端对应的服务器发送业务请求。之后，服务器会接收来自客户端的业务请求，并进行处理。但是，当用户发起的业务请求数量过多时，服务器需要处理的业务请求数量增多，从而可能会增加服务器的处理负载。

发明内容

本申请提供一种业务请求消息的发送方法、装置及存储介质，用于减小服务器的处理负载。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供一种业务请求消息的发送方法。该方法可以应用于中间层服务。中间层服务可以接收来自客户端的M个业务请求消息，并存储M个业务请求消息，M为正整数。中间层服务可以按照预设时间间隔从存储的M个业务请求消息中获取N个业务请求消息，并向业务服务器发送N个业务请求消息，业务服务器用于处理M个业务请求消息，预设时间间隔和N与业务服务器的处理资源相关联，N为正整数，N小于M。

可选的，中间层服务可以获取M个业务请求消息中每个业务请求消息的第一时刻，第一时刻为中间层服务接收到业务请求消息的时刻。上述“存储M个业务请求消息”的方法，还可以包括：中间层服务可以基于每个业务请求消息的第一时刻，按照第一时刻从早到晚的顺序，将M个业务请求消息存储至消息队列。

可选的，中间层服务可以对于每次发送N个业务请求消息，接收来自业务服务器的反馈消息，反馈消息用于指示已经成功接收N个业务请求消息。中间层服务可以为已经发送的N个业务请求消息添加成功信息，成功信息用于指示已经将N个业务请求消息发送至业务服务器。

可选的，对于每次发送N个业务请求消息，中间层服务若在发送N个业务请求消息之后的预设时长之内，未接收到反馈消息，则中间层服务重新向业务服务器发送N个业务请求消息。

第二方面，本申请提供一种业务请求消息的发送装置，该装置应用于中间层服务，该装置包括：接收模块、存储模块、发送模块、处理模块。

接收模块，用于接收来自客户端的M个业务请求消息，M为正整数。存储模块，用于存储M个业务请求消息，M为正整数。接收模块，还用于按照预设时间间隔从存储的M个业务请求消息中获取N个业务请求消息，N为正整数，N小于M。发送模块，用于向业务服务器发送N个业务请求消息，业务服务器用于处理M个业务请求消息，预设时间间隔和N与业务服务器的处理资源相关联。

可选的，接收模块，还用于获取M个业务请求消息中每个业务请求消息的第一时刻，第一时刻为中间层服务接收到业务请求消息的时刻。存储模块，具体用于基于每个业务请求消息的第一时刻，按照第一时刻从早到晚的顺序，将M个业务请求消息存储至消息队列。

可选的，接收模块，还用于对于每次发送N个业务请求消息，接收来自业务服务器的反馈消息，反馈消息用于指示已经成功接收N个业务请求消息。处理模块，用于为已经发送的N个业务请求消息添加成功信息，成功信息用于指示已经将N个业务请求消息发送至业务服务器。

可选的，发送模块，还用于对于每次发送N个业务请求消息，若在发送N个业务请求消息之后的预设时长之内，未接收到反馈消息，则重新向业务服务器发送N个业务请求消息。

第三方面，本申请提供了一种业务请求消息的发送装置，该装置包括：处理器和存储器。处理器和存储器耦合。存储器用于存储一个或多个程序，该一个或多个程序包括计算机执行指令，当该业务请求消息的发送装置运行时，处理器执行该存储器存储的该计算机执行指令，以实现如第一方面中的任一种可能的实现方式中所描述的业务请求消息的发送方法。

第四方面，本申请提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当指令在计算机上运行时，使得计算机执行上述第一方面中的任一种可能的实现方式中所描述的业务请求消息的发送方法。

第五方面，本申请提供了一种计算机程序产品，包括计算机程序，当其计算机程序被处理器执行时，使得计算机实现如第一方面中的任一种可能的实现方式中所描述的业务请求消息的发送方法。

上述方案中，业务请求消息的发送装置、计算机设备、计算机存储介质或者计算机程序产品所能解决的技术问题以及实现的技术效果可以参见上述第一方面所解决的技术问题以及技术效果，在此不再赘述。

本申请提供的技术方案至少带来以下有益效果：中间层服务可以接收来自客户端的M个业务请求消息，并存储M个业务请求消息，M为正整数。中间层服务按照预设时间间隔从存储的M个业务请求消息中获取N个业务请求消息，并向业务服务器发送N个业务请求消息，业务服务器用于处理M个业务请求消息，预设时间间隔和N与业务服务器的处理资源相关联，N为正整数，N小于M。这样一来，中间层服务可以先存储业务请求消息，再批量向业务服务器发送客户端的业务请求消息，避免客户端直接向业务服务器发送业务请求消息，减小业务服务器的处理负载。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理，并不构成对本申请的不当限定。

图1是根据一示例性实施例示出的一种发送业务请求消息的架构示意图；

图2是根据一示例性实施例示出的一种业务请求消息的发送方法的流程图；

图3是根据一示例性实施例示出的另一种业务请求消息的发送方法的流程图；

图4是根据一示例性实施例示出的另一种业务请求消息的发送方法的流程图；

图5是根据一示例性实施例示出的一种业务请求消息的发送装置的结构框图；

图6是根据一示例性实施例示出的一种业务请求消息的发送装置的结构示意图。

具体实施方式

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

本文中字符“/”，一般表示前后关联对象是一种“或者”的关系。例如，A/B可以理解为A或者B。

本申请的说明书和权利要求书中的术语“第一”和“第二”是用于区别不同的对象，而不是用于描述对象的特定顺序。

此外，本申请的描述中所提到的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或模块的过程、方法、***、产品或设备没有限定于已列出的步骤或模块，而是可选地还包括其他没有列出的步骤或模块，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或模块。

另外，在本申请实施例中，“示例性的”、或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”、或者“例如”等词旨在以具体方式呈现概念。

在对本申请实施例的业务请求消息的发送方法进行详细介绍之前，先对本申请实施例的实施环境和应用场景进行介绍。

目前，在业务请求的传输过程中，客户端可以接收来自用户的业务请求。然后，客户端会即时向客户端对应的服务器发送业务请求。之后，服务器会接收来自客户端的业务请求，并进行处理。但是，当用户发起的业务请求数量过多时，服务器需要处理的业务请求数量增多，从而可能会增加服务器的处理负载。

为了解决上述问题，本申请实施例提供一种业务请求消息的发送方法，该方法应用于中间层服务，中间层服务可以接收来自客户端的M个业务请求消息，并存储M个业务请求消息，M为正整数。中间层服务可以按照预设时间间隔从存储的M个业务请求消息中获取N个业务请求消息，并向业务服务器发送N个业务请求消息，业务服务器用于处理M个业务请求消息，预设时间间隔和N与业务服务器的处理资源相关联，N为正整数，N小于M。这样一来，中间层服务可以先存储业务请求消息，再批量向业务服务器发送客户端的业务请求消息，避免客户端直接向业务服务器发送业务请求消息，减小业务服务器的处理负载。

下面对本申请实施例的实施环境进行介绍。

图1为根据一示例性实施例示出的一种发送业务请求消息的架构示意图。该架构包括：客户端101、中间层服务102、业务服务器103。客户端101与中间层服务102可以进行有线/无线通信。中间层服务102与业务服务器103可以进行有线/无线通信。业务服务器103与客户端101可以进行有线/无线通信。

其中，客户端101，可以用于接收用户的业务请求消息，客户端101还可以向中间层服务发送业务请求消息。客户端101，还可以用于将处理后的业务请求消息可视化呈现。

需要说明的是，在本申请实施例中，对客户端不作限定。例如，客户端可以为本地运行的应用程序。又例如，客户端可以为万维网使用的网页浏览器。又例如，客户端可以为即时通讯的软件。客户端可以部署在电子设备上，也可以部署在其他的硬件设备上。

中间层服务102，可以用于存储业务请求消息。中间层服务102，还可以用于对客户端101发送的业务请求消息进行处理，并且可以向业务服务器103发送业务请求消息。中间层服务102，还可以用于接收业务服务器103返回的结果。

需要说明的是，在本申请实施例中，对中间层服务的部署位置不作限定。例如，中间层服务可以部署于客户端与业务服务器之间。又例如，中间层服务可以部署于客户端上。又例如，中间层服务可以部署于业务服务器上。在本申请实施例中，以中间层服务部署于客户端与业务服务器之间为例对业务请求消息的发送方法进行描述。

业务服务器103，可以用于对业务请求消息进行处理，并向客户端101发送处理后的业务请求消息。

下面结合说明书附图对本申请实施例进行具体说明。

如图2所示，为本申请实施例提供的一种业务请求消息的发送方法，该方法包括：

S201、中间层服务接收来自客户端的M个业务请求消息。

其中，M为正整数。

在一种可能的实现方式中，客户端可以接收来自用户的M个业务请求消息。之后，客户端可以向中间层服务发送M个业务请求消息。中间层服务可以接收来自客户端的M个业务请求消息。

示例性的，假如M为100，即客户端接收到100个业务请求消息，并向中间层服务发送100个业务请求消息。中间层服务接收来自客户端的100个业务请求消息。

需要说明的是，在本申请实施例中，客户端可以通过多线程的方式，向中间层服务发送M个业务请求消息。

S202、中间层服务存储M个业务请求消息。

在一种可能的实现方式中，中间层服务部署有数据库。中间层服务可以将M个业务请求消息存储至数据库。

需要说明的是，在本申请实施例中，中间层服务将M个业务请求消息存储至数据库，可以实现业务请求消息的持久化。也就是说，中间层服务可以长时间地保存业务请求消息。

示例性的，中间层服务将M个业务请求消息存储至数据库的相关代码如下所示。

ipvsDao＝(IprovisionDaoApi)BeanFactoryUtil.getBean(beanName:"iprovisionDaoApi")；

IpvsDepenDaoApi ipvsDepdDao＝(IpvsDepenDaoApi)BeanBeanFactoryUtil.getBean(beanName:"iprovisionDaoApi")。

其中，getBean用于表示获取对象(Bean)，对象包括M个业务请求消息。ipvsDao用于表示数据库。

S203、中间层服务按照预设时间间隔从存储的M个业务请求消息中获取N个业务请求消息。

其中，N为正整数，N小于M。

需要说明的是，在本申请实施例中，对预设时间间隔和N不作限定。例如，预设时间间隔可以为1秒，N可以为20。又例如，预设时间间隔可以为2秒，N可以为25。又例如，预设时间间隔可以为1.5秒，N可以为15。

在一种可能的实现方式中，中间层服务可以按照预设时间间隔，从存储的M个业务请求消息中获取K个业务请求消息。之后，中间层服务可以从K个业务请求消息中获取N个业务请求消息。其中，K为正整数，K小于M，K大于N或者K等于N。

示例性的，中间层服务从M个业务请求消息中获取N个业务请求消息的相关代码如下所示。

ipvsList＝ipvsDao.qryInstructRst()；

Map osMap＝new HashMao()；

If(ipvsList！＝null&&ipvsList.size()>0{logger.info("本次扫描指令集合条数："+ipvsList.size())；

ipvsDao.batchUpdateSearchByPsId(ipvsList)；}。

其中，ipvsList用于表示存储N个业务请求消息的表。ipvsList.size()用于表示N的值。

示例性的，假如预设时间间隔为1秒，M为100。假如中间层服务在1秒内可以获取50个业务请求消息，则K为50。假如N为10，则中间层服务可以从50个业务请求消息中获取10个业务请求消息。

在一种可能的设计中，预设时间间隔和N与业务服务器的处理资源相关联。也就是说，预设时间间隔与业务服务器的处理资源相关联，并且N与业务服务器的处理资源相关联。

在本申请实施例中，管理人员可以采用性能测试的方式，对业务服务器的处理资源进行检测。之后，管理人员可以根据业务服务器的处理资源设置预设时间间隔和N的值。

示例性的，设置预设时间间隔和N的值的相关代码如下所示。

instruct.batch.size＝14；load.time＝1000ms。

其中，N为14，预设时间间隔为1000毫秒。

S204、中间层服务向业务服务器发送N个业务请求消息。

其中，业务服务器用于处理M个业务请求消息。

需要说明的是，在本申请实施例中，中间层服务向业务服务器发送N个业务请求消息，可以避免单条请求下发。如此，可以减少业务服务器的连接数和读写次数，避免造成业务服务器的性能浪费。

在本申请实施例中，在中间层服务向业务服务器发送N个业务请求消息之后，业务服务器可以接收来自中间层服务的N个业务请求消息。之后，业务服务器可以对业务请求消息进行处理，得到处理后的业务请求消息。业务服务器可以向客户端发送处理后的业务请求消息。

可以理解的是，中间层服务可以接收来自客户端的M个业务请求消息，并存储M个业务请求消息，M为正整数。中间层服务按照预设时间间隔从存储的M个业务请求消息中获取N个业务请求消息，并向业务服务器发送N个业务请求消息，业务服务器用于处理M个业务请求消息，预设时间间隔和N与业务服务器的处理资源相关联，N为正整数，N小于M。这样一来，中间层服务可以先存储业务请求消息，再批量向业务服务器发送客户端的业务请求消息，避免客户端直接向业务服务器发送业务请求消息，减小业务服务器的处理负载。

在一些实施例中，如图3所示，在中间层服务存储M个业务请求消息(S202)之前，业务请求消息的发送方法还可以包括：S301。

S301、中间层服务获取M个业务请求消息中每个业务请求消息的第一时刻。

其中，第一时刻为中间层服务接收到业务请求消息的时刻。

示例性的，假如业务请求消息包括：业务请求消息1、业务请求消息2、业务请求消息3，中间层服务接收到业务请求消息的时刻分别为：接收到业务请求消息1的时刻为8点10分30秒，接收到业务请求消息2的时刻为8点10分31秒，接收到业务请求消息3的时刻为8点10分32秒。则业务请求消息1的第一时刻为8点10分30秒，业务请求消息2的第一时刻为8点10分31秒，业务请求消息3的第一时刻为8点10分32秒。

S302、中间层服务基于每个业务请求消息的第一时刻，按照第一时刻从早到晚的顺序，将M个业务请求消息存储至消息队列。

示例性的，假如M为3，业务请求消息包括：业务请求消息1、业务请求消息2、业务请求消息3，业务请求消息1的第一时刻为8点10分30秒、业务请求消息2的第一时刻为8点10分31秒、业务请求消息3的第一时刻为8点10分32秒，则中间层服务先存储业务请求消息1，再存储业务请求消息2，最后存储业务请求消息3。

需要说明的是，在本申请实施例中，队列可以为一种先进先出的线性表，先被存储在队列的业务请求消息，会优先被获取。示例性的，假如M为3，M个业务请求消息的存储顺序为：先存储业务请求消息1，再存储业务请求消息2，最后存储业务请求消息3。假如中间层服务获取的N个业务请求消息包括：业务请求消息1、业务请求消息2、业务请求消息3，则中间层服务获取N个业务请求消息的顺序为：先获取业务请求消息1，再获取业务请求消息2，最后获取业务请求消息3。

可以理解的是，中间层服务可以获取M个业务请求消息中每个业务请求消息的第一时刻，第一时刻为中间层服务接收到业务请求消息的时刻。之后，中间层服务可以基于每个业务请求消息的第一时刻，按照第一时刻从早到晚的顺序，将M个业务请求消息存储至消息队列。如此，中间层服务可以按照先进先出的方式，向业务服务器发送业务请求消息。这样一来，可以避免用户等待时间较长，造成用户体验的下降。

在一些实施例中，如图4所示，在中间层服务向业务服务器发送N个业务请求消息(S204)之后，对于每次发送N个业务请求消息，中间层服务可以执行S401-S404。

S401、中间层服务接收来自业务服务器的反馈消息。

其中，反馈消息用于指示已经成功接收N个业务请求消息。

在一种可能的实现方式中，业务服务器可以向中间层服务发送反馈消息。中间层服务可以接收来自服务器的反馈消息。

S402、中间层服务为已经发送的N个业务请求消息添加成功信息。

其中，成功信息用于指示已经将N个业务请求消息发送至业务服务器。

示例性的，中间层服务为已经发送的N个业务请求消息添加成功信息的相关代码如下所示。

public class RmqJobResponceSAP implements MessageListenerf{privatestatic Logger logger＝LoggerFactory.getLogger(RmqJobResponceSAP.class)；

@Override

public void onMessage(Message msg){Iprovision ipvs＝new Iprovision()；

IprovisionDaoApi iprovisionDao＝(IprovisionDaoApi)BeanFactoryUtil.getBean(beanName:"iprovisionDaoApi")；

String resultInfo＝new String(msg.getBody()).toString()；

System.out.println(resultInfo)；

logger.info("底层返回的信息为："+resultInfo)；

try{ipvs＝InstructInSendComm.insQryInstExecRst(JsonPluginsUtil.StrToJsonObj(resultInfo))；ipvs.setReturnDate(new Date())；

iprovisionDao.updatePsStatusAndResultInfoByPsId(ipvs)；}}}。

其中，String resultInfo＝new String(msg.getBody()).toString()用于表示将成功信息以字符串类型导入数据库。System.out.println(resultInfo)用于表示打印resultInfo，并在输出中添加新行。resultInfo用于表示业务服务器发送的成功信息。updatePsStatusAndResultInfoByPsId用于表示建立更新数据库的日志，更新后的数据库日志中包括成功信息。

S403、中间层服务确定在发送N个业务请求消息之后的预设时长之内，是否接收到反馈消息。

需要说明的是，在本申请实施例中，对预设时长不作限定。例如，预设时长可以为5秒。又例如，预设时长可以为2秒。又例如，预设时长可以为10秒。预设时长可以与预设时间间隔相同，也可以与预设时间间隔不相同。

在一种可能的实现方式中，中间层服务可以在预设时长之后，确定中间层服务中是否存储有已经发送的N个业务请求消息对应的成功信息。

在一种可能的设计中，若中间层服务存储有已经发送的N个业务请求消息对应的成功信息，则中间层服务接收到反馈消息。

在另一种可能的设计中，若中间层服务未存储有已经发送的N个业务请求消息对应的成功信息，则中间层服务未接收到反馈消息。

在一些实施例中，若在发送N个业务请求消息之后的预设时长之内，中间层服务未接收到反馈消息，中间层服务则可以执行S404。

S404、中间层服务重新向业务服务器发送N个业务请求消息。

需要说明的是，在本申请实施例中，对于中间层服务重新向业务服务器发送N个业务请求消息，管理人员可以设置重新发送N个业务请求消息的次数，避免由于重新发送的次数过少导致未达到调试效果，同时还需要避免由于重新发送的次数过多导致业务服务器的处理负载增加。本申请对重新发送N个业务请求消息的次数不作限定。例如，在通常情况下，重新发送N个业务请求消息的次数为3。

可以理解的是，对于每次发送N个业务请求消息，中间层服务可以接收来自业务服务器的反馈消息，反馈消息用于指示已经成功接收N个业务请求消息。中间层服务可以为已经发送的N个业务请求消息添加成功信息，成功信息用于指示已经将N个业务请求消息发送至业务服务器。若在发送N个业务请求消息之后的预设时长之内，未接收到反馈消息，则重新向业务服务器发送N个业务请求消息。如此，中间层服务可以监听业务服务器的返回的数据结果。这样一来，可以提高发送业务请求消息的***的可用性和稳定性。

在一些实施例中，在对于每次发送N个业务请求消息，中间层服务确定在发送N个业务请求消息之后的预设时长之内，是否接收到反馈消息(S403)之后，业务请求消息的发送方法还可以包括：

若中间层服务在发送N个业务请求消息之后的预设时长之内，未接收到反馈消息，中间层服务可以为已经发送的N个业务请求消息添加失败信息。

其中，失败信息用于指示未将N个业务请求消息发送至业务服务器。

在本申请实施例中，中间层服务可以对N个业务请求消息进行扫描，确定N个业务请求消息是否与失败消息相对应。若中间层服务确定N个业务请求消息与失败消息相对应，中间层服务则可以重新向业务服务器发送N个业务请求消息(S404)。

示例性的，中间层服务通过扫描，确定N个业务请求消息是否与失败消息相对应的相关代码如下所示。

其中，i_provision用于表示存储业务请求消息的数据库表，<description>扫描数据库表i_provision中状态为10记录代表同步接需回填的信息</description>用于表示扫描数据库表i_provision中的N个业务请求消息是否对应失败消息，状态为10用于表示失败消息。<cron-expression>0/1****？</cron-expression>用于表示每一秒对数据库表i_provision进行一次扫描。

需要说明的是，在本申请实施例中，对上述代码中定时控件(<cron-expression>0/1****？</cron-expression>)中的扫描频率不作限定。例如，定时控件中的扫描频率可以为每一秒扫描一次。又例如，定时控件中的扫描频率可以为每两秒扫描一次。又例如，定时控件中的扫描频率可以为每五秒扫描一次。

可以理解的是，对于每次发送N个业务请求消息，中间层服务确定未接收到反馈消息之后，中间层服务可以为已经发送的N个业务请求消息添加失败消息，失败消息用于指示未将N个业务请求消息发送至业务服务器。中间层服务可以通过扫描，确定与失败消息相对应的N个业务请求消息。这样一来，中间层服务通过扫描确定未发送至业务服务器的N个业务请求消息，可以提高发送业务请求消息的***的可用性和稳定性。

上述主要从计算机设备的角度对本申请实施例提供的方案进行了介绍。可以理解的是，计算机设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本申请所公开的实施例描述的各示例的业务请求消息的发送方法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例还提供一种业务请求消息的发送装置。该业务请求消息的发送装置可以为计算机设备，也可以是上述计算机设备中的CPU，还可以是上述计算机设备中用于发送业务请求消息的模块，还可以是上述计算机设备中用于发送业务请求消息的客户端。

本申请实施例可以根据上述方法示例对业务请求消息的发送进行功能模块或者功能单元的划分，例如，可以对应各个功能划分各个功能模块或者功能单元，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块或者功能单元的形式实现。其中，本申请实施例中对模块或者单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

如图5所示，为本申请实施例提供的一种业务请求消息的发送装置的结构示意图。该装置应用于中间层服务。业务请求消息的发送装置用于执行图2、图3和图4所示的业务请求消息的发送方法。业务请求消息的发送装置可以包括接收模块501、存储模块502、发送模块503和处理模块504。

接收模块501，用于接收来自客户端的M个业务请求消息，M为正整数。存储模块502，用于存储M个业务请求消息，M为正整数。接收模块501，还用于按照预设时间间隔从存储的M个业务请求消息中获取N个业务请求消息，N为正整数，N小于M。发送模块503，用于向业务服务器发送N个业务请求消息，业务服务器用于处理M个业务请求消息，预设时间间隔和N与业务服务器的处理资源相关联。

可选的，接收模块501，还用于获取M个业务请求消息中每个业务请求消息的第一时刻，第一时刻为中间层服务接收到业务请求消息的时刻。存储模块502，具体用于基于每个业务请求消息的第一时刻，按照第一时刻从早到晚的顺序，将M个业务请求消息存储至消息队列。

可选的，接收模块501，还用于对于每次发送N个业务请求消息，接收来自业务服务器的反馈消息，反馈消息用于指示已经成功接收N个业务请求消息。处理模块504，用于为已经发送的N个业务请求消息添加成功信息，成功信息用于指示已经将N个业务请求消息发送至业务服务器。

可选的，发送模块503，还用于对于每次发送N个业务请求消息，若在发送N个业务请求消息之后的预设时长之内，未接收到反馈消息，则重新向业务服务器发送N个业务请求消息。

图6是根据一示例性实施例示出的一种业务请求消息的发送装置的硬件结构示意图。该业务请求消息的发送装置可以包括处理器601，处理器601用于执行应用程序代码，从而实现本申请中的业务请求消息的发送方法。

处理器601可以是一个中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。

如图6所示，业务请求消息的发送装置还可以包括存储器602。其中，存储器602用于存储执行本申请方案的应用程序代码，并由处理器601来控制执行。

存储器602可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器602可以是独立存在，通过总线604与处理器601相连接。存储器602也可以和处理器601集成在一起。

如图6所示，业务请求消息的发送装置还可以包括通信接口603，其中，处理器601、存储器602、通信接口603可以相互耦合，例如，通过总线604相互耦合。通信接口603用于与其他设备进行信息交互，例如支持业务请求消息的发送装置与其他装置的信息交互。

需要指出的是，图6中示出的装置结构并不构成对该业务请求消息的发送装置的限定，除图6所示部件之外，该业务请求消息的发送装置可以包括比图示更多或更少的部件，或者组合某些部件，或者不相同的部件布置。

在实际实现时，处理模块504所实现的功能可以由图6所示的处理器601调用存储器602中的程序代码来实现。

本申请还提供了一种计算机可读存储介质，计算机可读存储介质上存储有指令，当计算机可读存储介质中的指令由计算机设备的处理器执行时，使得计算机能够执行上述所示实施例提供的业务请求消息的发送方法。例如，计算机可读存储介质可以为包括指令的存储器602，上述指令可由计算机设备的处理器601执行以完成上述方法。可选地，计算机可读存储介质可以是非临时性计算机可读存储介质，例如，非临时性计算机可读存储介质可以是ROM、RAM、CD-ROM、磁带、软盘和光数据存储设备等。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不相同的功能模块完成，即将装置的内部结构划分成不相同的功能模块，以完成以上描述的全分类部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不相同地方。可以根据实际的需要选择其中的部分或者全分类部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全分类部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例方法的全分类部或部分步骤。而前述的存储介质包括-U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种业务请求消息的发送方法，其特征在于，应用于中间层服务，所述方法包括：

接收来自客户端的M个业务请求消息，并存储所述M个业务请求消息，M为正整数；

按照预设时间间隔从存储的所述M个业务请求消息中获取N个业务请求消息，并向业务服务器发送所述N个业务请求消息，所述业务服务器用于处理所述M个业务请求消息，所述预设时间间隔和N与所述业务服务器的处理资源相关联，N为正整数，N小于M。

2.根据权利要求1所述的方法，其特征在于，在存储所述M个业务请求消息之前，所述方法还包括：

获取所述M个业务请求消息中每个业务请求消息的第一时刻，所述第一时刻为所述中间层服务接收到所述业务请求消息的时刻；

存储所述M个业务请求消息，包括：

基于所述每个业务请求消息的第一时刻，按照第一时刻从早到晚的顺序，将所述M个业务请求消息存储至消息队列。

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

对于每次发送所述N个业务请求消息，接收来自所述业务服务器的反馈消息，所述反馈消息用于指示已经成功接收所述N个业务请求消息；

为已经发送的所述N个业务请求消息添加成功信息，所述成功信息用于指示已经将所述N个业务请求消息发送至所述业务服务器。

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

对于每次发送所述N个业务请求消息，若在发送所述N个业务请求消息之后的预设时长之内，未接收到所述反馈消息，则重新向所述业务服务器发送所述N个业务请求消息。

5.一种业务请求消息的发送装置，其特征在于，应用于中间层服务，所述装置包括：

接收模块，用于接收来自客户端的M个业务请求消息，M为正整数；

存储模块，用于存储所述M个业务请求消息，M为正整数；

所述接收模块，还用于按照预设时间间隔从存储的所述M个业务请求消息中获取N个业务请求消息，N为正整数，N小于M；

发送模块，用于向业务服务器发送所述N个业务请求消息，所述业务服务器用于处理所述M个业务请求消息，所述预设时间间隔和N与所述业务服务器的处理资源相关联。

6.根据权利要求5所述的装置，其特征在于，

所述接收模块，还用于获取所述M个业务请求消息中每个业务请求消息的第一时刻，所述第一时刻为所述中间层服务接收到所述业务请求消息的时刻；

所述存储模块，具体用于基于所述每个业务请求消息的第一时刻，按照第一时刻从早到晚的顺序，将所述M个业务请求消息存储至消息队列。

7.根据权利要求5或6所述的装置，其特征在于，所述装置还包括：

所述接收模块，还用于对于每次发送所述N个业务请求消息，接收来自所述业务服务器的反馈消息，所述反馈消息用于指示已经成功接收所述N个业务请求消息；

处理模块，用于为已经发送的所述N个业务请求消息添加成功信息，所述成功信息用于指示已经将所述N个业务请求消息发送至所述业务服务器。

8.根据权利要求7所述的装置，其特征在于，

所述发送模块，还用于对于每次发送所述N个业务请求消息，若在发送所述N个业务请求消息之后的预设时长之内，未接收到所述反馈消息，则重新向所述业务服务器发送所述N个业务请求消息。

9.一种业务请求消息的发送装置，其特征在于，包括：处理器和存储器；所述处理器和所述存储器耦合；所述存储器用于存储一个或多个程序，该一个或多个程序包括计算机执行指令，当该业务请求消息的发送装置运行时，处理器执行该存储器存储的该计算机执行指令，以使该业务请求消息的发送装置执行如权利要求1-4中任一项所述的业务请求消息的发送方法。

10.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当计算机执行该指令时，该计算机执行如权利要求1-4中任一项所述的业务请求消息的发送方法。

Images