CN114237910A - 客户端负载均衡实现方法及装置 - Google Patents

Abstract

本发明公开了一种客户端负载均衡实现方法及装置，可用于云计算技术领域，该方法包括：对第一服务实例列表中的每个服务实例，在该服务实例的健康度小于健康度阈值时，确定该服务实例为故障的服务实例，将该服务实例从第一服务实例列表中剔除，并添加至第二服务实例列表；对第一服务实例列表中的每个服务实例，在该服务实例接收到请求后，在该服务实例上处理请求，若处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上；对第二服务实例列表中的每个服务实例，若该服务实例的恢复等待时间超过预设恢复等待窗口，将该服务实例从第二服务实例列表中提出，并添加至第以服务实例列表中。本发明可提高服务请求正确率。

Description

客户端负载均衡实现方法及装置

技术领域

本发明涉及云计算技术领域，尤其涉及一种客户端负载均衡实现方法及装置。

背景技术

本部分旨在为权利要求书中陈述的本发明实施例提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

现有主流的负载均衡方案根据其工作模式可分成两类：

一种是集中式的，即在服务的消费方和提供方之间使用独立的负载均衡设施(可以是硬件，如F5，也可以是软件，如nginx)，由该设施负责把访问请求通过某种策略转发至服务的提供方；

另一种是进程内，也称之为客户端负载均衡，将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。Spring cloud中负责做服务发现和路由的Ribbon就属于后者，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。

目前主流的客户端负载均衡实现，例如spring cloud的ribbon，所提供的这些负载均衡算法，分为两类，一类是基于固定算法的调度算法，例如随机、轮询、哈希等，另外是可基于响应时间进行统计的动态负载均衡算法。但是这两者有个共同的问题，都是基于后端服务正常对外提供服务，但是由于资源分配不合理，或者流量调度不合理导致来实现负载策略调整。

在实际的应用环境中，首先后端的服务往往由于业务自身问题，或者是网络、环境问题、依赖问题等等，经常会使得后端的某个服务出现异常，从而影响了上游服务的正常调用，具体表现例如直接返回了500错误，或者是返回了业务自定义的错误，或者是直接超时不返回等等。

此时，如果仍采用随机、轮询等固定算法的轮询策略的话，必然会有一部分流量被引导到这个异常的后端服务节点，从而影响了整个系统内的请求成功率；

在金融行业，或者是一些对系统请求成功要求比较严苛的企业，这种负载均衡算法实现是不能达到业务要求的，例如轮询策略，假设有5个后端服务实例地址，配置的是轮询策略的话，如果有一个后端服务实例因为其自身资源或节点网络或下游依赖等原因无法处理之后，会直接影响到前方服务的请求调用也会出现错误，产生一些请求错误。

而此时，后端的服务状态仍然是处于存活状态，在上游调用方服务做客户端负载均衡时，仍然会把该错误的服务实例包含在可选择的服务实例列表里；因此，假设如果当前采用的是轮询或者随机等相对选择策略比较固定的负载均衡算法时，势必会存在一部分的请求流量因为后端的某个服务实例因为无法正确处理而导致出现错误，并且错误的比例会根据服务实例故障比例放大。图1为现有的轮询负载均衡的原理示意图。在传统的行业，针对上述的这种异常场景，可以通过在客户端添加重试策略进行补救，采用轮询的负载均衡策略会在重试的第二次请求中将请求转发到另外的服务实例节点上，从而让本次请求最终能够被正确处理并返回有效的数据；但是在一些金融行业的部分核心业务场景，往往无法直接对错误的请求进行重试操作，会出现重复交易等问题。如果不在消费端进行重试补救，则业务的整体请求错误率会提高，从而整体的系统稳定性变差。

因此，目前缺乏一种有效方法以解决在对请求流量的正确率要求高的场景下，客户端负载均衡策略无法将存在错误的后端服务实例从可选列表中剔除而导致业务系统的请求错误率较高的问题。

发明内容

本发明实施例提供一种客户端负载均衡实现方法，用以解决在对请求流量的正确率要求高的场景下，客户端负载均衡策略无法将存在错误的后端服务实例从可选列表中剔除而导致业务系统的请求错误率较高的问题，该方法包括：

