CN110351311A - 负载均衡方法及计算机存储介质 - Google Patents

Abstract

本发明提供了一种负载均衡方法及计算机存储介质，其中，负载均衡方法包括：接收业务端发送的业务请求；根据所述业务请求，获取为所述业务请求所请求的业务提供服务的至少一个服务器的信息，其中，所述服务器的信息包括所述服务器的地址和所述服务器的健康度，所述健康度包括以下之一：健康、亚健康、病态、死亡；根据所述服务器中的所述健康度的占比信息，选择为所述业务请求所请求的业务提供服务的服务器；将选择的所述服务器的信息携带在业务请求响应中，向所述业务端发送所述业务请求响应。通过本发明实施例，有效地降低了服务器的访问压力，提高了获取的服务器的可用性。

Description

负载均衡方法及计算机存储介质

技术领域

本发明实施例涉及网络技术领域，尤其涉及一种负载均衡方法及计算机存储介质。

背景技术

随着网络技术的发展，网络用户呈指数级增长，用户对各种网络服务的要求也越来越高，例如，要求网络服务有更快的响应时间和更高的服务质量。

目前，用户通过业务端(即用户端)获取网络服务时，通常通过后台服务器的具体地址，向该具体地址发起业务请求。该后台服务器在接受到业务请求后，根据业务请求所请求的内容向业务端提供服务。但此种情况下，若该后台服务器已经无法提供服务，如已达满负载或者出现故障等，则业务端将无法获取到服务。

由此可见，如何获取有效的服务器，满足实际的服务需求，成为一个亟待解决的技术问题。

发明内容

有鉴于此，本发明实施例提供一种负载均衡方法及计算机存储介质，以解决现有技术中在请求服务器提供服务时，出现无法获取有效的服务器，以满足实际服务需求的问题。

根据本发明实施例的第一方面，提供了一种负载均衡方法，包括：接收业务端发送的业务请求；根据所述业务请求，获取为所述业务请求所请求的业务提供服务的至少一个服务器的信息，其中，所述服务器的信息包括所述服务器的地址和所述服务器的健康度，所述健康度包括以下之一：健康、亚健康、病态、死亡；根据所述服务器中的所述健康度的占比信息，选择为所述业务请求所请求的业务提供服务的服务器；将选择的所述服务器的信息携带在业务请求响应中，向所述业务端发送所述业务请求响应。

根据本发明实施例的第二方面，还提供了一种计算机存储介质，所述计算机存储介质中存储有：用于接收业务端发送的业务请求的指令；用于根据所述业务请求，获取为所述业务请求所请求的业务提供服务的至少一个服务器的信息的指令，其中，所述服务器的信息包括所述服务器的地址和所述服务器的健康度，所述健康度包括以下之一：健康、亚健康、病态、死亡；用于根据所述服务器中的所述健康度的占比信息，选择为所述业务请求所请求的业务提供服务的服务器的指令；用于将选择的所述服务器的信息携带在业务请求响应中，向所述业务端发送所述业务请求响应的指令。

通过本实施例提供的负载均衡方案，根据业务端发送的业务请求，获取可以为该业务请求所请求的业务提供服务的至少一个服务器的信息，包括服务器的地址和服务器的健康度；进而，根据健康度的占比确定最终提供服务的服务器。通过引入多个健康度级别，可以及时获取服务器的当前服务状态。以健康度的占比信息为负载均衡依据，确定为业务请求提供服务的服务器，一方面，可以从整体上了解可提供服务的服务器的整体状态情况，以进行负载均衡调整；另一方面，可以通过选择健康度较好的服务器提供服务，以提高获取有效的服务器进行服务的效率。通过基于服务器的健康度进行负载均衡的方式，有效地降低了服务器的访问压力，提高了获取的服务器的可用性，从而实现了获取有效的服务器来满足实际服务的需求。

附图说明

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

图1为根据本发明实施例一的一种负载均衡方法的步骤流程图；

图2为根据本发明实施例二的一种负载均衡方法的步骤流程图；

图3为图2所示实施例中的一种根据服务器中的健康度的占比信息，确定为业务请求所请求的业务提供服务的服务器的流程图；

图4为根据本发明实施例三的一种负载均衡方法的步骤流程图；

图5为图4所示实施例中的一种负载均衡系统的架构示意图；

图6为图4所示实施例中的一种服务器组的示意图；

图7为图4所示实施例中的一种双向心跳检测示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

参照图1，示出了根据本发明实施例一的一种负载均衡方法的步骤流程图。

本实施例的负载均衡方法包括以下步骤：

步骤S102，接收业务端发送的业务请求。

其中，业务请求用于请求提供可为某种业务提供服务的服务器的信息。业务请求中携带有相应的业务信息，根据该业务信息可以确定具有相应业务服务能力的服务器，并从中选择出相应的服务器为业务端进行服务。

步骤S104，根据业务请求，获取为业务请求所请求的业务提供服务的至少一个服务器的信息。

