CN106603598B - 处理业务请求的方法及装置 - Google Patents

Abstract

本申请公开了一种处理业务请求的方法、一种处理业务请求的装置、以及另一种处理业务请求的方法。其中，所述处理业务请求的方法包括：将接收到的客户端业务请求存储在消息中间件中；从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端。采用上述方法，由于在接收业务请求以及处理业务请求这两个环节之间采用了消息中间件，从而解决了客户端发送业务请求的速度与服务端处理业务请求的速度不匹配的问题，避免出现超出服务端处理能力的业务请求被拒绝的现象，从而在不增加硬件成本的条件下，实现了对业务请求的有效接纳与处理，特别是在偶发海量业务请求的情况下，本申请的上述有益效果更为显著。

Description

处理业务请求的方法及装置

技术领域

本申请涉及客户端/服务器模式下的业务请求处理技术，具体涉及一种处理业务请求的方法及装置。本申请同时涉及另一种处理业务请求的方法。

背景技术

互联网上的大量应用都是基于传统的Client/Server(客户端/服务器)模式，在该模式下，通常由客户端发起业务请求，由服务器一侧提供处理业务请求的服务。在具体应用中，处于服务器一侧的设备可以包括负责接收并中转业务请求的业务网关、以及负责处理业务请求的业务服务端，所述业务网关和业务服务端也可以统称为服务端。

由于传统客户端/服务器模式的交互过程通常采用同步处理方式，即：业务服务端通过与业务网关之间的连接接收到来自客户端的业务请求后，其与业务网关的连接一直处于持有状态，直至完成对业务请求的全部处理并返回处理结果后才断开连接。在这种同步处理方式下，业务服务端与业务网关之间的连接数目就决定了业务服务端的工作负荷，因此，为了保证可用性，业务服务端对于连接数目通常都是有限制的，一旦连接数目超过预设阈值，就会拒绝客户端业务请求，并向客户端返回“系统繁忙”之类的提示信息。由于传统的客户端/服务器模式的上述工作方式，在客户端请求数目众多的情况下，特别是在短时间内出现海量请求的情况下，对服务端的冲击通常超出、甚至远远超出服务端的承受能力，必然导致大量请求被拒绝，这部分客户端用户只能重新发起业务请求(例如：重复执行下单操作)，影响用户体验。

为了避免客户端请求被拒绝，服务端一侧可以通过增加服务器数量，来缓解或解决这一问题。这样做，虽然可以实现对海量用户请求的接纳以及处理，但是对于很多互联网应用来说，短时间内的海量用户请求并不是业务常态，而是在特定业务场景下(例如：大促活动等)才可能出现的偶发状态，而且偶发状态下的高峰期流量与业务常态下的非高峰期流量通常远远不是一个数量级，导致大量增加的服务器资源长期得不到有效利用、处于空闲状态，投入产出比偏高。如何在不增加服务器数量、不增加硬件成本的条件下，避免客户端业务请求被拒绝，从而提升用户体验，成为一个亟待解决的问题。

发明内容

本申请实施例提供的一种处理业务请求的方法和装置，提出了一种在不增加服务器数量的条件下有效接纳并处理用户业务请求的技术方案。本申请实施例还提供另一种处理业务请求的方法。

本申请提供一种处理业务请求的方法，包括：

将接收到的客户端业务请求存储在消息中间件中；

从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端。

可选的，所述方法包括：

与客户端之间建立长连接；

所述客户端业务请求是通过与客户端之间的长连接接收到的；

所述将处理结果返回给相应的客户端包括：通过长连接将所述处理结果推送给相应的客户端。

可选的，所述与客户端之间建立长连接、接收客户端业务请求以及将所述处理结果推送给相应客户端的操作，是基于SPDY协议实现的。

可选的，所述从消息中间件读取业务请求进行处理，包括：根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求、并进行处理。

可选的，用于表征所述处理能力的指标包括以下元素之一或任意组合：CPU负荷、内存使用率。

可选的，所述根据处理能力从消息中间件读取业务请求进行处理包括：根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求，并与各辅助服务端协同处理所述业务请求；

所述用于表征所述处理能力的指标还包括：所述辅助服务端的负载指标。

可选的，所述辅助服务端的负载指标包括以下元素之一或任意组合：处理失败率、响应时间、并发线程数量。

可选的，所述与各辅助服务端协同处理所述业务请求，包括：

按照流控策略，向辅助服务端分发业务请求；

接收并整合辅助服务端返回的处理结果，得到所述业务请求的最终处理结果；

其中，所述流控策略是根据辅助服务端的负载指标动态调整的。

可选的，所述将接收到的客户端业务请求存储在消息中间件中的步骤，由业务网关完成；

所述从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端的步骤由业务服务端完成，其中所述将处理结果返回给相应的客户端包括：将处理结果经由业务网关返回给相应的客户端。

可选的，所述方法用于互联网交易系统中，所述业务请求包括下单请求。

