CN103297395A - 一种互联网业务的实现方法、系统以及装置 - Google Patents

Abstract

本发明公开了一种互联网业务的实现方法、系统以及装置，主要技术方案包括：客户端将服务请求消息缓存至用于缓存消息队列，在确定消息队列中保存的服务请求消息满足发送条件后，将消息队列中保存的服务请求消息划分为至少一个组，每组服务请求消息中至少包括两个服务请求消息，将每组服务请求消息按照设定方式发送至服务器。根据该技术方案，服务请求消息可以以组的方式发送至服务器处理，多个服务请求消息执行两个网络IO，与现有技术相比，无需针对每个服务请求都执行两个网络IO，一方面，减少了网络调度资源的占用，另一方面，在互联网业务的实现需要进行多次服务请求时，避免了每个服务请求都占用两个网络IO时间，从而提高了服务实现的效率。

Description

一种互联网业务的实现方法、系统以及装置

技术领域

本申请涉及互联网技术领域，尤其涉及一种互联网业务的实现方法、系统以及装置。

背景技术

随着电子信息化时代的到来，互联网在人们的生活中发挥着越来越重要的作用，人们通过互联网可以快速、实时地获取各种信息，互联网应用给人们的生活、工作提供了很大的方便，从而成为目前应用非常普及的一种技术。

在网络连接模式中，常见的连接模式为C/S(Client/Server，客户端/服务器网)模式。在C/S模式的网络中，服务器是网络的核心，而客户端是网络的基础，客户端依靠服务器实现各类业务，服务器为客户端提供客户端所请求的业务。图1示出了客户端和服务器实现互联网业务的流程示意图，如图1所示，主要包括如下步骤：

步骤101、客户端将服务请求消息(Service request)发送至服务器；

步骤102、服务器接收客户端的服务请求消息后，对该服务请求进行处理；

步骤103、服务器向客户端发送服务响应消息(Service response)，该服务器响应消息中携带对服务请求消息的处理结果。

至此，客户端和服务器实现互联网业务的流程结束。

基于图1对应的流程，通过客户端向服务器发送Service request以及服务器向客户端发送Service response能够实现一次业务交互。在实际应用中，一个完整的业务流程通常需要客户端与服务器之间进行多次交互，即需要执行多次客户端向服务器发送Service request以及服务器向客户端发送Service response的过程。在每次客户端与服务器的交互过程中，需要经历两次网络IO(Inputoutput，输入输出)，如图1中的步骤101即为一次网络输入，步骤103即为一次网络输出，网络IO相对一次服务调用而言，需要耗费较多的时间，这在高并发业务调用请求的环境下，由于IO耗费的时间会显得尤为突出。

综上所述，现有技术针对每个服务请求都需要执行两个网络IO，一方面，这会占用较多的网络调度资源，另一方面，在互联网业务的实现需要进行多次服务请求时，每个服务请求都占用两个网络IO时间会降低服务实现的效率。

发明内容

有鉴于此，本申请实施例提供一种互联网业务的实现方法、系统以及装置，采用该技术方案，能够减少网络调度资源的占用以及提高服务实现的效率。

本申请实施例通过如下技术方案实现：

根据本申请实施例的一个方面，提供了一种互联网业务的实现方法，包括：

客户端将服务请求消息缓存至用于缓存待发送至服务器的服务请求消息的消息队列；并

在确定所述消息队列中保存的服务请求消息满足发送条件后，将所述消息队列中保存的服务请求消息划分为至少一个组，每组服务请求消息中至少包括两个服务请求消息；并

将每组服务请求消息按照设定的方式发送至服务器。

根据本申请实施例的另一个方面，还提供了一种互联网业务的实现方法，包括：

服务器接收客户端按照设定的方式发送的服务请求消息组，所述服务请求消息组中包括多个服务请求消息；

对所述服务请求消息组中的各服务请求消息进行处理得到服务请求响应消息，并按照设定方式将得到的服务请求响应消息发送给所述客户端。

根据本申请实施例的另一个方面，还提供了一种互联网业务的实现系统，包括：客户端和服务器；

所述客户端，用于将服务请求消息缓存至用于缓存待发送至服务器的服务请求消息的消息队列，在确定所述消息队列中保存的服务请求消息满足发送条件后，将所述消息队列中保存的服务请求消息划分为至少一个组，每组服务请求消息中至少包括两个服务请求消息，并将每组服务请求消息按照设定的方式发送至所述服务器；