其中，所述服务器的信息包括服务器的地址(如IP地址)和服务器的健康度(Health degree)，健康度包括以下之一：健康、亚健康、病态、死亡。

服务器的健康度用于指示服务器的当前服务状态，其中，健康度为健康用于指示服务器当前处于可服务状态且负载较低；亚健康用于指示服务器当前处于可服务状态且负载一般；病态用于指示服务器当前处于可服务状态且负载较重；死亡用于指示服务器当前处于不可提供服务状态。

步骤S106，根据所述服务器中的健康度的占比信息，选择为业务请求所请求的业务提供服务的服务器。

健康度的占比信息指示了可为业务请求所请求的业务提供服务的所有服务器的总体健康度情况。若占比信息指示健康和/或亚健康的服务器占比较多，则表明所有服务器总体健康度较好，可从中有效选择出提供服务的服务器，并且后续可继续承担一定量的负载；若占比信息指示病态和/或死亡的服务器占比较多，则表明可为该业务提供服务的这部分服务器目前负载较重，在从中选择出可提供服务的服务器后，后续需要通过适当方式进行调整。

在一种可行方式中，可以根据健康和/或亚健康的服务器的占比信息，确定为业务请求所请求的业务提供服务的服务器，以使选择出的服务器具有高可用性。

步骤S108，将选择的服务器的信息携带在业务请求响应中，向业务端发送所述业务请求响应。

在确定了为业务请求所请求的业务提供服务的服务器后，可将该服务器的信息如服务器的IP地址等，携带在业务请求响应中，向业务端反馈。

通过本实施例提供的负载均衡方法，根据业务端发送的业务请求，获取可以为该业务请求所请求的业务提供服务的至少一个服务器的信息，包括服务器的地址和服务器的健康度；进而，根据健康度的占比确定最终提供服务的服务器。通过引入多个健康度级别，可以及时获取服务器的当前服务状态。以健康度的占比信息为负载均衡依据，确定为业务请求提供服务的服务器，一方面，可以从整体上了解可提供服务的服务器的整体状态情况，以进行负载均衡调整；另一方面，可以通过选择健康度较好的服务器提供服务，以提高获取有效的服务器进行服务的效率。通过基于服务器的健康度进行负载均衡的方式，有效地降低了服务器的访问压力，提高了获取的服务器的可用性，从而实现了获取有效的服务器来满足实际服务的需求。

本实施例的负载均衡方法可以由任意具有数据处理功能的服务器实现。

实施例二

参照图2，示出了根据本发明实施例二的一种负载均衡方法的步骤流程图。

本实施例的负载均衡方法包括以下步骤：

步骤S202，接收服务器组的注册请求，根据注册请求为服务器组进行注册并生成对应的标识信息；向服务器组返回标识信息。

服务器组的注册请求用于以组为单位向相应的具有服务器管理功能的管理服务器进行注册，以接收管理服务器的管理，包括但不限于：注册、注销、心跳检测等等。管理服务器在接收到注册请求后，为发送该注册请求的服务器组进行注册，并可生成用于标识该服务器组的标识信息，如服务器组名称信息。该服务器组包括至少一台服务器，该服务器组中的所有服务器具有相同的标识信息如名称信息，但同时每台服务器还具有各自的IP地址以作组内区分。通过标识信息对服务器组进行统一管理，简化了管理流程，降低了管理成本。

但不限于此，在实际应用中，也可以采用非服务器组的方式，如单个服务器分别进行注册的方式等。

步骤S204，通过心跳检测消息获取服务器组的健康度信息。

心跳检测不是服务端主动发信息检测客户端状态，而是在服务端保存所有客户端的状态信息，然后等待客户端定时来访问服务端，更新自己的当前状态，如果客户端超过指定的时间没有来更新状态，则认为客户端已经宕机或者其状态异常。具体到本发明实施例，与该常规心跳检测不同的是，一方面，服务器组中的服务器会定时访问对其进行管理的管理服务器(管理服务器可以提供名字服务，是一个集注册/注销、心跳探测、服务发现于一体的系统，业务端可以通过访问其IP与其进行通信)；另一方面，也会定期向服务器组中的服务器发送心跳检测消息，从而实现服务器组中的服务器与管理服务器的双向心跳检测。

具体地，在实现本步骤时，一种可行方式中，可以向多个服务器(被管理服务器管理的服务器，包括但不限于服务器组中的服务器)发送第一心跳检测消息，根据多个服务器的返回结果确定多个服务器的第一健康度；并且，接收多个服务器推送的第二心跳检测消息，根据第二心跳检测消息确定多个服务器的第二健康度；根据第一健康度和第二健康度，确定多个服务器的最终健康度；其中，多个服务器包括为业务请求所请求的业务提供服务的至少一个服务器。其中，第一健康度和第二健康度均包括：健康、亚健康、病态、死亡，四个状态。使用第一健康度和第二健康度，仅为了区分两者来自于不同心跳检测消息的反馈。对于每台服务器，其第一健康度和第二健康度可能相同，也可能不同。通过该双向心跳检测方式，提高了对服务器的健康度检测的准确性，并可有效预防单向崩溃风险。

