CN105227602A - 一种负载均衡的方法、客户端、注册服务器和系统 - Google Patents

Abstract

本发明公开了一种负载均衡的方法、客户端、注册服务器和系统。所述负载均衡的方法包括：客户端与注册服务器建立长连接，当需要调用应用服务器时，到注册服务器上获取应用服务器的节点信息，所述节点信息包括应用服务器的权重；根据获取的应用服务器的节点信息中的权重做负载均衡，将所述请求信息直接发送到对应的应用服务器。本发明的技术方案能够根据应用服务器的连接/断开状态提供动态的负载均衡，且能够区分不同应用服务器的性能差异并且对请求的处理不需要注册服务器中转，减少了网络传输的节点，提高了传输效率，也减少了网络故障的几率。

Description

一种负载均衡的方法、客户端、注册服务器和系统

技术领域

本发明涉及计算机技术领域，特别涉及一种负载均衡的方法、客户端、注册服务器和系统。

背景技术

负载均衡(LoadBalance)，是由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。通过某种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器独立地回应客户的请求。

最早的负载均衡技术是通过DNS(DomainNameServer，域名服务器)来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。但该DNS负载均衡方案采用的是简单轮循的负载算法，且没有考虑容错，不能区分服务器之间的差异，不能反映服务器的当前运行状态。

另一种是反向代理负载均衡解决方案，把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。但该反向代理方式由代理服务器转发，增加了代理服务器的负担，而且网络传输多了一个节点，增加了网络延迟，也增加了出现故障的几率。

发明内容

为了解决上述问题，或者至少部分地解决上述问题，本发明提供了一种负载均衡的方法、客户端、注册服务器和系统。

为达到上述目的，本发明的技术方案是这样实现的：

一方面，本发明公开了一种负载均衡的方法，所述方法包括：

与注册服务器建立长连接，当需要调用应用服务器时，到注册服务器上获取应用服务器的节点信息；所述节点信息为应用服务器在注册服务器上注册的节点信息，该节点信息包括应用服务器的权重；

根据获取的应用服务器的节点信息中的权重，计算出虚拟节点；

根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点；

将所述请求信息直接发送到选取的虚拟节点对应的应用服务器。

一方面，本发明还公开了一种负载均衡的方法，所述方法包括：

与注册的应用服务器保持长连接，记录应用服务器的节点信息，所述节点信息包括应用服务器的权重；

与客户端建立长连接，当客户端需要调用应用服务器时，将应用服务器的节点信息发送给客户端，由客户端根据应用服务器的节点信息中的权重，计算出虚拟节点，并由客户端根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点，然后由客户端将所述请求信息直接发送到选取的虚拟节点对应的应用服务器。

另一方面，本发明还公开了一种负载均衡的客户端，所述客户端包括：

节点信息获取单元，适用于与注册服务器建立长连接，当需要调用应用服务器时，到注册服务器上获取应用服务器的节点信息，所述节点信息为应用服务器在注册服务器上注册的节点信息，该节点信息包括应用服务器的权重；并且，当新增或者移除应用服务器时，重新获取注册服务器上的节点信息；

虚拟节点计算单元，适用于根据获取的应用服务器的节点信息中的权重，计算出虚拟节点；

负载均衡单元，适用于根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点；

请求发送单元，适用于将所述请求信息直接发送到选取的虚拟节点对应的应用服务器。

再一方面，本发明还公开了一种负载均衡的注册服务器，所述注册服务器包括：

记录单元，适用于与注册的应用服务器保持长连接，记录应用服务器的节点信息，所述节点信息包括应用服务器的权重；

发送单元，适用于与客户端建立长连接，当客户端需要调用应用服务器时，将应用服务器的节点信息发送给客户端，由客户端根据应用服务器的节点信息中的权重，计算出虚拟节点，并由客户端根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点，然后由客户端将所述请求信息直接发送到选取的虚拟节点对应的应用服务器；

通知单元，适用于当新增或者移除应用服务器时通知客户端，由客户端重新获取节点信息并根据当前注册的所有应用服务器的虚拟节点重新做负载均衡。

又一方面，本发明还公开了一种负载均衡的系统，所述系统包括：至少一个如上所述的客户端、如上所述的注册服务器和至少一组应用服务器。

