CN105099989B

CN105099989B - 用于处理业务请求及获取业务处理结果的方法、装置和系统

Info

Publication number: CN105099989B
Application number: CN201410168704.XA
Authority: CN
Inventors: 孙棋
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2014-04-24
Filing date: 2014-04-24
Publication date: 2019-11-22
Anticipated expiration: 2034-04-24
Also published as: HK1213110A1; CN105099989A

Abstract

本申请公开了一种用于处理业务请求的方法和装置、一种用于获取业务处理结果的方法和装置、以及一种用于处理业务请求的系统。其中用于处理业务请求的方法包括：接收来自客户端的业务请求；将接收的业务请求转发到处理所述业务请求的业务服务端；判断是否需要针对所述业务请求进行异步处理；若是，向所述客户端发送包含异步处理指示的应答；若否，将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端。采用本申请提供的方法，可以缩短客户端用户的等待时间，改善用户体验，同时提升服务端的性能和吞吐能力。

Description

用于处理业务请求及获取业务处理结果的方法、装置和系统

技术领域

本申请涉及HTTP请求响应技术，具体涉及一种用于处理业务请求的方法和装置。本申请同时提供一种用于获取业务处理结果的方法和装置，以及一种用于处理业务请求的系统。

背景技术

互联网(简称Internet)是一种公用信息的载体，是大众传媒的一种，由于互联网具有的快捷性和普及性特点，使其成为现今最流行、最受欢迎的传媒之一，在现实生活中得到了广泛的应用。不论是使用台式机还是移动设备，用户都可以随时随地获取互联网资讯，实现了远程办公、电子商务、网络社交、即时通讯、娱乐和游戏等应用和服务。

B/S(Browser/Server浏览器/服务器)模式又称B/S结构，是随着Internet技术的兴起，对C/S(Client/Server客户端/服务器)模式应用的扩展。B/S模式是指在TCP/IP的支持下，以HTTP(Hypertext transfer protocol超文本传输协议)为传输协议，客户端通过浏览器访问所需的Web服务器以及与之相连的后台服务器的技术及体系结构，其基本工作原理是这样的：用户在客户端的浏览器中输入所需访问资源的URL，客户端浏览器通过HTTP协议向Web服务器提出浏览网页或者获取网络资源的请求，Web服务器收到来自客户端浏览器的请求后，将其自身存储的、或者是从其他服务器获取的数据，以HTML形式返回客户端浏览器，这个动作称为响应，客户端浏览器将接收到的网页数据或者是网络资源数据提取出来，并进行相应的显示或播放，用户就得到了所需的信息。

从上面介绍的基于传统B/S结构的HTTP请求应答模式可以看出，如果采用传统的B/S应答方式处理来自客户端的业务请求，那么整个交互过程是串行的，即：针对客户端发起的业务请求，服务端(通常包括业务网关和业务服务端)处理完毕后才会将最终处理结果返回给发起业务请求的客户端，因此对于客户端用户来说，其体验效果很大程度上依赖于服务端对业务请求的处理耗时情况，如果服务端执行一个耗时非常长的业务处理操作，那么就会导致客户端的界面一直处于等待状态，例如：长时间显示转动的菊花，用户此时没有其他选择只能等待，这样的体验对于用户来说并不理想。例如：手机淘宝电影票的客户端应用调用服务端的电影票系统选座下单，因电影票座位信息是接入第三方，再由第三方接入影院的数据，中间都是发起HTTP的请求，一次下单操作经常耗时达10s级别，客户端才能收到结果并展示告知用户。

采用传统的B/S应答方式，不仅会因为处理耗时导致用户体验很差，而且因为整个处理过程是串行完成的，因此服务端需要与客户端长时间的保持连接状态，从而导致大量的服务端资源被浪费，服务端的吞吐能力很低。

此外，虽然现在无线应用大范围普及，但目前仍旧有大量的用户所处的网络质量差、速度慢、不稳定，甚至在2G网络中使用移动应用，同样会导致或者加剧上述用户需要长时间等待的问题。同样以手机淘宝电影票的客户端为例，在服务端进行长耗时的业务处理时，在上述网络条件下客户端和服务端之间的数据连接很可能会中断，导致用户即使耐心等待也得不到最终的处理结果，最后只能通过超时处理方式(例如：再次下单、或者先查询上次下单是否成功再决定是否再次执行下单操作)获取最终的处理结果。

发明内容

本申请提供一种用于处理业务请求的方法和装置，以解决现有HTTP请求应答模式导致用户等待时间长、服务端吞吐能力低的问题。本申请另外提供一种用于获取业务处理结果的方法和装置，以及一种用于处理业务请求的系统。

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

接收来自客户端的业务请求；

将接收的业务请求转发到处理所述业务请求的业务服务端；

判断是否需要针对所述业务请求进行异步处理；若是，向所述客户端发送包含异步处理指示的应答；若否，将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端。

可选的，如果所述判断是否需要针对所述业务请求进行异步处理的判断结果为“是”，则所述方法包括：

接收所述业务服务端返回的针对所述业务请求的应答；

接收来自所述客户端的获取所述业务请求的最终处理结果的请求；

将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端。

可选的，所述异步处理指示包含所述业务请求的唯一标识和获取所述业务请求的最终处理结果的建议时间。

可选的，所述方法包括：

记录所述业务服务端历次处理业务请求所消耗时间的历史信息；

根据所述历史信息计算与所述业务请求对应的业务处理耗时参考值。

可选的，所述判断是否需要针对所述业务请求进行异步处理，包括：

判断所述业务请求中是否携带了请求异步处理的标识；或者，

判断所述业务请求涉及的业务操作是否被标识为需要采用异步处理方式；或者，

判断与所述业务请求对应的业务处理耗时参考值是否达到了预先设置的启用异步处理方式的阈值。

可选的，所述向所述客户端发送包含异步处理指示的应答，包括：

根据与所述业务请求对应的业务处理耗时参考值，估算所述业务服务端处理本次业务请求的耗时；

根据估算的所述业务服务端处理本次业务请求的耗时和所述业务请求中携带的网络环境数据，计算所述客户端获取最终处理结果的建议时间；

为所述业务请求生成唯一标识；

向所述客户端发送包含上述唯一标识和获取最终处理结果的建议时间的异步处理应答。

可选的，所述方法包括：

开启与所述客户端之间的持久连接功能。

可选的，所述方法包括：

接收所述业务服务端返回的针对所述业务请求的应答；

将所述业务请求的应答推送给所述客户端。

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

业务请求接收单元，用于接收来自客户端的业务请求；

业务请求转发单元，用于将接收的业务请求转发到处理所述业务请求的业务服务端；

业务请求处理单元，用于判断是否需要针对所述业务请求进行异步处理；若是，向所述客户端发送包含异步处理指示的应答；若否，将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端。

此外，本申请还提供一种用于获取业务处理结果的方法，包括：

向业务网关发送业务请求；

接收来自所述业务网关的对所述业务请求的应答；

判断所述应答是否包含异步处理指示；若是，根据所述应答包含的异步处理指示向所述业务网关获取所述业务请求的最终处理结果；若否，则所述应答即为所述业务请求的最终处理结果。

可选的，所述方法包括：

获取网络环境数据；

相应的，在向所述业务网关发送的业务请求中包含所述网络环境数据。

可选的，所述获取网络环境数据，包括：

识别当前所用网络的网络类型、网络制式和/或信号强度；

测试当前所用网络的网络传输速度；

根据上述步骤获取的信息生成所述网络环境数据。

可选的，所述方法包括：

根据所述获取的网络环境数据，判断当前所用网络是否为弱网络；

若是，向所述业务网关发送业务请求时携带请求异步处理的标识。

可选的，所述方法包括：

记录向所述业务网关发送所述业务请求的起始时间；

记录获取所述业务请求的最终处理结果的终止时间；

