负载均衡方法、装置、电子设备和介质

技术领域

本申请涉及计算机技术领域，尤其涉及负载均衡方法、装置、电子设备和介质。

背景技术

随着互联网计算机技术的快速发展，基于http协议的应用服务成为了主流，面对海量互联网用户的http流量冲击，促生了http负载均衡领域的技术发展，其主要的功能是保证http服务的高可用和高性能。

目前，负载均衡技术方案分为静态负载均衡和动态负载均衡两种类型，其中，静态负载均衡具有固定的负载分配策略，无法根据系统的实时负载情况进行适应性调整；而动态负载均衡可以根据系统的实时负载情况现动态调整，具有更高的灵活性和高效性，其中，动态负载均衡算法一般包括轮询法、加权轮询法以及源地址哈希法。虽然现有的动态负载均衡算法在提供高可用性和性能方面取得了很大进展，但仍然存在一些不足之处。对于轮询法，当服务性能参差不齐时，平均分配流量会导致性能差的服务响应缓慢，导致服务稳定性下降；通过源地址哈希取模计算，同样也是采取均分流量的策略，会出现性能好的服务资源浪费，性能差的服务稳定性下降；加权轮询法在面对实际服务资源性能动态变化的场景，按照既定的静态权重分配流量，会出现流量分配不均的问题。

发明内容

本申请旨在至少解决现有技术中存在的技术问题之一。为此，本申请提出一种负载均衡方法，通过服务节点的性能指标确定评分值，基于评分值的负载均衡方式可以更智能地分配服务请求，提高整体系统性能和资源利用率，并优化服务节点的利用，提供更高效、可靠的服务。

本申请还提出一种负载均衡装置、电子设备和存储介质。

根据本申请第一方面实施例的负载均衡方法，包括：

基于各服务节点对历史服务请求的响应信息，确定各服务节点的性能指标；

基于所述性能指标与所述历史服务请求的请求持续时间，确定各服务节点的评分参数；

基于所述评分参数和各服务节点对所述历史服务请求的调用成功率，确定各服务节点的评分值；所述评分值用于表征服务节点的服务性能；

基于所述评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至所述第一目标服务节点。

本申请实施例通过服务节点的性能指标确定评分值，基于评分值的负载均衡方式可以更智能地分配服务请求，提高整体系统性能和资源利用率，并优化服务节点的利用，提供更高效、可靠的服务。

根据本申请的一个实施例，所述性能指标包括垃圾回收时间、CPU使用率、内存使用率以及硬盘每秒输入输出的次数；

所述基于所述性能指标与所述历史服务请求的请求持续时间，确定各服务节点的评分参数，包括：

对各服务节点的所述垃圾回收时间、所述CPU使用率、所述内存使用率、所述硬盘每秒输入输出的次数以及所述请求持续时间，进行归一化处理；

获取归一化后的所述垃圾回收时间、所述CPU使用率、所述内存使用率、所述硬盘每秒输入输出的次数以及所述请求持续时间的乘积，将所述乘积作为各服务节点的评分参数。

根据本申请的一个实施例，所述基于所述评分参数和各服务节点对所述历史服务请求的调用成功率，确定各服务节点的评分值，包括：

获取各服务节点的所述评分参数与各服务节点的所述调用成功率之间的比值；

将所述比值作为各服务节点的评分值。

根据本申请的一个实施例，所述基于所述评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至所述第一目标服务节点，包括：

确定各服务节点的评分值的排序结果；

基于所述排序结果和所述服务请求的总数量，确定至少一个所述第一目标服务节点以及每个所述第一目标服务节点的所述服务请求的待分配数量；

基于每个所述第一目标服务节点的所述服务请求的待分配数量，向所述第一目标服务节点转发至少一个服务请求。

根据本申请的一个实施例，所述基于各服务节点对历史服务请求的响应信息，确定各服务节点的性能指标，包括：

对所述响应信息的消息头字段进行解析；所述消息头字段携带所述服务节点的性能指标；

从解析结果中获取各服务节点的性能指标。

根据本申请的一个实施例，所述基于所述评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至所述第一目标服务节点之后，还包括：

获取所述第一目标服务节点的健康检测信息；

基于所述健康检测信息，确定故障服务节点以及所述故障服务节点的故障类型；