在客户端侧获取第一服务实例列表和第二服务实例列表，所述第一服务实例列表用于存储后端的健康的服务实例，第二服务实例列表用于存储后端的故障的服务实例；

对第一服务实例列表中的每个服务实例，计算该服务实例的健康度，在该服务实例的健康度小于健康度阈值时，确定该服务实例为故障的服务实例，将该服务实例从第一服务实例列表中剔除，并添加至第二服务实例列表；

对第一服务实例列表中的每个服务实例，在该服务实例接收到请求后，在该服务实例上处理请求，若处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上；

对第二服务实例列表中的每个服务实例，获取该服务实例的恢复等待时间，若该服务实例的恢复等待时间超过预设恢复等待窗口，将该服务实例从第二服务实例列表中提出，并添加至第以服务实例列表中。

本发明实施例还提供一种客户端负载均衡实现装置，用以解决在对请求流量的正确率要求高的场景下，客户端负载均衡策略无法将存在错误的后端服务实例从可选列表中剔除而导致业务系统的请求错误率较高的问题，该装置包括：

服务实例获取模块，用于在客户端侧获取第一服务实例列表和第二服务实例列表，所述第一服务实例列表用于存储后端的健康的服务实例，第二服务实例列表用于存储后端的故障的服务实例；

健康度计算模块，用于对第一服务实例列表中的每个服务实例，计算该服务实例的健康度，在该服务实例的健康度小于健康度阈值时，确定该服务实例为故障的服务实例，将该服务实例从第一服务实例列表中剔除，并添加至第二服务实例列表；

请求处理模块，用于对第一服务实例列表中的每个服务实例，在该服务实例接收到请求后，在该服务实例上处理请求，若处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上；

服务实例恢复模块，用于对第二服务实例列表中的每个服务实例，获取该服务实例的恢复等待时间，若该服务实例的恢复等待时间超过预设恢复等待窗口，将该服务实例从第二服务实例列表中提出，并添加至第以服务实例列表中。

本发明实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述客户端负载均衡实现方法。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述客户端负载均衡实现方法。

本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现上述客户端负载均衡实现方法。

本发明实施例中，在客户端侧获取第一服务实例列表和第二服务实例列表，所述第一服务实例列表用于存储后端的健康的服务实例，第二服务实例列表用于存储后端的故障的服务实例；对第一服务实例列表中的每个服务实例，计算该服务实例的健康度，在该服务实例的健康度小于健康度阈值时，确定该服务实例为故障的服务实例，将该服务实例从第一服务实例列表中剔除，并添加至第二服务实例列表；对第一服务实例列表中的每个服务实例，在该服务实例接收到请求后，在该服务实例上处理请求，若处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上；对第二服务实例列表中的每个服务实例，获取该服务实例的恢复等待时间，若该服务实例的恢复等待时间超过预设恢复等待窗口，将该服务实例从第二服务实例列表中提出，并添加至第以服务实例列表中。与现有技术中采用轮询的负载均衡策略在重试的第二次请求中将请求转发到另外的服务实例节点上的技术方案相比，通过将故障的服务实例从第一服务实例列表中剔除，可以有效避免了请求被转发至故障的服务实例，从而导致整体的请求错误率过高的问题；而在故障的服务实例的恢复等待时间超过预设恢复等待窗口，将故障的服务实例添加至第一服务实例列表中，使其在接收到请求后，在该服务实例上处理请求，若处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上这样的试探行为，在保障了整体的最大请求成功率的同时，有效提升了所有服务实例的可用性，保障了服务的整体稳定性。

附图说明

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

图1为现有的轮询负载均衡的原理示意图；

图2为本发明实施例中客户端负载均衡实现方法的流程图；

图3为本发明实施例中计算每个服务实例的健康度的流程图；

图4为本发明实施例中客户端负载均衡实现装置的示意图；

图5为本发明实施例中计算机设备的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

首先，对本发明实施例涉及的术语进行解释。

负载均衡(Load balancing)是一种电子计算机技术，用来在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。使用带有负载平衡的多个服务器组件，取代单一的组件，可以通过冗余提高可靠性。负载平衡服务通常是由专用软件和硬件来完成。主要作用是将大量作业合理地分摊到多个操作单元上进行执行，用于解决互联网架构中的高并发和高可用的问题。