所述服务器，用于接收客户端按照设定的方式发送的服务请求消息组，并对所述服务请求消息组中的各服务请求消息进行处理得到服务请求响应消息，并按照设定方式将得到的服务请求响应消息发送给所述客户端。

根据本申请实施例的另一个方面，还提供了一种互联网业务的实现装置，包括：

消息缓存单元，用于将服务请求消息缓存至用于缓存待发送至服务器的服务请求消息的消息队列；

队列监控单元，用于确定所述消息队列中保存的服务请求消息是否满足发送条件；

分组控制单元，用于在所述队列监控单元确定所述消息队列中保存的服务请求消息满足发送条件后，将所述消息队列中保存的服务请求消息划分为至少一个组，每组服务请求消息中至少包括两个服务请求消息；

消息发送单元，用于将每组服务请求消息按照设定的方式发送至服务器。

根据本申请实施例的另一个方面，还提供了一种互联网业务的实现装置，包括：

消息接收单元，用于接收客户端按照设定的方式发送的服务请求消息组，所述服务请求消息组中包括多个服务请求消息；

消息处理单元，用于对所述消息接收单元接收的服务请求消息组中的各服务请求消息进行处理得到服务请求响应消息；

响应消息发送单元，用于按照设定方式将所述消息处理单元处理得到的服务请求响应消息发送给所述客户端。

通过本申请实施例提供的上述至少一个技术方案，在实现互联网业务时，客户端将先将服务请求消息缓存至用于缓存待发送至服务器的服务请求消息的消息队列，并在确定该消息队列中保存的服务请求消息满足发送条件后，将该消息队列中保存的服务请求消息划分为至少一个组，每组服务请求消息中至少包括两个服务请求消息，并将每组服务请求消息按照设定的方式发送至服务器。根据该技术方案，服务请求消息可以以组的方式发送至服务器处理，也就是说，多个服务请求消息执行两个网络IO，与现有技术相比，无需针对每个服务请求都执行两个网络IO，一方面，减少了网络调度资源的占用，另一方面，在互联网业务的实现需要进行多次服务请求时，避免了每个服务请求都占用两个网络IO时间，从而提高了服务实现的效率。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本申请的进一步理解，并且构成说明书的一部分，与本申请实施例一起用于解释本申请，并不构成对本申请的限制。在附图中：

图1为背景技术提供的客户端和服务器实现互联网业务的流程示意图；

图2为本发明实施例一提供的互联网业务的实现方法所使用的互联网系统的示意图；

图3为本发明实施例一提供的实现互联网业务的流程示意图；

图4为本发明实施例一提供的动态设置该第一阈值的流程示意图；

图5为本发明实施例二提供的实现互联网业务的流程示意图；

图6为本发明实施例三提供的一种实现互联网业务的装置的结构示意图；

图7为本发明实施例三提供的又一种实现互联网业务的装置的结构示意图；

图8为本发明实施例三提供的又一种实现互联网业务的装置的结构示意图。

具体实施方式

为了给出减少网络调度资源的占用以及提高服务实现的效率的实现方案，本申请实施例提供了一种互联网业务的实现方法、系统以及装置，该技术方案可以应用于互联网业务实现的过程，既可以实现为一种方法，也可以实现为一种系统和装置。以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请。并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

实施例一

本发明实施例一提供了一种互联网业务的实现方法，通过该方法，无需针对每个服务请求都执行两个网络IO，一方面，减少了网络调度资源的占用，另一方面，在互联网业务的实现需要进行多次服务请求时，避免了每个服务请求都占用两个网络IO时间，从而提高了服务实现的效率。

图2示出了本发明实施例一提供的互联网业务的实现方法所使用的互联网系统的示意图，如图2所示，该互联网系统包括客户端201以及服务器202，该客户端201以及服务器202可以基于各种协议实现通信，如互联网协议。其中，客户端201可以安装在各种用户终端中，如，个人电脑、手机等。

本实施例一中，预先在客户端中设置消息队列，该消息队列用于缓存待发送至服务器的服务请求消息，该服务请求消息可以由客户端生成，也可以由客户端所在终端设备中的应用程序生成并发送至客户端。服务请求消息可以根据实际的业务需求为各种类型的消息，例如，服务请求消息可以是请求获取服务数据的请求，也可以是请求调用服务器提供的服务的请求，并且，服务请求消息的消息格式可以视客户端与服务器之间的协议类型而确定。

