CN111049901B - 一种负载均衡方法、负载均衡系统及注册服务器 - Google Patents

Abstract

本申请公开了一种负载均衡方法、负载均衡系统、注册服务器及计算机可读存储介质，该负载均衡方法应用于注册服务器，包括：接收客户端发送的配置指令；基于所述配置指令为所述客户端分配公匙；在接收到所述客户端基于所述公匙而发起的访问指令时，在所述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器；向所述客户端返回所述目标业务服务器的地址，以触发所述客户端与所述目标业务服务器的超文本传输协议HTTP2.0连接。通过本申请方案，可支持HTTP2.0的协议转发，根据各个业务服务器的负载能力为客户端分配最为合适的业务服务器以实现业务请求。

Description

一种负载均衡方法、负载均衡系统及注册服务器

技术领域

本申请属于互联网技术领域，尤其涉及一种负载均衡方法、负载均衡系统、注册服务器及计算机可读存储介质。

背景技术

随着超文本传输协议(HyperText Transfer Protocol，HTTP)2.0的技术发展，越来越多的系统使用HTTP2.0作为设备间交互的通讯协议。然而，当前较为主流的第三方负载均衡服务器均不支持HTTP2.0协议。

基于此，当前亟需一种能够支持HTTP2.0协议的负载均衡方法。

发明内容

有鉴于此，本申请提供了一种负载均衡方法、负载均衡系统、注册服务器及计算机可读存储介质，可支持HTTP2.0的协议转发。

本申请的第一方面提供了一种负载均衡方法，上述负载均衡方法应用于注册服务器，包括：

接收客户端发送的配置指令；

基于上述配置指令为上述客户端分配公匙；

在接收到上述客户端基于上述公匙而发起的访问指令时，在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器；

向上述客户端返回上述目标业务服务器的地址，以触发上述客户端与上述目标业务服务器的超文本传输协议HTTP2.0连接。

本申请的第二方面提供了一种负载均衡系统，上述负载均衡系统包括客户端、注册服务器及服务器，其中，上述注册服务器包括：

接收单元，用于接收客户端发送的配置指令；

分配单元，用于基于上述配置指令为上述客户端分配公匙；

确定单元，用于在接收到上述客户端基于上述公匙而发起的访问指令时，在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器；

返回单元，用于向上述客户端返回上述目标业务服务器的地址，以触发上述客户端与上述目标业务服务器的超文本传输协议HTTP2.0连接。

本申请的第三方面提供了一种注册服务器，上述注册服务器包括存储器、处理器以及存储在上述存储器中并可在上述处理器上运行的计算机程序，上述处理器执行上述计算机程序时实现如上述第一方面的方法的步骤。

本申请的第四方面提供了一种计算机可读存储介质，上述计算机可读存储介质存储有计算机程序，上述计算机程序被处理器执行时实现如上述第一方面的方法的步骤。

本申请的第五方面提供了一种计算机程序产品，上述计算机程序产品包括计算机程序，上述计算机程序被一个或多个处理器执行时实现如上述第一方面的方法的步骤。

由上可见，在本申请方案中，将该负载均衡方法应用于注册服务器，通过该注册服务器接收客户端发送的配置指令，并基于上述配置指令为上述客户端分配公匙，在接收到上述客户端基于上述公匙而发起的访问指令时，在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器，并向上述客户端返回上述目标业务服务器的地址，以触发上述客户端与上述目标业务服务器的超文本传输协议HTTP2.0连接。通过本申请方案，可支持HTTP2.0的协议转发，根据各个业务服务器的负载能力为客户端分配最为合适的业务服务器以实现业务请求。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的负载均衡方法的实现流程示意图；

图2是本申请实施例提供的负载均衡系统的结构框图；

图3是本申请实施例提供的注册服务器的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

为了说明本申请上述的技术方案，下面通过具体实施例来进行说明。

下面对本申请实施例提供的一种负载均衡方法进行描述，请参阅图1，本申请实施例所提供的负载均衡方法应用于注册服务器，该注册服务器又可被称作注册服务中心。该负载均衡方法包括：

步骤101，接收客户端发送的配置指令；

在本申请实施例中，客户端可以是机器人等智能产品。上述客户端在进行业务操作之前，需要先向上述注册服务器发送配置指令。具体地，上述配置指令中携带有本次客户端所需求的业务类型。上述注册服务器在接收了该配置指令后，将基于该配置中所携带的客户端需求的业务类型，为该客户端配置并生成相应的公匙，也即APPKEY。需要注意的是，注册服务器基于不同的配置指令，所生成的公匙也不同。也即，上述公匙具备唯一性。