可选的，所述消息中间件包括：MetaQ分布式消息队列。

相应的，本申请还提供一种处理业务请求的装置，包括：

业务请求接收存储单元，用于将接收到的客户端业务请求存储在消息中间件中；

业务请求读取处理单元，用于从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端。

可选的，所述装置包括：

长连接建立单元，用于与客户端之间建立长连接；

所述业务请求接收存储单元具体用于，将通过与客户端之间的长连接接收到的客户端请求存储在消息中间件中；

所述业务请求读取处理单元具体用于，从消息中间件读取业务请求进行处理，并通过长连接将处理结果推送给相应的客户端。

可选的，所述业务请求读取处理单元具体用于，根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端。

可选的，所述业务请求读取处理单元具体用于，根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求，与各辅助服务端协同处理所述业务请求，并将处理结果返回给相应的客户端。

可选的，所述业务请求读取处理单元包括：

业务请求读取子单元，用于根据负责处理业务请求的服务端设备的处理能力从消息中间件中读取业务请求；

业务请求分发子单元，用于按照流控策略，向辅助服务端分发业务请求，所述流控策略是根据辅助服务端的负载指标动态调整的；

处理结果整合子单元，用于接收并整合辅助服务端返回的处理结果，得到所述业务请求的最终处理结果；

处理结果返回子单元，用于将所述业务请求的最终处理结果返回给相应的客户端。

此外，本申请还提供另一种处理业务请求的方法，包括：

从消息中间件读取待处理的客户端业务请求；

处理所述业务请求，并将处理结果提供给业务网关，以供业务网关向相应的客户端返回所述处理结果。

可选的，所述从消息中间件读取待处理的客户端业务请求，包括：根据宿主设备的处理能力从消息中间件读取待处理的客户端业务请求；

用于表征所述处理能力的指标包括以下元素之一或任意组合：CPU负荷、内存使用率。

可选的，所述处理所述业务请求包括：与各辅助服务端协同处理所述业务请求；

所述用于表征所述处理能力的指标还包括：所述辅助服务端的负载指标；

所述辅助服务端的负载指标包括以下元素之一或任意组合：处理失败率、响应时间、并发线程数量。

可选的，所述与各辅助服务端协同处理所述业务请求，包括：

按照流控策略，向辅助服务端分发业务请求；

接收并整合辅助服务端返回的处理结果，得到所述业务请求的最终处理结果；

其中，所述流控策略是根据辅助服务端的负载指标动态调整的。

与现有技术相比，本申请具有以下优点：

本申请提供的处理业务请求的方法，在接收环节将接收到的客户端业务请求存储在消息中间件中，在处理环节则从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端。本申请提供的上述方法，由于在接收业务请求以及处理业务请求这两个环节之间采用了消息中间件，从而解决了客户端发送业务请求的速度与服务端处理业务请求的速度不匹配的问题，避免出现超出服务端处理能力的业务请求被拒绝的现象，从而在不增加硬件成本的条件下，实现了对业务请求的有效接纳与处理，特别是在偶发海量业务请求的情况下，本申请的上述有益效果更为显著。

附图说明

图1是本申请的一种处理业务请求的方法的实施例的流程图；

图2是本申请实施例提供的从消息中间件读取业务请求进行处理的流程图；

图3是本申请实施例提供的与辅助服务端协同处理业务请求的处理流程图；

图4是本申请的一种处理业务请求的装置的实施例的示意图；

图5是本申请的另一种处理业务请求的方法的实施例的流程图；

图6是本申请的另一种处理业务请求的装置的实施例的示意图；

图7是本申请的一种中转业务请求的方法的实施例的流程图；

图8是本申请的一种中转业务请求的装置的实施例的示意图；

图9是本申请的一种业务请求方法的实施例的流程图；

图10是本申请的一种业务请求装置的实施例的示意图；

图11是本申请的一种业务请求处理系统的实施例的示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是，本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此，本申请不受下面公开的具体实施的限制。

在本申请中，分别提供了一种处理业务请求的方法及装置，另一种处理业务请求的方法及装置，一种中转业务请求的方法及装置，一种业务请求方法及装置，以及一种业务请求处理系统。在下面的实施例中逐一进行详细说明。

请参考图1，其为本申请的一种处理业务请求的方法的实施例的流程图。所述方法通常在为客户端提供服务的服务端实施。所述方法包括如下步骤：

步骤101、将接收到的客户端业务请求存储在消息中间件中。

客户端执行业务操作时(例如，在交易系统中，执行获取商品信息或者下单等操作)，通常会向提供相关服务的服务端发送业务请求，服务端则会接收到来自客户端的业务请求并进行处理。其中，每个业务请求通常都有唯一的ID作为标识，也称为业务请求标识(requestId)。

优选地，为了便于将处理结果及时地反馈给相应的客户端，在执行本步骤之前，可以先与发送业务请求的客户端之间建立长连接。