图2为本发明实施例中客户端负载均衡实现方法的流程图，包括：

步骤201，在客户端侧获取第一服务实例列表和第二服务实例列表，所述第一服务实例列表用于存储后端的健康的服务实例，第二服务实例列表用于存储后端的故障的服务实例；

步骤202，对第一服务实例列表中的每个服务实例，计算该服务实例的健康度，在该服务实例的健康度小于健康度阈值时，确定该服务实例为故障的服务实例，将该服务实例从第一服务实例列表中剔除，并添加至第二服务实例列表；

步骤203，对第一服务实例列表中的每个服务实例，在该服务实例接收到请求后，在该服务实例上处理请求，若处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上；

步骤204，对第二服务实例列表中的每个服务实例，获取该服务实例的恢复等待时间，若该服务实例的恢复等待时间超过预设恢复等待窗口，将该服务实例从第二服务实例列表中提出，并添加至第以服务实例列表中。

在本发明实施例中，与现有技术中采用轮询的负载均衡策略在重试的第二次请求中将请求转发到另外的服务实例节点上的技术方案相比，通过将故障的服务实例从第一服务实例列表中剔除，可以有效避免了请求被转发至故障的服务实例，从而导致整体的请求错误率过高的问题；而在故障的服务实例的恢复等待时间超过预设恢复等待窗口，将故障的服务实例添加至第一服务实例列表中，使其在接收到请求后，在该服务实例上处理请求，若处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上这样的试探行为，在保障了整体的最大请求成功率的同时，有效提升了所有服务实例的可用性，保障了服务的整体稳定性。

在步骤202中，计算该服务实例的健康度，在该服务实例的健康度小于健康度阈值时，确定该服务实例为故障的服务实例，将该服务实例从第一服务实例列表中剔除。

图3为本发明实施例中计算服务实例的健康度的流程图，在一实施例中，计算该服务实例的健康度，包括：

步骤301，统计该服务实例在单位时间内请求的响应状态码的错误次数、请求的慢响应次数、和自定义错误码次数；

步骤302，根据该服务实例在单位时间内请求的响应状态码的错误次数及对应权重、请求的慢响应次数及对应权重、和自定义错误码次数及对应权重，计算该服务实例的健康度。

其中，请求的响应状态码主要是根据协议层来定义本次请求是否成功被调用，例如采用HTTP协议，则非200的错误都会被划为错误的请求，因此，可统计单位时间请求的响应状态码的错误次数。

在网络相对比较稳定的环境下，一个请求的正常处理响应时间是相对比较确定的，如果网络出现抖动或者后端服务实例由于资源不足，往往会导致一个请求处理变慢，通过请求的响应时间可以大致评估出当前提供端服务实例的健康度状态；

不同的请求接口的响应时间也会不一样，默认可设置全局的慢响应时间阈值，如果一个请求的响应时间超过了该慢响应时间阈值，则认为本次请求不健康，即处理请求失败，记录为请求的慢响应次数加1；

另外，针对部分特殊的接口，可以单独设定响应的慢响应的超时阈值，用于匹配一些特殊的场景，避免将正常的响应请求被勿计算入健康度统计。

除了在协议层以及网络层可以对请求的健康度进行评估和计算外，有些特定的业务层面的错误码，是以响应报文中的特定字段来进行指明的，因此，也支持用户通过自定义配置响应报文中的错误码判断规则，从而将业务上的错误码也被计算入健康度统计；因此，可统计单位时间自定义错误码次数。

对于不同的错误，可以配置不同的权重，从而更加灵活的匹配用户对于错误的敏感度。权重会直接影响到某种错误类型在最终健康度的判定计算上，理论上某错误类型的权重数字越大，其对最终结果的影响越明显。以实际的场景举例：

请求的响应状态码的错误次数对应的权重为0.6，请求的慢响应次数对应的权重为0.1，自定义错误码次数对应的权重为0.3，最终整体的权重求和值为0.6+0.3+0.1＝1；这样子设定的好处在于，当用户只关心某种错误类型的时候，比如只需要考虑请求状态码的错误，则可直接设置该权重为1，其它的比重分别为0，这样在计算最终的健康度的时候，会自动忽略其它的两种错误类型。