计算所述终止时间和所述起始之间的差值，作为本次业务请求处理过程的往返时间；

根据所述往返时间修订所述网络环境数据。

可选的，所述根据所述应答包含的异步处理指示向所述业务网关获取所述业务请求的最终处理结果，包括：

根据所述异步处理指示包含的获取最终处理结果的建议时间，向所述业务网关发送获取与所述异步处理指示包含的业务请求标识对应的最终处理结果的请求；

接收所述业务网关返回的与所述业务请求标识对应的最终处理结果。

可选的，在执行所述向业务网关发送业务请求的步骤之前，向提出所述业务请求的应用程序返回成功应答。

可选的，如果接收到的来自所述业务网关的对所述业务请求的应答中包含异步处理指示，则执行下述操作：

提示发起所述业务请求的用户当前正在处理业务请求；

为所述用户提供获取所述业务请求最终处理结果的接口，或者，告知所述用户过一段时间再返回查看本次业务请求的最终处理结果。

可选的，如果执行所述获取最终处理结果步骤的次数，达到或者超过了预先设定的值，仍然未获取所述业务请求的最终处理结果，则转到向所述业务网关发送业务请求的步骤执行。

可选的，如果所述业务请求的最终处理结果为，本次业务请求失败，则转到所述向业务网关发送业务请求的步骤执行。

可选的，所述方法包括：

获取所述业务请求的最终处理结果后，显示所述最终处理结果。

向所述业务网关发送一次性获取与多个业务请求标识对应的最终处理结果的请求；

接收所述业务网关返回的与所述多个业务请求标识对应的多个最终处理结果。

相应的，本申请还提供一种用于获取业务处理结果的装置，包括：

业务请求发送单元，用于向业务网关发送业务请求；

业务应答接收单元，用于接收来自所述业务网关的对所述业务请求的应答；

业务应答处理单元，用于判断所述应答是否包含异步处理指示；若是，根据所述应答包含的异步处理指示向所述业务网关获取所述业务请求的最终处理结果；若否，则所述应答即为所述业务请求的最终处理结果。

此外，本申请还提供一种用于处理业务请求的系统，包括：根据上述任一项所述的用于处理业务请求的装置，和根据上述任一项所述的用于获取业务处理结果的装置，以及负责处理业务请求的业务服务端。

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

本申请的用于处理业务请求的方法，没有采用传统B/S结构的服务端(包括业务网关和业务服务端)处理完毕后再响应最终结果给用户的串行模式，而是通过客户端与业务网关的交互配合，在业务网关将所述业务请求转发给业务服务端的同时，判断客户端的业务请求是否需要进行异步处理，从而在业务处理耗时长或者弱网络等情况下，能够提前向所述客户端返回异步应答，不仅减少了客户端用户的无谓等待时间，有效改善用户体验，同时使服务端资源得到充分利用，提升服务端的性能与吞吐能力。

本申请的用于处理业务请求的方法，提供一种优选实施方式，在客户端和业务网关之间开启持久连接功能，并且将多个需要进行异步处理的业务请求的最终处理结果一次性获取回来，一方面可重复利用客户端和业务网关之间的数据连接，减少用于建立和释放数据连接的开销，同时有效减少数据的传输量，节省网络带宽。

附图说明

图1为本申请的用于处理业务请求的方法的实施例的流程图；

图2为本申请的向客户端发送包含异步处理指示的应答的实施例的流程图；

图3为本申请的向客户端提供最终处理结果的实施例的流程图；

图4为本申请的用于处理业务请求的装置的实施例的示意图；

图5为本申请的用于获取业务处理结果的方法的实施例的流程图；

图6为本申请的用于获取业务处理结果的装置的实施例的示意图；

图7为本申请的用于处理业务请求的系统的实施例的示意图；

图8为本申请的用于处理业务请求的系统的异步处理流程的实施例的示意图。

具体实施方式

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

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

请参考图1，其为本申请的一种用于处理业务请求的方法实施例的流程示意图。所述方法包括如下步骤：

步骤101：接收来自客户端的业务请求。

本申请的用于处理业务请求的方法，在弱网络或者业务请求处理耗时长的情况下，采用异步处理方式，直接向发起业务请求的客户端返回异步应答，而将业务请求的真正处理过程交由业务服务端完成，采用上述方法，能够缩短业务处理的响应时间，使客户端用户及时获知业务请求的处理情况。需要说明的是，本申请所述的弱网络，是一个相对的概念，而且并不局限于无线网络，通常是指网络传输速度或网络传输质量(例如：丢包率)低于设定阈值的网络。例如，目前2G网络传输速度相对较慢、网络传输质量相对较差，可以认为是弱网络，但是随着网络技术的发展，对弱网络的界定也会有所变化。

下面介绍本申请的用于处理业务请求的方法的具体步骤，为了便于描述，本文将实现了本申请的用于处理业务请求的方法的应用程序或者系统称为业务网关，将业务网关和负责处理业务请求的业务服务端统称为服务端。

业务网关首先要接收来自客户端的业务请求。客户端通过HTTP协议发送的业务请求中除了会封装需要执行的业务操作信息(例如业务操作所对应的api信息)外，通常还会携带一些用于指示服务端如何处理所述业务请求的信息。在本申请的技术方案中，客户端发送的业务请求中会携带网络环境数据，还可能携带请求对所述业务请求进行异步处理的标识。关于这部分，可以参见本申请的一种用于获取业务处理结果的方法实施例的相关说明。

步骤102：将接收的业务请求转发到处理所述业务请求的业务服务端。

接收来自客户端的业务请求后，解析该业务请求涉及的业务操作。根据该业务操作，将所述业务请求转发到能够执行或者处理所述业务操作的业务服务端。所述业务请求可以采用HTTP协议封装。为了提高业务网关的吞吐能力，本步骤可以采用异步方式来完成，即：业务网关发起对业务服务端的调用后，并不等待业务服务端返回处理结果，而是直接结束本次调用，继续处理其他的业务请求，所述业务处理端处理完所述调用涉及的业务操作后，会异步地将处理结果返回给业务网关。例如：在将所述业务请求转发到所述业务服务端的HTTP请求中，为callback关键字指定一个回调函数，所述业务请求处理完毕后会调用该回调函数返回最终处理结果。

步骤103：判断是否需要针对所述业务请求进行异步处理；若是，向所述客户端发送包含异步处理指示的应答；若否，将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端。

为了实现本申请的技术方案，使客户端用户在弱网络或者业务请求处理耗时长的情况下，能够及时获知业务请求的处理情况，需要业务网关和客户端的协同配合，一方面业务网关要能够判断所述业务请求是否需要采取异步处理方式，并在需要采取异步处理的情况下，立即向客户端返回应答，告知客户端所述业务请求在服务端一侧采取的是异步处理方式；另一方面，客户端接收到上述应答后，采用通知用户等方式改善用户体验，并稍后再向业务网关获取所述业务请求的最终处理结果。

对于业务网关来说，上述判断过程以及立即应答过程是通过本步骤实现的。本步骤所述的包含异步处理指示的应答是指，在发送给客户端的应答中包含特定的指示信息，用以告知客户端所述业务请求在服务端一侧采取的是异步处理方式。在具体实现中，所述特定的指示信息可以采用应答中的某个参数或者状态位的特定取值来表示。为了便于客户端获取所述业务请求的最终处理结果，所述异步处理指示还可以进一步包括告知客户端获取所述最终处理结果的具体方式，关于这部分的详细说明请参见后续步骤201-204的描述。

在本步骤中，业务网关判断是否需要针对所述业务请求进行异步处理，需要考虑以下几个方面的判断条件，其中至少有一个判断结果为“是”时，可以对所述业务请求进行异步处理。

1)判断所述业务请求中是否携带了请求异步处理的标识。