所述长连接，通常是指能够长期保持连接状态的数据连接。对于短连接，客户端与服务器之间每完成一次交互操作，通常就会释放连接，下次需要通信时再重新建立连接；而对于长连接，客户端与服务器在完成一次交互操作后可以不立即释放连接，后续的交互操作仍然可以继续使用这个连接，在没有数据交互的期间，双方可以通过发送链路检测包的方式保持连接状态(即，通常所述的心跳机制)。由此可见，长连接由于不需要频繁地建立以及释放连接，可以减少时间耗费、提高处理效率，而且还便于服务端主动向客户端推送信息，关于这部分内容请参见步骤102中的相关文字。

在具体实施时，客户端与服务端之间可以遵循TCP协议预先建立长连接、并利用心跳机制保持连接状态，客户端通过所述长连接向服务端发送业务请求，相应的，本步骤也基于长连接接收客户端的业务请求。本步骤还可以建立业务请求标识与长连接之间的对应关系，从而便于步骤102中执行推送操作。

优选地，可以采用支持长连接功能的SPDY协议建立与客户端之间的长连接通道，并基于该通道接收客户端业务请求，以及将处理结果推送给相应的客户端。SPDY是Google开发的基于TCP的应用层协议，具有数据流多路复用、最小化网络时延、HTTP报头压缩等特性，从而可以提高与客户端之间进行数据交互的性能以及安全性。在具体实施中，也可以采用其他支持长连接功能的协议，例如：HTTP2协议、或者QUIC(Quick UDP InternetConnections—快速UDP互联网连接)协议等。

本实施例基于长连接接收到客户端业务请求后，将所述业务请求以消息的形式存储在消息中间件中。所述消息中间件通常是指这样一种软件实体：该软件实体通过维护一系列预先定义的数据结构作为消息的存储、交换中心，并且对其他实体提供相应的消息管理、访问等功能，所述消息中间件可以是普通的消息队列，也可以是应用于集群环境中的分布式消息队列。

本实施例采用分布式消息中间件(MetaQ)作为用于存储客户端业务请求的消息中间件。MetaQ(全称为Metamorphosis)是一种开源的分布式消息中间件，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。所述分布式消息中间件定义的消息格式包括：消息标识、消息主题、消息内容以及消息属性。本步骤按照所述分布式消息中间件定义的消息格式将接收到的客户端业务请求存储在所述分布式消息中间件中，所述消息内容通常包含客户端业务请求，还可以包含与客户端业务请求相关的其他信息，例如：业务请求标识。

由于本步骤将接收到的客户端业务请求存储在消息中间件中，即使服务端处理业务请求的速率慢于客户端业务请求的到达速率，由于已经采用消息中间件进行存储，因此既无需拒绝客户端的业务请求、也不会导致业务请求被丢弃，从而实现了对业务请求的有效接纳，避免客户端执行重复操作。

步骤102、从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端。

本步骤涉及从消息中间件读取业务请求、处理业务请求、以及将处理结果返回给相应的客户端这样几个过程，具体包括以下步骤102-1至102-3，下面结合图2对整个处理过程作进一步说明。

步骤102-1、从消息中间件读取业务请求。

本步骤从消息中间件读取已存储的消息，并从所述消息中提取待处理的业务请求，其中，从消息中间件读取消息，可以是每次读取一条消息，也可以是采用批量形式读取，具体方式取决于所采用的消息中间件对外提供的访问接口。

在本实施例中采用所述分布式消息中间件作为消息中间件，由于所述分布式消息中间件提供批量拉取消息的机制，每次可以从所述分布式消息中间件中读取一批消息，从而可以提高消息中间件的吞吐量。本步骤根据所述分布式消息中间件的消息存储结构以及所述分布式消息中间件提供的访问接口，从所述分布式消息中间件读取消息，并从读取的消息中提取待处理的业务请求。

优选地，为了在保证服务端可用性的前提下，尽可能快速处理消息中间件中的业务请求，本步骤可以根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求，用于表征所述处理能力的指标包括以下元素之一或任意组合：CPU负荷、内存使用率等。

在本实施例中，采用CPU负荷，即CPU load表征所述处理能力。所述CPU load通常是指，在一段时间内CPU正在处理以及等待CPU处理的任务数之和的统计信息，该指标值可以通过查看系统资源使用状况的命令获取。一般来说，CPU load是与机器内核数有关的，在相同内核数的情况下，CPU load越高说明对于CPU资源的竞争越激烈，CPU负荷越大。

在具体实施时，可以根据CPU内核数预先设置CPU load的上限，例如，CPU为32核，则可以设置上限为32*1.5＝48，如果CPU load大于该上限，通常说明CPU已经超负荷运作，可以减少服务端处理业务请求的数量，因此可以减少单位时间内从消息中间件读取消息的数量，或者减少每次批量从消息中间件读取消息的数目；同样的道理，也可以设置CPU load的下限，当CPU load低于所述下限时，说明服务端的处理能力尚未得到充分发挥，则可以加快从消息中间件获取消息的速率。

