CN104980468A - 处理业务请求的方法、装置及系统 - Google Patents

Abstract

本发明提供了一种处理业务请求的方法，包括：接收上传的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点；否则，对所述业务请求进行排队处理。此外，还提供了一种处理业务请求的装置、系统。上述处理业务请求的方法和装置能够降低用户的平均等待时间。

Description

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

技术领域

本发明涉及计算机技术领域，特别是涉及一种处理业务请求的方法、装置及系统。

背景技术

现有一些大型的网站或互联网应用通常会面临访问流量突发性增长的情况，例如春运期间的火车票预购网站、降价促销活动中的电子商务网站、新开的游戏业务节点等。为了应对这种访问流量突发性增长的情况，网站或互联网应用的业务节点通常引入排队机制，在并发情况下按照接收的先后顺序仅批量处理较少的业务请求，而将后续接收的业务请求置于等待队列中，使得业务节点不会因为并发请求数太多而崩溃。

传统技术中通常由处理业务的应用服务器实现排队过程，应用服务器将许多非性能瓶颈的业务和性能瓶颈业务绑定在一起，用户只有排队进入系统后才能进行操作，且可能需要完成多个非性能瓶颈的业务和性能瓶颈业务之后才能完成业务流程，而仍在排队的用户则需要等待该用户完成整个业务流程之后才能进入系统，使得用户平均排队等待时间较长。

发明内容

基于此，有必要提供一种能够降低用户的排队等待时间的处理业务请求的方法。

一种处理业务请求的方法，包括：

接收上传的业务请求，提取所述业务请求的资源定位符；

获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；

判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点；否则，对所述业务请求进行排队处理。

此外，有必要提供一种能够降低用户的排队等待时间的处理业务请求的装置。

一种处理业务请求的装置，包括：

请求接收模块，用于接收上传的业务请求，提取所述业务请求的资源定位符；

业务分类模块，用于获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；

请求转发模块，用于在所述连接数小于所述连接数限额时，将所述业务请求转发给与所述业务标识对应的业务节点；

请求排队模块，用于在所述连接数大于或等于所述连接数限额时，对所述业务请求进行排队处理。

此外，还有必要提供一种能够降低用户的排队等待时间的处理业务请求的方法。

一种处理业务请求的方法，包括：

反向代理节点接收终端发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取所述业务标识对应的连接数及相应的连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点；

所述业务节点接收转发的业务请求，对其进行处理，生成相应的响应数据，并通过所述反向代理节点将所述响应数据返回给所述终端。

此外，有必要提供一种能够降低用户的排队等待时间的处理业务请求的系统。

一种处理业务请求的系统，包括反向代理节点和业务节点，其中：

反向代理节点用于接收终端发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取所述业务标识对应的连接数及相应的连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点；

所述业务节点用于接收转发的业务请求，对其进行处理，生成相应的响应数据，并通过所述反向代理节点将所述响应数据返回给所述终端。

此外，有必要提供一种能够降低用户的排队等待时间的处理网购业务请求的方法。

一种处理网购业务请求的方法，包括：

反向代理节点接收终端发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点，且所述业务标识包括商品展示业务、用户信息查询业务、订单生成业务和支付业务；

所述业务节点接收转发的业务请求，对其进行处理，生成相应的响应页面，并通过所述反向代理节点将所述响应数据返回给所述终端，且所述响应页面包含与业务标识对应的链接地址；

所述终端检测所述响应页面上与所述链接地址对应的触发指令，生成相应的业务请求，并将其发送给所述反向代理节点。

此外，有必要提供一种能够降低用户的排队等待时间的处理网购业务请求的系统。

一种处理网购业务请求的系统，包括：

反向代理节点接收终端发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点，且所述业务标识包括商品展示业务、用户信息查询业务、订单生成业务和支付业务；

所述业务节点接收转发的业务请求，对其进行处理，生成相应的响应页面，并通过所述反向代理节点将所述响应数据返回给所述终端，且所述响应页面包含与业务标识对应的链接地址；

所述终端检测所述响应页面上与所述链接地址对应的触发指令，生成相应的业务请求，并将其发送给所述反向代理节点。