本发明提供的负载均衡的方法、客户端、注册服务器和系统的技术方案，一方面能够根据应用服务器的状态(连接/断开)提供动态的负载均衡，另一方面能够区分不同应用服务器的性能差异做负载均衡；再一方面客户端只需要获取应用服务器的节点信息，对请求的处理不需要注册服务器中转，能够根据不同的协议做七层负载。相比于目前的DNS负载均衡，提供了权重的支持，并具有高可用性，能够及时发现应用服务器的增加或者删除，能够反映服务器的当前运行状态，且能够区分应用服务器之间的差异；相比较反向代理的负载均衡来说，不必通过代理服务器进行中转，减少了网络传输的节点，提高了传输效率，也减少了网络故障的几率。

附图说明

图1是本发明实施例中的一种负载均衡方法的流程图；

图2是本发明实施例中的一种负载均衡客户端的结构示意图；

图3是本发明实施例中的另一种负载均衡方法的流程图；

图4是本发明实施例中的一种负载均衡注册服务器的结构示意图；

图5是采用本发明提供的负载均衡方法的一个具体流程图；

图6是本发明实施例中的一种负载均衡系统的示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

图1是本发明实施例中的一种负载均衡方法的流程图。如图1所示，所述方法包括：

S11，客户端与注册服务器建立长连接，当需要调用应用服务器时，客户端到注册服务器上获取应用服务器的节点信息；所述节点信息为应用服务器在注册服务器上注册的节点信息，该节点信息包括应用服务器的权重。

在本发明的实施例中，应用服务器需要根据服务器的性能，在注册时根据服务器的能力不同计算出不同的权值。比如1核CPU(CentralProcessingUnit，中央处理器)，4G内存权值为1，那么一台16核CPU，64G内存的服务器权值就是256(16核/1核*64G/4G＝256)。当然，这个权重可以通过手工进行设置修改。

在本发明的一个实施例中，当新增或者移除应用服务器时，客户端重新获取注册服务器上的节点信息，并根据当前注册的所有应用服务器的虚拟节点重新做负载均衡。

S12，客户端根据获取的应用服务器的节点信息中的权重，计算出虚拟节点。

在本发明的实施例中，客户端根据应用服务器的权重，做出虚拟节点，比如某台应用服务器的权重为100，在客户端就虚拟100个节点。

S13，客户端根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点。

在本步骤中，客户端对当前注册的所有应用服务器的虚拟节点采用一致性哈希(ConsistentHashing)算法计算出虚拟节点的hash值(哈希值)，并将虚拟节点的hash值存于本地缓存中；当客户端收到请求信息时，对请求信息也采用一致性哈希算法计算出请求信息的hash值，所述请求信息中包含用户的标识信息；然后客户端依据请求信息的hash值与本地缓存的虚拟节点的hash值的比较结果，选取出一台虚拟节点。

一致性哈希算法是分布式系统负载均衡的首选算法，其基本思想就是将对象和服务器都映射到同一个hash数值空间中，并且使用相同的hash算法。哈希算法将任意长度的二进制值映射为固定长度的较小二进制值，这个小的二进制值称为hash值，hash值是一段数据唯一且极其紧凑的数值表示形式。在一致性哈希算法引入了“虚拟节点(virtualnode)”的概念，虚拟节点是实际节点在hash空间的复制品(replica)，一个实际节点对应了若干个“虚拟节点”，这个对应个数也称为“复制个数”，“虚拟节点”在hash空间中以hash值排列。引入“虚拟节点”后，映射关系就从对象–>节点转换到了对象->虚拟节点。其中，

在本发明的实施例中，客户端负载均衡采用一致性哈希算法，能够保证同一个用户调用到同一台服务器，所以能够支持有状态服务的负载均衡，即客户端上保存有之前的服务状态信息，将相同的用户路由到相同的应用服务器上。其中，客户端根据用户请求的hash值选取应用服务器的算法可以参考ketamahash算法，该ketamahash算法是一致性哈希算法的一种。特别说明的是，通过客户端一致性哈希算法实现的对有状态服务的负载均衡，可以针对任何请求以及协议，不局限于web请求。

S14，客户端将所述请求信息直接发送到选取的虚拟节点对应的应用服务器。

在本发明的实施例中，客户端只需要获取应用服务器的节点信息，对请求的处理不需要注册服务器中转，能够根据不同的协议做七层负载均衡。其中所谓的七层负载均衡，即基于URL(UniformResourceLocator，统一资源定位符)等应用层信息的负载均衡，通过URL或主机名接收请求，决定最终选择的内部服务器。因此相比较目前的软件代理负载实现，减少了网络传输的节点，提高了传输效率。