需要说明的是，本实施例采用CPU负荷表征所述处理能力，在其他实施方式中，也可以采用内存使用率，或者综合采用CPU负荷以及内存使用率，也都是可以的。

此外，如果后续步骤102-2的处理过程是与其它辅助服务端共同完成的(关于这部分说明请参见步骤102-2中的相关文字)，那么所述处理能力还取决于辅助服务端的负载状况。在这种情况下，用于表征所述处理能力的指标还可以包括：辅助服务端的负载指标，所述负载指标包括以下元素之一或任意组合：处理失败率、响应时间、并发线程数量等，通常这些负载指标越大，说明辅助服务端的工作负荷越大，则可以相应地减慢从消息中间件获取消息的速率。

在具体实施时，可以综合考量上述用于表征处理能力的各指标，采用预设的算法或者策略，调整并选择合适的速率从消息中间件中读取消息(并提取业务请求进行处理)；在处理业务请求的过程中，所述各指标也可能发生相应的变化，此时可以根据变化后的各指标再次调整从消息中间件拉取消息的速率，并对拉取消息中的业务请求进行处理，......，以此类推，从而实现了基于反馈模型的流量控制机制，能够自适应地根据负责处理业务请求的服务端设备(以及辅助服务端)的负载状况获取任务执行，从而在保证服务端可用性的前提下，提高服务端的处理性能。

步骤102-2、处理读取的业务请求。

本步骤对已经从消息中间件中读取的业务请求进行处理，例如，对于查询商品信息的业务请求，可以通过查询商品数据库获取所需信息。

在互联网应用中，很多客户端业务请求的处理过程通常比较复杂，涉及多个处理环节，而且考虑到不同处理环节之间的解耦以及模块复用，本步骤对业务请求进行必要处理(例如格式转换、信息提取等)后，可以将其交由其他辅助服务端(也称依赖系统)处理。在具体实施中，实施了本申请技术方案的服务端(以下简称本服务端)与所述辅助服务端，通常部署于不同的设备上。

以互联网交易系统为例，当本服务端(也称交易服务端)从消息中间件中读取的业务请求为下单请求时，通常可以与各辅助服务端协同处理所述下单请求，所述辅助服务端可以包括：优惠服务端、库存服务端、物流服务端等。

本服务端将业务请求交由辅助服务端处理的过程包括：向辅助服务端分发业务请求、以及接收并整合处理结果，这样两个步骤。下面结合图3作进一步说明。

步骤102-2-1：按照流控策略，向辅助服务端分发业务请求。

在具体实施时，本服务端与各个辅助服务端之间可以采用基于HSF(High-speedservice framework)架构的RPC(Remote Procedure Call—远程过程调用)机制，在各个服务端之间以提供服务(Service)的方式进行交互。例如在上面给出的互联网交易系统的例子中，本服务端可以发起对库存服务端的RPC调用，从而将业务请求分发给库存服务端进行处理。

在具体实施时，可以根据历史经验，预先设置与辅助服务端之间的流控策略，所述流控策略可以包括：在单位时间内分发到辅助服务端的业务请求数量的阈值。本服务端遵循预先设置的流控策略向辅助服务端分发业务请求，辅助服务端则在处理完毕后返回处理结果。

优选地，为了在确保辅助服务端可用性的前提下、尽可能发挥辅助服务端的处理能力，可以根据辅助服务端的负载指标动态调整与所述辅助服务端之间的流控策略。所述辅助服务端的负载指标包括以下元素之一或任意组合：处理失败率(包括超时未返回应答、协议异常等)、响应时间、并发线程数量。在具体实施时，可以通过对辅助服务端返回应答情况的统计、以及监控辅助服务端运行时的资源使用状况，获取上述负载指标，通常上述负载指标越大，说明辅助服务端的工作负荷越大。

在具体实施时，可以以上述负载指标为依据，动态调整本服务端与辅助服务端之间的流控参数。例如，如果负载指标小于预设阈值下限，则可以增大分发到辅助服务端的流量阈值，如果负载指标超出了预设阈值上限，则可以减小分发到辅助服务端的流量阈值，即：根据辅助服务端的负载情况自适应调整放置到辅助服务端的流量，从而最大限度地发挥辅助服务端的处理能力，在此基础上，自然也可以为提升本服务端的处理性能提供有力保障。

此外，还可以根据辅助服务端的负载指标，对满足预设要求的辅助服务端进行降级处理。例如，如果某辅助服务端的负载指标在预设时间段内一直或者多次(对次数的要求可以预先设定)大于预设安全阈值，导致该辅助服务端可能成为整个业务请求处理过程的瓶颈，在这种情况下，如果所述辅助服务端与业务请求处理过程之间是弱依赖关系，则可以对所述辅助服务端执行降级处理，例如：仅向所述辅助服务端分发少量业务请求，或者不分发业务请求(即：解除依赖关系)。以上面给出的互联网交易系统为例，监控埋点服务端即为弱依赖关系的辅助服务端，该辅助服务端并不影响业务请求的处理结果，因此当监控埋点服务端的负载指标在预设时间段内超出预设安全阈值，那么可以执行上述降级操作，从而达到消除瓶颈、提升处理性能的目的。