上述处理业务请求的方法、装置及系统中，对互联网应用的业务进行了划分，将瓶颈业务与非瓶颈业务分离，且通过资源定位符分别与业务请求对应。用户在瓶颈业务对应的业务节点上的排队等待仍然能保证处理瓶颈业务的服务器实体不会有较大的负载压力，从而不会造成整个服务器卡顿或瘫痪。而且，部分用户在瓶颈业务上进行业务操作时，其他用户可同时在非瓶颈业务上进行业务操作，使得后续的用户无需等待进入系统的用户处理完所有业务流程后才能进入系统，从而降低了用户平均排队等待的时间。

同时，将对业务请求进行排队处理的功能设置在反向代理节点处而不是传统技术的应用服务器上，使得在具体处理业务的业务节点负载压力较大时，不会影响到反向代理节点的响应速度，反向代理节点的并发数较高时，也不会影响到业务节点处理业务请求的效率，从而提高了系统的可靠性。

附图说明

图1为传统技术中具有排队机制的应用服务器处理业务请求的过程示意图；

图2为一个实施例中处理业务请求的系统的拓扑架构图；

图3为一个实施例中反向代理节点排队过程示意图；

图4为一个实施例中处理业务请求的方法的流程图；

图5为一个实施例中处理业务请求的方法的时序图；

图6为一个实施例中包含会话同步节点的处理业务请求的方法的时序图；

图7为一个实施例中处理网购业务请求的方法的时序图；

图8为一个实施例中处理网购业务请求时的排队过程示意图；

图9为一个实施例中抢购业务涉及的多个节点的数据交互图；

图10为一个实施例中抢购业务多个环节限流过程的示意图；

图11为一个实施例中抢购业务中用户终端上显示的排队状态的界面图；

图12为一个实施例中抢购业务中用户终端上显示的排队状态的界面图；

图13为一个实施例中处理业务请求的装置的结构示意图；

图14为一个实施例中处理业务请求的方法的流程图；

图15为一个实施例中处理网购业务请求的方法的流程图；

图16为一个实施例中运行处理网购业务请求的方法的服务器硬件环境示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

传统技术中，如图1所示，排队系统由应用服务器实现，应用服务器不仅要对终端发起的业务请求进行处理，还要维护整个排队系统（如图1所示，通常需不仅需要维护排队处理的等待队列，还需要管理执行具体业务逻辑来处理业务请求的执行队列）。使得在高并发环境下，特别是在突发性的例如电子商务中的抢购商品或春运期间订车票的应用场景中，应用服务器在耗费大量计算资源处理业务请求的时，无法分配更多的计算资源来对排队系统进行维护（如图1中，应用服务器会将大量的计算资源用在业务处理算法和业务处理接口的调用上，而对于排队系统的维护和调度则无法分配足够的计算资源），从而造成了用户在上述应用场景中获得较慢的系统响应，甚至会造成应用服务器的崩溃，因此可靠性不足。

而且，用户只有排队进入系统后才能进行操作，且为了保证用户进行业务操作的完整性，可能需要完成多个非性能瓶颈的业务和性能瓶颈业务之后才能完成业务流程，而仍在排队的用户则需要等待该用户完成整个业务流程之后才能进入系统，使得用户平均排队等待时间较长。

在本实施例中，为了解决上述问题，特提出了一种处理业务请求的方法。该方法可依赖于计算机程序，能够运行于基于冯洛伊曼体系的计算机系统上。该计算机系统可以是服务器网关设备或反向代理服务器。

如图2所示，本方法即可运行于图2中的反向代理节点10上，该反向代理节点可以是基于nginx框架的服务器，也可以基于其他具备反向代理功能的程序框架。业务节点20则可以是具体的执行业务处理任务的应用服务器，多个业务节点20与反向代理节点10连接。如图3所示，同一类业务的业务请求具有相同的业务标识，例如，支付业务过程中的终端发起的业务请求均对应支付业务的业务标识。业务节点则与业务标识对应，反向代理节点10则可根据业务标识对业务请求进行转发。需要说明的是不同的业务节点的硬件实体可以是同一服务器硬件实体，某些业务资源耗费较少，例如仅用于返回静态页面但对应不同业务标识的业务，则可多个业务节点对应同一服务器硬件实体，从而节省服务器资源。

