一种应用服务的负载均衡方法及系统.pdf

上传人:a**** 文档编号:4310138 上传时间:2018-09-13 格式:PDF 页数:17 大小:463.77KB
返回 下载 相关 举报
摘要
申请专利号:

CN201110433096.7

申请日:

2011.12.21

公开号:

CN102611735A

公开日:

2012.07.25

当前法律状态:

授权

有效性:

有权

法律详情:

授权|||专利申请权的转移IPC(主分类):H04L 29/08登记生效日:20151104变更事项:申请人变更前权利人:奇智软件(北京)有限公司变更后权利人:北京奇虎科技有限公司变更事项:地址变更前权利人:100016 北京市朝阳区酒仙桥路14号兆维大厦4层东侧单元变更后权利人:100088 北京市西城区新街口外大街28号D座112室(德胜园区)变更事项:申请人变更后权利人:奇智软件(北京)有限公司|||实质审查的生效IPC(主分类):H04L 29/08申请日:20111221|||公开

IPC分类号:

H04L29/08

主分类号:

H04L29/08

申请人:

奇智软件(北京)有限公司

发明人:

李强; 黄蔚

地址:

100016 北京市朝阳区酒仙桥路14号兆维大厦4层东侧单元

优先权:

专利代理机构:

北京润泽恒知识产权代理有限公司 11319

代理人:

苏培华

PDF下载: PDF下载
内容摘要

本申请提供了一种应用服务的负载均衡方法及系统,以解决目前网络服务中的负载均衡问题。所述方法包括:不断获取后端服务器的当前负载信息,所述当前负载信息包括后端服务器的应用程序运行数据,或者包括后端服务器的应用程序运行数据和性能数据;在每个获取周期内,依据所述当前负载信息重新计算后端服务器的权重;依据每次计算的权重调整后端服务器的分配,并选择后端服务器将客户端的接入请求进行路由。与传统的应用服务的负载均衡方法相比,本申请能够在完成同样功能的多个网络设备之间实现业务量的合理分配,而不至于出现一台设备过忙,其他设备未能充分发挥其作用的情况。

权利要求书

1.一种应用服务的负载均衡方法,其特征在于,包括:不断获取后端服务器的当前负载信息,所述当前负载信息包括后端服务器的应用程序运行数据,或者包括后端服务器的应用程序运行数据和性能数据;其中,所述应用程序运行数据是后端服务器的应用程序的运行数据,所述后端服务器为终端应用程序提供网络服务,所述终端应用程序与后端服务器的应用程序对应同一应用服务;在每个获取周期内,依据所述当前负载信息重新计算后端服务器的权重;依据每次计算的权重调整后端服务器的分配,并选择后端服务器将客户端的接入请求进行路由。2.根据权利要求1所述的方法,其特征在于:所述性能数据包括内存使用信息,和/或,CPU使用信息;所述应用程序运行数据包括实际在线人数,和/或正在下载的应用程序数,和/或正在下载的数据量,和/或实际连接数。3.根据权利要求1所述的方法,其特征在于,还包括:通过路由表维护所有可分配的后端服务器,所述路由表中记录了所有可分配的后端服务器的配置信息。4.根据权利要求3所述的方法,其特征在于,还包括:定时获取路由表中后端服务器的运行状态信息;依据所述运行状态信息检测相应的后端服务器是否异常或失效,并将异常或失效的后端服务器的配置信息从路由表中删除。5.根据权利要求3所述的方法,其特征在于,还包括:通过向所述路由表中添加后端服务器的配置信息,动态添加可分配的后端服务器。6.根据权利要求1至3任一所述的方法,其特征在于,还包括:预先配置后端服务器的最大处理能力,所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息;在每个获取周期内,依据获取的当前负载信息和所配置的最大处理能力,检测后端服务器是否满载,并对满载的后端服务器进行访问控制。7.根据权利要求1至3任一所述的方法,其特征在于,还包括:每个后端服务器上预先配置了相应的最大处理能力,所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息;每个后端服务器依据当前负载信息和所配置的最大处理能力,定时检测是否满载;定时获取后端服务器是否满载,并对满载的后端服务器进行访问控制。8.根据权利要求1至3任一所述的方法,其特征在于,所述定时获取后端服务器的当前负载信息之前,还包括:根据后端服务的类型,选择配置相适应的与后端服务器通信的交互协议;如果后端服务的类型调整,则重新配置相适应的与后端服务器通信的交互协议。9.根据权利要求1所述的方法,其特征在于,所述定时获取后端服务器的当前负载信息,包括:后端服务器提供监控接口,通过所述监控接口定时获取后端服务器的当前负载信息。10.根据权利要求1所述的方法,其特征在于,所述依据每次计算的权重调整后端服务器的分配,并选择后端服务器将客户端的接入请求进行路由,包括:依据每次计算的权重调整后端服务器的分配概率;按照所述分配概率随机选择后端服务器将客户端的接入请求进行路由。11.一种应用服务的负载均衡系统,其特征在于,包括:负载查询模块,用于不断获取后端服务器的当前负载信息,所述当前负载信息包括后端服务器的应用程序运行数据,或者包括后端服务器的应用程序运行数据和性能数据;其中,所述应用程序运行数据是后端服务器的应用程序的运行数据,所述后端服务器为终端应用程序提供网络服务,所述终端应用程序与后端服务器的应用程序对应同一应用服务;权重计算模块,用于在每个获取周期内,依据所述当前负载信息重新计算后端服务器的权重;负载调整模块,用于依据每次计算的权重调整后端服务器的分配,并选择后端服务器将客户端的接入请求进行路由。12.根据权利要求11所述的系统,其特征在于:所述性能数据包括内存使用信息,和/或,CPU使用信息;所述应用程序运行数据包括实际在线人数,和/或正在下载的应用程序数,和/或正在下载的数据量,和/或实际连接数。13.根据权利要求11所述的系统,其特征在于,还包括:负载维护模块,用于通过路由表维护所有可分配的后端服务器,所述路由表中记录了所有可分配的后端服务器的配置信息。14.根据权利要求13所述的系统,其特征在于,还包括:动态删除模块,用于定时获取路由表中后端服务器的运行状态信息;依据所述运行状态信息检测相应的后端服务器是否异常或失效,并将异常或失效的后端服务器的配置信息从路由表中删除。15.根据权利要求13所述的系统,其特征在于,还包括:动态添加模块,用于通过向所述路由表中添加后端服务器的配置信息,动态添加可分配的后端服务器。16.根据权利要求11至13任一所述的系统,其特征在于,还包括:第一访问控制模块,用于预先配置后端服务器的最大处理能力,所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息;在每个获取周期内,依据获取的当前负载信息和所配置的最大处理能力,检测后端服务器是否满载,并对满载的后端服务器进行访问控制。17.根据权利要求11至13任一所述的系统,其特征在于,还包括:第二访问控制模块,用于每个后端服务器上预先配置相应的最大处理能力,所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息;每个后端服务器依据当前负载信息和所配置的最大处理能力,定时检测是否满载;定时获取后端服务器是否满载,并对满载的后端服务器进行访问控制。18.根据权利要求11至13任一所述的系统,其特征在于,还包括:通信配置模块,用于根据后端服务的类型,选择配置相适应的与后端服务器通信的交互协议;如果后端服务的类型调整,则重新配置相适应的与后端服务器通信的交互协议。

说明书

一种应用服务的负载均衡方法及系统

技术领域

本申请涉及网络技术,特别是涉及一种应用服务的负载均衡方法及系
统。

背景技术

负载均衡(又称为负载分担),英文名称为Load Balance,其意思就是将
负载(工作任务)进行平衡、分摊到多个操作单元上进行执行,例如Web
服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而
共同完成工作任务。

通常,负载均衡会根据网络的不同层次(网络七层)来划分。其中,第
二层的负载均衡指将多条物理链路当作一条单一的聚合逻辑链路使用,这就
是链路聚合(Trunking)技术,它不是一种独立的设备,而是交换机等网络
设备的常用技术。现代负载均衡技术通常操作于网络的第四层或第七层,这
是针对网络应用的负载均衡技术,它完全脱离于交换机、服务器而成为独立
的技术设备。这也是本文现在要讨论的对象。

负载均衡有两方面的含义:第一层含义是,单个重负载的运算分担到多
台节点设备上做并行处理,每个节点设备处理结束后,将结果汇总,返回给
用户,系统处理能力得到大幅度提高,这就是我们常说的集群(clustering)
技术。第二层含义是:大量的并发访问或数据流量分担到多台节点设备上分
别处理,减少用户等待响应的时间,这主要针对Web服务器、FTP服务器、
企业关键应用服务器等网络应用。这里主要讨论第二层含义所指的负载均
衡。