步骤102-2-2：接收并整合辅助服务端返回的处理结果，得到所述业务请求的最终处理结果。

辅助服务端完成对业务请求的处理后，通常会返回处理结果。本步骤接收各辅助服务端返回的处理结果，并将各处理结果进行相应的整合操作，从而得到针对所述业务请求的最终处理结果。

在该过程中，还可以对各辅助服务端是否完成了正常的处理过程进行记录。例如：如果辅助服务端在预设时间段内未返回应答，则可以记录本次处理结果为超时失败；如果辅助服务端并未返回处理结果而是返回代表“协议异常”的标识码，则可以记录本次处理结果为协议异常失败；如果辅助服务端返回处理结果的同时还返回代表“正确处理”的标识码，则可以记录本次处理结果为成功。通过记录上述信息，可以统计辅助服务端负载指标中的处理失败率。同样的道理，也可以通过记录辅助服务端返回应答的时间，获知辅助服务端负载指标中的响应时间。

步骤102-3、将处理结果返回给相应的客户端。

步骤102-2已经生成了对业务请求的处理结果，本步骤可以存储所述处理结果，并根据接收到的来自客户端的针对所述业务请求的结果查询请求，将所述处理结果返回给客户端。

优选地，为了能够尽快将处理结果通知到客户端，同时也为了避免客户端采用轮询方式导致处理效率低等弊端，本实施例采用了通过预先建立的长连接将业务请求的处理结果推送给相应客户端的优选实施方式。

在本实施例中，在执行步骤101之前已经预先与发送业务请求的客户端建立了长连接，并且建立起了业务请求标识与长连接之间的对应关系，因此本步骤可以根据所述处理结果对应的业务请求的标识信息，查询所述对应关系，从而获知对应的长连接，然后就可以通过所述长连接向相应的客户端推送业务请求的处理结果。

优选地，如果在建立长连接时采用了SPDY协议，本步骤也可以采用SPDY协议执行所述推送操作。

通过步骤102-1至102-3，对从消息中间件读取业务请求进行处理、以及向客户端返回处理结果的过程进行了详细的说明，由于采用了从消息中间件读取业务请求进行处理的方式，即使出现偶发的海量业务请求，由于消息中间件的存在，服务端也不会受到直接的冲击，从而为业务请求的正确处理提供了有力保障。

至此，通过上面的步骤101至步骤102，对本发明提供的处理业务请求的方法进行了描述。需要说明的是，虽然本实施例采用了“步骤101”和“步骤102”这样的表述方式，但并不必然代表这两个步骤是顺序、依次执行的。在具体实现时，步骤101和步骤102的操作可以分别由服务端的两个进程或者两个线程来实现，也可以采用在物理上彼此独立的实体来实现，例如：由业务网关实现步骤101的功能，即：负责向消息中间件中写入业务请求；由业务服务端实现步骤102的功能，即：负责从消息中间件中读取业务请求、进行处理，并将业务请求经由业务网关返回给相应的客户端。

综上所述，本实施例提供的处理业务请求的方法，由于在接收业务请求以及处理业务请求这两个环节之间采用了消息中间件，从而解决了客户端发送业务请求的速度与服务端处理业务请求的速度不匹配的问题，避免出现超出服务端处理能力的业务请求被拒绝的现象，从而在不增加硬件成本的条件下，实现了对业务请求的有效接纳与处理，特别是在偶发海量业务请求的情况下，本申请的上述有益效果更为显著。

在上述的实施例中，提供了一种处理业务请求的方法，与之相对应的，本申请还提供一种处理业务请求的装置。请参看图4，其为本申请的一种处理业务请求的装置实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种处理业务请求的装置，包括：业务请求接收存储单元401，用于将接收到的客户端业务请求存储在消息中间件中；业务请求读取处理单元402，用于从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端。

可选的，所述装置包括：

长连接建立单元，用于与客户端之间建立长连接；

所述业务请求接收存储单元具体用于，将通过与客户端之间的长连接接收到的客户端请求存储在消息中间件中；

所述业务请求读取处理单元具体用于，从消息中间件读取业务请求进行处理，并通过长连接将处理结果推送给相应的客户端。

可选的，所述业务请求读取处理单元具体用于，根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端。

可选的，所述业务请求读取处理单元具体用于，根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求，与各辅助服务端协同处理所述业务请求，并将处理结果返回给相应的客户端。

可选的，所述业务请求读取处理单元包括：

业务请求读取子单元，用于根据负责处理业务请求的服务端设备的处理能力从消息中间件中读取业务请求；