具体的，在本实施例中，如图4所示，运行于反向代理节点10上的处理业务请求的方法可包括：

步骤S102：接收上传的业务请求，提取业务请求的资源定位符。

步骤S104：获取资源定位符对应的业务标识，获取业务标识对应的连接数及相应的连接数限额。

步骤S106：判断该连接数是否小于该连接数限额，若是，则执行步骤S108；否则，执行步骤S110。

步骤S108：将业务请求转发给与业务标识对应的业务节点.

步骤S110：对业务请求进行排队处理。

资源定位符即url（Uniform Resoure Locator），在传统技术中，网站或者移动互联网中的应用通常使用url来定位资源。用户使用浏览器或手机上的应用客户端向服务器请求资源或请求服务时，即可通过url来确定资源的位置和名称。

开发者在设计业务处理系统时，可为同一类型的业务对应的业务请求的url设置统一的访问路径。例如，对于邮件业务，用户发起的业务请求可以涉及接收、转发、发送和删除邮件等邮件业务，则所有对应邮件业务的业务请求可以使用“mail/”作为业务请求的前缀：

发送：http://域名/mail/send

接收：http://域名/mail/receive

删除：http://域名/mail/delete

反向代理节点在接收到以“mail/”为起始的业务请求时，即可根据该前缀得知该业务请求对应的业务类型为邮件业务，可以使用“mail”作为其业务标识，也可直接以url中的前缀作为业务标识。反向代理节点确定业务请求的业务标识之后即可对其是否需要排队进行判断。

需要说明的是，反向代理节点也可与一个或一个以上的业务节点运行于同一服务器硬件设备上。例如，对于一些展示静态页面的业务，对计算资源需求较小，可与反向代理节点运行于同一服务器硬件设备。

与业务标识对应的连接数即为已向该业务标识对应的业务节点转发给了业务请求，但在等待其回复响应数据的过程中与业务节点保持连接的连接数量。连接数限额即为可向该业务节点发起连接的最大数量。

也就是说，若反向代理节点与业务节点的连接数达到连接数限额，则反向代理节点不再向该业务节点转发业务请求，而是对该业务请求进行排队处理。

例如，在一个应用场景中，反向代理节点基于nginx框架，可采用前述的url前缀作为业务标识，然后利用nginx框架的url并发数限制来实现对具有相同的url前缀的业务请求进行连接数限制的功能。可静态或动态地对某个url前缀设置连接数限额，当nginx框架运行时，若该url前缀对应的实时的业务请求的连接数大于或等于设置的连接数限额，则暂停向该url前缀对应的业务节点转发业务请求。

在本实施例中，若连接数大于或等于连接数限额，则对业务请求进行排队处理的步骤，具体为：将业务请求添加到与业务标识对应的阻塞队列中。也就是说，每个业务标识都有相应的阻塞队列，当某个业务标识的连接数大于或等于连接数限额时，其对应的业务请求将会被按照接收的先后顺序依次添加到阻塞队列的队尾，而此时若反向代理节点接收到的对应其他业务标识的业务请求，且该业务请求的业务标识对应的连接数小于相应的连接数限额，则反向代理节点仍然转发该业务请求至该业务标识对应的业务节点，并不会被置于不同的业务标识所属的阻塞队列中。

进一步的，还可检测与业务标识对应的连接数是否小于业务标识对应的连接数限额，若是，则由业务标识对应的阻塞队列提取业务请求，并转发至与其对应的业务节点。

也就是说，若与业务节点的连接变少，低于了连接数限额的限制，则可从前述该业务标识对应的阻塞队列的队首提取出业务请求进行处理。

需要说明的是，不同的业务标识对应的多个阻塞队列可以是一个整体的阻塞队列中逻辑上的多个子集，多个业务标识对应的业务请求可存储在该同一个阻塞队列中，但需要添加与业务标识对应的标记，在阻塞队列中提取业务请求时，则可根据该标记区分业务请求。

进一步的，连接数限额可根据业务节点上存储的会话进行动态设置，具体为：获取与业务节点对应的会话信息，根据会话信息生成与业务节点对应的连接数限额。