可采用如下公式，计算每个服务实例的健康度：

E＝(e1×w1+e2×w2+e3×w3)/t

其中，e1、e2、e3分别为单位时间内请求的响应状态码的错误次数、请求的慢响应次数、和自定义错误码次数，w1、w2、w3为权重，t为单位时间，单位为秒。

在步骤202中，在该服务实例的健康度小于健康度阈值时，确定该服务实例为故障服务实例，将该服务实例从第一服务实例列表中剔除，其目的是为了保证整体的请求正确率，当后端某个服务实例的健康度过低，小于健康度阈值时，将其从服务实例列表中进行短暂剔除，从而避免上游请求的流量被转发到该问题服务实例上。

一般而言，后端服务实例出现故障有可能是短暂的，或者处于一些高可用机制保证，后端服务实例在异常宕机之后往往可能会被重启进程等方式恢复。

因此为了尽可能保证系统整体的可用性和稳定性，需要在服务实例健康度低被剔除一段时间之后，重新将其加入第一服务实例列表，然后重新尝试探测该服务实例的是否已经恢复。具体地，不是直接将服务实例进行恢复，而是通过半开状态的形式进行请求尝试，如果下一次请求能够被正常处理，则认为该服务实例已经恢复正常，如果该服务实例处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上。然后该服务实例需要再等待一个预设恢复等待窗口再尝试。

在一实施例中，在该服务实例上处理请求，包括：

若请求的响应时间超过慢响应时间阈值，确定处理请求失败，将该服务实例的请求的慢响应次数加一；否则，确定处理请求成功。

为了避免在健康度的统计过程中，由于下游依赖出现问题，或者网络不稳定等原因导致的波动使得后端的服务实例都被标记为故障服务实例的情况，需要对整体的剔除比例进行一个控制，即确定预设服务实例剔除条件。

在一实施例中，将该服务实例从第一服务实例列表中剔除，包括：

确定预设服务实例剔除条件；

若该服务实例剔除后，第一服务实例列表中服务实例的数量不符合预设服务实例保留条件，不对该服务实例进行剔除，否则，对该服务实例进行剔除。

在一实施例中，所述预设服务实例剔除条件包括最少服务实例保留比例或最少服务实例保留数量。

例如后端服务实例数量为10个，如果最少服务实例保留比例为50％，则当出现5个服务实例因为请求错误过高之后，将不再会有新的服务实例因为错误过高而被标记为故障服务实例，因此系统里最少会保留5个服务实例进行后端的请求处理。

例如最少实例保留数量为1个，在没有配置上述最少服务实例保留比例的前提下，在后端服务实例都存在错误过高的情况下，会逐渐将服务实例剔除到只保留最后一个，并且至少存在一个服务实例用于请求处理；

最少保留比例和最少保留数量，两个参数可以同时配置，同时生效，也可以单独只配置其中一项，在配置时需要配置两个的优先级，即默认选择哪种预设服务实例剔除条件。

综上所述，本发明实施例提出的方法的有益效果如下：

第一，通过健康度计算、故障服务实例剔除、预设恢复等待窗口等机制，保障系统整体的较高的请求成功率。

第二，基于请求的响应状态码的错误次数、请求的慢响应次数、和自定义错误码次数，对实例的健康度进行判定，并可以设置权重，允许用户根据业务不同场景灵活设定不同的权重标准，灵活性强。

第三，故障服务实例剔除，有效避免了当后端实例由于自身故障或者网络稳定性原因，仍然会有部分流量请求被转发到故障服务实例，从而导致整体的系统请求错误率过高的问题；

第四，提供了预设恢复等待窗口的故障服务实例恢复机制，并且结合请求试探行为，在保障了系统整体的最大请求成功率的同时，有效提升了整体的可用性，保障了系统的整体稳定性。

本发明实施例中还提供了一种客户端负载均衡实现装置，如下面的实施例所述。由于该装置解决问题的原理与客户端负载均衡实现方法相似，因此该装置的实施可以参见客户端负载均衡实现方法的实施，重复之处不再赘述。