目前在很多网络服务中,现有网络的各个核心部分随着用户与业务量的
提高,访问量和数据流量的快速增长,其处理能力和计算强度也相应地增大,
使得单一的服务器设备根本无法承担。在此情况下,如果扔掉现有设备去做
大量的硬件升级,这样将造成现有资源的浪费,而且如果再面临下一次业务
量的提升时,这又将导致再一次硬件升级的高额成本投入,甚至性能再卓越
的设备也不能满足当前业务量增长的需求。

基于此,目前需要解决的问题是:提供一种适用于网络服务的负载均衡
方法,能够在完成同样功能的多个网络设备之间实现业务量的合理分配,而
不至于出现一台设备过忙,其他设备未能充分发挥其作用的情况。

发明内容

本申请提供了一种应用服务的负载均衡方法及系统,以解决目前网络服
务中的负载均衡问题。

为了解决上述问题,本申请公开了一种应用服务的负载均衡方法,包括:

不断获取后端服务器的当前负载信息,所述当前负载信息包括后端服务
器的应用程序运行数据,或者包括后端服务器的应用程序运行数据和性能数
据;其中,所述应用程序运行数据是后端服务器的应用程序的运行数据,所
述后端服务器为终端应用程序提供网络服务,所述终端应用程序与后端服务
器的应用程序对应同一应用服务;

在每个获取周期内,依据所述当前负载信息重新计算后端服务器的权
重;

依据每次计算的权重调整后端服务器的分配,并选择后端服务器将客户
端的接入请求进行路由。

优选的,所述性能数据包括内存使用信息,和/或,CPU使用信息;所
述应用程序运行数据包括实际在线人数,和/或正在下载的应用程序数,和/
或正在下载的数据量,和/或实际连接数。

优选的,所述方法还包括:通过路由表维护所有可分配的后端服务器,
所述路由表中记录了所有可分配的后端服务器的配置信息。

优选的,所述方法还包括:定时获取路由表中后端服务器的运行状态信
息;依据所述运行状态信息检测相应的后端服务器是否异常或失效,并将异
常或失效的后端服务器的配置信息从路由表中删除。

优选的,所述方法还包括:通过向所述路由表中添加后端服务器的配置
信息,动态添加可分配的后端服务器。

优选的,所述方法还包括:预先配置后端服务器的最大处理能力,所述
最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或
应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用
信息;在每个获取周期内,依据获取的当前负载信息和所配置的最大处理能
力,检测后端服务器是否满载,并对满载的后端服务器进行访问控制。

优选的,所述方法还包括:每个后端服务器上预先配置了相应的最大处
理能力,所述最大处理能力表示为最大在线人数、和/或最大内存使用信息、
和/或最大CPU使用信息;每个后端服务器依据当前负载信息和所配置的最
大处理能力,定时检测是否满载;定时获取后端服务器是否满载,并对满载
的后端服务器进行访问控制。

优选的,所述定时获取后端服务器的当前负载信息之前,还包括:根据
后端服务的类型,选择配置相适应的与后端服务器通信的交互协议;如果后
端服务的类型调整,则重新配置相适应的与后端服务器通信的交互协议。

优选的,所述定时获取后端服务器的当前负载信息,包括:后端服务器
提供监控接口,通过所述监控接口定时获取后端服务器的当前负载信息。

优选的,所述依据每次计算的权重调整后端服务器的分配,并选择后端
服务器将客户端的接入请求进行路由,包括:依据每次计算的权重调整后端
服务器的分配概率;按照所述分配概率随机选择后端服务器将客户端的接入
请求进行路由。

本申请还提供了一种应用服务的负载均衡系统,包括:

负载查询模块,用于不断获取后端服务器的当前负载信息,所述当前负
载信息包括后端服务器的应用程序运行数据,或者包括后端服务器的应用程
序运行数据和性能数据;其中,所述应用程序运行数据是后端服务器的应用
程序的运行数据,所述后端服务器为终端应用程序提供网络服务,所述终端
应用程序与后端服务器的应用程序对应同一应用服务;

权重计算模块,用于在每个获取周期内,依据所述当前负载信息重新计
算后端服务器的权重;

负载调整模块,用于依据每次计算的权重调整后端服务器的分配,并选
择后端服务器将客户端的接入请求进行路由。

优选的,所述性能数据包括内存使用信息,和/或,CPU使用信息;所
述应用程序运行数据包括实际在线人数,和/或应用程序的最大下载个数、和
/或应用程序的最大下载数据量、和/或正在下载的应用程序数,和/或正在下
载的数据量,和/或实际连接数。

优选的,所述系统还包括:负载维护模块,用于通过路由表维护所有可
分配的后端服务器,所述路由表中记录了所有可分配的后端服务器的配置信
息。

优选的,所述系统还包括:动态删除模块,用于定时获取路由表中后端
服务器的运行状态信息;依据所述运行状态信息检测相应的后端服务器是否
异常或失效,并将异常或失效的后端服务器的配置信息从路由表中删除。

优选的,所述系统还包括:动态添加模块,用于通过向所述路由表中添
加后端服务器的配置信息,动态添加可分配的后端服务器。

优选的,所述系统还包括:第一访问控制模块,用于预先配置后端服务
器的最大处理能力,所述最大处理能力表示为最大在线人数、和/或最大内存
使用信息、和/或最大CPU使用信息;在每个获取周期内,依据获取的当前
负载信息和所配置的最大处理能力,检测后端服务器是否满载,并对满载的
后端服务器进行访问控制。

优选的,所述系统还包括:第二访问控制模块,用于每个后端服务器上
预先配置相应的最大处理能力,所述最大处理能力表示为最大在线人数、和
/或最大内存使用信息、和/或最大CPU使用信息;每个后端服务器依据当前
负载信息和所配置的最大处理能力,定时检测是否满载;定时获取后端服务
器是否满载,并对满载的后端服务器进行访问控制。

优选的,所述系统还包括:通信配置模块,用于根据后端服务的类型,
选择配置相适应的与后端服务器通信的交互协议;如果后端服务的类型调
整,则重新配置相适应的与后端服务器通信的交互协议。

与现有技术相比,本申请包括以下优点:

首先,本申请针对高并发的客户端请求,通过不断获取后端服务器的当
前负载信息,并依据所述当前负载信息计算后端服务器的权重,然后依据每
次计算的权重调整后端服务器的分配。简而言之,本申请在客户端需要接入
某个应用服务的时候,首先请求接入分发(dispatch)服务,该分发服务会
根据后端服务器的负载情况(如实际在线人数等),动态调整分发策略,动
态地返回后端相对空闲的服务器给客户端接入。与传统的应用服务的负载均
衡方法相比,本申请能够在完成同样功能的多个网络设备之间实现业务量的
合理分配,而不至于出现一台设备过忙,其他设备未能充分发挥其作用的情
况。

其次,本申请还能够定时从后端服务器获取其运行状态,如果发现某个
后端服务器的状态异常或已经失效,可以实时地从路由表中移除,避免再将
该后端服务器分配给客户端。相应的,也可以通过在路由表中添加后端服务
器的配置信息,而动态加入后端服务器供分配。

再次,本申请由于能够定时获取后端服务器的负载情况,因此当某个后
端服务器的负载接近最大处理能力时,可以对其进行访问控制,即不再将客
户端请求路由给该服务器,从而有效地保护后端服务。

再次,本申请中的分发(dispatch)服务器基于Erlang框架创建,可以
不局限后端服务的类型,通过动态配置分发(dispatch)服务器与后端服务
器通信的交互协议,满足不同类型的后端服务。

当然,实施本申请的任一产品不一定需要同时达到以上所述的所有优
点。

附图说明

图1是本申请实施例所述一种应用服务的负载均衡系统的网络架构图;

图2是本申请实施例所述一种应用服务的负载均衡方法流程图;

图3是本申请实施例所述一种应用服务的负载均衡系统的结构图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图
和具体实施方式对本申请作进一步详细的说明。

本申请所述的负载均衡主要指:大量的并发访问或数据流量分担到多台
节点设备上分别处理,减少用户等待响应的时间,这主要针对Web服务器、
FTP服务器、企业关键应用服务器等网络应用。

本申请在客户端需要接入某个应用服务的时候,首先请求接入分发
(dispatch)服务,该分发服务会根据后端服务器的负载情况(如实际在线
人数等),动态调整分发策略,动态地返回后端相对空闲的服务器给客户端
接入。

下面通过实施例首先介绍本申请的网络架构。

参照图1所示,是本申请实施例所述一种应用服务的负载均衡系统的网
络架构图。

本申请实施例所述的负载均衡主要通过分发(dispatch)服务器实现,
多个客户端与所述分发(dispatch)服务器连接,分发(dispatch)服务器与
多台后端服务器连接,其中每台后端服务器能够完成同样的业务功能。

当某客户端发起接入应用服务的请求时,该接入请求首先路由到所述分
发服务器,分发服务器根据后端服务器的负载情况动态调整分配策略,并根
据当前的分配策略选择一台服务器,将该接入请求路由到该服务器上处理。