如果所述业务请求中携带了请求异步处理的标识，说明当前客户端处于弱网络环境下，可能会出现数据连接断开的情况，因此客户端主动请求服务端采取异步处理方式处理所述业务请求。在这种情况下，不管业务服务端处理所述业务请求是否耗时，都可以采取异步处理方式。

2)判断所述业务请求涉及的业务操作是否被标识为需要采用异步处理方式。

业务服务端处理每种业务操作所花费的时间是不同的，例如：在淘宝应用中，查询购物车的相关信息可能只需要10ms，而处理一个下单操作可能耗时长一些，需要100ms，还有的操作可能耗时更长。不考虑网络环境的因素、也不考虑业务服务端可能出现的负载过大的情况，对于本身处理耗时就相对比较长的操作，系统会预先将其标识为需要采用异步处理方式。因此，如果所述业务请求涉及的业务操作属于已经被标识为需要采用异步处理方式的业务操作，那么对所述业务请求也要采取异步处理方式。

3)判断与所述业务请求对应的业务处理耗时参考值是否达到了预先设置的启用异步处理方式的阈值。

上述1)中的判断条件是考虑客户端的网络环境因素，2)中的判断条件是依据业务请求自身的处理耗时情况，本判断条件则是依据所述业务服务端处理能力的动态变化，决定所述业务请求的处理模式，是一个动态发现动态调整的过程。如果所述业务服务端针对所述业务请求的处理耗时参考值达到了预先设置的启用异步处理方式的阈值，那么对所述业务请求也要采取异步处理方式。为了实施判断条件3)，需要记录所述业务服务端历次处理业务请求所消耗时间的历史信息，并根据所述历史信息计算与所述业务请求对应的业务处理耗时参考值，下面针对这两个过程分别进行说明。

获取业务服务端处理业务请求所消耗的时间，最为简单的实现方式，就是记录两个时间点。第一个时间点是向所述业务服务端转发业务请求的时间点，第二个时间点是接收所述业务服务端返回所述业务请求的应答的时间点。计算位于两个时间点之间的时间段的长度，所述长度就是所述业务服务端处理所述业务请求所消耗的时间。其中向业务服务端发送请求和接收应答的数据传输时间，该时间通常非常短，可以忽略不计。

在具体实施过程中，为了便于软件模块的复用与维护，可以采用AOP技术计算每个业务请求的处理耗时。传统的OOP(Object-Oriented Programing，面向对象编程)技术通过封装、继承和多态性等机制建立一种对象层次结构，而AOP(Aspect-OrientedProgramming，面向方面编程)技术则利用一种称为“横切”的技术，剖解开封装的对象内部，并将影响多个类的公共行为(例如：日志功能、权限认证、异常处理等)封装到一个可重用模块，并将其名为“Aspect”，即方面。也可以这样理解，AOP技术就是将应用程序中的商业逻辑同对其提供支持的通用服务进行分离，便于减少系统的重复代码，降低模块间的耦合度，有利于软件系统的可操作性和可维护性。

在本实施例的一个具体例子中，将时间记录功能作为影响多个模块或者类的公共行为，封装到一个可重用模块中，并通过动态代理技术或者静态织入的方式，使得时间记录功能与业务网关自身的功能模块整合在一起，从而实现上述记录时间点的功能，并依据记录的关键时间点计算所述业务请求的业务处理耗时。

作为简单易行的实施方式，根据业务请求的处理耗时情况判断是否采用异步处理方式时，可以仅考虑上一次该业务请求的处理耗时，如果该处理耗时达到了预先设置的启用异步处理方式的阈值，则对所述业务请求启用异步处理方式。但是考虑到不可避免的网络波动、以及业务服务器一侧的突发事件等偶然因素，单独一次的处理耗时数据可能无法尽可能准确地反映所述业务服务端的处理能力，因此本申请的技术方案采取了下述方式：将每次业务请求的处理耗时的历史信息都记录下来，作为计算业务处理耗时参考值的依据。

获取了所述业务请求处理耗时的历史信息后，就可以计算与所述业务请求对应的业务处理耗时参考值。例如：可以从所述历史信息中，提取所述业务请求的最近100次的处理耗时，并计算这100次处理耗时的平均值，所述平均值即为所述业务请求的业务处理耗时参考值；也可以提取所述业务请求在最近半分钟或者一分钟之内的处理耗时，并将这段时间内的处理耗时的平均值作为所述业务请求的业务处理耗时参考值。当然，还可以采取加权的方式，为最近处理的业务请求的处理耗时分配较大的权重，从而能够更好地反映所述业务服务端处理能力的近期变化。

由此可见，与所述业务请求对应的业务处理耗时参考值并不是一个固定不变的值，每当业务服务端处理完一个业务请求，业务网关就应该参考所述业务请求处理耗时的历史信息和本次业务请求的处理耗时，通过计算更新与所述业务请求对应的业务处理耗时参考值。再次接收到所述业务请求时，就可以执行条件3)中的判断，如果当前的业务处理耗时参考值已经达到了预先设置的启用异步处理方式的阈值，则采用异步处理方式处理所述业务请求。关于业务处理耗时参考值的计算，在其他的实施方式中，可以采用不同于上述的其他计算方法，只要能够得到表征所述业务服务端处理能力的参数值即可，具体采用何种计算方法，不是本申请的核心，本申请不作具体限定。

综上所述，判断是否采用异步处理方式的三个条件中，判断条件2)是一种静态判断方式，而判断条件1)和3)则提供了动态调节机制，对于本身处理并不耗时的业务请求(系统未指定采用异步处理方式)，由于客户端网络环境的劣化，或者由于所述业务服务端的处理能力发生变化(负载过度导致处理速度减慢)，也可能采用异步处理方式。因此本申请的技术方案，实现了依据客户端网络环境的动态变化和服务端处理能力的动态变化，动态调整处理模式的功能。

如果经过上述判断步骤，判定所述业务请求需要采取异步处理，则立即向所述客户端发送包含异步处理指示的应答，而不需要等待所述业务服务端返回的处理结果。如果判定结果为，所述业务请求不需要采取异步处理，那么在判断结束后，等待所述业务服务端返回对所述业务请求的应答，并将该应答发送给所述客户端。

至此，发送所述业务请求的客户端已经收到了来自服务端的应答，对于不需要采取异步处理的业务请求来说，已经获取了来自业务服务端的应答，因此本次业务请求处理完毕；而对于需要进行异步处理的业务请求，则也收到了来自业务网关的异步应答，对于只是向所述业务服务端上传数据或者发送命令的业务操作，不需要从所述业务服务器查询信息、获取数据等，从客户端的角度看，因为已经收到应答，也可以认为本次业务请求已经处理完毕，至于所述业务服务端则可以继续处理所述业务请求。从客户端的角度看，整个系统的响应时间大为缩短，减少了客户端用户的无谓等待时间，有效改善用户体验。

考虑到有些采用异步处理方式的业务请求需要在业务服务端执行查询信息、获取数据的操作，而且即使是上传数据或者命令的业务请求，出于整个业务操作完整性的考虑，也需要获取业务服务端处理所述业务请求的执行情况，因此本申请进一步提供了为客户端反馈最终处理结果的技术方案。为了便于客户端获取最终的处理结果，在向所述客户端发送的包含异步处理指示的应答中，所述异步处理指示还可以进一步包含告知客户端获取最终处理结果的建议时间和所需携带的业务标识等信息。请参看图2，其为本申请的向所述客户端发送包含异步处理指示的应答的实施例流程图，该过程包括步骤201-步骤204。

步骤201：根据与所述业务请求对应的业务处理耗时参考值，估算所述业务服务端处理本次业务请求的耗时。

作为最为简单易行的实施方式，可以直接将与所述业务请求对应的业务处理耗时参考值作为所述业务服务端处理本次业务请求的耗时，考虑到所述业务服务端的处理能力当前可能正处于动态变化之中，而业务处理耗时参考值可能是一段时间内或者最近N次的平均值，因此可以参考所述业务服务端历次处理所述业务请求所消耗时间的历史信息，根据最近几次处理耗时的变化趋势，对业务处理耗时参考值进行微调，得到所述业务服务端处理本次业务请求的耗时的估计值。