步骤102，基于上述配置指令为上述客户端分配公匙；

在本申请实施例中，在基于上述客户端的配置指令生成了上述公匙后，注册服务器可以将所生成的公匙分配至上述客户端，也即，向上述客户端发送上述公匙。

步骤103，在接收到上述客户端基于上述公匙而发起的访问指令时，在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器；

在本申请实施例中，客户端在发起业务操作时，需要基于上述公匙向注册服务器发送上述访问指令，以访问该业务下的一个业务服务器。也即，在本申请实施例中，客户端的一个业务需求对应一个公匙，该公匙对应若干个与该业务相关的业务服务器。当注册服务器接收到上述客户端基于上述公匙而发起的访问指令时，先确定该访问指令所指向的是哪一类型的业务服务器，随后，在这一类型的业务服务器中确定一业务服务器作为目标业务服务器。

可选地，在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器之前，为了进一步验证访问指令的有效性，上述负载均衡方法还包括：

对上述公匙进行验证；

若上述公匙验证通过，则检测上述访问指令所请求的业务是否已激活；

相应地，上述在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器，包括：

若上述访问指令所请求的业务已激活，则在与上述业务相关联的两个以上业务服务器中确定目标业务服务器。

其中，由于上述公匙具备唯一性，且该公匙与上述客户端为唯一对应关系，因而，可以先对上述公匙进行验证，具体为验证该公匙是否为注册服务器向上述客户端基于其业务需求所发放的公匙。在公匙验证通过的情况下，注册服务器还需要进一步检测上述访问指令所请求的业务是否已激活，也即，检测是否有相应的业务服务器为客户端提供其所需要的业务。在上述访问指令所请求的业务已激活的情况下，认为当前有相应的业务服务器为客户端提供所需要的业务，此时才能够在与上述业务相关联的两个以上业务服务器中确定目标业务服务器。

可选地，为了避免出现某一业务服务器过载的现象，上述在两个以上业务服务器中确定目标业务服务器，包括：

A1、分别获取上述两个以上业务服务器的系统负荷值；

A2、将系统负荷值最小的业务服务器确定为目标业务服务器。

其中，先分别获取与客户端所请求的业务相关联的两个以上业务服务器的系统负荷值，上述系统负荷值指示了服务器的负载情况，其中，业务服务器的系统负荷值越小，则认为该业务服务器的负载越少；相反地，业务服务器的系统负荷值越大，则认为该业务服务器的负载越多。因而，在本申请实施例中，将系统负荷值最小的业务服务器确定为目标业务服务器，使得每一次客户端存在业务需求时，都会为该客户端分配该业务下负载最少的业务服务器，避免某一业务服务器出现过载现象。

步骤104，向上述客户端返回上述目标业务服务器的地址，以触发上述客户端与上述目标业务服务器的超文本传输协议HTTP2.0连接。

在本申请实施例中，注册服务器在确定了上述目标业务服务器后，可以进一步获取该目标业务服务器的互联网协议(Internet Protocol，IP)地址，并将该地址返回至上述客户端。上述客户端在接收到上述目标业务服务器的地址后，可以随即建立与该目标业务服务器的HTTP2.0连接。

进一步地，考虑到系统中有多种不同的业务类型，每一种业务可以选择是否进行激活，因而，上述负载均衡方法还包括业务的注册过程，包括：

B1、针对任一未激活的业务，检测是否接收到与上述业务相关联的业务服务器的注册请求；

B2、若接收到与上述业务相关联的业务服务器的注册请求，则基于上述注册请求激活上述业务。

在本申请实施例中，每一未激活业务在需要提供相应服务时，均需要在上述注册服务器中执行注册操作；因而，上述注册服务器可以实时监听各个业务的注册情况，针对任一未激活的业务，检测是否接收到与上述业务相关联的业务服务器的注册请求，上述注册请求包括业务服务器的地址以及该业务的业务类型。在接收到与上述业务相关联的业务服务器的注册请求时，可以基于上述注册请求激活上述业务，在该业务激活后，系统才可以为客户端提供该业务。

相应地，每一种已激活的业务在不再希望提供服务时，也可以选择是否进行注销，因而，上述负载均衡方法还包括业务的注销过程，包括：

C1、针对任一已激活业务，检测是否接收到与上述业务相关联的业务服务器的注销请求；