基于所述故障类型，调整所述故障服务节点处理所述服务请求的数量。

根据本申请的一个实施例，所述基于所述故障类型，调整所述故障服务节点处理所述服务请求的数量，包括：

确定所述故障类型为第一类型，则获取所述故障服务节点的服务请求处理量，将超出所述服务请求处理量的服务请求转发至备份节点或至少一个第二目标服务节点；其中，所述服务请求处理量小于所述故障服务节点的服务请求的待分配数量；

确定所述故障类型为第二类型，则将所述故障服务节点从负载均衡池中移除，并将所述故障服务节点的服务请求转发至备份服务节点或至少一个第二目标服务节点。

根据本申请第二方面实施例的负载均衡装置，包括：

获取模块，用于基于各服务节点对历史服务请求的响应信息，确定各服务节点的性能指标；

评分参数确定模块，用于基于所述性能指标与所述历史服务请求的请求持续时间，确定各服务节点的评分参数；

评分值确定模块，用于基于所述评分参数和各服务节点对所述历史服务请求的调用成功率，确定各服务节点的评分值；所述评分值用于表征服务节点的服务性能；

转发模块，用于基于所述评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至所述第一目标服务节点。

根据本申请第三方面实施例的电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述负载均衡方法。

根据本申请第四方面实施例的非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述负载均衡方法。

本申请实施例中的上述一个或多个技术方案，至少具有如下技术效果之一：

更智能地分配服务请求，提高整体系统性能和资源利用率，并优化服务节点的利用，提供更高效、可靠的服务；

实现动态分配流量的目的，提升http应用服务的稳定性和可靠性。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

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

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

图2是本申请实施例提供的负载均衡装置的模块示意图；

图3是本申请实施例提供的电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本申请的实施方式作进一步详细描述。以下实施例用于说明本申请，但不能用来限制本申请的范围。

在本申请实施例的描述中，需要说明的是，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

在本申请实施例中，除非另有明确的规定和限定，第一特征在第二特征“上”或“下”可以是第一和第二特征直接接触，或第一和第二特征通过中间媒介间接接触。而且，第一特征在第二特征“之上”、“上方”和“上面”可是第一特征在第二特征正上方或斜上方，或仅仅表示第一特征水平高度高于第二特征。第一特征在第二特征“之下”、“下方”和“下面”可以是第一特征在第二特征正下方或斜下方，或仅仅表示第一特征水平高度小于第二特征。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

图1是本申请实施例提供的负载均衡方法的流程示意图。参照图1，本申请实施例提供一种负载均衡方法，包括：

步骤100，基于各服务节点对历史服务请求的响应信息，确定各服务节点的性能指标；

需要说明的是，不同的http应用程序可能具有不同的负载模式和资源需求，因此，通用的负载均衡算法可能无法满足所有http应用程序的需求，这可能导致http应用程序的性能下降或资源浪费。基于此，本申请实施例通过抽取http应用程序的运行特征综合协调动态负载均衡策略，以提高负载均衡的性能。

采集各服务节点对历史服务请求的响应信息，即采集各服务节点在过去已完成的服务请求中，返回给用户的响应数据或信息。其中，历史服务请求是指应用程序中已发生的、过去已完成的服务请求记录，包括用户对应用程序发起的各种请求，如http请求、API调用、数据库查询等。然后，从各服务节点对历史服务请求的响应信息中提取各服务节点的性能指标。具体地，对响应信息的消息头字段进行解析，从解析结果中获取各服务节点的性能指标，其中，消息头字段携带服务节点的性能指标。

例如，通过http协议中自定义的header传递性能指标信息，header是指在http请求和响应消息中的消息头字段，将相应的性能指标值作为消息头字段的值进行传递。例如，自定义header属性列表为：

表1

客户端发送http请求时，可以在http请求头中添加该自定义消息头字段及对应的性能指标值，而服务器在返回响应信息时也可以在响应头中包含该消息头字段及对应的性能指标值。基于此，对响应信息的消息头字段进行解析，即可获取各服务节点的性能指标。

步骤200，基于所述性能指标与所述历史服务请求的请求持续时间，确定各服务节点的评分参数；

需要说明的是，请求持续时间（Round Trip Time，RTT）表示网络请求从起点到达目的地并再次返回起点所需的持续时间，该指标和评分结果成反比例关系，即请求持续时间越长表明网络延迟越大，需要降低http流量分配，反之则增加http流量分配。