图1所示的负载均衡网络架构适用于各种网络服务,例如IM(Instant 
Messenger,即时通讯)服务、云查杀服务、云盘服务、Push Service服务等
等。

基于图1,下面通过图2所示实施例对本申请所述方法的实现流程进行
详细说明。

参照图2所示,是本申请实施例所述一种应用服务的负载均衡方法流程
图。

以IM业务为例,针对大量IM客户端的高并发业务请求,分发(dispatch)
服务器将按照以下步骤进行负载均衡处理:

步骤201,不断获取后端服务器的当前负载信息,所述当前负载信息包
括后端服务器的应用程序运行数据,或者包括后端服务器的应用程序运行数
据和性能数据;

其中,所述应用程序运行数据是后端服务器的应用程序的运行数据,所
述后端服务器为终端应用程序提供网络服务,所述终端应用程序与后端服务
器的应用程序对应同一应用服务;

简而言之,提供应用服务的应用程序可分为客户端程序和服务器端的后
台程序,所述终端应用程序即是指客户端程序,所述后端服务器的应用程序
即是指后台程序,两者配合运行提供应用服务。

所述定时获取可以是分发服务器主动查询获取,也可以是被动获取,即
后端服务器定时上报自己的负载情况。

本申请实施例将采用主动获取的方式,具体如下:

每台后端服务器可以提供自己的监控接口,分发服务器可以自己编写插
件,该插件可以通过所述监控接口定期获取每台后端服务器的负载情况。

所述当前负载信息表示后端服务器在每个获取周期的实时负载情况,负
载信息可包括应用程序运行数据,或者包括应用程序运行数据和性能数据,
或者包括其他可反映应用程序运行情况的数据。

其中,所述性能数据是指能够反映后端服务器软硬件性能的数据,可包
括内存使用信息,和/或,CPU使用信息等。所述应用程序运行数据是指能
够反映后端服务器中应用程序的运行情况的数据,可包括实际在线人数,和
/或正在下载的应用程序数,和/或正在下载的数据量,和/或实际连接数等。
这些负载信息都是动态变量数据,都会随着时间而实时改变。

其中,在IM应用中,实际在线人数能够很合理地衡量后端服务器的实
际负载情况,通过统计实际在线人数,可以剔除从统计开始到当前时刻所有
统计出来的在线人数中,当前时刻实际在线的人数,而不是从开始到现在的
统计数据,因为在这个过程中有些客户端可能已经下线。例如,从t时刻到
t1时刻的一段时间内,总共有100个客户端连接上后端服务器,但是相继有
30人下线,因此在t1时刻的实际在线人数是70,而不是曾经与服务器建立
过连接的100人。

在多媒体下载应用,如音乐、视频、电影电视等网络下载中,正在下载
的应用程序数是指统计下载列表中当前正在下载的应用程序数,不包括已经
下载完毕和下载列表中未开始下载的应用程序数,因此正在下载的应用程序
数也能够合理地衡量后端服务器的实际负载情况。

进一步的,在应用程序的下载过程中,每个应用程序下载的数据量多少
也会影响后端服务器的负载,因此也可以统计出每个正在下载的应用程序的
下载数据量,然后累加,就可以得到正在下载的所有应用程序的数据量,该
数据量也能够合理地衡量后端服务器的实际负载情况。

此外,在其他连接多个客户端的应用中,通过统计实际连接数也可以反
映出后端服务器的实际负载情况。所述实际连接数是指与后端服务器保持连
接并进行交互的客户端数,不包含曾经连接过服务器但已经暂时或永久断开
连接的客户端,也不包含任务队列中等待与服务器建立连接的客户端。

内存使用信息和CPU使用信息可从服务器的性能方面衡量了后端服务
器的负载情况,服务器处理的业务不同,所耗费的内存和CPU也是不同的,
因此无论业务量的大小如何,通过服务器的内存和/或CPU使用信息可以反
映出一台服务器在当前的实际负载情况。具体的,所述内存或CPU的使用
信息可以表示为内存或CPU的使用率,或者表示为已经使用的内存或CPU
大小等。

此外,负载信息除以上列举的三种之外,还可以包含磁盘的读写、网卡
的读写等参数信息。

步骤202,在每个获取周期内,依据所述当前负载信息重新计算后端服
务器的权重;

即在每个获取周期内,每次获取到负载信息后,都会依据负载情况对每
台服务器的权重进行计算。当然,如果一台后端服务器的负载情况没有变化,
为了节省计算,也可以直接使用最近一次的权重计算结果。

在计算权重时,可采用下述的计算方法:

设定实际在线人数以x1表示,其权值为a;内存使用信息以x2表示,
其权值为b;CPU使用信息以x3表示,其权值为c;按照以下公式计算得到
一台后端服务器的总权重Y;

Y=1-(x1×a+x2×b+x3×c)

其中,“1-”表示权重高的服务器优先分配。

当然,上述计算方法仅是举例说明,可以采用其他的权重计算,本申请
对此不做限定。

步骤203,依据每次计算的权重调整后端服务器的分配,并选择后端服
务器将客户端的接入请求进行路由。

在每个获取周期内,与上一周期相比,如果后端服务器的权重有变化,
就需要重新调整服务器的分配,因为每次的分配是依据权重而完成。例如,
总共有A、B、C三台后端服务器,在上一获取周期中,按照权重由高到低
的排序是B、A、C,权重高的服务器比权重低的服务器处理更多的业务请
求,因此服务器B分配的业务请求较多,服务器A其次,服务器C最少。
在下一获取周期中,按照权重由高到低的排序变更为C、A、B,因此此时
服务器C分配的业务请求较多,服务器A其次,服务器B最少。

具体的,步骤203可以包含以下两个子步骤:

子步骤1,依据每次计算的权重调整后端服务器的分配概率;

按照权重高的服务器比权重低的服务器处理更多业务请求的原则,权重
高的服务器得到的分配机会较多,权重低得服务器得到的分配机会相对较
少。如果后端服务器的权重有调整,就需要相应调整分配概率。

例如,按照权重由高到低,服务器A的权重为0.5,服务器B的权重为
0.3,服务器C的权重为0.2,则相应的分配概率依次是50%、30%和20%。
如果权重从高到低调整为服务器B是0.4、服务器C是0.3、服务器A是0.3,
则相应的分配概率依次调整为40%、30%、30%。

子步骤2,按照所述分配概率随机选择后端服务器将客户端的接入请求
进行路由。

在负载均衡过程中,每次分配服务器是依据上述的分配概率随机进行,
即每次随机选择一台后端服务器,但总体保持各服务器的随机分配概率。例
如,在某一获取周期内,服务器A、B、C的分配概率是50%、30%和20%,
则总共分配10次请求,其中5次请求分配给服务器A处理,3次请求分配
给服务器B处理,2次请求分配给服务器C处理。

在选定某台后端服务器后,可以将当前的客户端的接入请求路由给所选
定的这台服务器。

综上所述,由上述流程可以看出,上述的适用于各种应用服务的负载均
衡方法能够根据后端服务器的负载情况,动态调整分发策略,动态地返回后
端相对空闲的服务器给客户端接入。与传统的应用服务的负载均衡方法相
比,上述方法能够在完成同样功能的多个网络设备之间实现业务量的合理分
配,而不至于出现一台设备过忙,其他设备未能充分发挥其作用的情况。

此外,分发服务器除了可以采用图2所示的负载均衡方法外,也可以采
用以下几种负载均衡方法中的任意一种:

(1)轮询法

在一个任务队列里,队列的每个成员(节点)都具有相同的地位,轮询
法简单地在这组成员中顺序轮转选择。在负载均衡环境中,分发服务器将新
的请求轮流发给任务队列中的下一节点,如此连续、周而复始,每个集群的
节点都在相等的地位下被轮流选择。

轮询法的活动是可预知的,每个节点被选择的机会是1/N,因此很容
易计算出节点的负载分布。轮询法典型的适用于集群中所有节点的处理能力
和性能均相同的情况。

(2)最少连接法

在最少连接法中,分发服务器纪录目前所有的活跃连接,把下一个新的
请求发给当前含有最少连接数的节点。

这种方法比较适合后端业务相同,机器配置相同,并且每个连接负载基
本类似的服务,比如IM业务。

(3)加权轮询调度法

加权轮询调度(Weighted Round-Robin Scheduling)方法用相应的权值表
示节点的处理性能,根据权值的高低顺序并按照轮询的方式将任务请求分配
到各节点。权值高的结点比权值低的结点处理更多的任务请求,相同权值的
结点处理相同份额的请求。

在整个业务处理过程中,这种加权轮询调度法对节点处理性能的权值设
置是固定的,不会随着节点实际性能的变化而修改权值,但是图2所示的方
法可以根据节点的实际负载情况动态修改权值,动态进行请求的分配。