业务节点在接收到反向代理节点转发的业务请求之后，若不存在与该业务请求对应的会话，需要先创建与该业务请求对应的会话。业务标识对应的会话信息即业务标识对应的业务节点正在处理的会话的个数和状态等信息。

反向代理节点可与业务节点共享会话。例如，反向代理节点可与业务节点通过内存共享来实现会话共享，或者业务节点可与反向代理节点之间建立长连接，使得反向代理节点可通过该长连接查询业务节点上缓存的会话状态。

在本实施例中，如图3所示，业务节点对业务请求进行处理，生成相应的响应数据，并通过反向代理节点将响应数据返回给终端。生成的响应数据中可包含与其他业务节点对应的链接。用户通过点击该链接则可发起与其他业务节点对应的业务请求。

例如，如图5所示，图5展示了用户使用终端完成一个涉及多个业务节点的业务流程的时序过程。该业务流程需要用户先在业务节点1中完成相应的业务操作（图5仅用于说明终端、反向代理节点和业务节点之间的交互过程，用户在业务节点1中完成相应的业务操作时也可向业务节点1发起多次业务请求，不限于图5中的仅一次业务请求），然后点击业务节点1返回的页面中对应业务节点2的入口链接，完成业务节点2上的业务操作，并得到最终的处理结果。

进一步的，如图4所示，可设置会话同步节点40，会话同步节点40与反向代理节点10和业务节点20连接。反向代理节点获取与业务节点对应的会话信息的步骤为：

接收会话同步节点下发的会话信息，该会话信息由会话同步节点检测得到。

也就是说，业务节点20在处理接收到的业务请求时，会将该业务请求的会话状态通过长连接上传到会话同步节点40，会话同步节点40则可接收多个业务节点20上传的会话状态，并统计每个业务节点上传的会话状态的个数，然后下发给反向代理节点10，反向代理节点即可获知每个业务标识对应的业务节点上当前有多少个会话在并发处理以及是哪些终端建立的会话，对于会话并发数量较高的业务节点，则可降低其连接数限额；对于会话并发数量较低的业务节点，则可提高其连接数限额。

需要说明的是，业务节点在会话状态发生变化时，均会通过前述的长连接通知会话同步节点进行更新，从而保证会话同步节点下发给反向代理节点的会话信息为实时信息。

例如，如图6所示，图6展示了涉及会话同步节点的时序过程。业务节点在处理业务请求时均会通过长连接将相应的会话状态上传至会话同步节点。

会话同步节点也可通过脚本检测与业务节点对应的会话信息。例如，在一个应用场景中，可基于Node.js框架实现会话同步节点的功能，例如，可在业务节点返回的响应页面中包含基于Node.js框架的脚本，当用户的浏览器或手机应用加载该响应页面或关闭该加载该响应页面时，则均会触发该脚本，通知基于Node.js的会话同步节点，会话同步节点则可获知该用户终端的会话状态，经统计后，即可下发给反向代理节点。

进一步的，获取资源定位符对应的业务标识的步骤之后还包括：获取业务请求对应的会话状态，根据会话状态判断业务请求是否需要排队，若否，则将其转发给与业务标识对应的业务节点。

例如，若邮件业务对应一个业务节点，某个用户先发起了邮件查看的业务请求，经过阻塞队列排队后，被转发至邮件业务的业务节点进行处理，返回了包含该用户的邮件列表的响应页面，然后用户选中该邮件列表中的某个邮件，并在会话超时期内发起了相应的邮件删除的业务请求，则由于邮件查看的业务请求在转发到业务节点时，业务节点创建了与该用户的终端对应的会话，则在该会话没有被注销时，仍然将后续的邮件删除的业务请求转发至该业务节点。

也就是说，用户若通过排队进入了某个业务节点进行某个业务流程的处理，则在该用户在该业务节点上的会话的生命期内，该用户后续发起的与该业务节点对应的业务请求均不需要排队而直接被转发至该业务节点，从而保证了用户操作的连续性，不会在处理某个业务流程的中，每接收到一个响应页面就重新排队一次，从而提高了操作的便利性。