其中，在向多个服务器发送第一心跳检测消息，根据多个服务器的返回结果确定多个服务器的第一健康度时，一种可行方式包括：每隔设定时间间隔向多个服务器中的每个服务器发送设定数量的第一心跳检测消息；接收每个服务器在设定时间段内对每个第一心跳检测消息的返回结果，根据返回结果的数量确定当前服务器的第一健康度。其中，设定时间间隔、设定数量和设定时间段均可由本领域技术人员根据实际情况适当设置，本发明实施例对此不作限制。例如，设定时间间隔为3S，设定数量为3个，设定时间段为5秒等等。由此，可以简单快速地实现管理服务器对被管理服务器的心跳检测。

在根据返回结果的数量确定当前服务器的第一健康度时，若返回结果的数量与设定数量相同，则确定当前服务器的第一健康度为健康；若返回结果的数量小于设定数量且大于第一设定值，则确定当前服务器的第一健康度为亚健康；若返回结果的数量小于第一设定值且大于第二设定值，则确定当前服务器的第一健康度为病态；若无返回结果，则确定当前服务器的第一健康度为死亡。其中，第一设定值大于第二设定值，第一设定值和第二设定值的具体设定根据实际需要和所述设定数量适当设定，本发明实施例对此不作限制。

可选地，在根据第一健康度和所述第二健康度，确定多个服务器的最终健康度时，可以针对多个服务器中的每个服务器，判断对应的第一健康度和第二健康度是否一致；若不一致，则将第二健康度确定为当前服务器的最终健康度。也即，将服务器推送的第二心跳检测消息所反映的健康度确定为最终健康度。相比较于主动到被检测端服务器进行检测，被检测端服务器自身主动向检测端服务器发送的心跳检测消息更为可靠。

步骤S206，接收业务端发送的业务请求。

如前所述，业务请求中携带有相应的业务信息，根据该业务信息可以确定具有相应业务服务能力的服务器，并从中选择出相应的服务器为业务端进行服务。

当服务器以服务器组为单位向管理服务器进行注册时，在一种可行方式中，业务端发送的业务请求中可以携带待请求的服务器组的标识信息，以提高业务请求被处理的速度和效率。

步骤S208：根据业务请求，获取为业务请求所请求的业务提供服务的至少一个服务器的信息。

其中，所述服务器的信息包括所述服务器的地址和所述服务器的健康度，所述健康度包括以下之一：健康、亚健康、病态、死亡。

在业务请求中携带有待请求的服务器组的标识信息时，可以根据业务请求中的服务器组的标识信息，从所述标识信息所标识的服务器组中获取为业务请求所请求的业务提供服务的至少一个服务器的信息。

步骤S210，根据服务器中的健康度的占比信息，选择为业务请求所请求的业务提供服务的服务器。

通过健康度的占比信息，可以了解相关服务器的整体情况，从中确定出有效的、可提供服务的服务器。

例如，在一种可行方式中，可以根据健康度为健康的服务器的占比信息和健康度为亚健康的服务器的占比信息，确定为业务请求所请求的业务提供服务的服务器。

其中，健康度为健康的服务器的占比，可以为可为所述业务提供服务的服务器中，健康度为健康的数量与除死亡状态之外的其它服务器的总数量的比值；或者，可以为可为所述业务提供服务的服务器中，健康度为健康的数量与所有可提供服务的服务器的总数的比值。与此类似，健康度为亚健康的服务器的占比，可以为可为所述业务提供服务的服务器中，健康度为亚健康的数量与除死亡状态之外的其它服务器的总数量的比值；或者，可以为可为所述业务提供服务的服务器中，健康度为亚健康的数量与所有可提供服务的服务器的总数的比值。

具体地，在一种可行的实现方式中，如图3所示，本步骤可以包括以下子步骤：

子步骤1：判断为业务请求所请求的业务提供服务的所有服务器中是否存在健康度为健康的服务器；若存在，则执行子步骤2；若不存在，则执行子步骤3。

子步骤2：若存在健康度为健康的服务器，则判断健康度为健康的服务器的占比是否大于或等于第一设定阈值；若是，则执行子步骤3，结合健康度为亚健康的服务器的占比，确定为业务请求所请求的业务提供服务的服务器；若否，则执行子步骤7。

其中，第一设定阈值可以由本领域技术人员根据实际需要适当设定，本发明对此不做限制，如，设置为50％等。

子步骤3：判断所述服务器中是否存在健康度为亚健康的服务器；若存在，则执行子步骤4；若不存在，则执行子步骤5。

也即，若所述服务器中存在健康度为亚健康的服务器，则执行子步骤4；若为业务请求所请求的业务提供服务的所有服务器中不存在健康度为亚健康的服务器，但是健康度为健康的服务器的占比大于或等于第一设定阈值，则此种情况下，可以直接从所述所有服务器中选择一个服务器。