基于以上内容,下面通过另一个实施例进行说明。在该实施例中,分发
服务器除可以采用图2所示的负载均衡方法外,还具有动态添加、动态删除
与其连接的后端服务器,以及根据后端服务器的负载情况进行后端访问控制
等功能。下面分别详细说明。

分发服务器采用路由表维护所有可分配的后端服务器,所述路由表中记
录了所有可分配的后端服务器的配置信息,所述配置信息包括服务器的IP
地址、端口配置等信息。在每个获取周期内,分发服务器按照所述路由表获
取路由表中记录的后端服务器的负载情况,并动态地进行负载调整。

基于所述路由表的维护,分发服务器还具有以下特点:

1、动态删除后端服务器

具体包含以下两个子步骤:

子步骤1,定时获取路由表中后端服务器的运行状态信息;

子步骤2,依据所述运行状态信息检测相应的后端服务器是否异常或失
效,并将异常或失效的后端服务器的配置信息从路由表中删除。

所述运行状态信息可以检测出后端服务器是否与分发服务器保持通信,
通信状态是否正常,等等。如果某台后端服务器由于各种原因而发生故障(即
异常)或完全宕机(即失效),通过这种定期的检测,就可以立即发现并自
动从路由表中删除,避免再将该后端服务器分配给客户端。

上述轮询法虽然也可以通过修改配置的方法删除失效的后端服务器,但
是这种修改之后,扩散需要时间,比如后端的一台服务器停机,修改配置使
其生效需要一定时间,这段时间可能会把这台失效的服务器继续路由给用
户。但是分发服务器采用的这种定期检测、实时删除的方法,可以动态地处
理失效的机器。

2、动态添加后端服务器

通过向所述路由表中添加后端服务器的配置信息,可以动态添加可分配
的后端服务器。

在后端现有的服务器不能满足处理需要的情况下,可以按照上述方式动
态添加新的服务器。这种动态添加的方式也可以立即生效,无需等待一定时
间。

3、后端访问控制

可以根据后端机器的实际在线人数、应用程序的下载情况、CPU、内存
等负载信息,动态计算并决定是否路由请求给后端服务器,从而有效地保护
后端的服务。

这种对后端的访问控制可采用以下两种实现方式:

一种方式是:预先配置后端服务器的最大处理能力,所述最大处理能力
表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最
大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信息;在每个
获取周期内,依据获取的当前负载信息和所配置的最大处理能力,检测后端
服务器是否满载,并对满载的后端服务器进行访问控制。

这种方式下,分发服务器每次获取到后端服务器的负载信息后,比较当
前的实际在线人数是否超过最大在线人数,如果超过,则表示满载需要进行
控制保护,不再给该服务器分配请求。

和/或,比较当前正在下载的应用程序的个数是否超过最大下载个数,
如果超过,则需要控制保护。

和/或,比较当前正在下载的应用程序的总下载量是否超过最大下载数
据量,如果超过,则需要控制保护。

和/或,比较当前的内存使用信息是否接近或超过最大内存使用信息,
如4G的内存当已占用3.7G时表示满载,需要控制保护。

和/或,比较当前的CPU使用信息是否接近或超过最大CPU使用信息,
如最大CPU使用率是85%,如果当前CPU使用率为83%则表示满载,需要
控制保护。

另一种方式是:每个后端服务器上预先配置了相应的最大处理能力,所
述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/
或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使
用信息;每个后端服务器依据当前负载信息和所配置的最大处理能力,定时
检测是否满载;分发服务器定时获取后端服务器是否满载,并对满载的后端
服务器进行访问控制。

所述第二种方式下,是否满载的判断由后端各台服务器完成,并将判断
结果反馈给分发服务器,分发服务器依据是否满载的结果调整访问控制策
略。

4、不局限后端服务的类型

分发服务器可以基于Erlang框架创建,Erlang是一种面向并发
(Concurrency Oriented)、面向消息(Message Oriented)的函数式(Functional)
编程语言。面向并发说明Erlang支持大规模的并发应用,可以在应用中处
理成千上万的并发,而不相互影响。面向消息,是为并发服务。在Erlang
的世界里,每个处理都是独立的个体,他们之间的交互仅仅靠消息,因此不
会有死锁。

基于Erlang框架特有的灵活性,可以通过编写组件的形式进行扩展,后
端可以是任意类型的服务,不局限服务的类型,只要提供负载查询的相关接
口,就可以使用该框架做负载均衡。

因此,在分发服务器定时获取后端服务器的当前负载信息之前,还包括
以下步骤:

根据后端服务的类型,选择配置相适应的与后端服务器通信的交互协
议;

如果后端服务的类型调整,则重新配置相适应的与后端服务器通信的交
互协议。

总之,通过动态配置分发(dispatch)服务器与后端服务器通信的交互
协议,满足不同类型的后端服务。

需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表
述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描
述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同
时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属
于优选实施例,所涉及的动作并不一定是本申请所必需的。

基于上述方法实施例的说明,本申请还提供了相应的应用服务的负载均
衡系统实施例。

参照图3所示,是本申请实施例所述一种应用服务的负载均衡系统的结
构图。

所述负载均衡系统可设置在分发服务器上实现应用服务的负载均衡,所
述负载均衡系统可包含以下模块:

负载查询模块10,用于不断获取后端服务器的当前负载信息,所述当前
负载信息包括后端服务器的应用程序运行数据,或者包括后端服务器的应用
程序运行数据和性能数据;其中,所述应用程序运行数据是后端服务器的应
用程序的运行数据,所述后端服务器为终端应用程序提供网络服务,所述终
端应用程序与后端服务器的应用程序对应同一应用服务;

权重计算模块20,用于在每个获取周期内,依据所述当前负载信息重新
计算后端服务器的权重;

负载调整模块30,用于依据每次计算的权重调整后端服务器的分配,并
选择后端服务器将客户端的接入请求进行路由。

其中,所述性能数据可包括内存使用信息,和/或,CPU使用信息;所
述应用程序运行数据包括实际在线人数,和/或正在下载的应用程序数,和/
或正在下载的数据量,和/或实际连接数。

其中,各后端服务器提供监控接口,负载查询模块10可通过所述监控
接口定时获取后端服务器的当前负载信息。

所述负载调整模块30可依据每次计算的权重调整后端服务器的分配概
率;然后,按照所述分配概率随机选择后端服务器将客户端的接入请求进行
路由。

上述应用服务的负载均衡系统能够在完成同样功能的多个网络设备之
间实现业务量的合理分配,而不至于出现一台设备过忙,其他设备未能充分
发挥其作用的情况。

基于图3的实施例,在另一系统实施例中,所述负载均衡系统还可以包
括其他模块,具体如下:

可选地,所述负载均衡系统还可以包括以下模块:

负载维护模块,用于通过路由表维护所有可分配的后端服务器,所述路
由表中记录了所有可分配的后端服务器的配置信息。

可选地,所述负载均衡系统还可以包括以下模块:

动态删除模块,用于定时获取路由表中后端服务器的运行状态信息;依
据所述运行状态信息检测相应的后端服务器是否异常或失效,并将异常或失
效的后端服务器的配置信息从路由表中删除。

可选地,所述负载均衡系统还可以包括以下模块:

动态添加模块,用于通过向所述路由表中添加后端服务器的配置信息,
动态添加可分配的后端服务器。

可选地,所述负载均衡系统还可以包括以下模块:

第一访问控制模块,用于预先配置后端服务器的最大处理能力,所述最
大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应
用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU使用信
息;在每个获取周期内,依据获取的当前负载信息和所配置的最大处理能力,
检测后端服务器是否满载,并对满载的后端服务器进行访问控制。

可选地,所述负载均衡系统还可以包括以下模块:

第二访问控制模块,用于每个后端服务器上预先配置相应的最大处理能
力,所述最大处理能力表示为最大在线人数、和/或应用程序的最大下载个数、
和/或应用程序的最大下载数据量、和/或最大内存使用信息、和/或最大CPU
使用信息;每个后端服务器依据当前负载信息和所配置的最大处理能力,定
时检测是否满载;定时获取后端服务器是否满载,并对满载的后端服务器进
行访问控制。

可选地,所述负载均衡系统还可以包括以下模块:

通信配置模块,用于根据后端服务的类型,选择配置相适应的与后端服
务器通信的交互协议;如果后端服务的类型调整,则重新配置相适应的与后
端服务器通信的交互协议。

对于上述负载均衡系统实施例而言,由于其与方法实施例基本相似,所
以描述的比较简单,相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明
的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见
即可。

最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语
仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求
或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

而且,上文中的“和/或”表示本文既包含了“和”的关系,也包含了“或”
的关系,其中:如果方案A与方案B是“和”的关系,则表示某实施例中
可以同时包括方案A和方案B;如果方案A与方案B是“或”的关系,则
表示某实施例中可以单独包括方案A,或者单独包括方案B。

以上对本申请所提供的一种应用服务的负载均衡方法及系统,进行了详
细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以
上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于
本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上
均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。