在一个应用场景中，如图7所示，图7展示了一次电子商务应用中抢购活动的业务流程的时序过程。该业务流程涉及的业务标识包括商品展示业务、用户信息查询业务、订单生成业务和支付业务。

其中，商品展示业务用于查询商品数据库的数据，并展示包含商品的图片、数量、价格的页面，用户可点击商品展示页面上与商品对应的购买链接进入购物车进行订单生成业务的操作；用户信息查询业务的用于查询用户的身份，从而展示或添加与用户身份相关的信息（例如会员打折等信息）；订单生成业务用于生成具体的交易订单，即通过购物车页面生成最终交易订单；支付业务则用于电子商务支付。

本应用场景中各个业务节点的交互过程则可具体为：

反向代理节点接收终端发起的业务请求，提取业务请求的资源定位符；获取资源定位符对应的业务标识，获取与业务标识对应的连接数及连接数限额；判断连接数是否小于所述连接数限额，若是，则将业务请求转发给与业务标识对应的业务节点，且业务标识包括商品展示业务、用户信息查询业务、订单生成业务和支付业务。

业务节点接收转发的业务请求，对其进行处理，生成相应的响应页面，并通过所述反向代理节点将所述响应数据返回给终端，且响应页面包含与业务标识对应的链接地址。

终端检测响应页面上与所述链接地址对应的触发指令（例如用户点击了响应页面中包含的链接地址），生成相应的业务请求，并将其发送给反向代理节点。

需要说明的时，用户在某个业务节点上进行业务操作时，发起的业务请求不限于图7中所示的一次，且用户在实际网上购物过程中的操作过程也不限于图7中所示的时序过程。例如，用户将某个商品添加到购物车之后可返回商品展示页并继续向购物车中添加商品并进行购买，而不用进入支付后再重新购买。

如图8所示，用户在分别进行进入商店首页、登录账号、生成订单和在线支付之前均需要进行排队，但通常情况下，抢购系统的瓶颈在于支付业务上（支付业务通常涉及外部业务接口，例如，网银接口或第三方支付接口的调用，通常有并发限制），采用上述方案可使得在支付业务存在瓶颈的情况下，用户可先经过较短时间的排队然后进入购物车，选好其希望购买的商品生成订单，然后再进行排队等待剩余的支付环节。而传统技术的排队系统中，用户排队进入抢购页面后，还需要先登录，再选择商品，然后生成订单，再完成支付，需要耗费较多的时间。而排队中的用户则需要等待该用户完成上述全部操作后才能进入系统。因此采用本方法的电商抢购系统，可使业务流程中某个环节的瓶颈不会影响到该业务流程中用户在其他环节的操作，从而提高了执行效率。

在一个实施例中，如图9所示，可将反向代理节点、业务节点和会话同步节点部署在不同的域名之下（如图9中的A为反向代理节点的域名，B和C为业务节点的域名，D为基于Node.js的会话同步节点），在进入商店之前的流量控制页（统称为商店加载页，对应商店首页加载业务）也可部署接入到A域名下，A和B向D发起长连接请求，B向D发起状态更新请求以实现实时采集玩家流量，B和C前后台系统间的信息交互以实现玩家的商品购买交易，C也接入到A的流量限制系统中以保护整个交易过程系统可用，D向A动态调整流量限制配置以实现实时调整A和C的流量限制策略。

在本实施例对应的应用场景中，如图10所示，以腾讯游戏微商店的一次抢购活动为例，详细阐述该实时主动调整流量的抢购系统的工作流程：

在抢购活动开始的时刻，海量玩家进入商店的时候，为了保护整个抢购活动中的服务器不会被挤宕机，限流步骤如下所示：

1.进入加载商店页限流。所有玩家由系统引导进入A域名，通过流量限制的玩家进入B域名，即商店首页；否则玩家进入排队等待状态。

2.进入商店首页限流。在进入商店首页后，系统在C域名下查询玩家信息，通过流量限制的玩家返回玩家信息并进入商品选择页；否则玩家进入排队等待状态。

3.下订单限流。玩家选择好物品下订单的时候，通过流量限制的玩家成功下订单；否则玩家进入排队等待状态。

