负载均衡的控制方法、装置及系统技术领域
本发明涉及互联网领域，具体而言，涉及一种负载均衡的控制方法、
装置及系统。
背景技术
如今，随着互联网技术的飞速发展，提供互联网服务的应用系统经常
需要同时面对海量的用户以及大量的并发请求数据。通过利用负载均衡算
法，在应用系统在遇到大量的并发请求数据时，按照预先设定的规则将数
据分配至系统中的不同服务器中，以达到扩展网络设备和服务器的带宽、
增加吞吐量、加强网络数据处理能力、提供网络的灵活性和可用性的技术
效果。在互联网服务的应用系统中，负载均衡是一种必要的用于解决信息
阻塞问题的技术手段。
在现有技术中，负载均衡的解决方案大体分为两种：通过软件方式实
现负载均衡，通过硬件方式实现负载均衡。
其中，通过软件方式实现负载均衡，是指在一台或多台服务器的操作
系统上，安装一个或多个附加软件或服务来实现负载均衡的功能。此种方
式因无需在应用系统中添加新的网络设备，所以具有配置简单、成本低廉
等优点。但是，由于单台服务器的处理能力有限，而用于实现负载均衡的
附加软件本身会消耗服务器的处理资源。所以，受服务器处理能力的限制，
通过软件方式实现负载均衡的解决方案在高并发的场景下容易形成处理
瓶颈。
通过硬件方式实现负载均衡，是指直接在服务器集群和外部网络之间
安装专门用于实现负载均衡功能的负载均衡设备。基于硬件方式实现负载
均衡，虽然可以保证处理性能，但是，因负载均衡本身价格昂贵，并且维
护和部署的成本非常高，所以不具有很高的通用性。
针对上述由于单台服务器的处理能力有限，导致的高并发场景下的负
载均衡效率低的问题，目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种负载均衡的控制方法、装置及系统，以至少
解决由于单台服务器的处理能力有限，导致的高并发场景下的负载均衡效
率低的技术问题。
根据本发明实施例的一个方面，提供了一种负载均衡的控制方法，包
括：接收数据处理请求；根据数据处理请求从负载均衡服务器中获取用于
对数据处理请求进行处理的应用服务器信息，其中，应用服务器信息用于
记录在应用服务器集群中负载最低的应用服务器的信息；根据应用服务器
信息，确定在应用服务器集群中与应用服务信息对应的应用服务器为目标
服务器，并将接收到的数据处理请求转发至目标服务器；接收目标服务器
根据数据处理请求返回的数据处理结果，其中，数据处理结果至少包括：
处理日志信息，处理日志信息为目标服务器处理数据处理请求的执行记录；
将数据处理结果上报至负载均衡服务器。
根据本发明实施例的另一方面，还提供了一种负载均衡的控制装置，
包括：第一接收模块，用于接收数据处理请求；获取模块，用于根据数据
处理请求从负载均衡服务器中获取用于对数据处理请求进行处理的应用
服务器信息，其中，应用服务器信息用于记录在应用服务器集群中负载最
低的应用服务器的信息；第一处理模块，用于根据应用服务器信息，确定
在应用服务器集群中与应用服务信息对应的应用服务器为目标服务器，并
将接收到的数据处理请求转发至目标服务器；第二接收模块，用于接收目
标服务器根据数据处理请求返回的数据处理结果，其中，数据处理结果至
少包括：处理日志信息，处理日志信息为目标服务器处理数据处理请求的
执行记录；上报模块，用于将数据处理结果上报至负载均衡服务器。
根据本发明实施例的另一方面，还提供了一种负载均衡的控制方法，
包括：根据本发明实施例的另一方面，还提供了一种负载均衡的控制方法，
包括：接收由反向代理服务器上报的数据处理结果，其中，数据处理结果
中至少包括：处理日志信息；根据数据处理结果，对与数据处理结果对应
的应用服务器的处理次数进行累加；根据处理日志信息，判断应用服务器
是否对数据处理请求处理成功；当应用服务器对数据处理请求处理成功时，
记录应用服务器处理数据处理请求的任务处理时长。
根据本发明实施例的另一方面，还提供了一种负载均衡的控制装置，
包括：第三接收模块，用于接收由反向代理服务器上报的数据处理结果，
其中，数据处理结果中至少包括：处理日志信息；第二累加模块，用于根
据数据处理结果，对与数据处理结果对应的应用服务器的处理次数进行累
加；第二判断模块，用于根据处理日志信息，判断应用服务器是否对数据
处理请求处理成功；记录模块，用于当应用服务器对数据处理请求处理成
功时，记录应用服务器处理数据处理请求的任务处理时长。
根据本发明实施例的另一方面，还提供了一种负载均衡的控制系统，
包括：应用服务器集群，至少包括两台应用服务器，用于对客户端发送的
数据处理请求进行处理，得到数据处理结果；负载均衡服务器，用于对与
反向代理服务器上报的数据处理结果对应的应用服务器的处理次数进行
累加，并根据数据处理结果中的处理日志信息，判断应用服务器是否对数
据处理请求处理成功，当应用服务器对数据处理请求处理成功时，记录应
用服务器处理数据处理请求的任务处理时长，并根据任务处理时长和处理
次数对应用服务器列表中的应用服务器进行排序；反向代理服务器，与应
用服务器集群与负载均衡服务器建立通讯连接，用于将接收到的客户端发
送的数据处理请求，根据从负载均衡服务器中获取的用于对数据处理请求
进行处理的应用服务器信息确定用于处理数据处理请求的应用服务器，然
后将数据处理请求转发至应用服务器中，并将接收到的目标服务器返回的
数据处理结果，上报至负载均衡服务器。
在本发明实施例中，采用接收数据处理请求；根据数据处理请求从负
载均衡服务器中获取用于对数据处理请求进行处理的应用服务器信息，其
中，应用服务器信息用于记录在应用服务器集群中负载最低的应用服务器
的信息；根据应用服务器信息，确定在应用服务器集群中与应用服务信息
对应的应用服务器为目标服务器，并将接收到的数据处理请求转发至目标
服务器；接收目标服务器根据数据处理请求返回的数据处理结果，其中，
数据处理结果至少包括：处理日志信息，处理日志信息为目标服务器处理
数据处理请求的执行记录；将数据处理结果上报至负载均衡服务器的方式，
通过第一接收模块，用于接收数据处理请求；获取模块，用于根据数据处
理请求从负载均衡服务器中获取用于对数据处理请求进行处理的应用服
务器信息，其中，应用服务器信息用于记录在应用服务器集群中负载最低
的应用服务器的信息；第一处理模块，用于根据应用服务器信息，确定在
应用服务器集群中与应用服务信息对应的应用服务器为目标服务器，并将
接收到的数据处理请求转发至目标服务器；第二接收模块，用于接收目标
服务器根据数据处理请求返回的数据处理结果，其中，数据处理结果至少
包括：处理日志信息，处理日志信息为目标服务器处理数据处理请求的执
行记录；上报模块，用于将数据处理结果上报至负载均衡服务器，达到了
在不影响反向代理的处理性能情况下，即可实现负载均衡的目的，从而实
现了在高并发场景下提高负载均衡服务器的执行效率的技术效果，进而解
决了由于单台服务器的处理能力有限，导致的高并发场景下的负载均衡效
率低的技术问题。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一
部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发
明的不当限定。在附图中：
图1是本发明实施例的一种实现负载均衡的控制方法的计算机终端的
硬件结构框图；
图2是根据本发明实施例的一种负载均衡的控制方法的流程示意图；
图3是根据本发明实施例的一种负载均衡的控制装置的示意图；
图4是根据本发明实施例的一种优选的负载均衡的控制装置的示意图；
图5是根据本发明实施例的一种优选的负载均衡的控制装置的示意图；
图6是根据本发明实施例的一种负载均衡的控制方法的流程示意图；
图7是根据本发明实施例的一种负载均衡的控制装置的示意图；
图8是根据本发明实施例的一种优选的负载均衡的控制装置的示意图；
图9是根据本发明实施例的一种负载均衡的控制系统的系统结构示意
图；
图10是根据本发明实施例的一种实施例的多终端的负载均衡的控制
方法在实际应用中的流程示意图；
图11是根据本发明实施例的一种优选的负载均衡的控制系统的系统
结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明
实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，
显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施
例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动
前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语
“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或
先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描
述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实
施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排
他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或
设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出
的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
实施例1
根据本发明实施例，提供了一种负载均衡的控制方法的方法实施例，
需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行
指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是
在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或
者类似的运算装置中执行。以运行在计算机终端上为例，图1是本发明实
施例的一种实现负载均衡的控制方法的计算机终端的硬件结构框图。如图
1所示，计算机终端10可以包括一个或多个(图中仅示出一个)处理器
102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件
FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的
传输模块106。本领域普通技术人员可以理解，图1所示的结构仅为示意，
其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括
比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。
存储器104可用于存储应用软件的软件程序以及模块，如本发明实施
例中的负载均衡的控制方法对应的程序指令/模块，处理器102通过运行存
储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据
处理，即实现上述的负载均衡的控制方法。存储器104可包括高速随机存
储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、
或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括
相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接
至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局
域网、移动通信网及其组合。
传输装置106用于经由一个网络接收或者发送数据。上述的网络具体
实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，
传输装置106包括一个网络适配器(Network Interface Controller，NIC)，
其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例
中，传输装置106可以为射频(Radio Frequency，RF)模块，其用于通过
无线方式与互联网进行通讯。
在上述运行环境下，本申请提供了如图2所示的负载均衡的控制方法。
图2是根据本发明实施例一的负载均衡的控制方法的流程图。
如图2所示，应用于反向代理服务器中的负载均衡的控制方法的一种
可选的方案包括如下实施步骤：
步骤S21，接收数据处理请求。
具体的，反向代理(Reverse Proxy)服务器用于接收由互联网络中的
客户端发送来的数据处理请求，然后将数据处理请求转发至内部应用服务
器集群中的一台或多台应用服务器，并将从应用服务器上接收到的数据处
理结果返回给互联网上发送数据处理请求的客户端。
通过步骤S21，通过用于进行反向代理的反向代理服务器，直接接收
从客户端接发送的据处理请求，其中，数据处理请求可以包括各种类型的
数据处理请求，例如，数据查询请求、数据上传请求、数据修改请求等，
此处不对数据处理请求的内容进行具体限定。
步骤S23，根据数据处理请求从负载均衡服务器中获取用于对数据处
理请求进行处理的应用服务器信息，其中，应用服务器信息用于记录在应
用服务器集群中负载最低的应用服务器的信息。
具体的，设置负载均衡服务器，并在负载均衡服务器与反向代理服务
器之间建立通讯链接。其中，负载均衡服务器用于对服务器集群中的各台
应用服务器的负载状态进行记录，并可以对每台应用服务器在单位时间内
的负载状态，生成用于反映各台应用服务器负载状态的应用服务器列表。
其中，负载均衡服务器可以为单独设置的服务器，也可以为部署于应用服
务器集群中的一台或多台应用服务器中的负载代理服务，此处不做具体限
定。
在步骤S23中，可以由负载均衡服务器，根据应用服务器集群中的每
台应用服务器的负载状态，确定在当前时间段内，负载率最低或者处于空
闲的应用服务器。当反向代理服务器在访问负载均衡服务器时，负载均衡
服务器直接将包含有当前时间段内负载率最低或者处于空闲的应用服务
器的应用服务器信息，发送至反向代理服务器当中。
当然，作为一种可选的事实方式，通过步骤S23，当反向代理服务器
在接收到客户端发送的数据处理请求时，可以通过访问负载均衡服务器，
从负载均衡服务器中获取记录着每台应用服务器的负载状态的数据表。
步骤S25，根据应用服务器信息，确定在应用服务器集群中与应用服
务信息对应的应用服务器为目标服务器，并将接收到的数据处理请求转发
至目标服务器。
具体的，在步骤S25中，反向代理服务器根据由负载均衡服务器获取
到的应用服务器信息，将与应用服务器信息对应的应用服务器确定为目标
服务器。
应用服务器信息中所包含的应用服务器既可以是一个，也可以是多个。
当应用服务器信息中包含的应用服务器不为一个时，反向代理服务器可以
在获取应用服务器信息的同时，获取负载均衡服务器中的应用服务器列表。
可以根据应用服务器列表中所记录的与应用服务器对应的负载状态，选择
一台负载率最低或者空闲的应用服务器，将该应用服务器确定为用于对数
据处理请求进行处理的目标服务器。其中，负载状态是用于表征应用服务
器负载的信息，可以为负载率、负载时间等。此处不做进一步限定。
其中，反向代理服务器获取到的应用服务器信息，既可以是只包含由
负载均衡服务器已经根据负载状态进行筛选过的，负载率最低或者处于空
闲的应用服务器的数据表，当然也可以时包含应用服务器集群中所有应用
服务器和与之相应的负载状态的数据表。
当接收到的应用服务器信息为已经根据负载状态进行筛选过的，负载
率最低或者处于空闲的应用服务器的数据表时，直接将数据表单中的应用
服务器确定为目标服务器。
当接收到的应用服务器信息为包含应用服务器集群中所有应用服务
器和与之相应的负载状态的数据表时，反向代理服务器可以根据负载状态
对每台应用服务器在预定时间段内的负载率进行计算，选择负载率最低应
用服务器作为目标服务器，其中，负载率的计算方法此处不做赘述。
在实际应用当中，反向代理服务器获取到的应用服务器信息，是包含
应用服务器集群中所有应用服务器的负载状态的数据表单，还是只包含负
载率最低或者空闲的应用服务器的数据表单，可以通过对用于获取应用服
务器信息的查询请求信息进行设定。具体设定的情况，可以根据反向代理
服务器的处理能力、负载均衡服务器的处理能力或实际需要而定。
步骤S27，接收目标服务器根据数据处理请求返回的数据处理结果，
其中，数据处理结果至少包括：处理日志信息，处理日志信息为目标服务
器处理数据处理请求的执行记录。
具体的，目标服务器在对数据处理请求进行处理后，将生成与数据处
理请求对应的数据处理结果。其中，在数据处理结果中，除了包括针对于
数据处理请求进行处理后得到的执行结果外，还包括对数据处理请求进行
处理的处理日志信息。在处理日志信息中，至少记载了应用服务器处理该
条数据处理请求的开始处理时间、完成处理时间、处理该条数据处理请求
时产生的错误代码。通过步骤S27，由反向代理服务器通过接收由目标服
务器对数据处理请求进行处理后生成的数据处理结果。
步骤S29，将数据处理结果上报至负载均衡服务器。
具体的，通过步骤S29反向代理服务器除了将接收到的数据处理结果
中的，目标服务器针对于数据处理请求进行处理后得到的执行结果反馈至
客户端之外，反向代理服务器还将处理日志信息上报至负载均衡服务器中，
由负载均衡服务器对其进行记录。
通过步骤S21至步骤S29，反向代理服务器在对客户端与应用服务器
集群中的每个应用服务器进行反向代理的同时，通过将每个应用服务器处
理数据处理请求时的日志文件上报至负载均衡服务器。并在反向代理服务
器接收到数据处理请求时，由负载均衡服务器根据每台应用服务器的处理
日志信息，确定的应用服务器在单位时间段内负载状态，并将预定时间内
负载率最低的应用服务器的信息反馈至反向代理服务器。达到了在不影响
反向代理的处理性能情况下，即可实现负载均衡的目的，从而实现了在高
并发场景下提高负载均衡服务器的执行效率的效果，从而解决了由于单台
服务器的处理能力有限，导致的高并发场景下的负载均衡效率低的问题。
作为一种可选的事实方式，在步骤S23根据数据处理请求从负载均衡
服务器中获取用于对数据处理请求进行处理的应用服务器信息中，可以包
括：
步骤S231a，当接收到数据处理请求时，生成用于获取应用服务器信
息的查询请求信息。
步骤S233a，将查询请求信息发送至负载均衡服务器。
步骤S235a，接收负载均衡服务器发送的与查询请求信息对应的应用
服务器信息，其中，应用服务器信息中至少包括：与对应的应用服务器信
息对应的应用服务器的基础配置信息和路由信息。
具体的，在反向代理服务器接收到数据处理请求之后，通过向负载均
衡服务器发送查询请求信息，可以从负载均衡服务器中获取包含有在应用
服务器集群中在单位时间内的负载率最低的应用服务器的基础配置信息
和与该台应用服务器对应的路由信息。其中，基础配置信息至少包括应用
服务器的标识信息，路由信息至少包括应用服务器的路由地址。
在实际应用中，可以将包含有应用服务器集群中所有应用服务器的路
由地址的路由表存储于负载均衡服务器中。在向应用服务器集群中添加或
删除应用服务器时，只需要对负载均衡服务器中的路由表进行就修改即可。
作为一种可选的事实方式，在步骤S25根据应用服务器信息，确定在
应用服务器集群中与应用服务信息对应的应用服务器为目标服务器，并将
接收到的数据处理请求转发至目标服务器中，可以包括：
步骤S251a，根据基础配置信息，确定应用服务器集群中的目标服务
器。
步骤S253a，从应用服务器信息中获取与目标服务器对应的路由信息。
步骤S255a，根据路由信息，将接收到的数据处理请求转发至目标服
务器。
具体的，通过步骤S251a至步骤S255a，反向代理服务器在通过应用
服务器信息确认目标服务器的同时，还可以通过应用服务器信息获取到与
目标服务器对应的路由地址。从而使反向代理服务器可以根据路由地址，
将数据处理请求直接转发至目标服务器当中。进而省去了反向服务器在确
定目标服务器后，还需要到路由地址表中查询与目标服务器对应的路由地
址的步骤，进一步的优化了反向代理服务器的处理效率，提高了整体的处
理性能。
作为一种可选的事实方式，在步骤S29将数据处理结果上报至负载均
衡服务器之后，上述方法还包括：
步骤S31，负载均衡服务器在接收到处理日志信息后，对目标服务器
的处理次数进行累加，其中，处理次数用于记录每台应用服务器处理数据
处理请求的次数。
步骤S33，负载均衡服务器根据处理日志信息，判断目标服务器对数
据处理请求是否处理成功。
步骤S35，当目标服务器对数据处理请求处理成功时，负载均衡服务
器对目标服务器处理数据处理请求的任务处理时长进行记录。
具体的，负载代理服务可以根据上报的处理日志信息对应用服务器处
理数据处理请求的次数进行记录，并对处理日志信息进行分析处理。其中，
可以通过根据处理日志信息中是否包含有错误代码，来判断目标服务器对
数据处理请求的处理是否成功。当处理日志信息中不存在错误代码时，从
处理日志信息中读取目标服务器对数据处理请求开始处理的时间和结束
处理的时间。根据开始处理时间和结束处理时间，确定目标服务器对数据
处理请求的处理时长。进一步的，可以将处理时长保存至应用服务器列表
当中。
在实际应用中，为了减小负载均衡服务器存储空间的开支，可以只对
预定时间区间内的数据处理结果进行记录，其中，预定时间区间的长短可
以根据负载均衡服务器中存储空间的大小而设定。优选的，预定时间区间
可以设置为一小时。
作为一种可选的事实方式，在步骤S35负载均衡服务器对目标服务器
处理数据处理请求的任务处理时长进行记录之后，上述方法还包括：
步骤S37，根据任务处理时长与处理次数，计算每台应用服务器在预
定时间内的平均处理时长。
步骤S39，根据平均处理时长和处理次数，对应用服务器列表中的应
用服务器进行排序处理，其中，所述应用服务器列表用于记录应用服务器
集群中每台应用服务器的应用服务器信息。
具体的，通过步骤S37至步骤S39，负载均衡服务器可以根据应用服
务器集群中每台应用服务器的处理次数和处理时长，确定在预定时间区间
内，应用服务器集群中每台应用服务器用于处理数据处理请求所耗费的平
均处理时长。根据平均时长，对每台应用服务器按照平均时长由短到长进
行排序。对于平均时长相同的应用服务器，可以进一步的根据处理次数的
数量进行排序。
当然，负载均衡服务器还可以通过对在预定时间区间内每台应用服务
器用于处理数据处理请求所耗费的总时长与预定时间区间的时间长度，来
计算每台应用服务的负载率，通过负载率的高低对应用服务器列表中的应
用服务器进行排序处理。
作为一种可选的事实方式，在步骤S23根据数据处理请求从负载均衡
服务器中获取用于对数据处理请求进行处理的应用服务器信息中，可以包
括：
步骤S231b，以预定时间频率，从负载均衡服务器中获取应用服务器
列表中排序最高的应用服务器信息。
步骤S233b，将获取到的应用服务器信息，按时间顺序以增量的方式
存储至本地的缓存存储器中。
具体的，为了避免因频繁访问负载均衡服务器导致负载均衡服务器处
理性能下降的问题，可以通过步骤S231b至步骤S233b，以预定的时间频
率，从负载均衡服务器中获取当前时间段内负载率最低的应用服务器信息，
以增量的方式，将应用服务器信息缓存至反向代理服务器本地。其中，时
间频率可以根据反向代理服务器向负载均衡服务器发送的数据处理请求
的数量而定，优选的，可以将时间频率设置为每分钟一次。
通过以有序的方式从负载均衡服务器获取应用服务器列表并在本地
创建副本，可以避免因频繁随机的对负载均衡服务器进行访问导致的处理
性能下降的问题。
作为一种可选的事实方式，在步骤S25根据应用服务器信息，确定在
应用服务器集群中与应用服务信息对应的应用服务器为目标服务器，并将
接收到的数据处理请求转发至目标服务器中，可以包括：
步骤S251b，从本地的缓存存储器中获取应用服务器信息。
步骤S253b，在获取成功的情况下，将与应用服务器信息对应的应用
服务器确定为目标服务器。
具体的，通过步骤S251b至步骤S253b，直接从本地的缓存存储器中
获取应用服务器列表的缓存副本。当获取成功时，可以将缓存副本中负载
率最低或者处于空闲的应用服务器确定为目标服务器。在获取失败时，可
以直接从负载均衡服务器获取负载率最低或者处于空闲的应用服务器，并
将其确定为目标服务器。
当然，也可以对每次缓存到本地的应用服务器信息设定过期日期。在
反向代理服务器从本地获取应用服务器信息时，首先对当前时间是否已经
超过过期日期进行判断，当当前时间是否超过过期日期之后，从负载均衡
服务器中获取应用服务器信息。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都
表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受
所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序
或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实
施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根
据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当
然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理
解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软
件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如
ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可
以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例的
方法。
实施例2
根据本发明实施例，还提供了一种用于实施上述应用于反向代理服务
器上负载均衡的控制方法的负载均衡的控制装置，如图3所示，该装置包
括：第一接收模块21、获取模块23、第一处理模块25、第二接收模块27
和上报模块29。
其中，第一接收模块21，用于接收数据处理请求；获取模块23，用
于根据数据处理请求从负载均衡服务器中获取用于对数据处理请求进行
处理的应用服务器信息，其中，应用服务器信息用于记录在应用服务器集
群中负载最低的应用服务器的信息；第一处理模块25，用于根据应用服务
器信息，确定在应用服务器集群中与应用服务信息对应的应用服务器为目
标服务器，并将接收到的数据处理请求转发至目标服务器；第二接收模块
27，用于接收目标服务器根据数据处理请求返回的数据处理结果，其中，
数据处理结果至少包括：处理日志信息，处理日志信息为目标服务器处理
数据处理请求的执行记录；上报模块29，用于将数据处理结果上报至负载
均衡服务器。
通过上述第一接收模块21、获取模块23、第一处理模块25、第二接
收模块27和上报模块29，反向代理服务器在对客户端与应用服务器集群
中的每个应用服务器进行反向代理的同时，通过将每个应用服务器处理数
据处理请求时的日志文件上报至负载均衡服务器。并在反向代理服务器接
收到数据处理请求时，由负载均衡服务器根据每台应用服务器的处理日志
信息，确定的应用服务器在单位时间段内负载状态，并将预定时间内负载
率最低的应用服务器的信息反馈至反向代理服务器。达到了在不影响反向
代理的处理性能情况下，即可实现负载均衡的目的，从而实现了在高并发
场景下提高负载均衡服务器的执行效率的效果，从而解决了由于单台服务
器的处理能力有限，导致的高并发场景下的负载均衡效率低的问题。
作为一种可选的事实方式，获取模块23包括：子生成模块231a、子
发送模块233a和子接收送模块235a。
其中，子生成模块231a，用于当接收到数据处理请求时，生成用于获
取应用服务器信息的查询请求信息；子发送模块233a，用于将查询请求信
息发送至负载均衡服务器；子接收送模块235a，用于接收负载均衡服务器
发送的与查询请求信息对应的应用服务器信息，其中，应用服务器信息中
至少包括：与对应的应用服务器信息对应的应用服务器的基础配置信息和
路由信息。
具体的，在反向代理服务器接收到数据处理请求之后，通过向负载均
衡服务器发送查询请求信息，可以从负载均衡服务器中获取包含有在应用
服务器集群中在单位时间内的负载率最低的应用服务器的基础配置信息
和与该台应用服务器对应的路由信息。其中，基础配置信息至少包括应用
服务器的标识信息，路由信息至少包括应用服务器的路由地址。
在实际应用中，可以将包含有应用服务器集群中所有应用服务器的路
由地址的路由表存储于负载均衡服务器中。在向应用服务器集群中添加或
删除应用服务器时，只需要对负载均衡服务器中的路由表进行就修改即可。
作为一种可选的事实方式，第一处理模块25包括：第一子确定模块
251a、第一子获取模块253a和子转发模块255a。
其中，第一子确定模块251a，用于根据基础配置信息，确定应用服务
器集群中的目标服务器；第一子获取模块253a，用于从应用服务器信息中
获取与目标服务器对应的路由信息；子转发模块255a，用于根据路由信息，
将接收到的数据处理请求转发至目标服务器。
具体的，通过第一子确定模块251a、第一子获取模块253a和子转发
模块255a，反向代理服务器在通过应用服务器信息确认目标服务器的同时，
还可以通过应用服务器信息获取到与目标服务器对应的路由地址。从而使
反向代理服务器可以根据路由地址，将数据处理请求直接转发至目标服务
器当中。进而省去了反向服务器在确定目标服务器后，还需要到路由地址
表中查询与目标服务器对应的路由地址的步骤，进一步的优化了反向代理
服务器的处理效率，提高了整体的处理性能。
作为一种可选的事实方式，如图4所示，装置还包括：第一累加模块
31、第一判断模块33和第二处理模块35。
其中，第一累加模块31，用于负载均衡服务器在接收到处理日志信息
后，对目标服务器的处理次数进行累加，其中，处理次数用于记录每台应
用服务器处理数据处理请求的次数；第一判断模块33，用于负载均衡服务
器根据处理日志信息，判断目标服务器对数据处理请求是否处理成功；第
二处理模块35，用于当目标服务器对数据处理请求处理成功时，负载均衡
服务器对目标服务器处理数据处理请求的任务处理时长进行记录。
具体的，负载代理服务可以根据上报的处理日志信息对应用服务器处
理数据处理请求的次数进行记录，并对处理日志信息进行分析处理。其中，
可以通过根据处理日志信息中是否包含有错误代码，来判断目标服务器对
数据处理请求的处理是否成功。当处理日志信息中不存在错误代码时，从
处理日志信息中读取目标服务器对数据处理请求开始处理的时间和结束
处理的时间。根据开始处理时间和结束处理时间，确定目标服务器对数据
处理请求的处理时长。进一步的，可以将处理时长保存至应用服务器列表
当中。
在实际应用中，为了减小负载均衡服务器存储空间的开支，可以只对
预定时间区间内的数据处理结果进行记录，其中，预定时间区间的长短可
以根据负载均衡服务器中存储空间的大小而设定。优选的，预定时间区间
可以设置为一小时。
作为一种可选的事实方式，如图5所示，上述装置还包括：第一计算
模块37和排序模块39。
其中，第一计算模块37，用于根据任务处理时长与处理次数，计算每
台应用服务器在预定时间内的平均处理时长；排序模块39，用于根据平均
处理时长和处理次数，对应用服务器列表中的应用服务器进行排序处理，
其中，应用服务器列表用于保存应用服务器集群中每台应用服务器的应用
服务器信息。
具体的，通过上述第一计算模块37和排序模块39，负载均衡服务器
可以根据应用服务器集群中每台应用服务器的处理次数和处理时长，确定
在预定时间区间内，应用服务器集群中每台应用服务器用于处理数据处理
请求所耗费的平均处理时长。根据平均时长，对每台应用服务器按照平均
时长由短到长进行排序。对于平均时长相同的应用服务器，可以进一步的
根据处理次数的数量进行排序。
当然，负载均衡服务器还可以通过对在预定时间区间内每台应用服务
器用于处理数据处理请求所耗费的总时长与预定时间区间的时间长度，来
计算每台应用服务的负载率，通过负载率的高低对应用服务器列表中的应
用服务器进行排序处理。
作为一种可选的事实方式，获取模块23包括：第二子获取模块231b
和子缓存模块233b。
其中，第二子获取模块231b，用于以预定时间频率，从负载均衡服务
器中获取应用服务器列表中排序最高的应用服务器信息；子缓存模块233b，
用于将获取到的应用服务器信息，按时间顺序以增量的方式存储至本地的
缓存存储器中。
具体的，为了避免因频繁访问负载均衡服务器导致负载均衡服务器处
理性能下降的问题，可以通过上述第二子获取模块231b和子缓存模块
233b，以预定的时间频率，从负载均衡服务器中获取当前时间段内负载率
最低的应用服务器信息，以增量的方式，将应用服务器信息缓存至反向代
理服务器本地。其中，时间频率可以根据反向代理服务器向负载均衡服务
器发送的数据处理请求的数量而定，优选的，可以将时间频率设置为每分
钟一次。
通过以有序的方式从负载均衡服务器获取应用服务器列表并在本地
创建副本，可以避免因频繁随机的对负载均衡服务器进行访问导致的处理
性能下降的问题。
作为一种可选的事实方式，第一处理模块包括：第三子获取模块251b
和第二子确定模块253b。
其中，第三子获取模块251b，用于从本地的缓存存储器中获取应用服
务器信息；第二子确定模块253b，用于在获取成功的情况下，将与应用服
务器信息对应的应用服务器确定为目标服务器。
具体的，通过上述第三子获取模块251b和第二子确定模块253b，直
接从本地的缓存存储器中获取应用服务器列表的缓存副本。当获取成功时，
可以将缓存副本中负载率最低或者处于空闲的应用服务器确定为目标服
务器。在获取失败时，可以直接从负载均衡服务器获取负载率最低或者处
于空闲的应用服务器，并将其确定为目标服务器。
当然，也可以对每次缓存到本地的应用服务器信息设定过期日期。在
反向代理服务器从本地获取应用服务器信息时，首先对当前时间是否已经
超过过期日期进行判断，当当前时间是否超过过期日期之后，从负载均衡
服务器中获取应用服务器信息。
实施例3
根据本发明实施例，还提供了一种应用于负载均衡服务器上的负载均
衡的控制方法的服务器或终端，如图6所示，该负载均衡的控制方法包括：
步骤S41，接收由反向代理服务器上报的数据处理结果，其中，数据
处理结果中至少包括：处理日志信息。
步骤S43，根据数据处理结果，对与数据处理结果对应的应用服务器
的处理次数进行累加。
步骤S45，根据处理日志信息，判断应用服务器是否对数据处理请求
处理成功。
步骤S47，当应用服务器对数据处理请求处理成功时，记录应用服务
器处理数据处理请求的任务处理时长。
具体的，通过上述步骤S41至步骤S47，负载代理服务可以根据上报
的处理日志信息对应用服务器处理数据处理请求的次数进行记录，并对处
理日志信息进行分析处理。其中，可以通过根据处理日志信息中是否包含
有错误代码，来判断目标服务器对数据处理请求的处理是否成功。当处理
日志信息中不存在错误代码时，从处理日志信息中读取目标服务器对数据
处理请求开始处理的时间和结束处理的时间。根据开始处理时间和结束处
理时间，确定目标服务器对数据处理请求的处理时长。进一步的，可以将
处理时长保存至应用服务器列表当中。
作为一种可选的事实方式，在步骤S47记录应用服务器处理数据处理
请求的任务处理时长之后，上述方法还包括：
步骤S49，根据任务处理时长与处理次数，计算应用服务器集群中的
每台应用服务器在预定时间内的平均处理时长。
步骤S51，根据平均处理时长和处理次数，对应用服务器列表中的应
用服务器进行排序处理，其中，应用服务器列表用于保存应用服务器集群
中每台应用服务器的应用服务器信息。
具体的，通过上述步骤S49至步骤S51，负载均衡服务器可以根据应
用服务器集群中每台应用服务器的处理次数和处理时长，确定在预定时间
区间内，应用服务器集群中每台应用服务器用于处理数据处理请求所耗费
的平均处理时长。根据平均时长，对每台应用服务器按照平均时长由短到
长进行排序。对于平均时长相同的应用服务器，可以进一步的根据处理次
数的数量进行排序。
当然，负载均衡服务器还可以通过对在预定时间区间内每台应用服务
器用于处理数据处理请求所耗费的总时长与预定时间区间的时间长度，来
计算每台应用服务的负载率，通过负载率的高低对应用服务器列表中的应
用服务器进行排序处理。
实施例4
根据本发明实施例，还提供了一种用于实施上述应用于负载均衡服务
器上的负载均衡的控制方法的负载均衡的控制装置，如图7所示，该装置
包括：第三接收模块41、第二累加模块43、第二判断模块45和记录模块
47。
其中，第三接收模块41，用于接收由反向代理服务器上报的数据处理
结果，其中，数据处理结果中至少包括：处理日志信息；第二累加模块43，
用于根据数据处理结果，对与数据处理结果对应的应用服务器的处理次数
进行累加；第二判断模块45，用于根据处理日志信息，判断应用服务器是
否对数据处理请求处理成功；记录模块47，用于当应用服务器对数据处理
请求处理成功时，记录应用服务器处理数据处理请求的任务处理时长。
具体的，通过上述第三接收模块41、第二累加模块43、第二判断模
块45和记录模块47，负载代理服务可以根据上报的处理日志信息对应用
服务器处理数据处理请求的次数进行记录，并对处理日志信息进行分析处
理。其中，可以通过根据处理日志信息中是否包含有错误代码，来判断目
标服务器对数据处理请求的处理是否成功。当处理日志信息中不存在错误
代码时，从处理日志信息中读取目标服务器对数据处理请求开始处理的时
间和结束处理的时间。根据开始处理时间和结束处理时间，确定目标服务
器对数据处理请求的处理时长。进一步的，可以将处理时长保存至应用服
务器列表当中。
作为一种可选的事实方式，如图8所示，上述装置还包括：第二计算
模块49和第三处理模块51。
其中，第二计算模块49，用于根据任务处理时长与处理次数，计算应
用服务器集群中的每台应用服务器在预定时间内的平均处理时长；第三处
理模块51，用于根据平均处理时长和处理次数，对应用服务器列表中的应
用服务器进行排序处理，其中，应用服务器列表用于保存应用服务器集群
中每台应用服务器的应用服务器信息。
具体的，通过上述第二计算模块49和第三处理模块51，负载均衡服
务器可以根据应用服务器集群中每台应用服务器的处理次数和处理时长，
确定在预定时间区间内，应用服务器集群中每台应用服务器用于处理数据
处理请求所耗费的平均处理时长。根据平均时长，对每台应用服务器按照
平均时长由短到长进行排序。对于平均时长相同的应用服务器，可以进一
步的根据处理次数的数量进行排序。
当然，负载均衡服务器还可以通过对在预定时间区间内每台应用服务
器用于处理数据处理请求所耗费的总时长与预定时间区间的时间长度，来
计算每台应用服务的负载率，通过负载率的高低对应用服务器列表中的应
用服务器进行排序处理。
实施例5
根据本发明实施例，还提供了一种用于实施上述方法的负载均衡的控
制系统，如图9所示，该系统包括：应用服务器集群20、负载均衡服务器
30和反向代理服务器40。
其中，应用服务器集群20，至少包括两台应用服务器，用于对客户端
发送的数据处理请求进行处理，得到数据处理结果；负载均衡服务器30，
用于对与反向代理服务器上报的数据处理结果对应的应用服务器的处理
次数进行累加，并根据数据处理结果中的处理日志信息，判断应用服务器
是否对数据处理请求处理成功，当应用服务器对数据处理请求处理成功时，
记录应用服务器处理数据处理请求的任务处理时长，并根据任务处理时长
和处理次数对应用服务器列表中的应用服务器进行排序；反向代理服务器
40，与应用服务器集群与负载均衡服务器建立通讯连接，用于将接收到的
客户端发送的数据处理请求，根据从负载均衡服务器中获取的用于对数据
处理请求进行处理的应用服务器信息确定用于处理数据处理请求的目标
服务器，然后将数据处理请求转发至应用服务器中，并将接收到的应用服
务器返回的数据处理结果，上报至负载均衡服务器。
作为一种可选的事实方式，如图10所示，通过引入负载均衡服务器
30对应用服务器集群20中的应用服务器的负载状态进行监控。当反向代
理服务器40每次进行反向代理时包括如下步骤：
步骤S1，先通过负载均衡服务器30查询应用服务器集群20中负载
压力最小的应用服务器。
步骤S2，将应用服务器集群20中负载压力最小的应用服务器作为目
标服务器，并将数据处理请求发送至目标服务器。
步骤S3，接收目标服务器返回的数据处理结果。
步骤S4，将数据处理结果上报至负载均衡服务器30。
步骤S5，负载均衡服务器30可以根据反向代理服务器40上报的数
据处理结果对应用服务器列表中的每个服务器的负载压力情况和处理成
功率情况进行更新。
其中，反向代理服务器的反向代理功能，可以通过Nginx反向代理服
务实现。
作为一种可选的事实方式，如图11所示，在反向代理服务器40中包
括：缓存装置41。其中，缓存装置41，缓存装置与负载均衡服务器建立
通讯连接，用于以预定时间频率，从负载均衡服务器中获取应用服务器列
表中排序最高的应用服务器信息，并将获取到的应用服务器信息，按时间
顺序以增量的方式进行存储。
具体的，为了减少反向代理服务器40每次都从负载均衡服务器30进
行负载压力的查询，导致的额外时间的消耗。反向代理服务器40可以在
本地的缓存装置41中缓存最近一段时间的查询结果。其中，当反向代理
服务器40每次向负载均衡服务器30查询之前，可以先从本地的缓存装置
41中对应用服务器信息进行查询，只当缓存装置41中缓存的内容过期或
者对缓存装置41访问失败时，再从负载均衡服务器30中获取压力最小的
服务器。
实施例6
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上
述存储介质可以用于保存上述实施例以提供的一种负载均衡的控制方法
所执行的程序代码。
可选地，在本实施例中，上述存储介质可以位于计算机网络中的多个
网络设备中的至少一个网络设备。
可选地，在本实施例中，存储介质902被设置为存储用于执行以下步
骤的程序代码：
S1，接收数据处理请求；
S2，根据数据处理请求从负载均衡服务器中获取用于对数据处理请求
进行处理的应用服务器信息，其中，应用服务器信息用于记录在应用服务
器集群中负载最低的应用服务器的信息；
S3，根据应用服务器信息，确定在应用服务器集群中与应用服务信息
对应的应用服务器为目标服务器，并将接收到的数据处理请求转发至目标
服务器；
S4，接收目标服务器根据数据处理请求返回的数据处理结果，其中，
数据处理结果至少包括：处理日志信息，处理日志信息为目标服务器处理
数据处理请求的执行记录；
S5，将数据处理结果上报至负载均衡服务器
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：当
接收到数据处理请求时，生成用于获取应用服务器信息的查询请求信息；
将查询请求信息发送至负载均衡服务器；接收负载均衡服务器发送的与查
询请求信息对应的应用服务器信息，其中，应用服务器信息中至少包括：
与对应的应用服务器信息对应的应用服务器的基础配置信息和路由信息
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：根
据基础配置信息，确定应用服务器集群中的目标服务器；从应用服务器信
息中获取与目标服务器对应的路由信息；根据路由信息，将接收到的数据
处理请求转发至目标服务器。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：负
载均衡服务器在接收到处理日志信息后，对目标服务器的处理次数进行累
加，其中，处理次数用于记录每台应用服务器处理数据处理请求的次数；
负载均衡服务器根据处理日志信息，判断目标服务器对数据处理请求是否
处理成功；当目标服务器对数据处理请求处理成功时，负载均衡服务器对
目标服务器处理数据处理请求的任务处理时长进行记录。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：根
据任务处理时长与处理次数，计算每台应用服务器在预定时间内的平均处
理时长；
根据平均处理时长和处理次数，对应用服务器列表中的应用服务器进
行排序处理，其中，应用服务器列表用于保存应用服务器集群中每台应用
服务器的应用服务器信息。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：以
预定时间频率，从负载均衡服务器中获取应用服务器列表中排序最高的应
用服务器信息；将获取到的应用服务器信息，按时间顺序以增量的方式存
储至本地的缓存存储器中。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：从
本地的缓存存储器中获取应用服务器信息；在获取成功的情况下，将与应
用服务器信息对应的应用服务器确定为目标服务器。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只
读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random
Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介
质。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为
独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。
基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的
部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计
算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算
机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施
例所述方法的全部或部分步骤。
在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实
施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可
通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，
例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外
的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，
或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦
合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或
通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，
作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地
方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的
部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元
中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在
一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软
件功能单元的形式实现。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的
普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进
和润饰，这些改进和润饰也应视为本发明的保护范围。