基于响应信息获取各服务节点的性能指标后，基于性能指标与历史服务请求的请求持续时间，确定各服务节点的评分参数，其中，评分参数用于对服务节点的服务性能进行评估和量化。

步骤300，基于所述评分参数和各服务节点对所述历史服务请求的调用成功率，确定各服务节点的评分值；所述评分值用于表征服务节点的服务性能；

需要说明的是，调用成功率（Invocation Success Rate，SuccRate），是指在服务或系统中，成功完成所请求服务的比例或百分比。其中，http状态返回码为200的标记为成功请求，非200的为失败请求，累计计数，成功请求数所占百分比即为调用成功率。该指标和评分结果成正比例关系，旨在为调用成功率高的服务节点合理提供更多http流量，反之降低服务节点的http流量。

基于评分参数和各服务节点对历史服务请求的调用成功率，确定各服务节点的评分值，其中，评分值用于表征服务节点的服务性能；评分值越高，服务性能越好；评分值越低，服务性能越差。

步骤400，基于所述评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至所述第一目标服务节点。

基于评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至第一目标服务节点，以实现负载均衡。

可选地，持续监控服务节点的性能，并相应地更新评分值。如果性能指标发生变化，则根据需要调整评分值，如此动态调整有助于保持最佳的负载均衡策略。

本申请实施例提供的负载均衡方法，通过基于各服务节点对历史服务请求的响应信息，确定各服务节点的性能指标；基于性能指标与历史服务请求的请求持续时间，确定各服务节点的评分参数；基于评分参数和各服务节点对历史服务请求的调用成功率，确定各服务节点的评分值；评分值用于表征服务节点的服务性能；基于评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至第一目标服务节点。本申请实施例通过服务节点的性能指标确定评分值，基于评分值的负载均衡方式可以更智能地分配服务请求，提高整体系统性能和资源利用率，并优化服务节点的利用，提供更高效、可靠的服务。

基于上述实施例，所述基于所述性能指标与所述历史服务请求的请求持续时间，确定各服务节点的评分参数，包括：

步骤210，对各服务节点的所述垃圾回收时间、所述CPU使用率、所述内存使用率、所述硬盘每秒输入输出的次数以及所述请求持续时间，进行归一化处理；

步骤220，获取归一化后的所述垃圾回收时间、所述CPU使用率、所述内存使用率、所述硬盘每秒输入输出的次数以及所述请求持续时间的乘积，将所述乘积作为各服务节点的评分参数。

需要说明的是，性能指标包括垃圾回收时间（garbage collection time，GCTime）、CPU使用率（Central Processing Unit Usage Rate，CPUUsage）、内存使用率（Random Access Memory Usage Rate，MemoryUsage）以及硬盘每秒输入输出的次数（Input/Output Operations Per Second，DiskIOPS），其中：

垃圾回收时间是指执行垃圾回收操作所花费的时间。当某个程序占用的一部分内存空间不再被这个程序访问时，这个程序会借助垃圾回收算法向操作系统归还这部分内存空间。该指标和评分结果成反比例关系，垃圾回收时间长表明应用负载高，需要降低http流量分配，反之增加http流量分配；

CPU使用率，该指标和评分结果成反比例关系，CPU使用率高表明应用计算负载高，需要降低http流量分配，反之增加http流量分配；

内存使用率，该指标和评分结果成反比例关系，内存使用率高表明应用计算使用计算内存容量高，需要降低http流量分配，反之增加http流量分配；

硬盘每秒输入输出的次数，该指标和评分结果成反比例关系，硬盘每秒输入输出的次数高表明硬盘存储设备输入输出繁忙，需要降低http流量分配，反之增加流量分配。

由于各性能指标的单位不一致，因此需要对各性能指标进行归一化处理，具体地，对各服务节点的垃圾回收时间、CPU使用率、内存使用率、硬盘每秒输入输出的次数以及请求持续时间，进行归一化处理。例如，对各性能指标进行标准差归一化处理，包括以下步骤：

（1）计算每个性能指标的平均值（Mean）和标准差（Standard Deviation）；

（2）对于垃圾回收时间、CPU使用率、内存使用率、硬盘每秒输入输出次数和请求持续时间的每个具体值（Value），应用以下公式进行标准化处理：