4.支付限流。成功下完订单的玩家在进行支付的时候，通过流量限制的玩家成功支付并完成物品发货，否则玩家进入排队等待状态。

如图11所示，在加载商店页限流和商店首页限流环节进行排队的用户可收到商店爆满的提示信息，并可通过点击“再挤挤”重新申请进入。如图12所示，在下订单限流环节进行排队的用户则可收到其在队列中具体的位置。

在以上限流步骤中，玩家在来到商店的时候，域名A都会向域名D发起一个长连接，然后在玩家每进入到下一个业务环节，域名B都会向域名D更新一次玩家状态，以实时统计每个限流步骤中的玩家数量和玩家状态。因此，根据当前抢购系统的总容量，反向代理节点即可以根据当前系统以上4个步骤中的玩家数量的比例来动态配置每一步的限流阀值，从而完成实时主动调整用户排队的体验。

在一个实施例中，如图13所示，一种处理业务请求的装置，包括请求接收模块102、业务分类模块104、请求转发模块106以及请求排队模块108，其中：

请求接收模块102，用于接收上传的业务请求，提取所述业务请求的资源定位符；

业务分类模块104，用于获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；

请求转发模块106，用于在所述连接数小于所述连接数限额时，将所述业务请求转发给与所述业务标识对应的业务节点；

请求排队模块108，用于在所述连接数大于或等于所述连接数限额时，对所述业务请求进行排队处理。

在一个实施例中，请求排队模块108还用于将业务请求添加到与业务标识对应的阻塞队列中。

在一个实施例中，请求转发模块106还用于检测与业务标识对应的连接数是否小于业务标识对应的连接数限额，若是，则由业务标识对应的阻塞队列提取业务请求，并转发至与其对应的业务节点。

在一个实施例中，如图13所示，处理业务请求的装置还包括限额配置模块110，用于获取与业务节点对应的会话信息，根据会话信息生成与业务节点对应的连接数限额。

在一个实施例中，限额配置模块110还用于接收会话同步节点下发的会话信息。

在一个实施例中，请求转发模块106还用于获取业务请求对应的会话状态，根据会话状态判断业务请求是否需要排队，若否，则将其转发给与业务标识对应的业务节点。

在一个实施例中，如图14所示，一种处理业务请求的方法，该方法可基于图2所示的计算机系统，该方法包括：

步骤S202，反向代理节点接收终端发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取所述业务标识对应的连接数及相应的连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点。

步骤S204，业务节点接收转发的业务请求，对其进行处理，生成相应的响应数据，并通过所述反向代理节点将所述响应数据返回给所述终端。

在本实施例中，还可设置会话同步节点，会话同步节点可检测所述业务节点的会话信息，并将其下发给所述反向代理节点。

反向代理节点获取业务标识对应的连接数限额的步骤为：根据会话同步节点下发的业务节点的会话信息生成与业务节点对应的连接数限额。

在本实施例中，业务节点接收转发的业务请求的步骤之后还可获取与所述业务请求对应的会话状态，并上传至会话同步节点。

一种处理业务请求的系统，如图2所示，包括反向代理节点10和业务节点20，其中：

反向代理节点10用于接收终端30发起的业务请求，提取业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取所述业务标识对应的连接数及相应的连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点。

业务节点20用于接收转发的业务请求，对其进行处理，生成相应的响应数据，并通过反向代理节点将所述响应数据返回给所述终端30。

在本实施例中，如图2所示，该系统还包括会话同步节点，用于检测所述业务节点的会话信息，并将其下发给所述反向代理节点。

反向代理节点还用于根据会话同步节点下发的业务节点的会话信息生成与所述业务节点对应的连接数限额。

在本实施例中，业务节点还用于获取与所述业务请求对应的会话状态，并上传至所述会话同步节点。

在一个实施例中，如图15所示，一种处理网购业务请求的方法，包括：

步骤S302，反向代理节点接收终端发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点，且所述业务标识包括商品展示业务、用户信息查询业务、订单生成业务和支付业务；

步骤S304，业务节点接收转发的业务请求，对其进行处理，生成相应的响应页面，并通过所述反向代理节点将所述响应数据返回给所述终端，且所述响应页面包含与业务标识对应的链接地址；