子步骤4：判断健康度为亚健康的服务器的占比是否大于或等于第二设定阈值，若是，则执行子步骤5；若否，则执行子步骤6。

其中，第二设定阈值可以由本领域技术人员根据实际需要适当设定，本发明对此不做限制，如，设置为50％等。

子步骤5：从获取的至少一个服务器中确定提供服务的服务器。结束本次流程。

也即，在健康度为健康的服务器的占比大于或等于第一设定阈值，且健康度为亚健康的服务器的占比大于或等于第二设定阈值的情况下，直接从获取的为业务请求所请求的业务提供服务的所有服务器中，选择一个服务器。

子步骤6：若健康度为亚健康的服务器的占比小于第二设定阈值，则增加健康度为亚健康的服务器的占比；然后，返回子步骤4继续执行。

即，若健康度为亚健康的服务器的占比小于第二设定阈值，则增加健康度为亚健康的服务器的占比，并根据增加后的占比继续判断健康度为亚健康的服务器的占比是否大于或等于第二设定阈值，直至增加后的占比大于或等于第二设定阈值。

也即，若为业务请求所请求的业务提供服务的所有服务器中，健康度为健康的服务器的占比大于或等于第一设定阈值，但健康度为亚健康的服务器的占比却小于第二设定阈值，此种情况下，可以通过一定方式虚拟增加健康度为亚健康的服务器的数量，进而提高其占比，以提高健康度为健康和健康度为亚健康的服务器被选中的概率。

其中，可以通过克隆选择算法，增加健康度为亚健康的服务器的占比。克隆选择算法的实质是在进化过程中，在每一代最优解的附近，根据亲和度的大小进行克隆，产生一个变异解的群体，从而扩大搜索范围，有助于防止进化的早熟和搜索限于局部极小值，同时通过克隆选择来加快收敛速度。其基本思想为：随机生成N个抗体组成的抗体群，对这些抗体进行一些操作后，选出抗体中优秀的决定基片段，针对这些优秀的决定基片段进行克隆操作，从而形成子抗体。克隆选择操作只是在优秀的抗体决定基中进行，而不是抗体的所有决定基中。

子步骤7：若健康度为健康的服务器的占比小于第一设定阈值，则增加健康度为健康的服务器的占比；然后，返回子步骤2继续执行。

即，若健康度为健康的服务器的占比小于第一设定阈值，则增加健康度为健康的服务器的占比，并根据增加后的占比继续判断健康度为健康的服务器的占比是否大于或等于第一设定阈值，直至增加后的占比大于或等于第一设定阈值。

也即，若为业务请求所请求的业务提供服务的所有服务器中，健康度为健康的服务器的占比小于第一设定阈值，此种情况下，可以通过一定方式虚拟增加健康度为健康的服务器的数量，进而提高其占比，以提高健康度为健康的服务器被选中的概率。

其中，可以通过克隆选择算法，增加健康度为亚健康的服务器的占比。

通过上述过程，可以从获取的为业务请求所请求的业务提供服务的所有服务器，以较大概率选择出健康度为健康或亚健康的服务器，为所述业务提供服务。

步骤S212：将确定的所述服务器的信息携带在业务请求响应中，向业务端发送所述业务请求响应。

通过本实施例提供的负载均衡方法，根据业务端发送的业务请求，获取可以为该业务请求所请求的业务提供服务的至少一个服务器的信息，包括服务器的地址和服务器的健康度；进而，根据健康度的占比选择最终提供服务的服务器。通过引入多个健康度级别，可以及时获取服务器的当前服务状态。以健康度的占比信息为负载均衡依据，选择为业务请求提供服务的服务器，一方面，可以从整体上了解可提供服务的服务器的整体状态情况，以进行负载均衡调整；另一方面，可以通过选择健康度较好的服务器提供服务，以提高获取有效的服务器进行服务的效率。通过基于服务器的健康度进行负载均衡的方式，有效地降低了服务器的访问压力，提高了获取的服务器的可用性，从而实现了获取有效的服务器来满足实际服务的需求。

本实施例的负载均衡方法可以由任意具有数据处理功能的服务器实现。

实施例三

参照图4，示出了根据本发明实施例三的一种负载均衡方法的步骤流程图。

本实施例以一个具体实施例的形式对本发明实施例提供的负载均衡方法进行说明。为便于理解，以下首先对本实施例中使用的负载均衡系统进行简要说明。

如图5所示，该负载均衡系统包括：服务模块servicemodule(被管理服务器管理的服务器，提供基础服务，由一系列服务器组成，为businessservice提供服务，businessservice通过访问服务器的IP获取某些基础服务)、管理nameservice平台(管理服务器，集注册/注销、心跳探测、服务发现于一体的服务器，businessservice通过访问其IP进行通信)、基础业务方businessservice(业务端)。其中，servicemodule中有IP地址为1.1.1.1，1.1.1.2，1.1.1.3，1.1.1.4的四台服务器部署基础用户信息服务，并对外提供相应服务。本实例中，设定nameservice的IP地址为2.2.2.2；businessservice作为业务端，IP地址为3.3.3.3。