图3示出了本实施例一提供的实现互联网业务的流程示意图，该实现过程主要涉及客户端和服务器之间的交互，主要包括如下步骤：

步骤301、客户端生成或接收新的服务请求消息后，将该服务请求消息缓存至用于缓存待发送至服务器的服务请求消息的消息队列。

步骤302、客户端确定消息队列中保存的服务请求消息是否满足发送条件。

步骤303、客户端在确定消息队列中保存的服务请求消息满足发送条件后，将消息队列中保存的服务请求消息划分为至少一个组。

该步骤303中，消息队列中一般包括多个服务请求消息，划分得到的每组服务请求消息中至少包括两个服务请求消息。具体地，可以设置一个阈值，根据该阈值将消息队列中保存的服务请求消息划分为分别包括该阈值个业务请求消息的组，其中，该阈值不大于消息队列中保存的消息总数，实际应用中，根据消息队列中保存的消息的总数，可能不能保证每个服务请求消息组中包括设置的阈值数目的业务请求消息，在此情况下，可以允许其中一个服务请求消息组中包括的服务请求消息的数目大于或小于设置的阈值。

步骤304、客户端将每组服务请求消息按照设定的方式发送至服务器。

该步骤304中，客户端将每组服务请求消息按照设定的方式发送至服务器，可以针对每组服务请求消息建立一个线程，并控制每个线程按照异步方式发送服务请求消息，即在一个线程发送完对应的服务请求消息组后，下一个线程发送对应的服务请求消息组，各线程之间发送服务请求消息组的时间间隔可以根据网络状况进行设置，如网络状况较优，则可以间隔较小，如网络状况较差，则可以间隔较大。优选地，客户端向服务器发送每组服务请求消息时，可以对服务请求消息组进行压缩处理，以减少传输的数据量。优选地，客户端在将每组服务请求消息按照设定的方式发送至服务器之后，可以清空消息队列中保存的业务请求消息，即对该消息队列进行初始化。

上述步骤301至步骤304独立地构成了互联网业务实现过程中客户端执行的步骤。

步骤305、服务器接收客户端发送的服务请求消息组后，对服务请求消息组中的各服务请求消息进行处理得到服务请求响应消息。

步骤306、服务器按照设定方式将得到的服务请求响应消息发送给客户端。

该步骤306中，服务器按照设定方式将得到的服务请求响应消息发送给客户端时，可以采用多种发送方式，例如，服务器可以将对客户端发送的所有服务请求消息处理得到的服务请求响应消息划分为至少一个组，并将各组服务请求响应消息按照异步方式发送给所述客户端，即所有服务请求消息处理完后一并反馈服务请求响应消息；或者，服务器在对客户端发送的每组服务请求消息处理得到服务请求响应消息后，将得到的服务请求响应消息直接发送给所述客户端，即每处理完一组服务请求消息，可以先反馈该组服务请求消息的服务请求响应消息，或者，一次反馈多组服务请求消息的服务请求响应消息，或者，将一组服务请求消息的服务请求响应消息拆分为多组反馈，具体反馈方式可以灵活设置，此处不再一一列举。优选地，服务器向客户端发送服务请求响应消息时，可以对服务请求响应消息进行压缩处理，以减少传输的数据量。

上述步骤305至步骤306独立地构成了互联网业务实现过程中客户端执行的步骤。

至此，实现互联网业务的流程结束。

可见，基于图3对应的流程，服务请求消息可以以组的方式发送至服务器处理，也就是说，多个服务请求消息执行两个网络IO，无需针对每个服务请求都执行两个网络IO，一方面，减少了网络调度资源的占用，另一方面，在互联网业务的实现需要进行多次服务请求时，避免了每个服务请求都占用两个网络IO时间，从而提高了服务实现的效率。

本实施例一提供的优选实施方式中，为了进一步区分被划分为同一个组中的各服务请求消息，可以在服务请求消息中携带消息标识ID，该ID可以由客户端按照设定方式生成。相应地，在服务请求消息中携带消息标识的情况下，上述步骤305中，服务请求响应消息也会携带消息ID，并且，服务请求响应消息中携带的消息ID与对应的服务请求中携带的消息ID相同，即服务请求消息与服务请求响应消息对于同一标识，以便于客户端区分各服务请求消息分别对应的服务请求响应消息。