步骤S306，终端检测响应页面上与所述链接地址对应的触发指令，生成相应的业务请求，并将其发送给所述反向代理节点。

在一个实施例中，如图2所示，一种处理网购业务请求的系统，包括反向代理节点10和业务节点20，其中：

反向代理节点10用于接收终端30发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点，且所述业务标识包括商品展示业务、用户信息查询业务、订单生成业务和支付业务；

业务节点20用于接收转发的业务请求，对其进行处理，生成相应的响应页面，并通过所述反向代理节点将所述响应数据返回给所述终端，且所述响应页面包含与业务标识对应的链接地址；

终端30用于检测响应页面上与所述链接地址对应的触发指令，生成相应的业务请求，并将其发送给所述反向代理节点。

上述处理业务请求的方法、装置及系统中，对互联网应用的业务进行了划分，将瓶颈业务与非瓶颈业务分离，且通过资源定位符分别与业务请求对应。用户在瓶颈业务对应的业务节点上的排队等待仍然能保证处理瓶颈业务的服务器实体不会有较大的负载压力，从而不会造成整个服务器卡顿或瘫痪。而且，部分用户在瓶颈业务上进行业务操作时，其他用户可同时在非瓶颈业务上进行业务操作，使得后续的用户无需等待进入系统的用户处理完所有业务流程后才能进入系统，从而降低了用户平均排队等待的时间。

同时，将对业务请求进行排队处理的功能设置在反向代理节点处而不是传统技术的应用服务器上，使得在具体处理业务的业务节点负载压力较大时，不会影响到反向代理节点的响应速度，反向代理节点的并发数较高时，也不会影响到业务节点处理业务请求的效率，从而提高了系统的可靠性。

在一个实施例中，如图16所示，提供了一种可运行前述处理业务请求的方法的反向代理节点结构示意图，该业务节点结构可应用于互联网应用的业务节点上。该业务节点500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器（central processing units，CPU）522（例如，一个或一个以上处理器）和存储器532，一个或一个以上存储应用程序542或数据544的存储介质530（例如一个或一个以上海量存储设备）。其中，存储器532和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块（如前述的请求接收模块102、业务分类模块104、请求转发模块106以及请求排队模块108），每个模块可以包括对业务节点中的一系列指令操作。更进一步地，中央处理器522可以设置为与存储介质530通信，在业务节点500上执行存储介质530中的一系列指令操作。业务节点500还可以包括一个或一个以上电源526，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口558，和/或，一个或一个以上操作系统541，例如WindowsServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述图4所示实施例中所述的由反向代理节点所执行的步骤可以基于该图16所示的业务节点结构。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（Read-Only Memory，ROM）或随机存储记忆体（Random Access Memory，RAM）等。

以上实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (20)

1.一种处理业务请求的方法，包括：

接收上传的业务请求，提取所述业务请求的资源定位符；

获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；

判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点；否则，对所述业务请求进行排队处理。

2.根据权利要求1所述的处理业务请求的方法，其特征在于，所述对所述业务请求进行排队处理的步骤为：

将所述业务请求添加到与所述业务标识对应的阻塞队列中。

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

检测与所述业务标识对应的连接数是否小于所述业务标识对应的连接数限额，若是，则由所述业务标识对应的阻塞队列提取业务请求，并转发至与其对应的业务节点。

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

获取与业务节点对应的会话信息，根据所述会话信息生成与所述业务节点对应的连接数限额。

5.根据权利要求4所述的处理业务请求的方法，其特征在于，所述获取与业务节点对应的会话信息的步骤为：

接收会话同步节点下发的会话信息。

6.根据权利要求1所述的处理业务请求的方法，其特征在于，所述获取所述资源定位符对应的业务标识的步骤之后还包括：

获取所述业务请求对应的会话状态，根据所述会话状态判断所述业务请求是否需要排队，若否，则将其转发给与所述业务标识对应的业务节点。

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

请求接收模块，用于接收上传的业务请求，提取所述业务请求的资源定位符；

业务分类模块，用于获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；

请求转发模块，用于在所述连接数小于所述连接数限额时，将所述业务请求转发给与所述业务标识对应的业务节点；