businessservice需要调用servicemodule满足相应的业务需求，如获取基础用户的信息，或者，实现某种具体业务。

Servicemodule需要先注册到nameservice。其中，nameservice具有有注册/注销功能，并且提供平台操作。只需要将1.1.1.1～1.1.1.4陆续在nameservice注册平台上完成注册行为，同时平台会返回一个name(注册服务的服务名，在管理服务平台完成注册后返回的一个唯一代号)，记为name＝user。即，user像个领导人，管理着1.1.1.1～1.1.1.4这4台服务器，user是这4台服务器的统一名字，如图6所示。

图5中同时示出了传统的服务发现模式和本发明实施例提供的服务发现模块。在传统的服务发现模式中，businessservice调用servicemodule服务的时候，通过LB算法得出一个IP，直接指定这个IP(比如1.1.1.1)进行服务，有可能无法获取有效的服务器，以满足实际服务需求。而本发明实施例提供的服务发现则通过引入健康度作为LB因子进行LB，有效解决了传统服务发现模式的上述问题。

nameservice有个子模块叫服务心跳探活器(用于双向心跳检测)，具备HeartBeat探活功能，采用双向-主动高优的探活模型，如图7所示。

图7中，服务心跳探活器会每隔3S向servicemodule的服务器发出T-Periodic-Detect(T周期性探测，一个T-Periodic-Detect是3个连续的HeartBeat)，即连续三个HeartBeat，然后服务心跳探活器会根据HeartBeat的返回结果，计算出servicemodule服务机器的健康度Health degree(给服务定义的安全级别，p0：健康；p1：亚健康：p2：病态；p3：死亡)。具体包括：

1.若T-Periodic-Detect中的三个HeartBeat在Max-Health-Timeout(最大健康度探测时间，描述的是HeartBeat的最大响应时间，如果单次HeartBeat超过Max-Health-Timeout，则默认servicemodule的Health degree是p3)内，全部正常返回，则Healthdegree＝p0，表示健康度为健康；

2.若T-Periodic-Detect中的三个HeartBeat在Max-Health-Timeout内，仅有2个正常返回，则Health degree＝p1，表示健康度为亚健康；

3.若T-Periodic-Detect中的三个HeartBeat在Max-Health-Timeout内，仅有1个正常返回，则Health degree＝p2，表示健康度为病态；

4.若T-Periodic-Detect中的三个HeartBeat在Max-Health-Timeout内，仅有0个正常返回，则Health degree＝p3，表示健康度为死亡。

同时，由图7中可以看出每个servicemodule上都有部署一个monitor，这个monitor的功能是发出M-Periodic-Detect(分钟级别探测推送，一个M-Periodic-Detect是servicemodule的服务器每分钟推送一次自身的Health degree，推送到服务心跳探活器)，即每分钟采集自身机器的状态主动推送给服务心跳探活器，服务心跳探活器根据monitor的推送结果去重置Health degree，不论当前的Health degree出于何种状态。换句话说，在Health degree的定义中，M-Periodic-Detect主动推送的优先级高于T-Periodic-Detect。

在双向-主动高优探活模型中，双向指的是存在T-Periodic-Detect和M-Periodic-Detect。传统的单向T-Periodic-Detect，因为无论是servicemodule的服务器还是服务心跳探活器都存在宕机停服的风险，比如服务心跳探活器的HeartBeat进程挂掉后，无法再访问servicemodule机器时，那么T-Periodic-Detect通道会都被阻塞，因HeartBeat无法触及servicemodule机器，而造成servicemodule的服务默认Health Degree都是p3，不可用。而在双向-主动高优探活模型中，因为还存在M-Periodic-Detect的通道，服务心跳探活器还能够正常去更新servicemodule机器的Health Degree，保证服务高可用。

基于上述负载均衡系统，本实施例的负载均衡方法包括以下步骤：

步骤S302：businessservice向nameservice发送请求，传递name＝user。

businessservice只需要调用nameservice，并将name＝user当做参数传递。

步骤S304：nameservice接受请求，取出user下管理的非死亡状态(health degree＝p3)的服务器列表，记servicelist＝{Ip1,Ip2...Ipi,…,Ipn}，共n个服务器，同时Ipi服务器的health degree记为Hdi，Hdi包含{p0,p1,p2}。

步骤S306：判断servicelist是否为空，如果servicelist为空，说明user下的服务器全部都是死亡状态，则给businessservice返回false；否则，自动进入步骤S308。

步骤S308：判断servicelist中Hdi＝p0的占比是否为0，如果为0，说明user下的服务器全部都是p2、p3状态，进入步骤S310判断；否则，自动进入步骤S312。