步骤202：根据估算的所述业务服务端处理本次业务请求的耗时和所述业务请求中携带的网络环境数据，计算所述客户端获取最终处理结果的建议时间。理论上，只要所述业务服务端处理完本次业务请求并将结果发送给所述业务网关，所述客户端就可以执行获取最终处理结果的操作，考虑到将异步应答发送给所述客户端以及客户端发送获取最终处理结果的过程，需要经过网络传输，也会造成一定的时延，特别是在弱网络情况下该时延可能比较长，因此在计算客户端获取最终处理结果的建议时间时，不仅要以估算出的业务服务端处理本次业务请求的耗时为基础，同时要结合所述业务请求中携带的网络环境数据(该数据可以从侧面反映客户端所在网络的传输速度等情况)，进一步估算得出客户端获取最终处理结果的建议时间。

步骤203：为所述业务请求生成唯一标识。所述客户端按照指定的建议时间获取最终处理结果时，需要明确告知需要获取的是哪一个业务请求的最终处理结果，因此，实现本申请方法的业务网关还要为所述业务请求生成一个唯一的标识，以与其他业务请求相区分。唯一业务标识的生成可以采用简单的递增方式，也可以采用具有一定容量的环形空间，来管理业务标识的分配与回收，只要业务网关能够根据该标识区分不同的业务请求、不会造成混淆即可。

步骤204：向所述客户端发送异步处理应答，所述异步处理应答包含上述唯一标识、和获取最终处理结果的建议时间。将在前面步骤中估算出的获取最终处理结果的建议时间和与所述业务请求生成的唯一标识，封装在异步处理应答中，一起发送给所述客户端。

所述客户端收到上述包含异步处理指示的应答后，会在异步处理指示指定的建议时间向所述业务网关发送获取最终处理结果的请求。请参看图3，其为本申请的向客户端提供最终处理结果的实施例流程图，所述业务网关通过以下步骤301-步骤303为所述客户端提供最终处理结果。

步骤301：接收所述业务服务端返回的针对所述业务请求的应答；

在步骤102中已经介绍了，业务网关和业务服务端之间的交互可以采用同步方式，也可以采用异步回调的方式。为了提高服务端的吞吐量，充分利用服务端的资源，本实施例的一个具体例子中采用了异步回调的方式。当所述业务请求被处理完毕，业务网关转发所述业务请求时指定的回调函数会被调用，从而告知业务网关所述业务请求处理完毕并返回处理结果。业务网关采用同步或者异步回调方式获取针对所述业务请求的应答后，应该将该应答中包含的处理结果与所述业务请求的标识(在向所述客户端返回异步应答时生成的该业务请求的唯一标识)一起存储，为所述客户端的后续查询操作做好准备。

步骤302：接收来自所述客户端的获取所述业务请求的最终处理结果的请求。所述客户端按照异步应答中指示的时间向业务网关发送获取最终处理结果的请求，业务网关接收该请求后，识别该请求是正常的业务请求还是获取最终处理结果的请求，如果是前者，则按照前面描述的步骤进行转发以及异步处理判断等，如果是后者，则从该请求中提取业务请求标识，并从已经存储的处理结果中，查找与所述业务请求标识对应的处理结果，该处理结果就是所述客户端需要获取的最终处理结果。

步骤303：将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端。即：将与所述业务请求标识对应的处理结果发送给所述客户端。至此，所述客户端在接收到针对所述业务请求的快速的异步应答之后，进一步获取了该业务请求的最终处理结果。

上面的步骤301-303描述了业务网关为客户端提供最终处理结果的常规流程。在具体的实施过程中，由于业务网关在异步应答中返回给客户端的获取最终处理结果的建议时间是一个参考时间，并不能保证客户端按照所述建议时间一定能够获取最终处理结果。例如：业务服务端的处理耗时突发性地增大，那么业务网关接收来自客户端的获取最终处理结果的请求时，可能还没有接收到所述业务服务端返回的针对所述业务请求的应答，也就是说步骤302会先于步骤301执行。在这种情况下，业务网关可以向客户端返回稍后重试的应答，并在接收到业务服务端返回的针对所述业务请求的应答后，再按照常规方式处理客户端的重新获取最终处理结果的请求。作为一种可选的实施方式，在上述业务服务端应答滞后的情况下，业务网关也可以在接收到业务服务端返回的针对所述业务请求的应答后，将该应答直接推送给客户端，从而可以避免客户端的重复请求操作。

为了进一步优化实施效果，本申请的用于处理业务请求的方法，还提供一种优选实施方式，在业务网关与客户端之间开启HTTP的持久连接功能。HTTP协议本身是基于TCP/IP协议之上的，而TCP作为面向连接的可靠传输协议，其数据连接的建立和释放都要遵循一套严格的交互流程，简单地说，建立一个TCP连接需要源和目的设备之间经历三次握手过程，而释放一个TCP连接则需要源和目的设备之间经历四次交互过程，如果每个HTTP请求和响应过程都使用新的TCP连接，那么就会出现频繁的建立连接和释放连接过程，相关的交互开销甚至可能造成网络拥塞。

为了缓解这一问题，本申请技术方案提供了开启HTTP持久连接功能的优选实施方式，即通常所说的HTTP Keep-Alive功能。启用HTTP Keep-Alive功能，使客户端与服务端的数据连接在较长的一段时间内持续有效，当出现对服务端的后继请求时，可以重复利用已经建立的数据连接，避免频繁的建立和关闭连接，从而减少网络拥塞，提高整个系统的处理效率。虽然启用Keep-Alive功能，可以减少建立和关闭连接的开销，但是因为在处理暂停期间，本来可以释放的资源仍旧被占用(在较长的一段时间内连接都处于保持状态)，因此服务端可能出现需要保持过多连接的情况，有可能导致服务端不堪重负。因此具体的实施过程中，要选择一个比较合适的平衡点，确定一个让数据连接保持有效的比较合理的持续时间，在本实施例的一个具体例子中，设置开启HTTP Keep-Alive支持60s的持久连接功能，在其他实施方式中，可以根据具体的应用场景设置不同的连接保持时间。

为了进一步优化实施效果，实施本申请的技术方案时，还可以采用一次性向客户端返回多次业务请求的业务处理结果的方式。如果接收到的来自客户端的获取最终处理结果的请求中，携带了多个业务请求标识，那么业务网关可以从已经存储的处理结果中，查找与所述多个业务请求标识中的每一个业务请求标识对应的处理结果，并将所有结果一并返回给所述客户端。

采用HTTP持久连接功能、以及将多个异步处理的业务请求的处理结果一次性发送给客户端的方式，不仅可以重复利用客户端和业务网关之间的数据连接，减少用于建立和释放数据连接的开销，同时还能够有效减少数据的传输量，节省网络带宽。

上面介绍的技术方案中，业务网关要根据客户端发送的获取最终处理结果的请求，向所述客户端发送最终处理结果。本申请的技术方案还提供了另外一种方式，即：业务网关主动向客户端推送所述业务请求的最终处理结果。业务网关通过同步或者异步回调方式接收业务服务端针对某个业务请求的处理结果后，不需要在本地存储，也不需要等待客户端发送获取最终处理结果的请求，而是直接将所述业务请求的处理结果发送给对应的客户端。采用这种方式，客户端能够更为及时地获取最终处理结果，同样可以实现本申请的技术方案。