请求排队模块，用于在所述连接数大于或等于所述连接数限额时，对所述业务请求进行排队处理。

8.根据权利要求7所述的处理业务请求的装置，其特征在于，所述请求排队模块还用于将所述业务请求添加到与所述业务标识对应的阻塞队列中。

9.根据权利要求8所述的处理业务请求的方法，其特征在于，所述请求转发模块还用于检测与所述业务标识对应的连接数是否小于所述业务标识对应的连接数限额，若是，则由所述业务标识对应的阻塞队列提取业务请求，并转发至与其对应的业务节点。

10.根据权利要求7所述的处理业务请求的装置，其特征在于，所述装置还包括限额配置模块，用于获取与业务节点对应的会话信息，根据所述会话信息生成与所述业务节点对应的连接数限额。

11.根据权利要求10所述的处理业务请求的装置，其特征在于，所述限额配置模块还用于接收会话同步节点下发的会话信息。

12.根据权利要求7所述的处理业务请求的装置，其特征在于，所述请求转发模块还用于

获取所述业务请求对应的会话状态，根据所述会话状态判断所述业务请求是否需要排队，若否，则将其转发给与所述业务标识对应的业务节点。

13.一种处理业务请求的方法，包括：

反向代理节点接收终端发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取所述业务标识对应的连接数及相应的连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点；

所述业务节点接收转发的业务请求，对其进行处理，生成相应的响应数据，并通过所述反向代理节点将所述响应数据返回给所述终端。

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

会话同步节点检测所述业务节点的会话信息，并将其下发给所述反向代理节点；

所述反向代理节点获取所述业务标识对应的连接数限额的步骤为：

根据所述会话同步节点下发的业务节点的会话信息生成与所述业务节点对应的连接数限额。

15.根据权利要求14所述的处理业务请求的方法，其特征在于，所述业务节点接收转发的业务请求的步骤之后还包括：

获取与所述业务请求对应的会话状态，并上传至所述会话同步节点。

16.一种处理业务请求的系统，其特征在于，包括反向代理节点和业务节点，其中：

反向代理节点用于接收终端发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取所述业务标识对应的连接数及相应的连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点；

所述业务节点用于接收转发的业务请求，对其进行处理，生成相应的响应数据，并通过所述反向代理节点将所述响应数据返回给所述终端。

17.根据权利要求16所述的处理业务请求的系统，其特征在于，所述系统还包括会话同步节点，用于检测所述业务节点的会话信息，并将其下发给所述反向代理节点；

所述反向代理节点还用于根据所述会话同步节点下发的业务节点的会话信息生成与所述业务节点对应的连接数限额。

18.根据权利要求17所述的处理业务请求的系统，其特征在于，所述业务节点还用于获取与所述业务请求对应的会话状态，并上传至所述会话同步节点。

19.一种处理网购业务请求的方法，包括：

反向代理节点接收终端发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点，且所述业务标识包括商品展示业务、用户信息查询业务、订单生成业务和支付业务；

所述业务节点接收转发的业务请求，对其进行处理，生成相应的响应页面，并通过所述反向代理节点将所述响应数据返回给所述终端，且所述响应页面包含与业务标识对应的链接地址；

所述终端检测所述响应页面上与所述链接地址对应的触发指令，生成相应的业务请求，并将其发送给所述反向代理节点。

20.一种处理网购业务请求的系统，其特征在于，包括：

反向代理节点接收终端发起的业务请求，提取所述业务请求的资源定位符；获取所述资源定位符对应的业务标识，获取与所述业务标识对应的连接数及连接数限额；判断所述连接数是否小于所述连接数限额，若是，则将所述业务请求转发给与所述业务标识对应的业务节点，且所述业务标识包括商品展示业务、用户信息查询业务、订单生成业务和支付业务；

所述业务节点接收转发的业务请求，对其进行处理，生成相应的响应页面，并通过所述反向代理节点将所述响应数据返回给所述终端，且所述响应页面包含与业务标识对应的链接地址；

所述终端检测所述响应页面上与所述链接地址对应的触发指令，生成相应的业务请求，并将其发送给所述反向代理节点。