本实施例一提供的优选实施方式中，在上述步骤306之后，即服务器按照设定方式将得到的服务请求响应消息发送给客户端之后，客户端还可以进一步执行如下步骤：

接收服务器针对接收的服务请求消息反馈的服务请求响应消息，每个服务请求响应消息中携带消息ID，且服务请求响应消息中携带的消息ID与对应的服务请求中携带的消息ID相同；

根据接收的服务请求响应消息分别携带的消息ID，确定各服务请求消息对应的服务请求响应消息。

基于上述过程，客户端在确定出各服务请求消息对应的服务请求响应消息后，可以将各服务请求响应消息分发到生成或发送服务请求消息的线程或应用程序进行后续处理。

本实施例一中提供的上述流程中，步骤302中涉及的发送条件可以根据具体实现的业务进行灵活设置，以下给出两个设置发送条件以及监控消息队列中保存的服务请求消息满足发送条件的两个具体实现方式：

实现方式一：通过设定的时间长度来监控是否满足发送条件

设置的发送条件可以为：消息队列中最早被缓存的业务请求消息的缓存时间与当前系统时间的差值达到第一阈值；

相应地，确定消息队列中保存的服务请求消息满足发送条件，即确定消息队列中最早被缓存的业务请求消息的缓存时间与当前系统时间的差值达到第一阈值。

该实现方式一可以应用于各种情况，尤其可以适用于对于消息处理实时性具有较高的业务。具体地，上述第一阈值可以在确定消息队列中最早被缓存的业务请求消息的缓存时间与当前系统时间的差值达到第一阈值之前设置，可以为固定值，也可以为动态更新的值。该实现方式一提供动态设置该第一阈值的具体实现过程，如图4所示，主要包括如下步骤：

步骤401、确定业务请求消息被缓存至消息队列的频率。

该步骤401中，业务请求消息被缓存至消息队列的频率可以为根据各业务请求消息分别被缓存至消息队列的时间确定出的各消息被缓存的平均时间间隔，也可以为其它能够表征消息存入频率的确定方式，如各消息被缓存的时间的方差，此处不再一一列举。

步骤402、根据设定的频率与阈值的对应关系，确定与确定出的该频率对应的阈值为第一阈值。

该步骤402中，预先设定的频率与阈值的对应关系，可以根据经验值确定，一般业务请求消息被缓存至消息队列的频率较大，则可以设置与该频率对应的阈值较大，业务请求消息被缓存至消息队列的频率较小，则可以设置与该频率对应的阈值较小，从而在业务请求消息被缓存至消息队列的频率较小的情况下，保证消息处理的及时性。应当理解，此处仅为设置频率与阈值的对应关系的一个举例，实际应用中，可以根据不同业务的具体需求进行灵活设置，也可以在业务请求消息被缓存至消息队列的频率较大时，设置与该频率对应的阈值较小，在业务请求消息被缓存至消息队列的频率较小时，设置与该频率对应的阈值较大，此处不再一一列举。

至此，动态确定第一阈值的流程结束。

实现方式二：通过设定的消息数量来监控是否满足发送条件

设置的发送条件可以为：消息队列中缓存的业务请求消息的数量达到第二阈值。

相应地，确定消息队列中保存的服务请求消息满足发送条件，即确定消息队列中缓存的业务请求消息的数量达到第二阈值。

该实现方式一可以应用于各种情况，尤其可以适用于对于消息处理实时性要求不高的业务。具体地，上述第二阈值可以在确定所述消息队列中缓存的业务请求消息的数量达到第二阈值之前确定，并且，该第二阈值的具体确定过程与上述具体实现方式一中第一阈值的具体确定过程相同，即可以设置为固定值，也可以动态确定，即：

确定业务请求消息被缓存至消息队列的频率；

根据设定的频率与阈值的对应关系，确定与确定出的所述频率对应的阈值为第二阈值。

以上对本实施例一提供的互联网业务的实现方法进行了详细描述，为了更好地理解该实施例提供的技术方案，以下给出该技术方案的一个更为具体的实现方式，该实现方式通过下述的实施例二描述。

实施例二

图5示出了该实施例二提供的实现互联网业务的流程示意图，如图5所示，主要包括如下步骤：

步骤501、客户端发起远程服务调用请求(即服务请求消息)。