本申请技术方案的核心在于，当客户端主动要求采用异步处理方式，或者业务网关通过静态设置或者动态监测的方式预先判断出业务服务端对当前业务请求的处理可能比较耗时的情况下，业务网关会立刻向发起所述业务请求的客户端返回一个异步应答，从而减少客户端用户的无谓等待时间，有效改善用户体验；另外，从系统的角度看，由于针对大量耗时的HTTP业务请求都采用先快速地返回中间结果，然后再由服务端采用多线程等异步方式处理具体的业务操作，从而使服务端资源得到充分利用，大幅提升服务端的吞吐能力。

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

本实施例的一种用于处理业务请求的装置，包括：业务请求接收单元401，用于接收来自客户端的业务请求；业务请求转发单元402，用于将接收的业务请求转发到处理所述业务请求的业务服务端；业务请求处理单元403，用于判断是否需要针对所述业务请求进行异步处理；若是，向所述客户端发送包含异步处理指示的应答；若否，将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端。

可选的，如果所述业务请求处理单元判定需要针对所述业务请求进行异步处理，所述装置还包括：

应答接收单元，用于接收所述业务服务端返回的针对所述业务请求的应答；

获取结果请求接收单元，用于接收来自所述客户端的获取所述业务请求的最终处理结果的请求；

结果发送单元，用于将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端。

可选的，所述业务请求处理单元所发送的应答中的异步处理指示包含，所述业务请求的唯一标识和获取所述业务请求的最终处理结果的建议时间。

可选的，所述装置包括：

耗时信息记录单元，用于记录所述业务服务端历次处理业务请求所消耗时间的历史信息；

耗时参考值计算单元，用于根据所述历史信息计算与所述业务请求对应的业务处理耗时参考值。

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

异步处理判断子单元，用于判断是否需要针对所述业务请求进行异步处理；

异步应答发送子单元，用于当所述异步处理判断子单元的输出为“是”时，向所述客户端发送包含异步处理指示的应答；

同步应答发送子单元，用于当所述异步处理判断子单元的输出为“否”时，将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端。

其中，所述异步处理判断子单元具体用于执行以下判断：

可选的，所述异步应答发送子单元包括：

处理耗时估算子单元，用于根据与所述业务请求对应的业务处理耗时参考值，估算所述业务服务端处理本次业务请求的耗时；

建议时间计算子单元，用于根据估算的所述业务服务端处理本次业务请求的耗时和所述业务请求中携带的网络环境数据，计算所述客户端获取最终处理结果的建议时间；

业务请求标识生成子单元，用于为所述业务请求生成唯一标识；

发送执行子单元，用于向所述客户端发送包含上述唯一标识和获取最终处理结果的建议时间的异步处理应答。

可选的，所述装置包括：

持久连接开启单元，开启与所述客户端之间的持久连接功能。

可选的，所述装置包括：

应答推送单元，用于将所述业务请求的应答推送给所述客户端。

与上述的用于处理业务请求的方法相对应，本申请还提供一种用于获取业务处理结果的方法。请参考图5，其为本申请提供的一种用于获取业务处理结果的方法的实施例的流程示意图，本实施例与第一实施例内容相同的部分不再赘述，请参见实施例一中的相应部分。本申请提供的一种用于获取业务处理结果的方法包括：

步骤501：向业务网关发送业务请求。

本申请提供的用于获取业务处理结果的方法，与本申请提供的用于处理业务请求的方法(请参见实施例一的描述)相互配合，在业务请求响应耗时长的情况下，采用提前向客户端返回异步应答的方式改善客户端用户的体验。其中业务请求响应耗时长可能是多方面原因造成的，例如：业务服务端繁忙，或者客户端与服务端之间的网络传输质量差等因素。为了使业务网关能够进行有针对性地判断和处理，客户端需要识别其所在网络的网络环境并生成网络环境数据，并在发送给业务网关的业务请求中携带相关信息。该过程涉及以下四个步骤：

1)识别当前所用网络的网络类型、网络制式和/或信号强度。

首先识别当前客户端使用的网络类型是蜂窝移动网络(即：通常所说的2G或者3G等移动通讯网络)还是无线局域网(即：通常所说的WIFI)，可以通过调用操作系统提供的类库或者接口函数进行判断，例如在ios系统下，可以调用Reachability类中的函数获取当前使用的网络类型是ReachableViaWiFi、或者ReachableViaWWAN；也可以通过调用getifaddrs()函数来判断当前使用的网络接口是否为WIFI。

如果当前网络类型不是WIFI，而是蜂窝移动网络，则可以进一步识别客户端当前所用网络的网络制式和信号强度，主要是通过调用客户端操作系统提供的相关类库或者函数接口来实现，不同的系统提供的类库或者函数接口可能不同，以安卓(android)系统为例，可以通过调用TelephonyManager类提供的getNetworkType()函数获取当前的网络制式，其调用方式的示意代码如下所示：

TelephonyManagertelephoneManager＝(TelephonyManager)getSystemService

(Context.TELEPHONY_SERVICE)；

int type＝telephoneManager.getNetworkType()；

执行上述函数调用后，就可以通过对type变量值的解读获取当前的网络制式。常用取值代表的网络制式如下所示：

type值代表的网络制式	type值	代表的网络制式
			1NETWORK_TYPE_GPRS	7	NETWORK_TYPE_1xRTT
2NETWORK_TYPE_EDGE	8	NETWORK_TYPE_HSDPA
			3NETWORK_TYPE_UMTS	9	NETWORK_TYPE_HSUPA
4NETWORK_TYPE_CDMA	10	NETWORK_TYPE_HSPA
			5NETWORK_TYPE_EVDO_0	11	NETWORK_TYPE_IDEN
6NETWORK_TYPE_EVDO_A	12	NETWORK_TYPE_EVDO_B

进一步还可以获取网络信号的强度，还是以安卓系统为例，通过TelephonyManager类提供的getGsmSignalStrength()函数可以获取信号强度，该类还提供了获取网络信号相关信息的其它函数，具体实施时可以根据需要调用。需要注意的是，在安卓系统下执行获取信强度的操作，需要先添加相应的权限，如下所示：

<uses-permissionandroid:name＝"android.permission.CHANGE_NEWWORK_STATE"/>

如果将本申请的技术方案应用在采用双绞线、同轴电缆或者是光纤等有线传输介质访问服务端的客户端设备，例如：桌面PC等，那么就可以略去本步骤的识别操作，直接执行步骤2)的网速测试即可。

2)测试当前所用网络的网络传输速度。

如果当前使用的是有线传输介质，或者通过步骤1)检测到当前使用的是WIFI、3G、或4G移动网络(缺省认为2G网络的网络传输速度和传输质量都是比较差的，因此不需要再进行网速测试)，则需要进一步进行网络传输速度的测试。本申请所述的网络传输速度是一个相对宽泛的概念，并不是指严格意义上的每秒钟传输多少比特或者字节的数据，而是指通过一些网络测试手段，获取当前网络的连通性、丢包率、往返时间等表征当前网络传输速度和质量的数值，这些数值可以从侧面反映当前网络环境的基本情况。

在具体实施过程中，可以采用ping命令进行网络速度测试，例如，以业务网关作为目的主机发送ping命令，并根据该命令的返回信息统计丢包率、路由跳数、以及往返时间RTT(round trip time)等，其中，RTT是计算机网络中的一个重要性能指标，它表示从发送端发送数据开始，到发送端接收到来自接收端的确认，总共经历的时延。如果在多次的测试中，发现RTT变化很大(即：存在明显的抖动现象)，通常说明与目的设备之间的连接状况不稳定。此外，还可以采用HTTP的调用测试，检查无业务情况下完成一次HTTP的请求、应答过程所需要的往返时间(简称rt时间)。上述用于进行网络速度测试的操作都是后台异步操作。

3)根据上述步骤获取的信息生成所述网络环境数据。