图4为本发明实施例中客户端负载均衡实现装置的示意图，包括：

服务实例获取模块401，用于在客户端侧获取第一服务实例列表和第二服务实例列表，所述第一服务实例列表用于存储后端的健康的服务实例，第二服务实例列表用于存储后端的故障的服务实例；

健康度计算模块402，用于对第一服务实例列表中的每个服务实例，计算该服务实例的健康度，在该服务实例的健康度小于健康度阈值时，确定该服务实例为故障的服务实例，将该服务实例从第一服务实例列表中剔除，并添加至第二服务实例列表；

请求处理模块403，用于对第一服务实例列表中的每个服务实例，在该服务实例接收到请求后，在该服务实例上处理请求，若处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上；

服务实例恢复模块404，用于对第二服务实例列表中的每个服务实例，获取该服务实例的恢复等待时间，若该服务实例的恢复等待时间超过预设恢复等待窗口，将该服务实例从第二服务实例列表中提出，并添加至第以服务实例列表中。

在一实施例中，健康度计算模块具体用于：

统计该服务实例在单位时间内请求的响应状态码的错误次数、请求的慢响应次数、和自定义错误码次数；

根据该服务实例在单位时间内请求的响应状态码的错误次数及对应权重、请求的慢响应次数及对应权重、和自定义错误码次数及对应权重，计算该服务实例的健康度。

在一实施例中，请求处理模块具体用于：

若请求的响应时间超过慢响应时间阈值，确定处理请求失败，将该服务实例的请求的慢响应次数加一；否则，确定处理请求成功。

在一实施例中，健康度计算模块具体用于：确定预设服务实例剔除条件；若该服务实例剔除后，第一服务实例列表中服务实例的数量不符合预设服务实例保留条件，不对该服务实例进行剔除，否则，对该服务实例进行剔除。

在一实施例中，所述预设服务实例剔除条件包括最少服务实例保留比例或最少服务实例保留数量。

综上所述，本发明实施例提出的装置的有益效果如下：

第一，通过健康度计算、故障服务实例剔除、预设恢复等待窗口等机制，保障系统整体的较高的请求成功率。

第二，基于请求的响应状态码的错误次数、请求的慢响应次数、和自定义错误码次数，对实例的健康度进行判定，并可以设置权重，允许用户根据业务不同场景灵活设定不同的权重标准，灵活性强。

第三，故障服务实例剔除，有效避免了当后端实例由于自身故障或者网络稳定性原因，仍然会有部分流量请求被转发到故障服务实例，从而导致整体的系统请求错误率过高的问题；

第四，提供了预设恢复等待窗口的故障服务实例恢复机制，并且结合请求试探行为，在保障了系统整体的最大请求成功率的同时，有效提升了整体的可用性，保障了系统的整体稳定性。

本发明实施例还提供一种计算机设备，图5为本发明实施例中计算机设备的示意图，所述计算机设备500包括存储器510、处理器520及存储在存储器510上并可在处理器520上运行的计算机程序530，所述处理器520执行所述计算机程序530时实现上述客户端负载均衡实现方法。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述客户端负载均衡实现方法。

本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现上述客户端负载均衡实现方法。

综上所述，本发明实施例提出的计算机设备、计算机可读存储介质、计算机程序产品的有益效果如下：

第一，通过健康度计算、故障服务实例剔除、预设恢复等待窗口等机制，保障系统整体的较高的请求成功率。

第二，基于请求的响应状态码的错误次数、请求的慢响应次数、和自定义错误码次数，对实例的健康度进行判定，并可以设置权重，允许用户根据业务不同场景灵活设定不同的权重标准，灵活性强。

第三，故障服务实例剔除，有效避免了当后端实例由于自身故障或者网络稳定性原因，仍然会有部分流量请求被转发到故障服务实例，从而导致整体的系统请求错误率过高的问题；

第四，提供了预设恢复等待窗口的故障服务实例恢复机制，并且结合请求试探行为，在保障了系统整体的最大请求成功率的同时，有效提升了整体的可用性，保障了系统的整体稳定性。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