步骤502、客户端将该远程服务调用请求封装为一个任务(OneTask)，其中包含请求ID(即消息ID)，该请求ID用于确定服务器反馈的处理结果(即确定服务请求响应消息)。

以下步骤503至步骤507可以根据需要循环执行，主要由Looper对象完成。

步骤503、将One Task放入消息队列。

消息队列可以通过并发非阻塞型队列实现，以支持高并发处理性能，如Java语言的java.util.concurrent.ConcurrentLinkedQueue。

通过定时任务监控消息队列，在定时时间到达后，将消息队列中的请求一次性取出，并分批次组包(即分组)。

步骤504、启动的线程以异步方式将各批次请求发给服务端。

其中，步骤503生成了几个批次，则启动几个线程，即线程与批次一一对应。

步骤505、客户端接收到服务器发送的线程处理应答(即服务请求响应消息)。因为几个批次的提交是异步的，后续拿到结果可以通过多线程并发的Future机制拿到结果；同时，发送过去的批量请求中带有请求ID，因此服务端的批量结果要根据与请求ID对应。

步骤506、客户端拆解批量结果得到MAP。

将结果放入Map<long，String>中，其中key为long类型，是请求ID，Value是String类型，为请求对应的结果。Map最好为并发非阻塞的Map实现，如java语言中的java.util.concurrent.ConcurrentHashMap，以提高并发处理能力；

步骤507、客户端根据请求ID确定出处理结果，返回给对应的请求。

该步骤507中，在确定出处理结果后，要将结果Map<long，String>中对应的Entry元素移出清理。

至此，实现互联网业务的流程结束。

实施例三

本实施例三提供了一种互联网业务的实现装置，通过该装置，无需针对每个服务请求都执行两个网络IO，一方面，减少了网络调度资源的占用，另一方面，在互联网业务的实现需要进行多次服务请求时，避免了每个服务请求都占用两个网络IO时间，从而提高了服务实现的效率。

图6示出了本实施例三提供的一种实现互联网业务的装置的结构示意图，如图6所示，主要包括：

消息缓存单元601、队列监控单元602、分组控制单元603以及消息发送单元604；

其中：

消息缓存单元601，用于将服务请求消息缓存至用于缓存待发送至服务器的服务请求消息的消息队列；

队列监控单元602，用于确定消息队列中保存的服务请求消息是否满足发送条件

分组控制单元603，用于在队列监控单元602确定消息队列中保存的服务请求消息满足发送条件时，将消息队列中保存的服务请求消息划分为至少一个组，每组服务请求消息中至少包括两个服务请求消息；

消息发送单元604，用于将分组控制单元603分组得到的每组服务请求消息按照设定的方式发送至服务器。

本实施例三提供的一个优选实施方式中，图6所示装置包括的队列监控单元602，具体用于在确定消息队列中最早被缓存的服务请求消息的缓存时间与当前系统时间的差值达到第一阈值，或确定消息队列中缓存的服务请求消息的数量达到第二阈值时，确定消息队列中保存的服务请求消息满足发送条件。

本实施例三提供的一个优选实施方式中，图6所示装置包括的队列监控单元602，还用于在通过确定消息队列中最早被缓存的服务请求消息的缓存时间与当前系统时间的差值达到第一阈值的方式确定消息队列中保存的服务请求消息满足发送条件时，在确定消息队列中最早被缓存的服务请求消息的缓存时间与当前系统时间的差值达到第一阈值之前，确定服务请求消息被缓存至消息队列的频率，并根据设定的频率与阈值的对应关系，确定与确定出的频率对应的阈值为第一阈值。

本实施例三提供的一个优选实施方式中，图6所示装置包括的队列监控单元602，还用于在通过确定消息队列中缓存的服务请求消息的数量达到第二阈值的方式确定消息队列中保存的服务请求消息满足发送条件时，确定消息队列中缓存的服务请求消息的数量达到第二阈值之前，确定服务请求消息被缓存至消息队列的频率，并根据设定的频率与阈值的对应关系，确定与确定出的频率对应的阈值为第二阈值。

本实施例三提供的一个优选实施方式中，图6所示装置包括的分组控制单元603，具体用于根据第三阈值，将消息队列中保存的服务请求消息划分为分别包括第三阈值个服务请求消息的组，其中，第三阈值不大于消息队列中保存的消息总数。

本实施例三提供的一个优选实施方式中，图6所示装置包括的消息发送单元604，具体用于针对每组服务请求消息建立一个线程，并控制每个线程按照异步方式发送服务请求消息。