获取了网络类型、制式、信号强度、以及进行了网络速度测试后，就可以根据获取的数据生成反映网络状况的网络环境数据。例如，因为上述数据的取值范围都是不同的，可以先进行归一化处理，然后为不同的参数设置不同的权重，并按照权重进行求和，或者设置一种映射规则，如果上述参数满足规则中的某一项，则采用与该项规则对应的值作为当前的网络环境数据。具体采用何种算法生成网络环境数据不是本申请的核心，不同的实施方式可以采用不同的算法，只要能够反映当前网络环境的状况就可以了。

4)根据业务请求从发起到返回最终处理结果的时间，修订所述网络环境数据。

采用上述步骤生成的网络环境数据仅仅表征了在未承载业务的情况下测试得到的网络状况，该数据具有一定的参考价值，但是并不完善。在本申请的技术方案中，采用了记录HTTP业务请求从发起到返回的往返时间、并用该时间修订所述网络环境数据的方式，从而使得网络环境数据不仅能够反映网络质量，同时也反映特定业务场景的处理耗时情况，是上述两方面信息的综合体现。因此客户端在完成原有的发送HTTP请求、接收HTTP应答的流程中，还需要完成以下功能：

a)记录向业务网关发送业务请求的起始时间；

b)记录获取所述业务请求的最终处理结果的终止时间；

c)计算所述终止时间和所述起始之间的差值，作为本次业务请求处理过程的往返时间；

d)根据所述往返时间修订所述网络环境数据。

在具体实施的过程中，上述功能的实现同样可以采用AOP技术，具体说明请参见实施例一中的相关说明，此处不再赘述。至于如何根据所述往返时间修订所述网络环境数据，不同的实施方式可以采用不同的方法，例如：计算步骤3)生成的网络环境数据与所述往返时间的平均值，或者根据当前系统的具体情况，为这两个数据分配不同的权重，然后计算加权平均值。本实施例采用了先根据步骤1)和2)生成网络环境数据，然后再根据每次业务请求的往返时间对所述网络环境数据进行修订的方式，在其他实施方式中，也可以直接根据步骤1)和2)获取的网络数据以及每次业务请求的往返时间，直接计算得出网络环境数据。上述都是具体实施方式的变更，都不偏离本申请的核心，都在本申请的保护范围之内。

由于每种业务请求涉及的业务操作的处理复杂程度不同(例如：下单请求的处理耗时较长，而查询购物车请求的处理耗时相对较短)，因此每种业务请求的往返时间也会有比较大的差别，如果针对所有的业务请求都使用同一个网络环境数据，无法很好地反映不同业务操作的差别。作为一种比较理想的处理方式，应该为每一种业务请求计算对应的网络环境数据，这样才能为服务端提供更为准确的信息。

通过上面几个方面的操作，获取了网络环境数据。其中步骤1)、2)、3)涉及的操作并不需要反复执行，因为通常网络环境的变化不会很频繁，因此只需要在客户端启动的时候执行一次，如果客户端后续通过后台监听等方式发现网络环境发生比较大的变化后，可以再触发进行相关的识别或测试操作。而4)中涉及的操作则是伴随着每次HTTP业务请求的发起和结束都要进行的，是对网络环境数据不断修订的过程。

上面介绍了网络环境数据的生成和修订过程，客户端之所以要执行这部分操作，是为了向业务网关提供该数据，为业务网关在判断是否需要采用异步处理方式、以及计算获取最终处理结果的建议时间时提供必要的参考。也就是说，为了实现本申请的技术方案，为客户端提供异步响应机制，需要业务网关和客户端的相互配合、共同实现。因此，客户端在向业务网关发送业务请求时，需要携带与所述业务请求对应的网络环境数据。在本实施例的一个具体例子中，网络环境数据是根据网络制式等参数、网速测试得到的数据、以及业务请求往返时间计算得出的一个具体数值，在其他实施方式中，可以将上述反映网络状况的各个数据作为一组参数发送给所述业务网关，这样做便于业务网关对客户端的网络环境做出更为准确的判断，但是相应的也会增加每次发送业务请求的数据传输量，占用更多的带宽。因此在具体的实施过程中，可以综合考虑上述方式，选择合适的上传网络环境数据的方式。

此外，客户端发送的业务请求中不仅需要携带网络环境数据，还可以在当前网络是弱网络的情况下携带要求业务网关采用异步处理方式的标识。之所以携带该标识，出于如下考虑：如果客户端当前所用的网络是弱网络，那么传输速度和传输质量相对都比较差，客户端和服务端之间的数据传输和处理的延时会比较长(例如：数秒)而且还有可能发生连接断开的现象，因此在这种情况下客户端采用携带异步处理标识的方式建议业务网关采用异步处理方式，从而避免客户端用户的长时间等待，业务网关一侧接收该业务请求后，发现所述业务请求携带了请求异步处理的标识，则可以直接针对所述业务请求返回异步应答，然后再进行后续的处理。

关于弱网络的判定，客户端可以采用不同的策略，在本实施例的一个具体例子中，采用根据网络环境数据判断是否为弱网络的方式，因为网络环境数据能够综合反映网络速率、传输质量、以及业务请求往返时间等因素，因此可以为弱网络的判定设定一个阈值或者范围，如果当前的网络环境数据的值达到该阈值或者属于该范围，就判定当前网络是弱网络。在其他实施方式中，也可以采用其他判定规则，例如：直接根据网络制式判断，如果网络制式属于2G移动网络，则认为当前网络是弱网络；当然也可以采用网络制式与丢包率或者其他参数相结合的判定方法。

步骤502：接收来自所述业务网关的对所述业务请求的应答。

执行上述步骤501后，发送了携带网络环境数据(在弱网络下还携带异步处理标识)的业务请求后，由于采用了本申请的技术方案，通常在很短的时间内就会接收来自所述业务网关的应答。该应答可能就是针对所述业务请求的最终处理结果，也可能是业务网关提前返回的异步应答，执行下述步骤503作进一步的判断。

步骤503：判断所述应答是否包含异步处理指示；若是，根据所述应答包含的异步处理指示向所述业务网关获取所述业务请求的最终处理结果；若否，则所述应答即为所述业务请求的最终处理结果。

如果所述应答中不包含异步处理指示，则说明当前应答就是所述业务请求的最终处理结果，那么对于当前的业务请求来说，本次的请求响应过程就完成了。下面针对所述应答包含异步处理指示的情况，详细描述本申请技术方案的处理过程：

1)判断所述应答是否包含异步处理指示。

所述异步处理指示包括：该应答对应的业务请求的标识、以及获取该业务请求的最终处理结果的建议时间。如果客户端在接收的应答中检测到上述信息，则说明当前应答并不是所述业务请求的最终处理结果，而是异步应答，这时应该将业务请求的标识以及建议时间都存储下来，以便后续根据客户端的获取请求提供该业务请求的最终处理结果。当然异步处理指示还可以包括一个明确的指示标识，例如：1代表包含异步处理指示，0代表不包含异步处理指示，客户端检测到上述指示标识为1的情况下再去进一步读取业务请求标识和建议时间，这种实施方式也是可以的。

2)优化与客户端用户的交互。

如果客户端经过上述判断，发现应答中包含异步处理指示，对于采用后台方式处理的业务，可以不执行额外的操作，对于在前台并且需要同步实时展示处理结果的业务请求，为了改善用户体验，可以执行下述操作：提示发起所述业务请求的用户当前正在处理业务请求，并为所述用户提供获取所述业务请求最终处理结果的接口(例如：显示在触摸屏上的按钮等)，或者，告知所述用户过一段时间再返回查看本次业务请求的最终处理结果。

采用上述处理方式，提前告知了用户当前正在执行业务处理，避免用户在没有任何信息提示的情况下作无谓的等待。同时，主动为用户提供查询业务处理最终结果的接口，避免用户在等待过程中重复发起业务请求，给服务端带来额外的压力；也可以提示用户不等待，而是去执行其他的操作，过一段时间后再返回当前界面查看最终处理结果。采用本申请的技术方案，由于及时、快速地向用户反馈了当前业务请求的处理情况，并且为用户提供了多样化的选择，从而让用户摆脱了只能看着转动的菊花、长时间等待的无奈状况。