标准化值=(Value-Mean)/Standard Deviation，其中，Value为原始值，Mean为平均值，Standard Deviation为标准差。

通过以上步骤，可以将不同性能指标的取值范围统一到均值为0、标准差为1的区间，以消除单位不一致的影响，方便进行综合评估和比较分析。

在归一化各性能指标后，获取垃圾回收时间、CPU使用率、内存使用率、硬盘每秒输入输出的次数以及请求持续时间的乘积，将乘积作为各服务节点的评分参数。例如，评分参数=垃圾回收时间

进一步地，获取各服务节点的评分参数与各服务节点的调用成功率之间的比值，将比值作为各服务节点的评分值，例如，评分值=调用成功率/评分参数，即评分公式如下：

；

其中，

本申请实施例通过实时获取http应用的性能指标，借助动态的评分公式，将评分实时动态的反馈到流量分配权重中，以使服务性能好的服务节点获取到更多http流量，反之则分配较少的流量，从而达到动态分配流量的目的，提升http应用服务的稳定性和可靠性。

基于上述实施例，所述基于所述评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至所述第一目标服务节点，包括：

步骤410，确定各服务节点的评分值的排序结果；

步骤420，基于所述排序结果和所述服务请求的总数量，确定至少一个所述第一目标服务节点以及每个所述第一目标服务节点的所述服务请求的待分配数量；

步骤430，基于每个所述第一目标服务节点的所述服务请求的待分配数量，向所述第一目标服务节点转发至少一个服务请求。

在确定各服务节点的评分值后，对各评分值进行排序，例如按照得分从高到低的顺序排列服务节点，得到排序结果后，可以将服务节点的名称和相应的评分值列出，形成排序列表，如表2所示，4个http服务节点A，B，C、D的排序如下：

表2

然后基于排序结果和服务请求的总数量，确定至少一个第一目标服务节点以及每个第一目标服务节点的服务请求的待分配数量。其中，待分配数量可以理解为每个第一目标服务节点当前可以处理服务请求的数量。例如，假设当前接收到的服务请求数量为100条，基于评分值确定服务节点A可以处理60条、服务节点B可以处理30条、服务节点C可以处理10条，即服务节点A、B、C可以处理完100条服务请求，那么第一目标服务节点为服务节点A、B、C。进一步基于每个第一目标服务节点的服务请求的待分配数量，向第一目标服务节点转发至少一个服务请求。例如，向服务节点A分配60条服务请求、向服务节点B分配30条服务请求、向服务节点C分配10条服务请求。

本申请实施例通过实时获取http应用的性能指标，借助动态的评分公式，将评分实时动态的反馈到流量分配权重中，以使服务性能好的服务节点获取到更多http流量，反之则分配较少的流量，从而达到动态分配流量的目的，提升http应用服务的稳定性和可靠性。

基于上述实施例，所述基于所述评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至所述第一目标服务节点之后，还包括：

步骤440，获取所述第一目标服务节点的健康检测信息；

步骤450，基于所述健康检测信息，确定故障服务节点以及所述故障服务节点的故障类型；

步骤460，基于所述故障类型，调整所述故障服务节点处理所述服务请求的数量。

定期对第一目标服务节点进行检测，以获取第一目标节点的健康检测信息，如检测节点的网络连通性、CPU使用率、内存利用率、磁盘空间和读写速度等。然后，基于健康检测信息，确定故障服务节点以及故障服务节点的故障类型，基于故障类型，调整故障服务节点处理服务请求的数量。具体地：

确定故障类型为第一类型，则获取故障服务节点的服务请求处理量，将超出服务请求处理量的服务请求转发至备份节点或至少一个第二目标服务节点；其中，服务请求处理量小于故障服务节点的服务请求的待分配数量。例如，第一类型为出现故障但节点可用，即可以正常运行，可包括以下几种情况：

部分功能失效：节点上的某些功能或模块可能存在故障，但节点的其他功能仍然可以正常运行。例如，一个服务器可能存在存储故障，但仍能够响应网络请求。

性能降低：节点可能由于硬件故障、网络问题或其他原因而导致性能下降，但仍能够处理部分请求。这意味着节点仍然可以提供服务，但响应时间可能较长或处理速度较慢。