步骤S310：判断servicelist中Hdi＝p1的占比是否为0，如果为0，则自动进入步骤S316，否则，自动进入步骤S314。

步骤S312：判断servicelist中Hdi＝p0的占比是否>＝50％，如果是，则进入步骤S310；如果否，则使用随机克隆选择算法克隆servicelist中的Hdi＝p0的实例数，然后重复进入步骤S312。

步骤S314：判断servicelist中除了Hdi＝p0的实例后，Hdi＝p1的剩余占比是否>＝50％，如果是，则自动进入步骤S316；如果否，则使用随机克隆选择算法克隆servicelist中的Hdi＝p1的实例数，然后重复进入步骤S314。

步骤S316：对于最终得到的servicelist做LB(Load Balance，负载均衡)，得到一个随机IP，返回给businessservice。

根据本实施例，通过双向-主动高优的探活模型，提高了服务器健康度检测的准确性，并可有效预防单向崩溃风险；引入“健康度”的概念，更细粒度地提高LB服务的高可用，对于一个服务，不再是“健康”和“不健康”两个级别，而是包含多个健康级别去区分服务，更好地贴合业务；把“健康度”当成负载均衡因子引入LB，保证了服务的健康均衡性和高可用性。

实施例四

本发明实施例还提供了一种计算机存储介质，所述计算机存储介质中存储有：用于接收业务端发送的业务请求的指令；用于根据所述业务请求，获取为所述业务请求所请求的业务提供服务的至少一个服务器的信息的指令，其中，所述服务器的信息包括所述服务器的地址和所述服务器的健康度，所述健康度包括以下之一：健康、亚健康、病态、死亡；用于根据所述服务器中的所述健康度的占比信息，选择为所述业务请求所请求的业务提供服务的服务器的指令；用于将选择的所述服务器的信息携带在业务请求响应中，向所述业务端发送所述业务请求响应的指令。

可选地，用于根据所述服务器中的所述健康度的占比信息，选择为所述业务请求所请求的业务提供服务的服务器的指令，包括：用于根据所述健康度为健康的服务器的占比信息和所述健康度为亚健康的服务器的占比信息，选择为所述业务请求所请求的业务提供服务的服务器的指令。

可选地，所述用于根据所述健康度为健康的服务器的占比信息和所述健康度为亚健康的服务器的占比信息，选择为所述业务请求所请求的业务提供服务的服务器的指令，包括：用于判断所述服务器中是否存在所述健康度为健康的服务器的指令；用于若存在，则判断所述健康度为健康的服务器的占比是否大于或等于第一设定阈值的指令；用于若大于或等于所述第一设定阈值，则结合所述健康度为亚健康的服务器的占比，选择为所述业务请求所请求的业务提供服务的服务器的指令。

可选地，所述计算机存储介质中还存储有：用于若所述健康度为健康的服务器的占比小于所述第一设定阈值，则增加所述健康度为健康的服务器的占比，并根据增加后的占比继续判断所述健康度为健康的服务器的占比是否大于或等于所述第一设定阈值，直至增加后的占比大于或等于所述第一设定阈值的指令。

可选地，所述增加所述健康度为健康的服务器的占比，包括：通过克隆选择算法，增加所述健康度为健康的服务器的占比。

可选地，所述用于若大于或等于所述第一设定阈值，则结合所述健康度为亚健康的服务器的占比，选择为所述业务请求所请求的业务提供服务的服务器的指令，包括：用于若大于或等于所述第一设定阈值，则判断所述服务器中是否存在所述健康度为亚健康的服务器的指令；用于若存在，则判断所述健康度为亚健康的服务器的占比是否大于或等于第二设定阈值的指令；用于若是，则从获取的所述至少一个服务器中选择提供服务的服务器的指令；用于若不是，则增加所述健康度为亚健康的服务器的占比，并根据增加后的占比继续判断所述健康度为亚健康的服务器的占比是否大于或等于所述第二设定阈值，直至增加后的占比大于或等于所述第二设定阈值。

可选地，所述计算机存储介质中还存储有：用于若不存在所述健康度为亚健康的服务器，则从获取的所述至少一服务器中选择提供服务的服务器的指令。

可选地，所述计算机存储介质中还存储有：用于若所述服务器中不存在所述健康度为健康的服务器，则判断所述服务器中是否存在所述健康度为亚健康的服务器的指令；用于若存在，则判断所述健康度为亚健康的服务器的占比是否大于或等于第二设定阈值的指令；用于若是，则从获取的所述至少一服务器中确定提供服务的服务器的指令；用于若不是，则增加所述健康度为亚健康的服务器的占比，并根据增加后的占比继续判断所述健康度为亚健康的服务器的占比是否大于或等于所述第二设定阈值，直至增加后的占比大于或等于所述第二设定阈值的指令。

可选地，所述计算机存储介质中还存储有：用于若不存在所述健康度为亚健康的服务器，则从获取的所述至少一服务器中确定提供服务的服务器的指令。