业务请求分发子单元，用于按照流控策略，向辅助服务端分发业务请求，所述流控策略是根据辅助服务端的负载指标动态调整的；

处理结果整合子单元，用于接收并整合辅助服务端返回的处理结果，得到所述业务请求的最终处理结果；

处理结果返回子单元，用于将所述业务请求的最终处理结果返回给相应的客户端。

此外，本申请还提供另一种处理业务请求的方法，所述方法通常在负责处理业务请求的业务服务端实施。请参考图5，其为本申请提供的另一种处理业务请求的方法的实施例的流程图，本实施例与上述方法实施例步骤相同的部分不再赘述，下面重点描述不同之处。本申请提供的另一种处理业务请求的方法包括：

步骤501、从消息中间件读取待处理的客户端业务请求。

优选地，本步骤可以根据实施本方法的宿主设备的处理能力从消息中间件读取待处理的客户端业务请求。用于表征所述处理能力的指标包括以下元素之一或任意组合：CPU负荷、内存使用率。

步骤502、处理所述业务请求，并将处理结果提供给业务网关，以供业务网关向相应的客户端返回所述处理结果。

所述处理所述业务请求包括：与各辅助服务端协同处理所述业务请求。相应的，用于表征宿主设备处理能力的指标还包括：所述辅助服务端的负载指标。所述辅助服务端的负载指标包括以下元素之一或任意组合：处理失败率、响应时间、并发线程数量。

所述与各辅助服务端协同处理所述业务请求，包括：按照流控策略，向辅助服务端分发业务请求；接收并整合辅助服务端返回的处理结果，得到所述业务请求的最终处理结果；其中，所述流控策略是根据辅助服务端的负载指标动态调整的。

得到针对业务请求的处理结果后，可以通过向业务网关发送消息、或者调用业务网关提供的服务接口等方式，将处理结果提供给业务网关。在具体实施时，通常也可以将处理结果对应的业务请求标识一并发送给业务网关，以便业务网关根据所述业务请求标识，将所述处理结果发送给相应的客户端。

在上述的实施例中，提供了另一种处理业务请求的方法，与之相对应的，本申请还提供另一种处理业务请求的装置。请参看图6，其为本申请的另一种处理业务请求的装置的实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种处理业务请求的装置，包括：业务请求读取单元601，用于从消息中间件读取待处理的客户端业务请求；业务请求处理单元602，用于处理所述业务请求，并将处理结果提供给业务网关，以供业务网关向相应的客户端返回所述处理结果。

此外，本申请还提供一种中转业务请求的方法，所述方法通常在负责存储业务请求的业务网关实施。请参考图7，其为本申请提供的一种中转业务请求的方法的实施例的流程图，本实施例与上述各方法实施例步骤相同的部分不再赘述，下面重点描述不同之处。本申请提供的一种中转业务请求的方法包括：

步骤701、接收客户端发送的业务请求，并将所述业务请求存储在消息中间件中，以供业务服务端读取并处理。

优选地，为了尽快将业务服务端的处理结果返回给客户端，在接收客户端发送的业务请求之前，可以先与客户端建立长连接。相应的，所述业务请求是通过与客户端之间的长连接接收到的。在具体实施时，可以维护业务请求标识与长连接之间的对应关系。

步骤702、将所述业务服务端提供的处理结果返回给相应的客户端。

在具体实施时，可以将业务服务端提供的处理结果存储下来，然后根据来自客户端的查询请求，将相应的处理结果返回给客户端。

优选地，可以通过预先建立的长连接将所述处理结果推送给相应的客户端。在具体实施时，业务服务端向业务网关提供处理结果时，通常可以一并提供对应的业务请求标识，因此本步骤可以根据业务请求标识查找业务请求标识与长连接之间的对应关系，从而将所述处理结果采用正确的长连接推送给相应的客户端。

在上述的实施例中，提供了一种中转业务请求的方法，与之相对应的，本申请还提供一种中转业务请求的装置。请参看图8，其为本申请的一种中转业务请求的装置的实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种中转业务请求的装置，包括：业务请求存储单元801，用于接收客户端发送的业务请求，并将所述业务请求存储在消息中间件中，以供业务服务端读取并处理；处理结果返回单元802，用于将所述业务服务端提供的处理结果返回给相应的客户端。

此外，本申请还提供一种业务请求方法，所述方法通常在发起业务请求的客户端实施。请参考图9，其为本申请提供的一种业务请求方法的实施例的流程图，本实施例与上述各方法实施例步骤相同的部分不再赘述，下面重点描述不同之处。本申请提供的一种业务请求方法包括：

步骤901、向业务网关发送业务请求。

客户端可以通过与业务网关之间建立的普通数据连接，即通常所述的短连接，向业务网关发送业务请求。

优选地，为了能够尽快接收到业务网关返回的处理结果，同时避免采用轮询方式影响执行效率，在执行本步骤之前可以建立与所述业务网关之间的长连接。相应的，本步骤可以通过所述长连接向业务网关发送业务请求，而业务网关则可以基于所述长连接推送业务请求的处理结果。