资源受限：节点可能由于资源限制（如内存不足、磁盘空间不足等）导致部分功能或服务受到影响，但仍然可以处理一部分请求。

临时故障：节点可能存在瞬时的故障，但很快自行恢复正常。这可能是由于网络抖动、临时负载过高等原因导致的故障，节点在故障后能够自动恢复。

若节点出现上述故障情况，则说明故障服务节点的故障类型为第一类型，此时，需要减少分配至该故障服务节点的服务请求数量，先获取故障服务节点的服务请求处理量，然后超出服务请求处理量的服务请求转发至备份节点或至少一个第二目标服务节点。例如，假设故障服务节点A的待分配数量为20，当前可以处理的服务请求数量为15，则将多出的5条服务请求转发至备份节点，或者重新确定的至少一个第二目标服务节点。其中，第二目标服务节点的确定方式与第一目标服务节点的确定方式相同。

需要说明的是，如果节点存在故障，即使仍然可用，也需要及时进行故障诊断和修复。故障的存在可能会导致节点性能下降、数据不一致或进一步的故障扩散，因此需要尽快解决问题，以确保系统的可靠性和稳定性。

确定故障类型为第二类型，则将故障服务节点从负载均衡池中移除，并将故障服务节点的服务请求转发至备份服务节点或至少一个第二目标服务节点。例如，第二类型为出现故障后不可用，即无法正常运行，可包括以下几种情况：

硬件故障：节点上的硬件（如服务器、网络设备等）发生严重故障导致节点无法正常运行。例如，硬盘损坏、电源故障等都可能导致节点完全无法启动或提供服务。

软件故障：节点上的关键软件组件出现故障或崩溃，导致节点无法提供服务。例如，操作系统崩溃、数据库损坏等都可能造成节点不可用。

网络故障：节点与其他节点或客户端之间的网络连接中断或不稳定，导致节点无法与其他系统通信或提供服务。例如，网络设备故障、网络拥塞等都可能导致节点无法正常工作。

人为错误：节点的管理或操作存在人为错误，导致节点失效或不可用。例如，配置错误、误操作等都可能导致节点无法正常运行。

若节点出现上述故障情况，则说明故障服务节点的故障类型为第二类型，此时，需要将其从负载均衡池中移除，并停止向该故障服务节点分发服务请求，以避免将服务请求发送到出现故障的节点上，减少因故障服务节点引起的请求失败的风险。同时，将故障服务节点的服务请求转发至备份服务节点或至少一个第二目标服务节点，以确保请求能够被及时处理，提高系统的稳定性。另一方面，还需要启动故障处理流程，对故障服务节点进行修复或替换，直到节点恢复正常运行。当故障服务节点恢复正常，可以将其重新添加到负载均衡池中，继续向其分发服务请求。

本申请实施例通过定期进行健康检查可以及时发现出现故障的节点，避免故障节点继续提供服务导致请求失败或超时，减少了对用户的影响；根据故障节点的不同情况，可以动态地将请求转发至备份节点或其他正常节点，确保请求能够被及时处理，该动态调整可以保证服务的可用性和性能，提高用户体验，同时，减少等待时间，提升系统的反应速度。另一方面，通过定期健康检查和动态调整请求分发，可以降低因为故障节点导致的系统风险，减少停机时间和维护成本，同时，及时发现和处理故障节点，可以提高系统的可维护性，减少对整个系统运行的影响。

下面对本申请实施例提供的负载均衡装置进行描述，下文描述的负载均衡装置与上文描述的负载均衡方法可相互对应参照。

参考图2，图2是本申请实施例提供的负载均衡装置的模块示意图，本申请的负载均衡装置包括获取模块201、评分参数确定模块202、评分值确定模块203和转发模块204。

获取模块201，用于基于各服务节点对历史服务请求的响应信息，确定各服务节点的性能指标；

评分参数确定模块202，用于基于所述性能指标与所述历史服务请求的请求持续时间，确定各服务节点的评分参数；

评分值确定模块203，用于基于所述评分参数和各服务节点对所述历史服务请求的调用成功率，确定各服务节点的评分值；所述评分值用于表征服务节点的服务性能；

转发模块204，用于基于所述评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至所述第一目标服务节点。