本实施例三提供的一个优选实施方式中，图6所示装置包括的队列监控单元602，还用于在消息发送单元将每组服务请求消息按照设定的方式发送至服务器之后，清空消息队列中保存的服务请求消息。

如图7所示，本实施例三提供的一个优选实施方式中，图6所示装置还可以进一步包括：

响应消息接收单元605，用于在消息发送单元604将每组服务请求消息按照设定的方式发送至服务器之后，接收服务器针对接收的服务请求消息反馈的服务请求响应消息，每个服务请求响应消息中携带消息标识ID，且服务请求响应消息中携带的消息ID与对应的服务请求中携带的消息ID相同，并根据接收的服务请求响应消息分别携带的消息ID，确定各服务请求消息对应的服务请求响应消息。

图6或图7对应的实现互联网业务的装置可以位于客户端中。

图8示出了本实施例三提供的又一种实现互联网业务的装置的结构示意图，如图8所示，主要包括：

消息接收单元801、消息处理单元802以及响应消息发送单元803；

其中：

消息接收单元801，用于接收客户端按照设定的方式发送的服务请求消息组，服务请求消息组中包括多个服务请求消息；

消息处理单元802，用于对消息接收单元801接收的服务请求消息组中的各服务请求消息进行处理得到服务请求响应消息；

响应消息发送单元803，用于按照设定方式将消息处理单元处理得到的服务请求响应消息发送给客户端。

本实施例三提供的一个优选实施方式中，图8所示装置包括的消息处理单元802，具体用于在服务请求响应消息中携带消息标识ID，服务请求响应消息中携带的消息ID与对应的服务请求中携带的消息ID相同。

本实施例三提供的一个优选实施方式中，图8所示装置包括的响应消息发送单元803，具体用于将对客户端发送的所有服务请求消息处理得到的服务请求响应消息划分为至少一个组，并将各组服务请求响应消息按照异步方式发送给客户端；或在对客户端发送的每组服务请求消息处理得到服务请求响应消息后，将得到的服务请求响应消息直接发送给客户端。

图8对应的实现互联网业务的装置可以位于服务器中。

应当理解，以上实现互联网业务的装置包括的模块仅为根据该装置实现的功能进行的逻辑划分，实际应用中，可以进行上述单元的叠加或拆分。并且该实施例提供的实现互联网业务的装置所实现的功能与上述实施例一和实施例二中提供的实现互联网业务的方法流程一一对应，对于该装置所实现的更为详细的处理流程，在上述方法实施例中已做详细描述，此处不再详细描述。

并且，本实施例三中的实现互联网业务的装置还具有能够实现实施例一和实施例二方案的功能模块，此处不再赘述。

实施例四

本实施例四提供了一种互联网业务的实现系统，通过该系统，无需针对每个服务请求都执行两个网络IO，一方面，减少了网络调度资源的占用，另一方面，在互联网业务的实现需要进行多次服务请求时，避免了每个服务请求都占用两个网络IO时间，从而提高了服务实现的效率。

本实施例四中提供的互联网业务的实现系统可以如图2所示，包括客户端和服务器，其中：

客户端，用于将服务请求消息缓存至用于缓存待发送至服务器的服务请求消息的消息队列，在确定消息队列中保存的服务请求消息满足发送条件时，将消息队列中保存的服务请求消息划分为至少一个组，每组服务请求消息中至少包括两个服务请求消息，并将每组服务请求消息按照设定的方式发送至服务器；

服务器，用于接收客户端按照设定的方式发送的服务请求消息组，并对服务请求消息组中的各服务请求消息进行处理得到服务请求响应消息，并按照设定方式将得到的服务请求响应消息发送给客户端。

本申请的实施例所提供的互联网业务的实现系统可通过计算机程序实现。本领域技术人员应该能够理解，上述的模块划分方式仅是众多模块划分方式中的一种，如果划分为其他模块或不划分模块，只要互联网业务的实现系统具有上述功能，都应该在本申请的保护范围之内。

本领域的技术人员应明白，本申请的实施例可提供为方法、装置(设备)、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、装置(设备)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (23)

1.一种互联网业务的实现方法，其特征在于，包括：

客户端将服务请求消息缓存至用于缓存待发送至服务器的服务请求消息的消息队列；并