一种应用服务的负载均衡方法及系统.pdf_第1页
第1页 / 共17页
一种应用服务的负载均衡方法及系统.pdf_第2页
第2页 / 共17页
一种应用服务的负载均衡方法及系统.pdf_第3页
第3页 / 共17页
点击查看更多>>
资源描述

《一种应用服务的负载均衡方法及系统.pdf》由会员分享,可在线阅读,更多相关《一种应用服务的负载均衡方法及系统.pdf(17页珍藏版)》请在专利查询网上搜索。

1、(10)申请公布号 CN 102611735 A (43)申请公布日 2012.07.25 C N 1 0 2 6 1 1 7 3 5 A *CN102611735A* (21)申请号 201110433096.7 (22)申请日 2011.12.21 H04L 29/08(2006.01) (71)申请人奇智软件(北京)有限公司 地址 100016 北京市朝阳区酒仙桥路14号 兆维大厦4层东侧单元 (72)发明人李强 黄蔚 (74)专利代理机构北京润泽恒知识产权代理有 限公司 11319 代理人苏培华 (54) 发明名称 一种应用服务的负载均衡方法及系统 (57) 摘要 本申请提供了一种应用。

2、服务的负载均衡方法 及系统,以解决目前网络服务中的负载均衡问题。 所述方法包括:不断获取后端服务器的当前负载 信息,所述当前负载信息包括后端服务器的应用 程序运行数据,或者包括后端服务器的应用程序 运行数据和性能数据;在每个获取周期内,依据 所述当前负载信息重新计算后端服务器的权重; 依据每次计算的权重调整后端服务器的分配,并 选择后端服务器将客户端的接入请求进行路由。 与传统的应用服务的负载均衡方法相比,本申请 能够在完成同样功能的多个网络设备之间实现业 务量的合理分配,而不至于出现一台设备过忙,其 他设备未能充分发挥其作用的情况。 (51)Int.Cl. 权利要求书3页 说明书11页 附图。

3、2页 (19)中华人民共和国国家知识产权局 (12)发明专利申请 权利要求书 3 页 说明书 11 页 附图 2 页 1/3页 2 1.一种应用服务的负载均衡方法,其特征在于,包括: 不断获取后端服务器的当前负载信息,所述当前负载信息包括后端服务器的应用程序 运行数据,或者包括后端服务器的应用程序运行数据和性能数据;其中,所述应用程序运 行数据是后端服务器的应用程序的运行数据,所述后端服务器为终端应用程序提供网络服 务,所述终端应用程序与后端服务器的应用程序对应同一应用服务; 在每个获取周期内,依据所述当前负载信息重新计算后端服务器的权重; 依据每次计算的权重调整后端服务器的分配,并选择后端服。

4、务器将客户端的接入请求 进行路由。 2.根据权利要求1所述的方法,其特征在于: 所述性能数据包括内存使用信息,和/或,CPU使用信息; 所述应用程序运行数据包括实际在线人数,和/或正在下载的应用程序数,和/或正在 下载的数据量,和/或实际连接数。 3.根据权利要求1所述的方法,其特征在于,还包括: 通过路由表维护所有可分配的后端服务器,所述路由表中记录了所有可分配的后端服 务器的配置信息。 4.根据权利要求3所述的方法,其特征在于,还包括: 定时获取路由表中后端服务器的运行状态信息; 依据所述运行状态信息检测相应的后端服务器是否异常或失效,并将异常或失效的后 端服务器的配置信息从路由表中删除。。

5、 5.根据权利要求3所述的方法,其特征在于,还包括: 通过向所述路由表中添加后端服务器的配置信息,动态添加可分配的后端服务器。 6.根据权利要求1至3任一所述的方法,其特征在于,还包括: 预先配置后端服务器的最大处理能力,所述最大处理能力表示为最大在线人数、和/ 或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大内存使用信 息、和/或最大CPU使用信息; 在每个获取周期内,依据获取的当前负载信息和所配置的最大处理能力,检测后端服 务器是否满载,并对满载的后端服务器进行访问控制。 7.根据权利要求1至3任一所述的方法,其特征在于,还包括: 每个后端服务器上预先配置了相应的最大处。

6、理能力,所述最大处理能力表示为最大在 线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或最大 内存使用信息、和/或最大CPU使用信息; 每个后端服务器依据当前负载信息和所配置的最大处理能力,定时检测是否满载; 定时获取后端服务器是否满载,并对满载的后端服务器进行访问控制。 8.根据权利要求1至3任一所述的方法,其特征在于,所述定时获取后端服务器的当前 负载信息之前,还包括: 根据后端服务的类型,选择配置相适应的与后端服务器通信的交互协议; 如果后端服务的类型调整,则重新配置相适应的与后端服务器通信的交互协议。 9.根据权利要求1所述的方法,其特征在于,所述定时获取后端。

7、服务器的当前负载信 息,包括: 权 利 要 求 书CN 102611735 A 2/3页 3 后端服务器提供监控接口,通过所述监控接口定时获取后端服务器的当前负载信息。 10.根据权利要求1所述的方法,其特征在于,所述依据每次计算的权重调整后端服务 器的分配,并选择后端服务器将客户端的接入请求进行路由,包括: 依据每次计算的权重调整后端服务器的分配概率; 按照所述分配概率随机选择后端服务器将客户端的接入请求进行路由。 11.一种应用服务的负载均衡系统,其特征在于,包括: 负载查询模块,用于不断获取后端服务器的当前负载信息,所述当前负载信息包括后 端服务器的应用程序运行数据,或者包括后端服务器的。

8、应用程序运行数据和性能数据;其 中,所述应用程序运行数据是后端服务器的应用程序的运行数据,所述后端服务器为终端 应用程序提供网络服务,所述终端应用程序与后端服务器的应用程序对应同一应用服务; 权重计算模块,用于在每个获取周期内,依据所述当前负载信息重新计算后端服务器 的权重; 负载调整模块,用于依据每次计算的权重调整后端服务器的分配,并选择后端服务器 将客户端的接入请求进行路由。 12.根据权利要求11所述的系统,其特征在于: 所述性能数据包括内存使用信息,和/或,CPU使用信息; 所述应用程序运行数据包括实际在线人数,和/或正在下载的应用程序数,和/或正在 下载的数据量,和/或实际连接数。 。

9、13.根据权利要求11所述的系统,其特征在于,还包括: 负载维护模块,用于通过路由表维护所有可分配的后端服务器,所述路由表中记录了 所有可分配的后端服务器的配置信息。 14.根据权利要求13所述的系统,其特征在于,还包括: 动态删除模块,用于定时获取路由表中后端服务器的运行状态信息;依据所述运行状 态信息检测相应的后端服务器是否异常或失效,并将异常或失效的后端服务器的配置信息 从路由表中删除。 15.根据权利要求13所述的系统,其特征在于,还包括: 动态添加模块,用于通过向所述路由表中添加后端服务器的配置信息,动态添加可分 配的后端服务器。 16.根据权利要求11至13任一所述的系统,其特征在。

10、于,还包括: 第一访问控制模块,用于预先配置后端服务器的最大处理能力,所述最大处理能力表 示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、 和/或最大内存使用信息、和/或最大CPU使用信息;在每个获取周期内,依据获取的当前 负载信息和所配置的最大处理能力,检测后端服务器是否满载,并对满载的后端服务器进 行访问控制。 17.根据权利要求11至13任一所述的系统,其特征在于,还包括: 第二访问控制模块,用于每个后端服务器上预先配置相应的最大处理能力,所述最大 处理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下 载数据量、和/或最大内存使。

11、用信息、和/或最大CPU使用信息;每个后端服务器依据当前 负载信息和所配置的最大处理能力,定时检测是否满载;定时获取后端服务器是否满载,并 权 利 要 求 书CN 102611735 A 3/3页 4 对满载的后端服务器进行访问控制。 18.根据权利要求11至13任一所述的系统,其特征在于,还包括: 通信配置模块,用于根据后端服务的类型,选择配置相适应的与后端服务器通信的交 互协议;如果后端服务的类型调整,则重新配置相适应的与后端服务器通信的交互协议。 权 利 要 求 书CN 102611735 A 1/11页 5 一种应用服务的负载均衡方法及系统 技术领域 0001 本申请涉及网络技术,特别。

12、是涉及一种应用服务的负载均衡方法及系统。 背景技术 0002 负载均衡(又称为负载分担),英文名称为Load Balance,其意思就是将负载(工 作任务)进行平衡、分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关 键应用服务器和其它关键任务服务器等,从而共同完成工作任务。 0003 通常,负载均衡会根据网络的不同层次(网络七层)来划分。其中,第二层的负 载均衡指将多条物理链路当作一条单一的聚合逻辑链路使用,这就是链路聚合(Trunking) 技术,它不是一种独立的设备,而是交换机等网络设备的常用技术。现代负载均衡技术通常 操作于网络的第四层或第七层,这是针对网络应用的负载。