在具体实施时，为了便于在接收推送的结果后进行有针对性地处理，本步骤在向业务网关发送业务请求之前，可以注册针对待发送业务请求的回调处理器(也称回调函数)，通常可以通过在发送业务请求的接口中指定回调函数的方式，实现所述注册功能。

在向业务网关发送业务请求后，通常在一段时间后才能获取处理结果，为了提供友好的人机界面，可以在客户端的显示设备上显示“请求正在处理中，请耐心等待”、或者其他类似的提示文字。

步骤902、接收所述业务网关返回的针对所述业务请求的处理结果，所述处理结果是由业务服务端从消息中间件中读取并处理后得到的。

由于客户端发送的业务请求，首先经业务网关存储在消息中间件中，此后业务服务端再从消息中间件中读取所述业务请求进行处理，因此即使在海量业务请求的情况下，也不会出现业务请求被拒绝的现象，因此客户端在发送业务请求后，通常都可以接收到业务网关返回的处理结果，而无需重复发送业务请求，在提高客户端执行效率的同时，能够有效提升用户体验。

在具体实施时，本步骤可以采用轮询方式向业务网关发送处理结果查询请求，并接收业务网关返回的处理结果。

优选地，可以通过预先建立的长连接接收业务网关推送的处理结果。采用这种处理方式，客户端无需通过轮询向服务端发送获取处理结果的请求，在业务网关将处理结果推送到客户端之前，客户端用户可以无阻断的做其它事情，从而可以进一步提高客户端的执行效率，提升用户的使用体验。

具体实施时，可以通过监听方式接收所述业务网关推送的处理结果，并回调之前注册的回调处理器执行预设操作，例如：通过渲染页面或者弹出通知消息的方式，告知客户端用户之前发起的业务请求已处理完毕，也可以显示相应的处理结果。

在上述的实施例中，提供了一种业务请求方法，与之相对应的，本申请还提供一种业务请求装置。请参看图10，其为本申请的一种业务请求装置的实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种业务请求装置，包括：请求发送单元1001，用于向业务网关发送业务请求；处理结果接收单元1002，用于接收所述业务网关返回的针对所述业务请求的处理结果，所述处理结果是由业务服务端从消息中间件中读取所述业务请求并处理后得到的。

此外，本申请还提供一种业务请求处理系统，如图11所示，所述系统包括上述实施例所述的处理业务请求的装置1101、中转业务请求的装置1102、业务请求装置1103、以及用于承载消息中间件的设备1104。所述业务请求装置通常部署于移动通讯设备、个人电脑等客户端设备，所述消息中间件可以为分布式消息队列，例如：MetaQ，所述用于承载消息中间件的设备可以是服务器，所述处理业务请求的装置、以及所述中转业务请求的装置可以分别部署于不同的服务器上，其中前者通常称为业务服务端，后者通常称为业务网关(业务服务端和业务网关可以统称为服务端)。

本实施例提供的业务请求处理系统的基本处理流程是：客户端设备向业务网关发送业务请求，业务网关将接收到的业务请求存储在消息中间件中，业务服务端则从消息中间件中读取业务请求进行处理并将处理结果提供给业务网关，由业务网关将所述处理结果返回给相应的客户端。

在具体应用中，所述业务请求处理系统可以采用多种具体的实施方式，例如：可以包含多个业务网关，形成业务网关集群，也可以包含多个业务服务端，形成业务服务端集群，所述业务网关集群与业务服务端集群通过消息中间件进行协作，完成对业务请求的处理。此外，所述系统还可以包含用于辅助业务服务端处理业务请求的其他辅助服务端。上述列举的实施方式的变更，以及在其他具体应用中可能采用的不同部署方式或实施方式，只要能够实现本申请所述的业务请求处理系统的整体功能，就都在本申请的保护范围之内。

综上所述，本申请提供的业务请求处理系统，由于在接收业务请求以及处理业务请求这两个环节之间采用了消息中间件，从而解决了客户端发送业务请求的速度与服务端处理处理业务请求的速度不匹配的问题，避免出现超出服务端处理能力的业务请求被拒绝的现象，从而在不增加硬件成本的条件下，实现了对业务请求的有效接纳与处理，特别是在偶发海量业务请求的情况下，本申请的上述有益效果更为显著。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

Claims (16)

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

将接收到的客户端业务请求存储在消息中间件中；

从消息中间件读取业务请求进行处理，包括：根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求、并与辅助服务端协同处理所述业务请求，其中，用于表征所述处理能力的指标包括：所述辅助服务端的负载指标；

其中，所述根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求，包括：根据所述辅助服务端的负载指标的变化，动态调整从所述消息中间件获取消息的速率；将处理结果返回给相应的客户端。

2.根据权利要求1所述的处理业务请求的方法，其特征在于，包括：