在确定所述消息队列中保存的服务请求消息满足发送条件后，将所述消息队列中保存的服务请求消息划分为至少一个组，每组服务请求消息中至少包括两个服务请求消息；并

将每组服务请求消息按照设定的方式发送至服务器。

2.如权利要求1所述的方法，其特征在于，确定所述消息队列中保存的服务请求消息满足发送条件，包括：

确定所述消息队列中最早被缓存的业务请求消息的缓存时间与当前系统时间的差值达到第一阈值；或

确定所述消息队列中缓存的业务请求消息的数量达到第二阈值。

3.如权利要求2所述的方法，其特征在于，在通过确定所述消息队列中最早被缓存的业务请求消息的缓存时间与当前系统时间的差值达到第一阈值的方式确定所述消息队列中保存的服务请求消息满足发送条件时，在确定所述消息队列中最早被缓存的业务请求消息的缓存时间与当前系统时间的差值达到第一阈值之前，还包括：

确定业务请求消息被缓存至所述消息队列的频率；

根据设定的频率与阈值的对应关系，确定与确定出的所述频率对应的阈值为第一阈值。

4.如权利要求2所述的方法，其特征在于，在通过确定所述消息队列中缓存的业务请求消息的数量达到第二阈值的方式确定所述消息队列中保存的服务请求消息满足发送条件时，确定所述消息队列中缓存的业务请求消息的数量达到第二阈值之前，还包括：

确定业务请求消息被缓存至所述消息队列的频率；

根据设定的频率与阈值的对应关系，确定与确定出的所述频率对应的阈值为第二阈值。

5.如权利要求1所述的方法，其特征在于，将所述消息队列中保存的服务请求消息划分为至少一个组，包括：

根据第三阈值，将所述消息队列中保存的服务请求消息划分为分别包括所述第三阈值个业务请求消息的组，其中，所述第三阈值不大于所述消息队列中保存的消息总数。

6.如权利要求1所述的方法，其特征在于，将每组服务请求消息按照设定的方式发送至服务器，包括：

针对每组服务请求消息建立一个线程，并控制每个线程按照异步方式发送服务请求消息。

7.如权利要求1所述的方法，其特征在于，所述服务请求消息中携带消息标识ID；将每组服务请求消息按照设定的方式发送至服务器之后，还包括：

接收所述服务器针对接收的服务请求消息反馈的服务请求响应消息，每个服务请求响应消息中携带消息ID，且服务请求响应消息中携带的消息ID与对应的服务请求中携带的消息ID相同；

根据接收的所述服务请求响应消息分别携带的消息ID，确定各服务请求消息对应的服务请求响应消息。

8.如权利要求1所述的方法，其特征在于，将每组服务请求消息按照设定的方式发送至服务器之后，还包括：

清空所述消息队列中保存的所述业务请求消息。

9.一种互联网业务的实现方法，其特征在于，包括：

服务器接收客户端按照设定的方式发送的服务请求消息组，所述服务请求消息组中包括多个服务请求消息；

对所述服务请求消息组中的各服务请求消息进行处理得到服务请求响应消息，并按照设定方式将得到的服务请求响应消息发送给所述客户端。

10.如权利要求9所述的方法，其特征在于，所述服务请求消息中携带消息标识ID；

所述服务请求响应消息携带消息ID，且服务请求响应消息中携带的消息ID与对应的服务请求中携带的消息ID相同。

11.如权利要求9所述的方法，其特征在于，按照设定方式将得到的服务请求响应消息发送给所述客户端，包括：

服务器将对所述客户端发送的所有服务请求消息处理得到的服务请求响应消息划分为至少一个组，并将各组服务请求响应消息按照异步方式发送给所述客户端；或

服务器在对所述客户端发送的每组服务请求消息处理得到服务请求响应消息后，将得到的服务请求响应消息直接发送给所述客户端。

12.一种互联网业务的实现系统，其特征在于，包括：客户端和服务器；

所述客户端，用于将服务请求消息缓存至用于缓存待发送至服务器的服务请求消息的消息队列，在确定所述消息队列中保存的服务请求消息满足发送条件后，将所述消息队列中保存的服务请求消息划分为至少一个组，每组服务请求消息中至少包括两个服务请求消息，并将每组服务请求消息按照设定的方式发送至所述服务器；

所述服务器，用于接收客户端按照设定的方式发送的服务请求消息组，并对所述服务请求消息组中的各服务请求消息进行处理得到服务请求响应消息，并按照设定方式将得到的服务请求响应消息发送给所述客户端。