3)获取所述业务请求的最终处理结果。

虽然接收到了来自业务网关的异步应答，并且及时对用户作出了提示，但是毕竟没有获取所述业务请求的最终处理结果，对于类似查询信息之类的业务请求，获取最终处理结果对用户来说也是必须的。因此本申请的技术方案进一步提供了获取所述业务请求的最终处理结果的步骤，该步骤的执行，可以由用户操作客户端界面显示的查询最终处理结果的接口(例如：点击触摸屏上的相应按钮)来触发，也可以由客户端检测到异步应答中指定的建议时间时自动触发，基本处理过程如下：

客户端向所述业务网关发送获取最终处理结果的请求，该请求中必须携带所需获取最终处理结果的业务请求的标识，该标识是由业务网关分配、并且包含在异步应答的异步处理指示中下发给客户端的。业务网关根据该业务请求标识，查找对应的最终处理结果，并向客户端反馈该处理结果，相应的，客户端就接收到了与所述业务请求标识对应的最终处理结果。

4)根据需要显示最终处理结果。

获取所述业务请求的最终处理结果后，如果所述业务请求涉及的是后台处理的业务，则不需要在当前界面上显示，如果需要同步实时展示业务处理结果，则在当前界面上显示已经获取的最终处理结果，以便于用户及时获取所需信息。至此，一个业务处理响应时间比较长的业务请求就通过本申请提供的异步处理方式处理完毕了。

考虑到业务网关在异步应答中返回的获取最终处理结果的建议时间是一个参考时间，该建议时间不能保证客户端获取最终处理结果的请求能够一次成功，例如：业务服务端的处理耗时突发性地增大，那么业务网关接收到客户端的获取最终处理结果的请求时，与该请求对应的处理结果可能还没有从业务服务端返回到业务网关，导致本次客户端获取操作失败。为了解决这一问题，本申请的技术方案提供了重试机制，具体说明如下：客户端发送获取最终处理结果的请求后，如果业务网关没能提供最终处理结果，这种情况下客户端可以再次发送获取最终处理结果的请求......如果客户端执行获取最终处理结果步骤的次数，达到或者超过了预先设定的值，仍然未获取所述业务请求的最终处理结果，则可以认为本次业务请求失败，客户端可以转到步骤301，重新向业务网关发送所述业务请求。

同上面的处理类似，如果客户端获取了所述业务请求的最终处理结果，但是该处理结果为本次业务请求处理失败，那么也转到步骤301，重新向业务网关发送所述业务请求。

为了进一步改善用户体验，在执行向业务网关发送业务请求的步骤之前，可以向提出所述业务请求的应用程序返回成功应答。具体地说，如果用户的业务请求，不需要实时的展示执行结果，或者在离线情况下仍可进行(如添加宝贝到购物车，在离线时也可以添加成功)，那么可以直接向提出所述业务请求的应用程序返回业务请求处理成功的应答，从而用户可以继续进行其他的操作，而客户端则可以在后台采用本申请的技术方案，采用异步处理方式更新服务端的数据。采用这种处理方式，即使网络已经处于离线状态(例如：基站切换、过山洞、WIFI与3G切换等)，也可以在连接网络后再提交数据，并获取请求的结果，既保证用户体验非常流畅，同时也使服务端资源得到充分利用。

为了减少数据的传输量，节省网络带宽，本申请的技术方案还提供了一种优选实施方式：客户端可以向业务网关发送一次性获取多个最终处理结果的请求，即，在所述请求中携带多个希望获取最终处理结果的业务请求的标识。相应的，业务网关要能够识别一次性获取多个最终处理结果的请求，并根据该请求中携带的多个业务请求标识，分别查找与之对应的、已经接收到的最终处理结果，并将已经收到的多个处理结果一次性发送给客户端。客户端仅通过一次收发过程就获取了多个业务请求的最终处理结果，从而减少了数据的传输量，提高了客户端的处理效率。

采用本申请的用于获取业务处理结果的方法，一方面在弱网络情况下主动要求业务网关采用异步处理方式，另一方面在接收到包含异步处理指示的应答后，优化与客户端用户之间的交互界面，为用户提供多种选择，并根据用户的选择或者按照业务网关的建议时间再进一步获取业务请求的最终处理结果。从而在业务服务端处理耗时长或者弱网络的情况下，减少客户端用户的无谓等待时间，在需要实时同步展示业务处理结果的场景下，可以改善用户体验，在非实时的场景下，则可以直接采用后台操作处理的方式，使用户的体验更为流畅。

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

本实施例的一种用于获取业务处理结果的装置，包括：业务请求发送单元601，用于向业务网关发送业务请求；业务应答接收单元602，用于接收来自所述业务网关的对所述业务请求的应答；业务应答处理单元603，用于判断所述应答是否包含异步处理指示；若是，根据所述应答包含的异步处理指示向所述业务网关获取所述业务请求的最终处理结果；若否，则所述应答即为所述业务请求的最终处理结果。

可选的，所述装置包括：

网络环境数据获取单元，用于获取网络环境数据；

相应的，所述业务请求发送单元发送的业务请求中包含所述网络环境数据。

可选的，所述网络环境数据获取单元包括：

网络参数识别子单元，用于识别当前所用网络的网络类型、网络制式和/或信号强度；

网络速度测试子单元，用于测试当前所用网络的网络传输速度；

网络环境数据生成子单元，用于根据所述网络参数识别子单元和所述网络速度测试子单元获取的信息生成所述网络环境数据。

可选的，所述装置包括：

弱网络判断单元，用于根据所述获取的网络环境数据，判断当前所用网络是否为弱网络；

相应的，当所述弱网络判断单元的输出为“是”时，所述业务请求发送单元发送业务请求时携带请求异步处理的标识。

可选的，所述装置包括：

起始时间记录单元，用于记录向所述业务网关发送所述业务请求的起始时间；

终止时间记录单元，用于记录获取所述业务请求的最终处理结果的终止时间；

往返时间计算单元，用于计算所述终止时间和所述起始之间的差值，作为本次业务请求处理过程的往返时间；

数据修订单元，用于根据所述往返时间修订所述网络环境数据。

可选的，所述业务应答处理单元包括：

异步应答判断子单元，用于判断所述应答是否包含异步处理指示；

处理结果获取子单元，用于当所述异步应答判断子单元的输出为“是”时，根据所述应答包含的异步处理指示向所述业务网关获取所述业务请求的最终处理结果。

其中，处理结果获取子单元包括：

处理结果请求子单元，用于根据所述异步处理指示包含的获取最终处理结果的建议时间，向所述业务网关发送获取与所述异步处理指示包含的业务请求标识对应的最终处理结果的请求；

处理结果接收子单元，用于接收所述业务网关返回的与所述业务请求标识对应的最终处理结果。

可选的，所述装置包括：

成功应答返回单元，用于在触发所述业务请求发送单元向业务网关发送业务请求之前，向提出所述业务请求的应用程序返回成功应答。

可选的，所述装置包括：

用户提示单元，用于当所述异步应答判断子单元的输出为“是”时，提示发起所述业务请求的用户当前正在处理业务请求；

选择提供单元，用于当所述异步应答判断子单元的输出为“是”时，为所述用户提供获取所述业务请求最终处理结果的接口，或者，告知所述用户过一段时间再返回查看本次业务请求的最终处理结果。

可选的，所述装置包括：

执行控制单元，用于监控执行所述获取最终处理结果步骤的次数，当所述次数达到或者超过了预先设定的值，仍然未获取所述业务请求的最终处理结果，则触发所述业务请求发送单元。

可选的，所述装置包括：

失败处理单元，用于当所述业务请求的最终处理结果为，本次业务请求失败时，触发所述业务请求发送单元。

可选的，所述装置包括：