相应于上述负载均衡方法，本发明实施例提供了一种负载均衡客户端。图2是本发明实施例中的一种负载均衡客户端的结构示意图。如图2所示，该负载均衡客户端200包括：

节点信息获取单元210，适用于与注册服务器建立长连接，当需要调用应用服务器时，到注册服务器上获取应用服务器的节点信息，所述节点信息为应用服务器在注册服务器上注册的节点信息，该节点信息包括应用服务器的权重；并且，当新增或者移除应用服务器时，重新获取注册服务器上的节点信息；

虚拟节点计算单元220，适用于根据获取的应用服务器的节点信息中的权重，计算出虚拟节点；

负载均衡单元230，适用于根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点；

请求发送单元240，适用于将所述请求信息直接发送到选取的虚拟节点对应的应用服务器。

在本发明的一个实施例中，所述负载均衡单元230包括：

节点hash值计算模块，适用于对当前注册的所有应用服务器的虚拟节点采用一致性哈希算法计算出虚拟节点的hash值；

hash值缓存模块，适用于将虚拟节点的hash值存于本地缓存中；

请求hash值计算模块，适用于对请求信息采用一致性哈希算法计算出请求信息的hash值，所述请求信息中包含用户的标识信息；

比较选取模块，适用于依据请求信息的hash值与本地缓存的虚拟节点的hash值的比较结果，选取出一台虚拟节点。

其中，客户端根据请求的hash值选取应用服务器的算法请参考ketamahash算法。

图3是本发明实施例中的另一种负载均衡方法的流程图。如图3所示，所述方法包括：

S31，注册服务器与注册的应用服务器保持长连接，记录应用服务器的节点信息，所述节点信息包括应用服务器的权重。

S32，注册服务器与客户端建立长连接，当客户端需要调用应用服务器时，将应用服务器的节点信息发送给客户端，由客户端根据应用服务器的节点信息中的权重，计算出虚拟节点，并由客户端根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点，然后由客户端将所述请求信息直接发送到选取的虚拟节点对应的应用服务器。

S33，当新增或者移除应用服务器时注册服务器通知客户端，由客户端重新获取节点信息并根据当前注册的所有应用服务器的虚拟节点重新做负载均衡。

其中，当保持长连接的应用服务器连接断开时，移除该应用服务器。在本发明的实施例中，当一台应用服务器启动以后，将会在注册服务器上注册一个服务节点，此节点通过一个长连接保持。应用服务器和注册服务器之间通过定时发送KeepAlive信息保持心跳，当一台应用服务器失效时，注册服务器将删除这个节点，后续的请求就不会再路由到失效的应用服务器。

相应于上述另一种负载均衡方法，本发明实施例提供了一种负载均衡注册服务器。图4是本发明实施例中的一种负载均衡注册服务器的结构示意图。如图4所示，该负载均衡注册服务器400包括：

记录单元410，适用于与注册的应用服务器保持长连接，记录应用服务器的节点信息，所述节点信息包括应用服务器的权重；

发送单元420，适用于与客户端建立长连接，当客户端需要调用应用服务器时，将应用服务器的节点信息发送给客户端，由客户端根据应用服务器的节点信息中的权重，计算出虚拟节点，并由客户端根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点，然后由客户端将所述请求信息直接发送到选取的虚拟节点对应的应用服务器；

通知单元430，适用于当新增或者移除应用服务器时通知客户端，由客户端重新获取节点信息并根据当前注册的所有应用服务器的虚拟节点重新做负载均衡。

其中，所述记录单元410包括：移除模块，适用于保持长连接的应用服务器连接断开时，移除该应用服务器。

在本发明的实施例中，为了防止注册服务器的单点失效以及一致性问题，注册服务器需要采用分布式一致性(Paxos)算法。该Paxos算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。一个典型的场景是，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。节点通信存在两种模型：共享内存(Sharedmemory)和消息传递(Messagespassing)。Paxos算法就是一种基于消息传递模型的一致性算法。

图5是采用本发明提供的负载均衡方法的一个具体流程图。如图5所示，该流程包括：

S51，应用服务器启动，根据自身的硬件配置计算一个权重。

可以将该权重存储于该应用服务器中。

S52，应用服务器到注册服务器注册一个节点信息，该节点信息包括应用服务器的权重。

在本发明的实施例中，应用服务器在注册服务器注册的节点定义示例：