C2、若接收到与上述业务相关联的业务服务器的注销请求，则基于上述注销请求注销上述业务。

在本申请实施例中，已激活的业务在需要关闭相应服务时，可以在上述注册服务器中执行注销操作；因而，上述注册服务器可以实时监听各个业务的注销情况，针对任一已激活的业务，检测是否接收到与上述业务相关联的业务服务器的注销请求，上述注销请求包括业务服务器的地址。在接收到与上述业务相关联的业务服务器的注销请求时，可以基于上述注销请求注销上述业务；当该业务下的所有已激活的业务服务器均发起了注销请求后，系统就无法再为客户端提供该业务。

进一步地，为了保障客户端的有效性，在上述步骤104之后，上述负载均衡方法还包括：

D1、接收上述客户端发送的第一令牌消息；

D2、接收上述目标业务服务器所发送的在与上述客户端建立HTTP2.0连接时所获得的第二令牌消息；

D3、验证上述第一令牌消息与上述第二令牌消息是否相匹配；

其中，客户端在获得了目标业务服务器的地址后，先不与该目标业务服务器建立连接，而是通过一第三方认证服务器获取令牌消息(access token)，随后，立刻向上述注册服务器发送该令牌消息。注册服务器在接收到上述令牌消息后，将该令牌消息记为第一令牌消息。随后，客户端再发起与目标业务服务器的建立连接请求，在客户端与目标业务服务器建立连接的过程中，客户端也可以向上述目标业务服务器发送上述令牌消息，随后，该目标业务服务器向注册服务器转发所接收到的令牌消息，该令牌消息被记为第二令牌消息。也即，第一令牌消息是客户端直接向注册服务器发送的令牌消息，该令牌消息的信息流向为客户端-注册服务器；而第二令牌消息是目标业务服务器向注册服务器所转发的客户端的令牌消息，该令牌消息的信息流向为客户端-目标业务服务器-注册服务器。随后，注册服务器验证上述第一令牌消息是否与上述第二令牌消息一致，以保障只有在服务器向一客户端反馈目标业务服务器地址后，该客户端才可以与相应的目标业务服务器建立连接；也即，每一客户端与业务服务器的连接均在上述注册服务器的监管下。

D4、若上述第一令牌消息与上述第二令牌消息相匹配，则向上述目标业务服务器发送允许建立连接消息，以指示上述目标业务服务器建立与上述客户端的HTTP2.0连接；

D5、若上述第一令牌消息与上述第二令牌消息不匹配，则向上述目标业务服务器发送禁止建立连接消息，以指示上述目标业务服务器中止建立与上述客户端的HTTP2.0连接。

其中，只有在第一令牌消息与上述第二令牌消息相匹配时，才认为该客户端确实正要与注册服务器为其分配的目标业务服务器进行连接，此时，向上述目标业务服务器发送允许建立连接消息，以实现上述客户端与上述目标业务服务器的HTTP2.0连接；反之，若上述第一令牌消息与上述第二令牌消息不匹配，则认为该客户端的有效性有待查验，此时需禁止上述客户端与上述目标业务服务器的HTTP2.0连接。

进一步地，针对语音处理业务，该业务下的各个业务服务器还可以与第三方音频服务器，例如阿里云OSS(Object Storage Service)服务器相连接。则目标业务服务器在与客户端建立连接后，若接收到客户端所发起的语音处理请求，则可以异步获取该语音处理请求中所携带的音频数据，并将该音频数据追加上传至阿里云OSS服务器；相应地，在目标业务服务器基于上述语音处理请求生成语音响应消息时，也可以异步获取该语音响应消息中所携带的音频数据，并将该音频数据追加上传至阿里云OSS服务器。也即，可以将客户端发送的音频数据及目标业务服务器反馈的音频数据都追加上传至阿里云OSS服务器中。上述阿里云OSS服务器可以通过音频语音文字转换(Text to Speech，TTS)服务，对阿里云OSS服务器所接收到的音频数据进行语音文字转换处理(包括语音转文字处理及文字转语音处理)或其它数据处理操作，此处不作限定。

由上可见，本申请实施例中，提出了一种注册服务器，通过该注册服务器，基于已激活的业务，在客户端存在相应业务需求时，向客户端反馈负载较小的目标业务服务器的地址，以满足客户端的业务请求，实现不同时刻客户端与业务服务器的动态HTTP2.0连接。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