可选地，所述增加所述健康度为亚健康的服务器的占比，包括：通过克隆选择算法，增加所述健康度为亚健康的服务器的占比。

可选地，所述计算机存储介质中还存储有：用于在所述接收业务端发送的业务请求之前，向多个服务器发送第一心跳检测消息，根据所述多个服务器的返回结果确定所述多个服务器的第一健康度；并且，接收所述多个服务器推送的第二心跳检测消息，根据所述第二心跳检测消息确定所述多个服务器的第二健康度的指令；用于根据所述第一健康度和所述第二健康度，确定所述多个服务器的最终健康度的指令；其中，所述多个服务器包括为所述业务请求所请求的业务提供服务的所述至少一个服务器。

可选地，用于根据所述第一健康度和所述第二健康度，确定所述多个服务器的最终健康度的指令，包括：用于针对所述多个服务器中的每个服务器，判断对应的第一健康度和第二健康度是否一致；若不一致，则将所述第二健康度确定为当前服务器的最终健康度的指令。

可选地，所述用于向多个服务器发送第一心跳检测消息，根据所述多个服务器的返回结果确定所述多个服务器的第一健康度的指令，包括：用于每隔设定时间间隔向所述多个服务器中的每个服务器发送设定数量的第一心跳检测消息的指令；用于接收每个服务器在设定时间段内对每个第一心跳检测消息的返回结果，根据所述返回结果的数量确定当前服务器的第一健康度的指令。

可选地，所述用于根据所述返回结果的数量确定当前服务器的第一健康度的指令，包括：用于若所述返回结果的数量与所述设定数量相同，则确定当前服务器的第一健康度为健康的指令；用于若所述返回结果的数量小于所述设定数量且大于第一设定值，则确定当前服务器的第一健康度为亚健康的指令；用于若所述返回结果的数量小于所述第一设定值且大于第二设定值，则确定当前服务器的第一健康度为病态的指令；用于若无返回结果，则确定当前服务器的第一健康度为死亡的指令；其中，所述第一设定值大于所述第二设定值。

可选地，所述业务请求中携带有待请求的服务器组的标识信息，其中，所述服务器组包括至少一个服务器；所述用于根据所述业务请求，获取为所述业务请求所请求的业务提供服务的至少一个服务器的信息的指令，包括：用于根据所述业务请求中的服务器组的标识信息，从所述标识信息所标识的服务器组中获取为所述业务请求所请求的业务提供服务的至少一个服务器的信息的指令。

可选地，所述计算机存储介质中还存储有：用于在所述接收业务端发送的业务请求之前，接收所述服务器组的注册请求，根据所述注册请求为所述服务器组进行注册并生成对应的标识信息；向所述服务器组返回所述标识信息的指令。

通过本实施例的计算机存储介质，可以实现前述多个方法实施例中相应的负载均衡方法，并具有相应实施例的有益效果，在此不再赘述。

以上所描述的方法实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

Claims (17)

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

接收业务端发送的业务请求；

根据所述业务请求，获取为所述业务请求所请求的业务提供服务的至少一个服务器的信息，其中，所述服务器的信息包括所述服务器的地址和所述服务器的健康度，所述健康度包括以下之一：健康、亚健康、病态、死亡；

根据所述服务器中的所述健康度的占比信息，选择为所述业务请求所请求的业务提供服务的服务器；

将选择的所述服务器的信息携带在业务请求响应中，向所述业务端发送所述业务请求响应。

2.根据权利要求1所述的方法，其特征在于，根据所述服务器中的所述健康度的占比信息，选择为所述业务请求所请求的业务提供服务的服务器，包括：

根据所述健康度为健康的服务器的占比信息和所述健康度为亚健康的服务器的占比信息，选择为所述业务请求所请求的业务提供服务的服务器。

3.根据权利要求2所述的方法，其特征在于，所述根据所述健康度为健康的服务器的占比信息和所述健康度为亚健康的服务器的占比信息，选择为所述业务请求所请求的业务提供服务的服务器，包括：

判断所述服务器中是否存在所述健康度为健康的服务器；

若存在，则判断所述健康度为健康的服务器的占比是否大于或等于第一设定阈值；

若大于或等于所述第一设定阈值，则结合所述健康度为亚健康的服务器的占比，选择为所述业务请求所请求的业务提供服务的服务器。

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

若所述健康度为健康的服务器的占比小于所述第一设定阈值，则增加所述健康度为健康的服务器的占比，并根据增加后的占比继续判断所述健康度为健康的服务器的占比是否大于或等于所述第一设定阈值，直至增加后的占比大于或等于所述第一设定阈值。

5.根据权利要求4所述的方法，其特征在于，所述增加所述健康度为健康的服务器的占比，包括：

通过克隆选择算法，增加所述健康度为健康的服务器的占比。

6.根据权利要求3所述的方法，其特征在于，所述若大于或等于所述第一设定阈值，则结合所述健康度为亚健康的服务器的占比，选择为所述业务请求所请求的业务提供服务的服务器，包括：