1.一种客户端负载均衡实现方法，其特征在于，包括：

在客户端侧获取第一服务实例列表和第二服务实例列表，所述第一服务实例列表用于存储后端的健康的服务实例，第二服务实例列表用于存储后端的故障的服务实例；

对第一服务实例列表中的每个服务实例，计算该服务实例的健康度，在该服务实例的健康度小于健康度阈值时，确定该服务实例为故障的服务实例，将该服务实例从第一服务实例列表中剔除，并添加至第二服务实例列表；

对第一服务实例列表中的每个服务实例，在该服务实例接收到请求后，在该服务实例上处理请求，若处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上；

对第二服务实例列表中的每个服务实例，获取该服务实例的恢复等待时间，若该服务实例的恢复等待时间超过预设恢复等待窗口，将该服务实例从第二服务实例列表中提出，并添加至第以服务实例列表中。

2.如权利要求1所述的方法，其特征在于，计算该服务实例的健康度，包括：

统计该服务实例在单位时间内请求的响应状态码的错误次数、请求的慢响应次数、和自定义错误码次数；

根据该服务实例在单位时间内请求的响应状态码的错误次数及对应权重、请求的慢响应次数及对应权重、和自定义错误码次数及对应权重，计算该服务实例的健康度。

3.如权利要求2所述的方法，其特征在于，在该服务实例上处理请求，包括：

若请求的响应时间超过慢响应时间阈值，确定处理请求失败，将该服务实例的请求的慢响应次数加一；否则，确定处理请求成功。

4.如权利要求1所述的方法，其特征在于，将该服务实例从第一服务实例列表中剔除，包括：

确定预设服务实例剔除条件；

若该服务实例剔除后，第一服务实例列表中服务实例的数量不符合预设服务实例保留条件，不对该服务实例进行剔除，否则，对该服务实例进行剔除。

5.如权利要求4所述的方法，其特征在于，所述预设服务实例剔除条件包括最少服务实例保留比例或最少服务实例保留数量。

6.一种客户端负载均衡实现装置，其特征在于，包括：

服务实例获取模块，用于在客户端侧获取第一服务实例列表和第二服务实例列表，所述第一服务实例列表用于存储后端的健康的服务实例，第二服务实例列表用于存储后端的故障的服务实例；

健康度计算模块，用于对第一服务实例列表中的每个服务实例，计算该服务实例的健康度，在该服务实例的健康度小于健康度阈值时，确定该服务实例为故障的服务实例，将该服务实例从第一服务实例列表中剔除，并添加至第二服务实例列表；

请求处理模块，用于对第一服务实例列表中的每个服务实例，在该服务实例接收到请求后，在该服务实例上处理请求，若处理请求失败，将所述请求转发至服务实例列表中的其他服务实例上；

服务实例恢复模块，用于对第二服务实例列表中的每个服务实例，获取该服务实例的恢复等待时间，若该服务实例的恢复等待时间超过预设恢复等待窗口，将该服务实例从第二服务实例列表中提出，并添加至第以服务实例列表中。

7.如权利要求6所述的装置，其特征在于，健康度计算模块具体用于：

统计该服务实例在单位时间内请求的响应状态码的错误次数、请求的慢响应次数、和自定义错误码次数；

根据该服务实例在单位时间内请求的响应状态码的错误次数及对应权重、请求的慢响应次数及对应权重、和自定义错误码次数及对应权重，计算该服务实例的健康度。

8.如权利要求7所述的装置，其特征在于，请求处理模块具体用于：

若请求的响应时间超过慢响应时间阈值，确定处理请求失败，将该服务实例的请求的慢响应次数加一；否则，确定处理请求成功。

9.如权利要求6所述的装置，其特征在于，健康度计算模块具体用于：

确定预设服务实例剔除条件；

若该服务实例剔除后，第一服务实例列表中服务实例的数量不符合预设服务实例保留条件，不对该服务实例进行剔除，否则，对该服务实例进行剔除。

10.如权利要求9所述的装置，其特征在于，所述预设服务实例剔除条件包括最少服务实例保留比例或最少服务实例保留数量。

11.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至5任一所述方法。

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

13.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现权利要求1至5任一所述方法。

Images