对应于上文所提出的负载均衡方法，下面对本申请实施例提供的一种负载均衡系统进行描述，请参阅图2，本申请实施例中的负载均衡系统包括客户端1、包含多个业务服务器的业务服务器集群2以及注册服务器3，其中，在业务服务器集群中，各个不同业务下均有两个以上业务服务器；例如，业务1下对应有业务服务器211、业务服务器212及业务服务器213；业务2下对应有业务服务器221及业务服务器222；以此类推，业务N下对应有业务服务器2N1、业务服务器2N2至业务服务器2NM，其中，M为该业务N下的业务服务器的个数。上述注册服务器3包括：

接收单元301，用于接收客户端发送的配置指令；

分配单元302，用于基于上述配置指令为上述客户端分配公匙；

确定单元303，用于在接收到上述客户端基于上述公匙而发起的访问指令时，在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器；

返回单元304，用于向上述客户端返回上述目标业务服务器的地址，以触发上述客户端与上述目标业务服务器的超文本传输协议HTTP2.0连接。

可选地，上述注册服务器3还包括：

公匙验证单元，用于在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器之前，对上述公匙进行验证；

激活检测单元，用于若上述公匙验证通过，则检测上述访问指令所请求的业务是否已激活；

相应地，上述确定单元303，具体用于若上述访问指令所请求的业务已激活，则在与上述业务相关联的两个以上业务服务器中确定目标业务服务器。

可选地，上述注册服务器3还包括：

注册检测单元，用于针对任一未激活的业务，检测是否接收到与上述业务相关联的业务服务器的注册请求；

业务激活单元，用于若接收到与上述业务相关联的业务服务器的注册请求，则基于上述注册请求激活上述业务。

可选地，上述注册服务器3还包括：

注销检测单元，用于针对任一已激活业务，检测是否接收到与上述业务相关联的业务服务器的注销请求；

业务注销单元，用于若接收到与上述业务相关联的业务服务器的注销请求，则基于上述注销请求注销上述业务。

可选地，确定单元303包括：

负荷值获取子单元，用于分别获取上述两个以上业务服务器的系统负荷值；

目标业务服务器确定子单元，用于将系统负荷值最小的业务服务器确定为目标业务服务器。

可选地，上述注册服务器3还包括：

令牌接收单元，用于接收上述客户端发送的第一令牌消息，其中，令牌消息由上述客户端向第三方认证服务器所请求而得；

上述令牌接收单元，还用于接收上述目标业务服务器所发送的在与上述客户端建立HTTP2.0连接时所获得的第二令牌消息；

令牌验证单元，用于验证上述第一令牌消息与上述第二令牌消息是否相匹配；

连接控制单元，用于若上述第一令牌消息与上述第二令牌消息相匹配，则向上述目标业务服务器发送允许建立连接消息，以实现上述客户端与上述目标业务服务器的HTTP2.0连接；

上述连接控制单元，还用于若上述第一令牌消息与上述第二令牌消息不匹配，则向上述目标业务服务器发送禁止建立连接消息，以禁止上述客户端与上述目标业务服务器的HTTP2.0连接。

由上可见，在本申请实施例中，负载均衡系统提出了一种注册服务器，通过该注册服务器，基于已激活的业务，在客户端存在相应业务需求时，向客户端反馈负载较小的目标业务服务器的地址，以满足客户端的业务请求，实现不同时刻客户端与业务服务器的动态HTTP2.0连接。

本申请实施例三提供了一种注册服务器，请参阅图3，本申请实施例中的注册服务器30包括：存储器31，一个或多个处理器32(图3中仅示出一个)及存储在存储器31上并可在处理器上运行的计算机程序。其中：存储器31用于存储软件程序以及模块，处理器32通过运行存储在存储器31的软件程序以及单元，从而执行各种功能应用以及数据处理，以获取上述预设事件对应的资源。具体地，处理器32通过运行存储在存储器31的上述计算机程序时实现以下步骤：

接收客户端发送的配置指令；

基于上述配置指令为上述客户端分配公匙；

在接收到上述客户端基于上述公匙而发起的访问指令时，在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器；

向上述客户端返回上述目标业务服务器的地址，以触发上述客户端与上述目标业务服务器的超文本传输协议HTTP2.0连接。

假设上述为第一种可能的实施方式，则在第一种可能的实施方式作为基础而提供的第二种可能的实施方式中，在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器之前，处理器32通过运行存储在存储器31的上述计算机程序时还实现以下步骤：