13、均衡技术,它完全脱离于交换机、 服务器而成为独立的技术设备。这也是本文现在要讨论的对象。 0004 负载均衡有两方面的含义:第一层含义是,单个重负载的运算分担到多台节点设 备上做并行处理,每个节点设备处理结束后,将结果汇总,返回给用户,系统处理能力得到 大幅度提高,这就是我们常说的集群(clustering)技术。第二层含义是:大量的并发访问 或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间,这主要针对Web 服务器、FTP服务器、企业关键应用服务器等网络应用。这里主要讨论第二层含义所指的负 载均衡。 0005 目前在很多网络服务中,现有网络的各个核心部分随着用户与业务量的提高,。

14、访 问量和数据流量的快速增长,其处理能力和计算强度也相应地增大,使得单一的服务器设 备根本无法承担。在此情况下,如果扔掉现有设备去做大量的硬件升级,这样将造成现有资 源的浪费,而且如果再面临下一次业务量的提升时,这又将导致再一次硬件升级的高额成 本投入,甚至性能再卓越的设备也不能满足当前业务量增长的需求。 0006 基于此,目前需要解决的问题是:提供一种适用于网络服务的负载均衡方法,能 够在完成同样功能的多个网络设备之间实现业务量的合理分配,而不至于出现一台设备过 忙,其他设备未能充分发挥其作用的情况。 发明内容 0007 本申请提供了一种应用服务的负载均衡方法及系统,以解决目前网络服务中的负。

15、 载均衡问题。 0008 为了解决上述问题,本申请公开了一种应用服务的负载均衡方法,包括: 0009 不断获取后端服务器的当前负载信息,所述当前负载信息包括后端服务器的应用 程序运行数据,或者包括后端服务器的应用程序运行数据和性能数据;其中,所述应用程序 运行数据是后端服务器的应用程序的运行数据,所述后端服务器为终端应用程序提供网络 服务,所述终端应用程序与后端服务器的应用程序对应同一应用服务; 0010 在每个获取周期内,依据所述当前负载信息重新计算后端服务器的权重; 说 明 书CN 102611735 A 2/11页 6 0011 依据每次计算的权重调整后端服务器的分配,并选择后端服务器将。

16、客户端的接入 请求进行路由。 0012 优选的,所述性能数据包括内存使用信息,和/或,CPU使用信息;所述应用程序运 行数据包括实际在线人数,和/或正在下载的应用程序数,和/或正在下载的数据量,和/ 或实际连接数。 0013 优选的,所述方法还包括:通过路由表维护所有可分配的后端服务器,所述路由表 中记录了所有可分配的后端服务器的配置信息。 0014 优选的,所述方法还包括:定时获取路由表中后端服务器的运行状态信息;依据 所述运行状态信息检测相应的后端服务器是否异常或失效,并将异常或失效的后端服务器 的配置信息从路由表中删除。 0015 优选的,所述方法还包括:通过向所述路由表中添加后端服务器。

17、的配置信息,动态 添加可分配的后端服务器。 0016 优选的,所述方法还包括:预先配置后端服务器的最大处理能力,所述最大处理能 力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据 量、和/或最大内存使用信息、和/或最大CPU使用信息;在每个获取周期内,依据获取的当 前负载信息和所配置的最大处理能力,检测后端服务器是否满载,并对满载的后端服务器 进行访问控制。 0017 优选的,所述方法还包括:每个后端服务器上预先配置了相应的最大处理能力,所 述最大处理能力表示为最大在线人数、和/或最大内存使用信息、和/或最大CPU使用信 息;每个后端服务器依据当前负载信息和所配置。

18、的最大处理能力,定时检测是否满载;定 时获取后端服务器是否满载,并对满载的后端服务器进行访问控制。 0018 优选的,所述定时获取后端服务器的当前负载信息之前,还包括:根据后端服务的 类型,选择配置相适应的与后端服务器通信的交互协议;如果后端服务的类型调整,则重新 配置相适应的与后端服务器通信的交互协议。 0019 优选的,所述定时获取后端服务器的当前负载信息,包括:后端服务器提供监控接 口,通过所述监控接口定时获取后端服务器的当前负载信息。 0020 优选的,所述依据每次计算的权重调整后端服务器的分配,并选择后端服务器将 客户端的接入请求进行路由,包括:依据每次计算的权重调整后端服务器的分配。

19、概率;按 照所述分配概率随机选择后端服务器将客户端的接入请求进行路由。 0021 本申请还提供了一种应用服务的负载均衡系统,包括: 0022 负载查询模块,用于不断获取后端服务器的当前负载信息,所述当前负载信息包 括后端服务器的应用程序运行数据,或者包括后端服务器的应用程序运行数据和性能数 据;其中,所述应用程序运行数据是后端服务器的应用程序的运行数据,所述后端服务器为 终端应用程序提供网络服务,所述终端应用程序与后端服务器的应用程序对应同一应用服 务; 0023 权重计算模块,用于在每个获取周期内,依据所述当前负载信息重新计算后端服 务器的权重; 0024 负载调整模块,用于依据每次计算的权。

20、重调整后端服务器的分配,并选择后端服 务器将客户端的接入请求进行路由。 说 明 书CN 102611735 A 3/11页 7 0025 优选的,所述性能数据包括内存使用信息,和/或,CPU使用信息;所述应用程序运 行数据包括实际在线人数,和/或应用程序的最大下载个数、和/或应用程序的最大下载数 据量、和/或正在下载的应用程序数,和/或正在下载的数据量,和/或实际连接数。 0026 优选的,所述系统还包括:负载维护模块,用于通过路由表维护所有可分配的后端 服务器,所述路由表中记录了所有可分配的后端服务器的配置信息。 0027 优选的,所述系统还包括:动态删除模块,用于定时获取路由表中后端服务器。

21、的运 行状态信息;依据所述运行状态信息检测相应的后端服务器是否异常或失效,并将异常或 失效的后端服务器的配置信息从路由表中删除。 0028 优选的,所述系统还包括:动态添加模块,用于通过向所述路由表中添加后端服务 器的配置信息,动态添加可分配的后端服务器。 0029 优选的,所述系统还包括:第一访问控制模块,用于预先配置后端服务器的最大处 理能力,所述最大处理能力表示为最大在线人数、和/或最大内存使用信息、和/或最大CPU 使用信息;在每个获取周期内,依据获取的当前负载信息和所配置的最大处理能力,检测后 端服务器是否满载,并对满载的后端服务器进行访问控制。 0030 优选的,所述系统还包括:第。

22、二访问控制模块,用于每个后端服务器上预先配置相 应的最大处理能力,所述最大处理能力表示为最大在线人数、和/或最大内存使用信息、和 /或最大CPU使用信息;每个后端服务器依据当前负载信息和所配置的最大处理能力,定时 检测是否满载;定时获取后端服务器是否满载,并对满载的后端服务器进行访问控制。 0031 优选的,所述系统还包括:通信配置模块,用于根据后端服务的类型,选择配置相 适应的与后端服务器通信的交互协议;如果后端服务的类型调整,则重新配置相适应的与 后端服务器通信的交互协议。 0032 与现有技术相比,本申请包括以下优点: 0033 首先,本申请针对高并发的客户端请求,通过不断获取后端服务器。

23、的当前负载信 息,并依据所述当前负载信息计算后端服务器的权重,然后依据每次计算的权重调整后端 服务器的分配。简而言之,本申请在客户端需要接入某个应用服务的时候,首先请求接入分 发(dispatch)服务,该分发服务会根据后端服务器的负载情况(如实际在线人数等),动 态调整分发策略,动态地返回后端相对空闲的服务器给客户端接入。与传统的应用服务的 负载均衡方法相比,本申请能够在完成同样功能的多个网络设备之间实现业务量的合理分 配,而不至于出现一台设备过忙,其他设备未能充分发挥其作用的情况。 0034 其次,本申请还能够定时从后端服务器获取其运行状态,如果发现某个后端服务 器的状态异常或已经失效,可。

24、以实时地从路由表中移除,避免再将该后端服务器分配给客 户端。相应的,也可以通过在路由表中添加后端服务器的配置信息,而动态加入后端服务器 供分配。 0035 再次,本申请由于能够定时获取后端服务器的负载情况,因此当某个后端服务器 的负载接近最大处理能力时,可以对其进行访问控制,即不再将客户端请求路由给该服务 器,从而有效地保护后端服务。 0036 再次,本申请中的分发(dispatch)服务器基于Erlang框架创建,可以不局限后端 服务的类型,通过动态配置分发(dispatch)服务器与后端服务器通信的交互协议,满足不 同类型的后端服务。 说 明 书CN 102611735 A 4/11页 8。