与客户端之间建立长连接；

所述客户端业务请求是通过与客户端之间的长连接接收到的；

所述将处理结果返回给相应的客户端包括：通过长连接将所述处理结果推送给相应的客户端。

3.根据权利要求2所述的处理业务请求的方法，其特征在于，所述与客户端之间建立长连接、接收客户端业务请求以及将所述处理结果推送给相应客户端的操作，是基于SPDY协议实现的。

4.根据权利要求1所述的处理业务请求的方法，其特征在于，用于表征所述处理能力的指标还包括以下元素之一或任意组合：CPU负荷、内存使用率。

5.根据权利要求4所述的处理业务请求的方法，其特征在于，所述辅助服务端的负载指标包括以下元素之一或任意组合：处理失败率、响应时间、并发线程数量。

6.根据权利要求4所述的处理业务请求的方法，其特征在于，所述与各辅助服务端协同处理所述业务请求，包括：

按照流控策略，向辅助服务端分发业务请求；

接收并整合辅助服务端返回的处理结果，得到所述业务请求的最终处理结果；

其中，所述流控策略是根据辅助服务端的负载指标动态调整的。

7.根据权利要求1所述的处理业务请求的方法，其特征在于，所述将接收到的客户端业务请求存储在消息中间件中的步骤，由业务网关完成；

所述从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端的步骤由业务服务端完成，其中所述将处理结果返回给相应的客户端包括：将处理结果经由业务网关返回给相应的客户端。

8.根据权利要求1-7任一项所述的处理业务请求的方法，其特征在于，所述方法用于互联网交易系统中，所述业务请求包括下单请求。

9.根据权利要求1-7 任一项所述的处理业务请求的方法，其特征在于，所述消息中间件包括：MetaQ分布式消息队列。

10.一种处理业务请求的装置，其特征在于，包括：

业务请求接收存储单元，用于将接收到的客户端业务请求存储在消息中间件中；

业务请求读取处理单元，用于从消息中间件读取业务请求进行处理，并将处理结果返回给相应的客户端，所述业务请求读取处理单元具体用于，根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求、并与辅助服务端协同处理所述业务请求，将处理结果返回给相应的客户端，其中，用于表征所述处理能力的指标包括：所述辅助服务端的负载指标；所述根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求，包括：根据所述辅助服务端的负载指标的变化，动态调整从所述消息中间件获取消息的速率。

11.根据权利要求10所述的处理业务请求的装置，其特征在于，包括：

长连接建立单元，用于与客户端之间建立长连接；

所述业务请求接收存储单元具体用于，将通过与客户端之间的长连接接收到的客户端请求存储在消息中间件中；

所述业务请求读取处理单元具体用于，从消息中间件读取业务请求进行处理，并通过长连接将处理结果推送给相应的客户端。

12.根据权利要求11所述的处理业务请求的装置，其特征在于，所述业务请求读取处理单元包括：

业务请求读取子单元，用于根据负责处理业务请求的服务端设备的处理能力从消息中间件中读取业务请求；

业务请求分发子单元，用于按照流控策略，向辅助服务端分发业务请求，所述流控策略是根据辅助服务端的负载指标动态调整的；

处理结果整合子单元，用于接收并整合辅助服务端返回的处理结果，得到所述业务请求的最终处理结果；

处理结果返回子单元，用于将所述业务请求的最终处理结果返回给相应的客户端。

13.一种处理业务请求的方法，其特征在于，包括：根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求、并与辅助服务端协同处理所述业务请求，其中，用于表征所述处理能力的指标包括：所述辅助服务端的负载指标；

处理所述业务请求，并将处理结果提供给业务网关，以供业务网关向相应的客户端返回所述处理结果；

其中，所述根据负责处理业务请求的服务端设备的处理能力从消息中间件读取业务请求，包括：根据所述辅助服务端的负载指标的变化，动态调整从所述消息中间件获取消息的速率。

14.根据权利要求13所述的处理业务请求的方法，其特征在于，所述从消息中间件读取待处理的客户端业务请求，包括：根据宿主设备的处理能力从消息中间件读取待处理的客户端业务请求；

用于表征所述处理能力的指标包括以下元素之一或任意组合：CPU负荷、内存使用率。

15.根据权利要求14所述的处理业务请求的方法，其特征在于，所述处理所述业务请求包括：与各辅助服务端协同处理所述业务请求；

所述用于表征所述处理能力的指标还包括：所述辅助服务端的负载指标；

所述辅助服务端的负载指标包括以下元素之一或任意组合：处理失败率、响应时间、并发线程数量。

16.根据权利要求15所述的处理业务请求的方法，其特征在于，所述与各辅助服务端协同处理所述业务请求，包括：

按照流控策略，向辅助服务端分发业务请求；

接收并整合辅助服务端返回的处理结果，得到所述业务请求的最终处理结果；

其中，所述流控策略是根据辅助服务端的负载指标动态调整的。

Images