对上述公匙进行验证；

若上述公匙验证通过，则检测上述访问指令所请求的业务是否已激活；

相应地，上述在上述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器，包括：

若上述访问指令所请求的业务已激活，则在与上述业务相关联的两个以上业务服务器中确定目标业务服务器。

在上述第二种可能的实施方式作为基础而提供的第三种可能的实施方式中，处理器32通过运行存储在存储器31的上述计算机程序时还实现以下步骤：

针对任一未激活的业务，检测是否接收到与上述业务相关联的业务服务器的注册请求；

若接收到与上述业务相关联的业务服务器的注册请求，则基于上述注册请求激活上述业务。

在上述第二种可能的实施方式作为基础而提供的第四种可能的实施方式中，处理器32通过运行存储在存储器31的上述计算机程序时还实现以下步骤：

针对任一已激活业务，检测是否接收到与上述业务相关联的业务服务器的注销请求；

若接收到与上述业务相关联的业务服务器的注销请求，则基于上述注销请求注销上述业务。

在上述第一种可能的实施方式作为基础，或者上述第二种可能的实施方式作为基础，或者上述第三种可能的实施方式作为基础，或者上述第四种可能的实施方式作为基础而提供的第五种可能的实施方式中，上述在两个以上业务服务器中确定目标业务服务器，包括：

分别获取上述两个以上业务服务器的系统负荷值；

将系统负荷值最小的业务服务器确定为目标业务服务器。

在上述第一种可能的实施方式作为基础，或者上述第二种可能的实施方式作为基础，或者上述第三种可能的实施方式作为基础，或者上述第四种可能的实施方式作为基础而提供的第六种可能的实施方式中，在上述向上述客户端返回上述目标业务服务器的地址之后，处理器32通过运行存储在存储器31的上述计算机程序时还实现以下步骤：

接收上述客户端发送的第一令牌消息，其中，上述第一令牌消息由上述客户端向第三方认证服务器所请求而得；

接收上述目标业务服务器所发送的在与上述客户端建立HTTP2.0连接时所获得的第二令牌消息；

验证上述第一令牌消息与上述第二令牌消息是否相匹配；

若上述第一令牌消息与上述第二令牌消息相匹配，则向上述目标业务服务器发送允许建立连接消息，以指示上述目标业务服务器建立与上述客户端的HTTP2.0连接；

若上述第一令牌消息与上述第二令牌消息不匹配，则向上述目标业务服务器发送禁止建立连接消息，以指示上述目标业务服务器中止建立与上述客户端的HTTP2.0连接。

应当理解，在本申请实施例中，所称处理器32可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器31可以包括只读存储器和随机存取存储器，并向处理器32提供指令和数据。存储器31的一部分或全部还可以包括非易失性随机存取存储器。例如，存储器31还可以存储设备类型的信息。

由上可见，在本申请实施例中，通过注册服务器构建了一负载均衡系统，该注册服务器可以基于已激活的业务，在客户端存在相应业务需求时，向客户端反馈负载较小的目标业务服务器的地址，以满足客户端的业务请求，实现不同时刻客户端与业务服务器的动态HTTP2.0连接。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将上述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者外部设备软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，上述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，上述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，上述计算机程序包括计算机程序代码，上述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。上述计算机可读存储介质可以包括：能够携带上述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机可读存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，上述计算机可读存储介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读存储介质不包括是电载波信号和电信信号。

以上上述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (6)

1.一种负载均衡方法，其特征在于，所述负载均衡方法应用于注册服务器，包括：

接收客户端发送的配置指令；所述配置指令中携带客户端所需求的业务类型；

基于所述配置指令为所述客户端分配公匙；其中，所述公匙与客户端一一对应，且所述公匙对应若干个与所述业务类型相关的业务服务器；

在接收到所述客户端基于所述公匙而发起的访问指令时，在所述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器；

向所述客户端返回所述目标业务服务器的地址，以触发所述客户端与所述目标业务服务器的超文本传输协议HTTP2.0连接；

在所述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器之前，所述负载均衡方法还包括：

对所述公匙进行验证；

若所述公匙验证通过，则检测所述访问指令所请求的业务是否已激活；

相应地，所述在所述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器，包括：

若所述访问指令所请求的业务已激活，则在与所述业务相关联的两个以上业务服务器中确定目标业务服务器；

所述负载均衡方法还包括：

针对任一未激活的业务，检测是否接收到与所述业务相关联的业务服务器的注册请求；