13.一种互联网业务的实现装置，其特征在于，包括：

消息缓存单元，用于将服务请求消息缓存至用于缓存待发送至服务器的服务请求消息的消息队列；

队列监控单元，用于确定所述消息队列中保存的服务请求消息是否满足发送条件；

分组控制单元，用于在所述队列监控单元确定所述消息队列中保存的服务请求消息满足发送条件后，将所述消息队列中保存的服务请求消息划分为至少一个组，每组服务请求消息中至少包括两个服务请求消息；

消息发送单元，用于将每组服务请求消息按照设定的方式发送至服务器。

14.如权利要求13所述的装置，其特征在于，所述队列监控单元，具体用于在确定所述消息队列中最早被缓存的业务请求消息的缓存时间与当前系统时间的差值达到第一阈值，或确定所述消息队列中缓存的业务请求消息的数量达到第二阈值时，确定所述消息队列中保存的服务请求消息满足发送条件。

15.如权利要求14所述的装置，其特征在于，所述队列监控单元，还用于在通过确定所述消息队列中最早被缓存的业务请求消息的缓存时间与当前系统时间的差值达到第一阈值的方式确定所述消息队列中保存的服务请求消息满足发送条件时，在确定所述消息队列中最早被缓存的业务请求消息的缓存时间与当前系统时间的差值达到第一阈值之前，确定业务请求消息被缓存至所述消息队列的频率，并根据设定的频率与阈值的对应关系，确定与确定出的所述频率对应的阈值为第一阈值。

16.如权利要求14所述的装置，其特征在于，所述队列监控单元，还用于在通过确定所述消息队列中缓存的业务请求消息的数量达到第二阈值的方式确定所述消息队列中保存的服务请求消息满足发送条件时，确定所述消息队列中缓存的业务请求消息的数量达到第二阈值之前，确定业务请求消息被缓存至所述消息队列的频率，并根据设定的频率与阈值的对应关系，确定与确定出的所述频率对应的阈值为第二阈值。

17.如权利要求13所述的装置，其特征在于，所述分组控制单元，具体用于根据第三阈值，将所述消息队列中保存的服务请求消息划分为分别包括所述第三阈值个业务请求消息的组，其中，所述第三阈值不大于所述消息队列中保存的消息总数。

18.如权利要求13所述的装置，其特征在于，所述消息发送单元，具体用于针对每组服务请求消息建立一个线程，并控制每个线程按照异步方式发送服务请求消息。

19.如权利要求13所述的装置，其特征在于，还包括：

响应消息接收单元，用于在所述消息发送单元将每组服务请求消息按照设定的方式发送至服务器之后，接收所述服务器针对接收的服务请求消息反馈的服务请求响应消息，每个服务请求响应消息中携带消息标识ID，且服务请求响应消息中携带的消息ID与对应的服务请求中携带的消息ID相同，并根据接收的所述服务请求响应消息分别携带的消息ID，确定各服务请求消息对应的服务请求响应消息。

20.如权利要求13所述的装置，其特征在于，所述队列监控单元，还用于在所述消息发送单元将每组服务请求消息按照设定的方式发送至服务器之后，清空所述消息队列中保存的所述业务请求消息。

21.一种互联网业务的实现装置，其特征在于，包括：

消息接收单元，用于接收客户端按照设定的方式发送的服务请求消息组，所述服务请求消息组中包括多个服务请求消息；

消息处理单元，用于对所述消息接收单元接收的服务请求消息组中的各服务请求消息进行处理得到服务请求响应消息；

响应消息发送单元，用于按照设定方式将所述消息处理单元处理得到的服务请求响应消息发送给所述客户端。

22.如权利要求21所述的装置，其特征在于，所述消息处理单元，具体用于在所述服务请求响应消息中携带消息标识ID，所述服务请求响应消息中携带的消息ID与对应的服务请求中携带的消息ID相同。

23.如权利要求21所述的装置，其特征在于，所述响应消息发送单元，具体用于将对所述客户端发送的所有服务请求消息处理得到的服务请求响应消息划分为至少一个组，并将各组服务请求响应消息按照异步方式发送给所述客户端；或在对所述客户端发送的每组服务请求消息处理得到服务请求响应消息后，将得到的服务请求响应消息直接发送给所述客户端。

Images