说明：应用服务器在向注册服务器注册时，会根据自己的硬件配置计算出一个权重，计算的方法根据硬件配置(CPU/内存/硬盘)来计算，计算的策略可以调整。

S53，注册的应用服务器和注册服务器之间保持长连接。

可以通过keepalive机制保持长连接，一旦连接断开，则认为应用服务器失效，进入步骤S58。

S54，客户端和注册服务器建立长连接，当需要调用应用服务器时，到注册服务器上获取应用服务器的节点信息。

S55，客户端根据获取的应用服务器节点信息中的权重，计算出虚拟节点，将虚拟节点存于客户端本地缓存中。

在本发明的实施例中，客户端根据权重进行虚拟节点计算，并且当新增或者移出一台应用服务器时，将会重新进行负载均衡，平均到其他应用服务器上面去。

虚拟节点计算的算法示例如下：

其中node.getWeight()为此应用服务器的权重。

S56，客户端根据请求信息进行一致性哈希运算，并且根据请求的协议选取一台虚拟节点，该请求信息中包含用户的标识信息。

对于有状态的服务，客户端根据传入的key值采用一致性哈希算法，保证相同的用户路由到相同的应用服务器。其中，客户端传入的key值，只要是能够获取hashcode的对象即可，因此能够支持不同的协议。

在本发明的实施例中，客户端根据传入的key值计算出的hash值以及根据虚拟节点计算出的hash值，选出路由的应用服务器。具体算法请参考ketamahash算法。算法示例如下：

S57，客户端将请求信息直接发送到选取的虚拟节点对应的应用服务器。

S58，当新增或者移出应用服务器时，注册服务器节点发生变化，注册服务器将变化信息通知客户端，客户端重新获取节点信息，更新本地缓存。

图6是本发明实施例中的一种负载均衡系统的示意图。如图6所示，该系统由至少一组应用服务器(631、632、633…)、至少一个客户端(611、612、613…)和注册服务器620三个部分组成。其中，客户端(611、612、613…)的结构可以如图2所示，注册服务器620的结构可以如图4所示。

注册服务器620是本系统的核心部分，当一台应用服务器启动以后，将会在注册服务器上注册一个服务节点，此节点通过一个长连接保持。应用服务器和注册服务器之间通过定时发送KeepAlive信息保持心跳，当一台应用服务器失效时，注册服务器将删除这个节点，后续的请求就不会再路由到失效的应用服务器。

至少一组应用服务器(631、632、633…)位于注册服务器620后端，为客户端提供某一种特定的服务。一组应用服务器和另一组应用服务器通过ServiceName区分。

应用服务器需要根据服务器的性能，在注册时根据服务器的能力不同计算出不同的权值。当然，这个权重可以通过手工进行设置修改。应用服务器可以同时提供多个地址，针对不同的协议提供不同的服务端口。

客户端(611、612、613…)通过长连接连接注册服务器620，订阅应用服务器的注册节点，当应用服务器注册节点发生变化时，注册服务器会通知客户端，客户端更新本地缓存信息。客户端还要根据应用服务器的权重，做出虚拟节点，然后根据所有服务器的虚拟节点做负载均衡。

客户端负载均衡采用一致性哈希算法，能够保证同一个用户调用到同一台服务器，所以能够支持所有状态服务的负载均衡。客户端根据请求的hash值取应用服务器的算法请参考ketamahash算法。

综上所述，本发明提供的负载均衡的方法、客户端、注册服务器和系统的技术方案，相对于现有负载均衡方案的有益效果或者优点有：

A)根据应用服务器的配置情况计算权重，从而能够根据应用服务器的性能实现负载均衡；

B)客户端只需要获取应用服务器的节点信息，对请求的处理不需要注册服务器中转，能够根据不同的协议做七层负载；

C)通过客户端一致性哈希算法，能够支持有状态服务的负载均衡；并且客户端采用一致性哈希算法，可以针对任何请求以及协议，不局限于web请求。

D)对于有状态服务的负载均衡，当新增或者移出一台应用服务器时，这台应用服务器的负载能够均匀的分配到其他应用服务器上去；

E)相比于目前的DNS负载均衡，能够及时发现应用服务器的增加或者删除，能够反映服务器的当前运行状态，根据应用服务器的状态(连接/断开)提供动态的负载均衡；

F)相比较反向代理的负载均衡来说，不必通过代理服务器进行中转，减少了网络传输的节点，提高了传输效率，也减少了网络故障的几率。