若接收到与所述业务相关联的业务服务器的注册请求，则基于所述注册请求激活所述业务；

在所述向所述客户端返回所述目标业务服务器的地址之后，所述负载均衡方法还包括：

客户端获得目标业务服务器地址后，通过第三方认证服务器获取令牌消息，并向注册服务器发送所述令牌消息；

所述注册服务器接收到所述令牌消息后，将所述令牌消息记为第一令牌消息；

所述客户端发送与所述目标业务服务器的建立连接请求，在所述客户端与所述目标业务服务器建立连接过程中，所述客户端向所述目标业务服务器发送所述令牌消息；

所述目标业务服务器接收所述令牌消息，并向所述注册服务器转发所接收到的令牌消息；

所述注册服务器接收到所述令牌消息后，将所述令牌消息记为第二令牌消息；

验证所述第一令牌消息与所述第二令牌消息是否相匹配；

若所述第一令牌消息与所述第二令牌消息相匹配，则向所述目标业务服务器发送允许建立连接消息，以指示所述目标业务服务器建立与所述客户端的HTTP2.0连接；

若所述第一令牌消息与所述第二令牌消息不匹配，则向所述目标业务服务器发送禁止建立连接消息，以指示所述目标业务服务器中止建立与所述客户端的HTTP2.0连接。

2.如权利要求1所述的负载均衡方法，其特征在于，所述负载均衡方法还包括：

针对任一已激活业务，检测是否接收到与所述业务相关联的业务服务器的注销请求；

若接收到与所述业务相关联的业务服务器的注销请求，则基于所述注销请求注销所述业务。

3.如权利要求1至2任一项所述的负载均衡方法，其特征在于，所述在两个以上业务服务器中确定目标业务服务器，包括：

分别获取所述两个以上业务服务器的系统负荷值；

将系统负荷值最小的业务服务器确定为目标业务服务器。

4.一种负载均衡系统，其特征在于，所述负载均衡系统包括客户端、注册服务器及业务服务器，其中，所述注册服务器包括：

接收单元，用于接收客户端发送的配置指令；所述配置指令中携带客户端所需求的业务类型；

分配单元，用于基于所述配置指令为所述客户端分配公匙；其中，所述公匙与客户端一一对应，且所述公匙对应若干个与所述业务类型相关的业务服务器；

确定单元，用于在接收到所述客户端基于所述公匙而发起的访问指令时，在所述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器；

返回单元，用于向所述客户端返回所述目标业务服务器的地址，以触发所述客户端与所述目标业务服务器的超文本传输协议HTTP2.0连接；

所述注册服务器还包括：

公匙验证单元，用于在所述访问指令的指示下，在两个以上业务服务器中确定目标业务服务器之前，对所述公匙进行验证；

激活检测单元，用于若所述公匙验证通过，则检测所述访问指令所请求的业务是否已激活；

相应地，所述确定单元，具体用于若所述访问指令所请求的业务已激活，则在与所述业务相关联的两个以上业务服务器中确定目标业务服务器；

所述注册服务器还包括：

注册检测单元，用于针对任一未激活的业务，检测是否接收到与所述业务相关联的业务服务器的注册请求；

业务激活单元，若接收到与所述业务相关联的业务服务器的注册请求，则基于所述注册请求激活所述业务；

所述注册服务器还包括：

令牌接收单元，用于接收所述客户端发送的第一令牌消息，所述第一令牌消息是在客户端获得目标业务服务器地址后，通过第三方认证服务器获取的令牌消息；

所述令牌接收单元，还用于接收所述目标业务服务器发送的第二令牌消息，所述第二令牌消息是在客户端发送与所述目标业务服务器的建立连接请求后，在所述客户端与所述目标业务服务器建立连接过程中，所述客户端向所述目标业务服务器发送的令牌消息；

令牌验证单元，用于验证所述第一令牌消息与所述第二令牌消息是否相匹配；

连接控制单元，用于若所述第一令牌消息与所述第二令牌消息相匹配，则向所述目标业务服务器发送允许建立连接消息，以指示所述目标业务服务器建立与所述客户端的HTTP2.0连接；

所述连接控制单元，还用于若所述第一令牌消息与所述第二令牌消息不匹配，则向所述目标业务服务器发送禁止建立连接消息，以指示所述目标业务服务器中止建立与所述客户端的HTTP2.0连接。

5.一种注册服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至3任一项所述方法的步骤。

6.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至3任一项所述方法的步骤。

Images