若大于或等于所述第一设定阈值，则判断所述服务器中是否存在所述健康度为亚健康的服务器；

若存在，则判断所述健康度为亚健康的服务器的占比是否大于或等于第二设定阈值；

若是，则从获取的所述至少一个服务器中选择提供服务的服务器；

若不是，则增加所述健康度为亚健康的服务器的占比，并根据增加后的占比继续判断所述健康度为亚健康的服务器的占比是否大于或等于所述第二设定阈值，直至增加后的占比大于或等于所述第二设定阈值。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

若不存在所述健康度为亚健康的服务器，则从获取的所述至少一服务器中选择提供服务的服务器。

8.根据权利要求3所述的方法，其特征在于，所述方法还包括：

若所述服务器中不存在所述健康度为健康的服务器，则判断所述服务器中是否存在所述健康度为亚健康的服务器；

若存在，则判断所述健康度为亚健康的服务器的占比是否大于或等于第二设定阈值；

若是，则从获取的所述至少一服务器中确定提供服务的服务器；

若不是，则增加所述健康度为亚健康的服务器的占比，并根据增加后的占比继续判断所述健康度为亚健康的服务器的占比是否大于或等于所述第二设定阈值，直至增加后的占比大于或等于所述第二设定阈值。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括：

若不存在所述健康度为亚健康的服务器，则从获取的所述至少一服务器中确定提供服务的服务器。

10.根据权利要求6或8所述的方法，其特征在于，所述增加所述健康度为亚健康的服务器的占比，包括：

通过克隆选择算法，增加所述健康度为亚健康的服务器的占比。

11.根据权利要求1所述的方法，其特征在于，在所述接收业务端发送的业务请求之前，所述方法还包括：

向多个服务器发送第一心跳检测消息，根据所述多个服务器的返回结果确定所述多个服务器的第一健康度；

并且，接收所述多个服务器推送的第二心跳检测消息，根据所述第二心跳检测消息确定所述多个服务器的第二健康度；

根据所述第一健康度和所述第二健康度，确定所述多个服务器的最终健康度；

其中，所述多个服务器包括为所述业务请求所请求的业务提供服务的所述至少一个服务器。

12.根据权利要求11所述的方法，其特征在于，根据所述第一健康度和所述第二健康度，确定所述多个服务器的最终健康度，包括：

针对所述多个服务器中的每个服务器，判断对应的第一健康度和第二健康度是否一致；

若不一致，则将所述第二健康度确定为当前服务器的最终健康度。

13.根据权利要求11或12所述的方法，其特征在于，所述向多个服务器发送第一心跳检测消息，根据所述多个服务器的返回结果确定所述多个服务器的第一健康度，包括：

每隔设定时间间隔向所述多个服务器中的每个服务器发送设定数量的第一心跳检测消息；

接收每个服务器在设定时间段内对每个第一心跳检测消息的返回结果，根据所述返回结果的数量确定当前服务器的第一健康度。

14.根据权利要求13所述的方法，其特征在于，所述根据所述返回结果的数量确定当前服务器的第一健康度，包括：

若所述返回结果的数量与所述设定数量相同，则确定当前服务器的第一健康度为健康；

若所述返回结果的数量小于所述设定数量且大于第一设定值，则确定当前服务器的第一健康度为亚健康；

若所述返回结果的数量小于所述第一设定值且大于第二设定值，则确定当前服务器的第一健康度为病态；

若无返回结果，则确定当前服务器的第一健康度为死亡；

其中，所述第一设定值大于所述第二设定值。

15.根据权利要求1所述的方法，其特征在于，所述业务请求中携带有待请求的服务器组的标识信息，其中，所述服务器组包括至少一个服务器；

所述根据所述业务请求，获取为所述业务请求所请求的业务提供服务的至少一个服务器的信息，包括：根据所述业务请求中的服务器组的标识信息，从所述标识信息所标识的服务器组中获取为所述业务请求所请求的业务提供服务的至少一个服务器的信息。

16.根据权利要求15所述的方法，其特征在于，在所述接收业务端发送的业务请求之前，所述方法还包括：

接收所述服务器组的注册请求，根据所述注册请求为所述服务器组进行注册并生成对应的标识信息；

向所述服务器组返回所述标识信息。

17.一种计算机存储介质，其特征在于，所述计算机存储介质中存储有：

用于接收业务端发送的业务请求的指令；

用于根据所述业务请求，获取为所述业务请求所请求的业务提供服务的至少一个服务器的信息的指令，其中，所述服务器的信息包括所述服务器的地址和所述服务器的健康度，所述健康度包括以下之一：健康、亚健康、病态、死亡；

用于根据所述服务器中的所述健康度的占比信息，选择为所述业务请求所请求的业务提供服务的服务器的指令；

用于将选择的所述服务器的信息携带在业务请求响应中，向所述业务端发送所述业务请求响应的指令。