051]为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
[0052]传统技术中，如图1所示，排队系统由应用服务器实现，应用服务器不仅要对终端发起的业务请求进行处理，还要维护整个排队系统(如图1所示，通常需不仅需要维护排队处理的等待队列，还需要管理执行具体业务逻辑来处理业务请求的执行队列)。使得在高并发环境下，特别是在突发性的例如电子商务中的抢购商品或春运期间订车票的应用场景中，应用服务器在耗费大量计算资源处理业务请求的时，无法分配更多的计算资源来对排队系统进行维护(如图1中，应用服务器会将大量的计算资源用在业务处理算法和业务处理接口的调用上，而对于排队系统的维护和调度则无法分配足够的计算资源)，从而造成了用户在上述应用场景中获得较慢的系统响应，甚至会造成应用服务器的崩溃，因此可靠性不足。
[0053]而且，用户只有排队进入系统后才能进行操作，且为了保证用户进行业务操作的完整性，可能需要完成多个非性能瓶颈的业务和性能瓶颈业务之后才能完成业务流程，而仍在排队的用户则需要等待该用户完成整个业务流程之后才能进入系统，使得用户平均排队等待时间较长。
[0054]在本实施例中，为了解决上述问题，特提出了一种处理业务请求的方法。该方法可依赖于计算机程序，能够运行于基于冯洛伊曼体系的计算机系统上。该计算机系统可以是服务器网关设备或反向代理服务器。
[0055]如图2所示，本方法即可运行于图2中的反向代理节点10上，该反向代理节点可以是基于nginx框架的服务器，也可以基于其他具备反向代理功能的程序框架。业务节点20则可以是具体的执行业务处理任务的应用服务器，多个业务节点20与反向代理节点10连接。如图3所示，同一类业务的业务请求具有相同的业务标识，例如，支付业务过程中的终端发起的业务请求均对应支付业务的业务标识。业务节点则与业务标识对应，反向代理节点10则可根据业务标识对业务请求进行转发。需要说明的是不同的业务节点的硬件实体可以是同一服务器硬件实体，某些业务资源耗费较少，例如仅用于返回静态页面但对应不同业务标识的业务，则可多个业务节点对应同一服务器硬件实体，从而节省服务器资源。
[0056]具体的，在本实施例中，如图4所示，运行于反向代理节点10上的处理业务请求的方法可包括:
[0057]步骤S102:接收上传的业务请求，提取业务请求的资源定位符。
[0058]步骤S104:获取资源定位符对应的业务标识，获取业务标识对应的连接数及相应的连接数限额。
[0059]步骤S106:判断该连接数是否小于该连接数限额，若是，则执行步骤S108 ;否则，执行步骤SI 10。
[0060]步骤S108:将业务请求转发给与业务标识对应的业务节点.
[0061]步骤SllO:对业务请求进行排队处理。
[0062]资源定位符即url (Uniform Resoure Locator),在传统技术中，网站或者移动互联网中的应用通常使用url来定位资源。用户使用浏览器或手机上的应用客户端向服务器请求资源或请求服务时，即可通过url来确定资源的位置和名称。
[0063]开发者在设计业务处理系统时，可为同一类型的业务对应的业务请求的url设置统一的访问路径。例如，对于邮件业务，用户发起的业务请求可以涉及接收、转发、发送和删除邮件等邮件业务，则所有对应邮件业务的业务请求可以使用“mail/”作为业务请求的前三双:
[0064]发送:http://域名 /mail/send
[0065]接收:http://域名 /mail/receive
[0066]删除:http://域名 /mail/delete
[0067]反向代理节点在接收到以“mail/”为起始的业务请求时，即可根据该前缀得知该业务请求对应的业务类型为邮件业务，可以使用“mail”作为其业务标识，也可直接以url中的前缀作为业务标识。反向代理节点确定业务请求的业务标识之后即可对其是否需要排队进行判断。
[0068]需要说明的是，反向代理节点也可与一个或一个以上的业务节点运行于同一服务器硬件设备上。例如，对于一些展示静态页面的业务，对计算资源需求较小，可与反向代理节点运行于同一服务器硬件设备。
[0069]与业务标识对应的连接数即为已向该业务标识对应的业务节点转发给了业务请求，但在等待其回复响应数据的过程中与业务节点保持连接的连接数量。连接数限额即为可向该业务节点发起连接的最大数量。
[0070]也就是说，若反向代理节点与业务节点的连接数达到连接数限额，则反向代理节点不再向该业务节点转发业务请求，而是对该业务请求进行排队处理。
[0071]例如,在一个应用场景中，反向代理节点基于nginx框架,可采用前述的url前缀作为业务标识，然后利用nginx框架的url并发数限制来实现对具有相同的url前缀的业务请求进行连接数限制的功能。可静态或动态地对某个url前缀设置连接数限额，当nginx框架运行时，若该url前缀对应的实时的业务请求的连接数大于或等于设置的连接数限额，贝1J暂停向该url前缀对应的业务节点转发业务请求。
[0072]在本实施例中，若连接数大于或等于连接数限额，则对业务请求进行排队处理的步骤，具体为:将业务请求添加到与业务标识对应的阻塞队列中。也就是说，每个业务标识都有相应的阻塞队列，当某个业务标识的连接数大于或等于连接数限额时，其对应的业务请求将会被按照接收的先后顺序依次添加到阻塞队列的队尾，而此时若反向代理节点接收到的对应其他业务标识的业务请求，且该业务请求的业务标识对应的连接数小于相应的连接数限额，则反向代理节点仍然转发该业务请求至该业务标识对应的业务节点，并不会被置于不同的业务标识所属的阻塞队列中。
[0073]进一步的，还可检测与业务标识对应的连接数是否小于业务标识对应的连接数限额，若是，则由业务标识对应的阻塞队列提取业务请求，并转发至与其对应的业务节点。
[0074]也就是说，若与业务节点的连接变少，低于了连接数限额的限制，则可从前述该业务标识对应的阻塞队列的队首提取出业务请求进行处理。
[0075]需要说明的是，不同的业务标识对应的多个阻塞队列可以是一个整体的阻塞队列中逻辑上的多个子集，多个业务标识对应的业务请求可存储在该同一个阻塞队列中，但需要添加与业务标识对应的标记，在阻塞队列中提取业务请求时，则可根据该标记区分业务请求。
[0076]进一步的，连接数限额可根据业务节点上存储的会话进行动态设置，具体为:获取与业务节点对应的会话信息，根据会话信息生成与业务节点对应的连接数限额。
[0077]业务节点在接收到反向代理节点转发的业务请求之后，若不存在与该业务请求对应的会话，需要先创建与该业务请求对应的会话。业务标识对应的会话信息即业务标识对应的业务节点正在处理的会话的个数和状态等信息。
[0078]反向代理节点可与业务节点共享会话。例如，反向代理节点可与业务节点通过内存共享来实现会话共享，或者业务节点可与反向代理节点之间建立长连接，使得反向代理节点可通过该长连接查询业务节点上缓存的会话状态。
[0079]在本实施例中，如图3所示,业务节点对业务请求进行处理，生成相应的响应数据，并通过反向代理节点将响应数据返回给终端。生成的响应数据中可包含与其他业务节点对应的链接。用户通过点击该链接则可发起与其他业务节点对应的业务请求。
[0080]例如，如图5所示，图5展示了用户使用终端完成一个涉及多个业务节点的业务流程的时序过程。该业务流程需要用户先在业务节点I中完成相应的业务操作(图5仅用于说明终端、反向代理节点和业务节点之间的交互过程，用户在业务节点I中完成相应的业务操作时也可向业务节点I发起多次业务请求，不限于图5中的仅一次业务请求)，然后点击业务节点I返回的页面中对应业务节点2的入口链接，完