处理结果显示单元，用于获取所述业务请求的最终处理结果后，显示所述最终处理结果。

可选的，所述处理结果获取子单元包括：

批量获取请求单元，用于向所述业务网关发送一次性获取与多个业务请求标识对应的最终处理结果的请求；

批量结果接收单元，用于接收所述业务网关返回的与所述多个业务请求标识对应的多个最终处理结果。

本申请实施例还提供了一种用于处理业务请求的系统，如图7所示，该系统包括上述实施例所述的用于获取业务处理结果的装置701和用于处理业务请求的装置702，以及负责处理业务请求的业务服务端703。所述用于获取业务处理结果的装置可以部署于移动通讯设备、个人电脑、PAD、iPad等多种终端设备，通常称为客户端，所述用于处理业务请求的装置通常部署于服务器，例如：业务网关服务器，但并不局限于服务器，也可以是能够实现所述用于处理业务请求的方法的任何设备。

下面结合附图8说明所述用于处理业务请求的系统的异步处理过程的基本流程。以用于获取业务处理结果的装置部署在智能手机客户端、所述用于处理业务请求的装置部署于业务网关服务器为例：客户端自动识别网络状况，判断当前网络是否为弱网络，如果是弱网络，那么客户端发起需要业务服务端处理的业务请求时会携带异步处理请求标识，业务网关服务器将接收到的业务请求转发给处理该请求的业务服务端，并且判断是否需要针对所述业务请求采用异步处理方式，对于处理耗时较长或者携带了异步处理请求标识的业务请求，业务网关采用异步处理方式，在计算出获取最终处理结果的建议时间后，立刻向所述客户端返回包含所述建议时间的异步应答，客户端接收异步应答后会通过告知用户业务请求正在处理中等方式优化与用户的交互，并按照异步应答中包含的建议时间向业务网关服务器获取所述业务请求的最终处理结果。

本申请提供的用于处理业务请求的系统，没有采用传统B/S结构的服务端处理完毕后再响应最终结果给用户的串行模式，而是通过客户端与业务网关的交互配合，在业务网关将所述业务请求转发给业务服务端的同时，判断客户端的业务请求是否需要进行异步处理，从而在业务处理耗时长或者弱网络等情况下，能够提前向所述客户端返回异步应答，不仅减少了客户端用户的无谓等待时间，有效改善用户体验；同时由于采用了异步处理机制，使服务端资源得到充分利用，提升服务端的性能与吞吐能力。

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

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

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

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

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

Claims

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

接收来自客户端的业务请求；

将接收的业务请求转发到处理所述业务请求的业务服务端；

判断是否需要针对所述业务请求进行异步处理；若是，向所述客户端发送包含异步处理指示的应答；若否，将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端；所述异步处理指示包含所述业务请求的唯一标识和获取所述业务请求的最终处理结果的建议时间；所述建议时间根据所述业务请求对应的业务处理耗时参考值和所述业务请求中携带的网络环境数据得到；

所述业务请求的业务处理耗时参考值通过下述方式获得：

从历史信息中，提取所述业务请求的最近预设次数的处理耗时，并计算所述最近预设次数的处理耗时的平均值，所述平均值即为所述业务请求的业务处理耗时参考值；或者，

从历史信息中，提取所述业务请求在最近半分钟或者一分钟之内的处理耗时，并将这段时间内的处理耗时的平均值作为所述业务请求的业务处理耗时参考值。

2.根据权利要求1所述的用于处理业务请求的方法，其特征在于，如果所述判断是否需要针对所述业务请求进行异步处理的判断结果为“是”，则所述方法包括：

接收所述业务服务端返回的针对所述业务请求的应答；

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

4.根据权利要求3所述的用于处理业务请求的方法，其特征在于，所述判断是否需要针对所述业务请求进行异步处理，包括：

5.根据权利要求4所述的用于处理业务请求的方法，其特征在于，所述向所述客户端发送包含异步处理指示的应答，包括：

为所述业务请求生成唯一标识；

6.根据权利要求1-5任意一项所述的用于处理业务请求的方法，其特征在于，包括：

开启与所述客户端之间的持久连接功能。

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

接收所述业务服务端返回的针对所述业务请求的应答；

将所述业务请求的应答推送给所述客户端。

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

业务请求接收单元，用于接收来自客户端的业务请求；

业务请求处理单元，用于判断是否需要针对所述业务请求进行异步处理；若是，向所述客户端发送包含异步处理指示的应答；若否，将所述业务服务端返回的针对所述业务请求的应答发送给所述客户端；所述异步处理指示包含所述业务请求的唯一标识和获取所述业务请求的最终处理结果的建议时间；所述建议时间根据所述业务请求对应的业务处理耗时参考值和所述业务请求中携带的网络环境数据得到；

所述业务请求的业务处理耗时参考值通过下述方式获得：

9.一种用于获取业务处理结果的方法，其特征在于，包括：

获取网络环境数据；

向业务网关发送业务请求；在向所述业务网关发送的业务请求中包含所述网络环境数据；

若是，向所述业务网关发送业务请求时携带请求异步处理的标识；

接收来自所述业务网关的对所述业务请求的应答；

10.根据权利要求9所述的用于获取业务处理结果的方法，其特征在于，包括：

获取网络环境数据；

11.根据权利要求10所述的用于获取业务处理结果的方法，其特征在于，所述获取网络环境数据，包括：

识别当前所用网络的网络类型、网络制式和/或信号强度；

测试当前所用网络的网络传输速度；

根据上述步骤获取的信息生成所述网络环境数据。

12.根据权利要求10-11任意一项所述的用于获取业务处理结果的方法，其特征在于，包括：

记录向所述业务网关发送所述业务请求的起始时间；

记录获取所述业务请求的最终处理结果的终止时间；

根据所述往返时间修订所述网络环境数据。

13.根据权利要求9所述的用于获取业务处理结果的方法，其特征在于，所述根据所述应答包含的异步处理指示向所述业务网关获取所述业务请求的最终处理结果，包括：

14.根据权利要求9所述的用于获取业务处理结果的方法，其特征在于，在执行所述向业务网关发送业务请求的步骤之前，向提出所述业务请求的应用程序返回成功应答。

15.根据权利要求9所述的用于获取业务处理结果的方法，其特征在于，如果接收到的来自所述业务网关的对所述业务请求的应答中包含异步处理指示，则执行下述操作：

提示发起所述业务请求的用户当前正在处理业务请求；

16.根据权利要求9所述的用于获取业务处理结果的方法，其特征在于，如果执行所述获取最终处理结果步骤的次数，达到或者超过了预先设定的值，仍然未获取所述业务请求的最终处理结果，则转到向所述业务网关发送业务请求的步骤执行。

17.根据权利要求9所述的用于获取业务处理结果的方法，其特征在于，如果所述业务请求的最终处理结果为，本次业务请求失败，则转到所述向业务网关发送业务请求的步骤执行。

18.根据权利要求9所述的用于获取业务处理结果的方法，其特征在于，包括：

19.根据权利要求9所述的用于获取业务处理结果的方法，其特征在于，所述根据所述应答包含的异步处理指示向所述业务网关获取所述业务请求的最终处理结果，包括：

20.一种用于获取业务处理结果的装置，其特征在于，包括：

网络环境数据获取单元，用于获取网络环境数据；

相应的，所述业务请求发送单元发送的业务请求中包含所述网络环境数据；

业务请求发送单元，用于向业务网关发送业务请求；在向所述业务网关发送的业务请求中包含所述网络环境数据；

相应的，当所述弱网络判断单元的输出为“是”时，所述业务请求发送单元发送业务请求时携带请求异步处理的标识；

21.一种用于处理业务请求的系统，其特征在于，包括：根据上述权利要求8所述的用于处理业务请求的装置；和

根据权利要求20所述的用于获取业务处理结果的装置；以及

负责处理业务请求的业务服务端。