本申请实施例提供的负载均衡装置，通过基于各服务节点对历史服务请求的响应信息，确定各服务节点的性能指标；基于性能指标与历史服务请求的请求持续时间，确定各服务节点的评分参数；基于评分参数和各服务节点对历史服务请求的调用成功率，确定各服务节点的评分值；评分值用于表征服务节点的服务性能；基于评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至第一目标服务节点。本申请实施例通过服务节点的性能指标确定评分值，基于评分值的负载均衡方式可以更智能地分配服务请求，提高整体系统性能和资源利用率，并优化服务节点的利用，提供更高效、可靠的服务。

在一个实施例中，所述性能指标包括垃圾回收时间、CPU使用率、内存使用率以及硬盘每秒输入输出的次数；评分参数确定模块202，具体用于：

对各服务节点的所述垃圾回收时间、所述CPU使用率、所述内存使用率、所述硬盘每秒输入输出的次数以及所述请求持续时间，进行归一化处理；

获取归一化后的所述垃圾回收时间、所述CPU使用率、所述内存使用率、所述硬盘每秒输入输出的次数以及所述请求持续时间的乘积，将所述乘积作为各服务节点的评分参数。

在一个实施例中，评分值确定模块203，具体用于：

获取各服务节点的所述评分参数与各服务节点的所述调用成功率之间的比值；

将所述比值作为各服务节点的评分值。

在一个实施例中，转发模块204，具体用于：

确定各服务节点的评分值的排序结果；

基于所述排序结果和所述服务请求的总数量，确定至少一个所述第一目标服务节点以及每个所述第一目标服务节点的所述服务请求的待分配数量；

基于每个所述第一目标服务节点的所述服务请求的待分配数量，向所述第一目标服务节点转发至少一个服务请求。

在一个实施例中，获取模块201，具体用于：

对所述响应信息的消息头字段进行解析；所述消息头字段携带所述服务节点的性能指标；

从解析结果中获取各服务节点的性能指标。

在一个实施例中，转发模块204，还用于：

获取所述第一目标服务节点的健康检测信息；

基于所述健康检测信息，确定故障服务节点以及所述故障服务节点的故障类型；

基于所述故障类型，调整所述故障服务节点处理所述服务请求的数量。

在一个实施例中，转发模块204，还用于：

确定所述故障类型为第一类型，则获取所述故障服务节点的服务请求处理量，将超出所述服务请求处理量的服务请求转发至备份节点或至少一个第二目标服务节点；其中，所述服务请求处理量小于所述故障服务节点的服务请求的待分配数量；

确定所述故障类型为第二类型，则将所述故障服务节点从负载均衡池中移除，并将所述故障服务节点的服务请求转发至备份服务节点或至少一个第二目标服务节点。

图3示例了一种电子设备的实体结构示意图，如图3所示，该电子设备可以包括：处理器(processor)310、通信接口(Communications Interface)320、存储器(memory)330和通信总线340，其中，处理器310，通信接口320，存储器330通过通信总线340完成相互间的通信。处理器310可以调用存储器330中的逻辑指令，以执行如下方法：

基于各服务节点对历史服务请求的响应信息，确定各服务节点的性能指标；

基于所述性能指标与所述历史服务请求的请求持续时间，确定各服务节点的评分参数；

基于所述评分参数和各服务节点对所述历史服务请求的调用成功率，确定各服务节点的评分值；所述评分值用于表征服务节点的服务性能；

基于所述评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至所述第一目标服务节点。

此外，上述的存储器330中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

又一方面，本申请实施例还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以执行上述各实施例提供的负载均衡方法，例如包括：

基于各服务节点对历史服务请求的响应信息，确定各服务节点的性能指标；

基于所述性能指标与所述历史服务请求的请求持续时间，确定各服务节点的评分参数；

基于所述评分参数和各服务节点对所述历史服务请求的调用成功率，确定各服务节点的评分值；所述评分值用于表征服务节点的服务性能；

基于所述评分值确定至少一个第一目标服务节点，以将当前接收到的至少一个服务请求转发至所述第一目标服务节点。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行各个实施例或者实施例的某些部分所述的方法。

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

以上实施方式仅用于说明本申请，而非对本申请的限制。尽管参照实施例对本申请进行了详细说明，本领域的普通技术人员应当理解，对本申请的技术方案进行各种组合、修改或者等同替换，都不脱离本申请技术方案的精神和范围，均应涵盖在本申请的保护范围中。