25、 0037 当然,实施本申请的任一产品不一定需要同时达到以上所述的所有优点。 附图说明 0038 图1是本申请实施例所述一种应用服务的负载均衡系统的网络架构图; 0039 图2是本申请实施例所述一种应用服务的负载均衡方法流程图; 0040 图3是本申请实施例所述一种应用服务的负载均衡系统的结构图。 具体实施方式 0041 为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实 施方式对本申请作进一步详细的说明。 0042 本申请所述的负载均衡主要指:大量的并发访问或数据流量分担到多台节点设备 上分别处理,减少用户等待响应的时间,这主要针对Web服务器、FTP服务器、企业关键应用。

26、 服务器等网络应用。 0043 本申请在客户端需要接入某个应用服务的时候,首先请求接入分发(dispatch) 服务,该分发服务会根据后端服务器的负载情况(如实际在线人数等),动态调整分发策 略,动态地返回后端相对空闲的服务器给客户端接入。 0044 下面通过实施例首先介绍本申请的网络架构。 0045 参照图1所示,是本申请实施例所述一种应用服务的负载均衡系统的网络架构 图。 0046 本申请实施例所述的负载均衡主要通过分发(dispatch)服务器实现,多个客户 端与所述分发(dispatch)服务器连接,分发(dispatch)服务器与多台后端服务器连接,其 中每台后端服务器能够完成同样的。

27、业务功能。 0047 当某客户端发起接入应用服务的请求时,该接入请求首先路由到所述分发服务 器,分发服务器根据后端服务器的负载情况动态调整分配策略,并根据当前的分配策略选 择一台服务器,将该接入请求路由到该服务器上处理。 0048 图1所示的负载均衡网络架构适用于各种网络服务,例如IM(Instant Messenger,即时通讯)服务、云查杀服务、云盘服务、Push Service服务等等。 0049 基于图1,下面通过图2所示实施例对本申请所述方法的实现流程进行详细说明。 0050 参照图2所示,是本申请实施例所述一种应用服务的负载均衡方法流程图。 0051 以IM业务为例,针对大量IM客。

28、户端的高并发业务请求,分发(dispatch)服务器 将按照以下步骤进行负载均衡处理: 0052 步骤201,不断获取后端服务器的当前负载信息,所述当前负载信息包括后端服务 器的应用程序运行数据,或者包括后端服务器的应用程序运行数据和性能数据; 0053 其中,所述应用程序运行数据是后端服务器的应用程序的运行数据,所述后端服 务器为终端应用程序提供网络服务,所述终端应用程序与后端服务器的应用程序对应同一 应用服务; 0054 简而言之,提供应用服务的应用程序可分为客户端程序和服务器端的后台程序, 所述终端应用程序即是指客户端程序,所述后端服务器的应用程序即是指后台程序,两者 配合运行提供应用服。

29、务。 说 明 书CN 102611735 A 5/11页 9 0055 所述定时获取可以是分发服务器主动查询获取,也可以是被动获取,即后端服务 器定时上报自己的负载情况。 0056 本申请实施例将采用主动获取的方式,具体如下: 0057 每台后端服务器可以提供自己的监控接口,分发服务器可以自己编写插件,该插 件可以通过所述监控接口定期获取每台后端服务器的负载情况。 0058 所述当前负载信息表示后端服务器在每个获取周期的实时负载情况,负载信息可 包括应用程序运行数据,或者包括应用程序运行数据和性能数据,或者包括其他可反映应 用程序运行情况的数据。 0059 其中,所述性能数据是指能够反映后端服。

30、务器软硬件性能的数据,可包括内存使 用信息,和/或,CPU使用信息等。所述应用程序运行数据是指能够反映后端服务器中应用 程序的运行情况的数据,可包括实际在线人数,和/或正在下载的应用程序数,和/或正在 下载的数据量,和/或实际连接数等。这些负载信息都是动态变量数据,都会随着时间而实 时改变。 0060 其中,在IM应用中,实际在线人数能够很合理地衡量后端服务器的实际负载情 况,通过统计实际在线人数,可以剔除从统计开始到当前时刻所有统计出来的在线人数中, 当前时刻实际在线的人数,而不是从开始到现在的统计数据,因为在这个过程中有些客户 端可能已经下线。例如,从t时刻到t1时刻的一段时间内,总共有1。

31、00个客户端连接上后 端服务器,但是相继有30人下线,因此在t1时刻的实际在线人数是70,而不是曾经与服务 器建立过连接的100人。 0061 在多媒体下载应用,如音乐、视频、电影电视等网络下载中,正在下载的应用程序 数是指统计下载列表中当前正在下载的应用程序数,不包括已经下载完毕和下载列表中未 开始下载的应用程序数,因此正在下载的应用程序数也能够合理地衡量后端服务器的实际 负载情况。 0062 进一步的,在应用程序的下载过程中,每个应用程序下载的数据量多少也会影响 后端服务器的负载,因此也可以统计出每个正在下载的应用程序的下载数据量,然后累加, 就可以得到正在下载的所有应用程序的数据量,该数。

32、据量也能够合理地衡量后端服务器的 实际负载情况。 0063 此外,在其他连接多个客户端的应用中,通过统计实际连接数也可以反映出后端 服务器的实际负载情况。所述实际连接数是指与后端服务器保持连接并进行交互的客户端 数,不包含曾经连接过服务器但已经暂时或永久断开连接的客户端,也不包含任务队列中 等待与服务器建立连接的客户端。 0064 内存使用信息和CPU使用信息可从服务器的性能方面衡量了后端服务器的负载 情况,服务器处理的业务不同,所耗费的内存和CPU也是不同的,因此无论业务量的大小如 何,通过服务器的内存和/或CPU使用信息可以反映出一台服务器在当前的实际负载情况。 具体的,所述内存或CPU的。

33、使用信息可以表示为内存或CPU的使用率,或者表示为已经使用 的内存或CPU大小等。 0065 此外,负载信息除以上列举的三种之外,还可以包含磁盘的读写、网卡的读写等参 数信息。 0066 步骤202,在每个获取周期内,依据所述当前负载信息重新计算后端服务器的权 说 明 书CN 102611735 A 6/11页 10 重; 0067 即在每个获取周期内,每次获取到负载信息后,都会依据负载情况对每台服务器 的权重进行计算。当然,如果一台后端服务器的负载情况没有变化,为了节省计算,也可以 直接使用最近一次的权重计算结果。 0068 在计算权重时,可采用下述的计算方法: 0069 设定实际在线人数以。

34、x1表示,其权值为a;内存使用信息以x2表示,其权值为b; CPU使用信息以x3表示,其权值为c;按照以下公式计算得到一台后端服务器的总权重Y; 0070 Y1-(x1a+x2b+x3c) 0071 其中,“1-”表示权重高的服务器优先分配。 0072 当然,上述计算方法仅是举例说明,可以采用其他的权重计算,本申请对此不做限 定。 0073 步骤203,依据每次计算的权重调整后端服务器的分配,并选择后端服务器将客户 端的接入请求进行路由。 0074 在每个获取周期内,与上一周期相比,如果后端服务器的权重有变化,就需要重新 调整服务器的分配,因为每次的分配是依据权重而完成。例如,总共有A、B、C。

35、三台后端服务 器,在上一获取周期中,按照权重由高到低的排序是B、A、C,权重高的服务器比权重低的服 务器处理更多的业务请求,因此服务器B分配的业务请求较多,服务器A其次,服务器C最 少。在下一获取周期中,按照权重由高到低的排序变更为C、A、B,因此此时服务器C分配的 业务请求较多,服务器A其次,服务器B最少。 0075 具体的,步骤203可以包含以下两个子步骤: 0076 子步骤1,依据每次计算的权重调整后端服务器的分配概率; 0077 按照权重高的服务器比权重低的服务器处理更多业务请求的原则,权重高的服务 器得到的分配机会较多,权重低得服务器得到的分配机会相对较少。如果后端服务器的权 重有调。

36、整,就需要相应调整分配概率。 0078 例如,按照权重由高到低,服务器A的权重为0.5,服务器B的权重为0.3,服务器 C的权重为0.2,则相应的分配概率依次是50、30和20。如果权重从高到低调整为服 务器B是0.4、服务器C是0.3、服务器A是0.3,则相应的分配概率依次调整为40、30、 30。 0079 子步骤2,按照所述分配概率随机选择后端服务器将客户端的接入请求进行路由。 0080 在负载均衡过程中,每次分配服务器是依据上述的分配概率随机进行,即每次随 机选择一台后端服务器,但总体保持各服务器的随机分配概率。例如,在某一获取周期内, 服务器A、B、C的分配概率是50、30和20,则。