需要说明的是：

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

本领域的技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。此外，不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (10)

1.一种负载均衡的方法，其特征在于，所述方法包括：

与注册服务器建立长连接，当需要调用应用服务器时，到注册服务器上获取应用服务器的节点信息；所述节点信息为应用服务器在注册服务器上注册的节点信息，该节点信息包括应用服务器的权重；

根据获取的应用服务器的节点信息中的权重，计算出虚拟节点；

根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点；

将所述请求信息直接发送到选取的虚拟节点对应的应用服务器。

2.如权利要求1所述的方法，其特征在于，所述根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点包括：

对当前注册的所有应用服务器的虚拟节点采用一致性哈希算法计算出虚拟节点的hash值，并将虚拟节点的hash值存于本地缓存中；

对请求信息采用一致性哈希算法计算出请求信息的hash值，所述请求信息中包含用户的标识信息；

依据请求信息的hash值与本地缓存的虚拟节点的hash值的比较结果，

选取出一台虚拟节点。

3.如权利要求1或2所述的方法，其特征在于，所述方法还包括：

当新增或者移除应用服务器时，重新获取注册服务器上的节点信息，并根据当前注册的所有应用服务器的虚拟节点重新做负载均衡。

4.一种负载均衡的方法，其特征在于，所述方法包括：

与注册的应用服务器保持长连接，记录应用服务器的节点信息，所述节点信息包括应用服务器的权重；

与客户端建立长连接，当客户端需要调用应用服务器时，将应用服务器的节点信息发送给客户端，由客户端根据应用服务器的节点信息中的权重，计算出虚拟节点，并由客户端根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点，然后由客户端将所述请求信息直接发送到选取的虚拟节点对应的应用服务器。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

当新增或者移除应用服务器时通知客户端，由客户端重新获取节点信息并根据当前注册的所有应用服务器的虚拟节点重新做负载均衡；

其中，当保持长连接的应用服务器连接断开时，移除该应用服务器。

6.一种负载均衡的客户端，其特征在于，所述客户端包括：

节点信息获取单元，适用于与注册服务器建立长连接，当需要调用应用服务器时，到注册服务器上获取应用服务器的节点信息，所述节点信息为应用服务器在注册服务器上注册的节点信息，该节点信息包括应用服务器的权重；并且，当新增或者移除应用服务器时，重新获取注册服务器上的节点信息；

虚拟节点计算单元，适用于根据获取的应用服务器的节点信息中的权重，计算出虚拟节点；

负载均衡单元，适用于根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点；

请求发送单元，适用于将所述请求信息直接发送到选取的虚拟节点对应的应用服务器。

7.如权利要求6所述的客户端，其特征在于，所述负载均衡单元包括：

节点hash值计算模块，适用于对当前注册的所有应用服务器的虚拟节点采用一致性哈希算法计算出虚拟节点的hash值；

hash值缓存模块，适用于将虚拟节点的hash值存于本地缓存中；

请求hash值计算模块，适用于对请求信息采用一致性哈希算法计算出请求信息的hash值，所述请求信息中包含用户的标识信息；

比较选取模块，适用于依据请求信息的hash值与本地缓存的虚拟节点的hash值的比较结果，选取出一台虚拟节点。

8.一种负载均衡的注册服务器，其特征在于，所述注册服务器包括：

记录单元，适用于与注册的应用服务器保持长连接，记录应用服务器的节点信息，所述节点信息包括应用服务器的权重；

发送单元，适用于与客户端建立长连接，当客户端需要调用应用服务器时，将应用服务器的节点信息发送给客户端，由客户端根据应用服务器的节点信息中的权重，计算出虚拟节点，并由客户端根据当前注册的所有应用服务器的虚拟节点做负载均衡，为请求信息选取出一台虚拟节点，然后由客户端将所述请求信息直接发送到选取的虚拟节点对应的应用服务器；

通知单元，适用于当新增或者移除应用服务器时通知客户端，由客户端重新获取节点信息并根据当前注册的所有应用服务器的虚拟节点重新做负载均衡。

9.如权利要求8所述的注册服务器，其特征在于，所述记录单元包括：

移除模块，适用于保持长连接的应用服务器连接断开时，移除该应用服务器。

10.一种负载均衡的系统，其特征在于，所述系统包括：至少一个权利要求6或7所述的客户端、权利要求8或9所述的注册服务器和至少一组应用服务器。