37、总共分配10次请求,其中5次请求分配 给服务器A处理,3次请求分配给服务器B处理,2次请求分配给服务器C处理。 0081 在选定某台后端服务器后,可以将当前的客户端的接入请求路由给所选定的这台 服务器。 0082 综上所述,由上述流程可以看出,上述的适用于各种应用服务的负载均衡方法能 够根据后端服务器的负载情况,动态调整分发策略,动态地返回后端相对空闲的服务器给 客户端接入。与传统的应用服务的负载均衡方法相比,上述方法能够在完成同样功能的多 个网络设备之间实现业务量的合理分配,而不至于出现一台设备过忙,其他设备未能充分 说 明 书CN 102611735 A 10 7/11页 11 发挥其作用。

38、的情况。 0083 此外,分发服务器除了可以采用图2所示的负载均衡方法外,也可以采用以下几 种负载均衡方法中的任意一种: 0084 (1)轮询法 0085 在一个任务队列里,队列的每个成员(节点)都具有相同的地位,轮询法简单地在 这组成员中顺序轮转选择。在负载均衡环境中,分发服务器将新的请求轮流发给任务队列 中的下一节点,如此连续、周而复始,每个集群的节点都在相等的地位下被轮流选择。 0086 轮询法的活动是可预知的,每个节点被选择的机会是1/N,因此很容易计算出节点 的负载分布。轮询法典型的适用于集群中所有节点的处理能力和性能均相同的情况。 0087 (2)最少连接法 0088 在最少连接法。

39、中,分发服务器纪录目前所有的活跃连接,把下一个新的请求发给 当前含有最少连接数的节点。 0089 这种方法比较适合后端业务相同,机器配置相同,并且每个连接负载基本类似的 服务,比如IM业务。 0090 (3)加权轮询调度法 0091 加权轮询调度(Weighted Round-Robin Scheduling)方法用相应的权值表示节点 的处理性能,根据权值的高低顺序并按照轮询的方式将任务请求分配到各节点。权值高的 结点比权值低的结点处理更多的任务请求,相同权值的结点处理相同份额的请求。 0092 在整个业务处理过程中,这种加权轮询调度法对节点处理性能的权值设置是固定 的,不会随着节点实际性能的。

40、变化而修改权值,但是图2所示的方法可以根据节点的实际 负载情况动态修改权值,动态进行请求的分配。 0093 基于以上内容,下面通过另一个实施例进行说明。在该实施例中,分发服务器除可 以采用图2所示的负载均衡方法外,还具有动态添加、动态删除与其连接的后端服务器,以 及根据后端服务器的负载情况进行后端访问控制等功能。下面分别详细说明。 0094 分发服务器采用路由表维护所有可分配的后端服务器,所述路由表中记录了所有 可分配的后端服务器的配置信息,所述配置信息包括服务器的IP地址、端口配置等信息。 在每个获取周期内,分发服务器按照所述路由表获取路由表中记录的后端服务器的负载情 况,并动态地进行负载调。

41、整。 0095 基于所述路由表的维护,分发服务器还具有以下特点: 0096 1、动态删除后端服务器 0097 具体包含以下两个子步骤: 0098 子步骤1,定时获取路由表中后端服务器的运行状态信息; 0099 子步骤2,依据所述运行状态信息检测相应的后端服务器是否异常或失效,并将异 常或失效的后端服务器的配置信息从路由表中删除。 0100 所述运行状态信息可以检测出后端服务器是否与分发服务器保持通信,通信状态 是否正常,等等。如果某台后端服务器由于各种原因而发生故障(即异常)或完全宕机(即 失效),通过这种定期的检测,就可以立即发现并自动从路由表中删除,避免再将该后端服 务器分配给客户端。 0。

42、101 上述轮询法虽然也可以通过修改配置的方法删除失效的后端服务器,但是这种修 说 明 书CN 102611735 A 11 8/11页 12 改之后,扩散需要时间,比如后端的一台服务器停机,修改配置使其生效需要一定时间,这 段时间可能会把这台失效的服务器继续路由给用户。但是分发服务器采用的这种定期检 测、实时删除的方法,可以动态地处理失效的机器。 0102 2、动态添加后端服务器 0103 通过向所述路由表中添加后端服务器的配置信息,可以动态添加可分配的后端服 务器。 0104 在后端现有的服务器不能满足处理需要的情况下,可以按照上述方式动态添加新 的服务器。这种动态添加的方式也可以立即生效。

43、,无需等待一定时间。 0105 3、后端访问控制 0106 可以根据后端机器的实际在线人数、应用程序的下载情况、CPU、内存等负载信息, 动态计算并决定是否路由请求给后端服务器,从而有效地保护后端的服务。 0107 这种对后端的访问控制可采用以下两种实现方式: 0108 一种方式是:预先配置后端服务器的最大处理能力,所述最大处理能力表示为最 大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载数据量、和/或 最大内存使用信息、和/或最大CPU使用信息;在每个获取周期内,依据获取的当前负载信 息和所配置的最大处理能力,检测后端服务器是否满载,并对满载的后端服务器进行访问 控制。 0。

44、109 这种方式下,分发服务器每次获取到后端服务器的负载信息后,比较当前的实际 在线人数是否超过最大在线人数,如果超过,则表示满载需要进行控制保护,不再给该服务 器分配请求。 0110 和/或,比较当前正在下载的应用程序的个数是否超过最大下载个数,如果超过, 则需要控制保护。 0111 和/或,比较当前正在下载的应用程序的总下载量是否超过最大下载数据量,如 果超过,则需要控制保护。 0112 和/或,比较当前的内存使用信息是否接近或超过最大内存使用信息,如4G的内 存当已占用3.7G时表示满载,需要控制保护。 0113 和/或,比较当前的CPU使用信息是否接近或超过最大CPU使用信息,如最大C。

45、PU 使用率是85,如果当前CPU使用率为83则表示满载,需要控制保护。 0114 另一种方式是:每个后端服务器上预先配置了相应的最大处理能力,所述最大处 理能力表示为最大在线人数、和/或应用程序的最大下载个数、和/或应用程序的最大下载 数据量、和/或最大内存使用信息、和/或最大CPU使用信息;每个后端服务器依据当前负 载信息和所配置的最大处理能力,定时检测是否满载;分发服务器定时获取后端服务器是 否满载,并对满载的后端服务器进行访问控制。 0115 所述第二种方式下,是否满载的判断由后端各台服务器完成,并将判断结果反馈 给分发服务器,分发服务器依据是否满载的结果调整访问控制策略。 0116 。

46、4、不局限后端服务的类型 0117 分发服务器可以基于Erlang框架创建,Erlang是一种面向并发(Concurrency Oriented)、面向消息(Message Oriented)的函数式(Functional)编程语言。面向并发说 明Erlang支持大规模的并发应用,可以在应用中处理成千上万的并发,而不相互影响。面 说 明 书CN 102611735 A 12 9/11页 13 向消息,是为并发服务。在Erlang的世界里,每个处理都是独立的个体,他们之间的交互仅 仅靠消息,因此不会有死锁。 0118 基于Erlang框架特有的灵活性,可以通过编写组件的形式进行扩展,后端可以是 。

47、任意类型的服务,不局限服务的类型,只要提供负载查询的相关接口,就可以使用该框架做 负载均衡。 0119 因此,在分发服务器定时获取后端服务器的当前负载信息之前,还包括以下步 骤: 0120 根据后端服务的类型,选择配置相适应的与后端服务器通信的交互协议; 0121 如果后端服务的类型调整,则重新配置相适应的与后端服务器通信的交互协议。 0122 总之,通过动态配置分发(dispatch)服务器与后端服务器通信的交互协议,满足 不同类型的后端服务。 0123 需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列 的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作。

48、顺序的限制,因为 依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知 悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本申请所必需 的。 0124 基于上述方法实施例的说明,本申请还提供了相应的应用服务的负载均衡系统实 施例。 0125 参照图3所示,是本申请实施例所述一种应用服务的负载均衡系统的结构图。 0126 所述负载均衡系统可设置在分发服务器上实现应用服务的负载均衡,所述负载均 衡系统可包含以下模块: 0127 负载查询模块10,用于不断获取后端服务器的当前负载信息,所述当前负载信息 包括后端服务器的应用程序运行数据,或者包括后端服务器的应。

49、用程序运行数据和性能数 据;其中,所述应用程序运行数据是后端服务器的应用程序的运行数据,所述后端服务器为 终端应用程序提供网络服务,所述终端应用程序与后端服务器的应用程序对应同一应用服 务; 0128 权重计算模块20,用于在每个获取周期内,依据所述当前负载信息重新计算后端 服务器的权重; 0129 负载调整模块30,用于依据每次计算的权重调整后端服务器的分配,并选择后端 服务器将客户端的接入请求进行路由。 0130 其中,所述性能数据可包括内存使用信息,和/或,CPU使用信息;所述应用程序运 行数据包括实际在线人数,和/或正在下载的应用程序数,和/或正在下载的数据量,和/ 或实际连接数。 0131 其中,各后端服务器提供监控接口,负载查。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 电学 > 电通信技术


copyright@ 2017-2020 zhuanlichaxun.net网站版权所有
经营许可证编号:粤ICP备2021068784号-1