CN107094171A - 负载均衡方法及装置 - Google Patents

Abstract

本发明揭示了一种负载均衡方法及装置。所述方法包括：获取网络系统中服务提供方的服务状态变化信息；按照所述服务状态变化信息对参与负载均衡的服务提供方队列进行更新；根据所述服务提供方队列，为服务调用方均衡配置相应的服务提供方。由此，该负载均衡方法及装置能够根据服务提供方的服务状态变化信息自动运行和维护服务提供方队列，使服务提供方队列中的服务提供方能及时自动更新，从而有效提高了负载均衡的效率。

Description

负载均衡方法及装置

技术领域

本发明涉及互联网技术领域，特别涉及一种负载均衡方法及装置。

背景技术

网络系统包括前端和后端，在网络系统的架构设计中，通常后端会部署多个提供服务的服务提供方，然后根据服务调用方的情况通过LVS/Nginx等负载均衡器进行负载均衡，即为服务调用方均衡配置相应的服务提供方。

然而，由于网络系统中业务需求的变化，后端提供服务的服务提供方会根据这些变化作相应的增减。由于LVS/Nginx等负载均衡器进行负载均衡时是基于固定配置进行流量转发的，所以当服务提供方出现变化时，常用的LVS/Nginx等负载均衡器无法感知后端服务提供方的增减，必须在服务提供方出现变化的时候，通过手动修改负载均衡配置才能对变化后的服务提供方进行更新。因此无法实现负载均衡的自动化运行和维护，直接降低了负载均衡的效率。

例如，当有服务提供方A新上线时，在没有手动修改配置前，LVS/Nginx等负载均衡器并未感知到该上线情况，即负载均衡器并未感知到服务提供方A的增加，所以无法将服务调用方分配给该服务提供方A，从而出现该服务提供方A处于空闲状态的情况，造成服务提供方资源的浪费，极大地影响了负载均衡的效率。当服务提供方B离线时，LVS/Nginx等负载均衡器并未感知到该离线情况，仍可能将服务调用方分配给服务提供方B，从而使分配给服务提供方B的服务调用方得不到及时处理，直接影响了负载均衡的效率。

发明内容

为了解决相关技术中存在的无法实现负载均衡自动运行和维护，负载均衡的效率较低的问题，本发明提供了一种负载均衡方法及装置。

一种负载均衡方法，所述方法包括：

获取网络系统中服务提供方的服务状态变化信息；

按照所述服务状态变化信息对参与负载均衡的服务提供方队列进行更新；

根据所述服务提供方队列，为服务调用方均衡配置相应的服务提供方。

一种负载均衡装置，所述装置包括：

获取模块，用于获取网络系统中服务提供方的服务状态变化信息；

更新模块，用于按照所述服务状态变化信息对参与负载均衡的服务提供方队列进行更新；

配置模块，用于根据所述服务提供方队列，为服务调用方均衡配置相应的服务提供方。

本发明的实施例提供的技术方案可以包括以下有益效果：

获取网络系统中服务提供方的服务状态变化信息，按照该服务状态变化信息对参与负载均衡的服务提供方队列进行更新，根据该服务提供方队列，为服务调用方均衡配置相应的服务提供方，从而使得负载均衡的服务提供方出现变化时，自动更新服务提供方队列，因此会将服务调用方分配给最新的服务提供方队列，从而实现了负载均衡的自动运行和维护，提高了负载均衡的效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并于说明书一起用于解释本发明的原理。

图1是负载均衡的一个具体应用示意图；

图2是根据一示例性实施例示出的一种负载均衡方法的流程图；

图3是对应图2中实施例的获取网络系统中服务提供方的服务状态变化信息步骤的流程图；

图4是对应图2中实施例的按照所述服务状态变化信息对参与负载均衡的服务提供方队列进行更新步骤的一种具体实现流程图；

图5是对应图2中实施例的根据所述服务提供方队列，为服务调用方均衡配置相应的服务提供方步骤的一种具体实现流程图；

图6是根据一示例性实施例示出的一种负载均衡示意图；

图7是根据一示例性实施例示出的增加一个服务提供方的负载均衡示意图；

图8是根据一示例性实施例示出的一种负载均衡装置的框图；

图9是图8对应实施例示出的获取模块的细节进行描述的框图；

图10是图8对应实施例示出的更新模块的细节进行描述的框图；

图11是图8对应实施例示出的配置模块的细节进行描述的框图。

具体实施方式

这里将详细地对示例性实施例执行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

图1是负载均衡的一个具体应用示意图。该具体应用包括：至少一个服务提供方110、至少一个服务代理130、至少一个服务调用方150和至少一个服务提供方队列170。

服务提供方110与服务代理130之间的关联方式，包括有线或无线的网络关联方式，以及二者之间往来的数据关联方式，具体的关联方式不受本实施例的限制。

服务代理130与服务提供方队列170之间的关联方式，包括有线或无线的网络关联方式，以及二者之间往来的数据关联方式，具体的关联方式不受本实施例的限制。

服务调用方150与服务提供方队列170之间的关联方式，包括有线或无线的网络关联方式，以及二者之间往来的数据关联方式，具体的关联方式不受本实施例的限制。

并且在此具体应用中，服务代理130会获取到服务提供方110的服务状态变化信息，然后根据服务状态变化信息更新服务提供方队列170，这时候服务调用方150就能选用到自动更新后的服务提供方队列170里的服务提供方。进而实现了自动化更新服务提供方队列，提高了负载均衡的效率。

图2是根据一示例性实施例示出的一种负载均衡方法的流程图。如图2所示，该负载均衡方法可以包括以下步骤。

在步骤S210中，获取网络系统中服务提供方的服务状态变化信息。

其中，服务提供方是指能提供实际的服务处理能力或者任务处理能力的一方，服务提供方在网络系统中成功进行注册之后，才能进行服务处理。

网络系统中，服务提供方的状态发生变化后，会生成服务状态变化信息并发送给网络系统中的服务代理。该服务状态变化信息里包括服务提供方标识、消息类型、服务类型等。

服务代理获取到该服务状态变化信息后，根据该服务状态变化信息执行相应的操作。

在步骤S230中，按照服务状态变化信息对参与负载均衡的服务提供方队列进行更新。

其中，经过步骤S210获得服务状态变化信息后，服务代理将收到的服务状态变化信息进行处理，包括提取该服务状态变化信息的内容。

服务代理会请求监听网络系统中服务提供方的服务状态变化，在服务提供方发生变化的时候，服务代理会收到服务状态变化信息，通过该服务状态变化信息，对服务提供方队列进行处理。

本方案中，服务提供方是指能提供实际处理能力的服务节点，服务提供方标识是指对服务提供方进行识别的特定标记。可以是指服务提供方的网络地址，例如192.168.66.89。网络系统中的服务节点，都会预先设定相应的名称和网络地址，这样在网络系统中能被识别和通讯。服务提供方的消息类型可以是上线、在线或离线。

服务提供方队列是指包括一系列服务提供方标识等内容的组合，也可以称为服务提供方链。服务调用方发起服务调用请求后，服务提供方队列将该调用请求转发到服务提供方标识对应的服务提供方。

在收到服务状态变化信息后，通过及时对服务提供方队列进行相应的更新处理，以保证服务调用方的资源有效利用和服务调用方得到实时的处理，从而提高负载均衡的效率。

在步骤S250中，根据服务提供方队列，为服务调用方均衡配置相应的服务提供方。

其中，服务调用方是指能调用服务请求或者服务任务的一方，此处相应的服务提供方是指与该服务调用方相匹配的服务提供方。

根据步骤S230更新的服务提供方队列是根据最新的服务状态变化信息对服务提供方队列进行的更新或调整后的服务提供方队列。此处的均衡配置是指更新后的服务提供方队列中的服务提供方被服务调用方选择到的概率均等。

例如，网络系统中，目前有3个服务提供方，那么每个服务提供方接到服务调用方的概率是33.333％。如果这时候新注册了一个服务提供方，也就是网络系统中总共存在4个服务提供方，这时候每个服务提供方接到服务调用方的概率是25％。如果前面3个服务提供方中有一个出现了故障，也就是网络系统中总共存在2个服务提供方,这时候每个服务提供方接到服务调用方的概率是50％。

通过如上所述的方法，网络系统中服务提供方的状态信息发生变化时，能够根据收到的服务状态变化信息自动更新服务提供方队列，实现了负载均衡的自动运行和维护，大大提高了负载均衡的效率。

图3是对应图2中实施例示出的对步骤S210的细节的描述。该步骤S210可以包括以下步骤。

在步骤S211中，根据预置的时间间隔向注册中心发送监听状态变化的请求。

其中，预置的时间间隔是指时间间隔是预先设定的。网络系统中，由于数据瞬间变化，所以预先设置的时间间隔不能过大，否则就可能失去了监听的效果。例如预先设置时间间隔为1秒，即说明服务代理每隔1秒钟就向注册中心发送监听状态变化的请求。

在网络系统中，服务提供方会发送注册请求，该注册请求用于服务提供方的注册登记，在服务提供方进行成功注册登记后，会按照一定的时间间隔来发送心跳请求，网络系统根据是否能收到该心跳请求来判断服务提供方是否在线。

服务提供方成功进行注册登记后，网络系统会发送服务状态变化信息，在此情形下，该服务状态变化信息包括上线等信息。

服务提供方注册成功后，如果网络系统能正常收到心跳请求，即说明服务提供方依然存活或在线，该服务提供方的状态信息没有发生变化，能够正常处理服务调用方。

如果间隔一定时间或者间隔一定次数无法收到心跳请求，即说明服务提供方的状态信息已经发生变化，网络系统会发送服务状态变化信息，在此情形下，该服务状态变化信息包括离线等信息，无法继续处理服务调用方。

注册中心是存在于网络系统中的一个节点，注册中心能接收服务提供方的注册请求，并根据收到的服务请求对服务提供方进行注册。

在步骤S213中，接收注册中心响应请求发送的服务状态变化信息。

注册中心在收到服务代理监听状态变化的请求时，如果监听到服务提供方的状态发生了变化，会针对该请求进行响应，向服务代理发送相应的服务状态变化信息。

例如，服务提供方注册成功后，注册中心会将该注册成功的状态信息发给所有在监听服务状态变化信息的服务代理。成功注册的服务提供方，会定时向注册中心发送心跳请求，注册中心会根据是否正常收到心跳请求来判断该服务提供方的状态信息。如果状态信息发生变化，注册中心还会将发生变化的该状态信息发给所有在监听服务状态变化信息的服务代理。

通过如上所述的方法，通过预置的时间间隔监听服务提供方的状态变化，状态发生变化时能够服务代理能及时收到服务提供方的服务状态变化信息，为实现负载均衡的自动运行和维护，提高了负载均衡的效率提供了方便。

图4是对应图2中实施例的按照所述服务状态变化信息对参与负载均衡的服务提供方队列进行更新步骤的一种具体实现流程图。该S230步骤可以包括以下步骤。

在步骤S231中，从服务状态变化信息获取消息类型。

通过步骤S210获取了服务状态变化信息，本步骤S231中，从该服务状态变化信息提取消息类型，根据获取的消息类型进行后续的操作。其中消息类型一般会有上线、在线、离线等。

例如，现在收到的服务状态变化信息中包括有：消息类型，服务类型，服务提供方标识等。服务代理根据会从该服务状态变化信息中提取该消息类型。正常情况下，当服务提供方的状态信息发生变化时，就会生成一条服务状态变化信息。因为服务状态变化信息包括该服务提供方消息类型等，因此根据收到的这个服务状态变化信息，就能获取到与服务状态变化信息中的消息类型对应的服务提供方。即使在特殊情况下，比如在极短的时候内，多个服务提供方的状态信息发生了变化，就会为每个服务提供方生成一条服务状态变化信息，因此根据收到的这个服务状态变化信息，也能获取到消息类型与该消息类型对应的服务提供方。

在本方案中的消息类型代表的是服务提供方的状态，比如上线代表服务提供方注册成功；在线代表服务提供方注册成功后，网络系统能正常接收到该服务提供方的反馈信息，比如心跳请求等；离线代表服务提供方无法提供服务，比如服务提供方出现故障或者掉线等，这时候网络系统无法正常收到服务提供方的反馈信息，比如无法收到心跳请求。

在步骤S233中，按照所述消息类型对参与负载均衡的服务提供方队列进行更新。

服务代理从服务状态变化信息获取到消息类型后，依据该消息类型对参与负载均衡的服务提供方队列进行更新。

其中，本方案中主要涉及到的消息类型是上线和离线。如果服务代理收到的消息类型是上线，则在服务提供方队列中增加消息类型对应的服务提供方标识，如果服务代理收到的消息类型是离线，则在服务提供方队列中删除消息类型对应的服务提供方标识。

此处对应的服务提供方标识是指该消息类型所指向的服务提供方标识。上线的消息类型是指有新的服务提供方注册成功，对于该注册成功的服务提供方，还需要在服务提供方队列中进行相应的操作才能够正常提供相应的任务处理能力，只有将该注册成功的服务提供方对应的服务提供方标识增加到服务提供方队列之后，才能被服务调用方使用到该注册的服务提供方。

例如，网络系统中，目前包括一个服务提供方A，一个服务提供方队列B，一个服务代理C和一个服务调用方D。这也就是说服务提供方队列B中只有一个服务提供方标识即与服务提供方A对应的服务提供方标识，这样服务调用方D被服务提供方A选择到的概率就是100％。如果这个时候服务代理C发现有一个服务提供方E注册成功，服务代理C会将与该注册成功的服务提供方E对应的服务提供方标识增加到服务提供方队列B中，此时服务提供方队列B中存在两个服务提供方标识(与服务提供方A对应的服务提供方标识和与服务提供方E对应的服务提供方标识)，在此情形下，服务调用方D被服务提供方A或者被服务提供方E选择到的概率均为50％。

同理，如果网络系统中，目前包括一个服务提供方A和一个服务提供方B，一个服务提供方队列C，一个服务代理D和一个服务调用方E，且与服务提供方A对应的服务提供方标识和与服务提供方B对应的服务提供方标识均在服务提供方队列C中。这也就是说服务提供方队列C中有两个服务提供方即与服务提供方A对应的服务提供方标识和与服务提供方B对应的服务提供方标识，这样服务调用方E被服务提供方A或服务提供方B选择到的概率各是50％。如果这个时候服务代理D发现有一个服务提供方A的服务状态信息变成了离线，这说明服务提供方A无法被服务调用方选择到，因此不能提供相应的处理能力。所以需要服务代理根据这个离线的服务状态变化信息，在服务提供方队列中对与服务提供方A对应的服务提供方标识进行相应的操作，即将与服务提供方A对应的服务提供方标识删除掉。这样服务提供方队列中仅剩下一个与服务提供方B对应的服务提供方标识，因此服务调用方E被服务提供方B选择到的概率就是100％。

进一步的，服务代理收到上线的消息类型时，在服务提供方队列中，增加服务提供方标识与服务提供方虚拟名称的对应关系条目。其中，服务提供方虚拟名称是服务代理随机生成的名称，具有唯一性，即在服务提供方队列里增加一条该服务提供方虚拟名称与服务提供方标识具有对应关系的记录，该记录将该服务提供方虚拟名称指向服务提供方标识对应的服务提供方。当然，服务代理收到下线的消息类型时，会在服务提供方队列中删除与服务提供方标识的记录，这样即删除了下线的服务提供方标识对应的记录，因此不会再被分配给服务调用方。

例如，服务代理收到服务提供方注册信息后，生成了一个服务提供方虚拟名称为“SVC-PRODUCER-ZO2I67MHAQ44UUM7”，其对应的服务提供方标识为172.100.79.3。服务提供方标识与服务提供方虚拟名称的对应关系条目为SVC-PRODUCER-ZO2I67MHAQ44UUM7-ptcp-m comment--comment"service producer rule"-m tcp-j DNAT--to-destination172.100.79.3:80，通过该规则即建立了相应的对应关系，即DNAT转发关系。负载均衡分配的时候，根据这个对应关系，通过服务调用方的服务类型，找到服务提供方队列中的该服务类型里的服务提供方标识的对应关系条目，最终通过对应关系条目将服务调用请求分配给实际的服务提供方。

进一步的，服务状态变化信息里还包括服务类型等内容，服务提供方的服务类型可以是数据库类型、Redis类型或者网页类型等。可以理解的是，为了将服务提供方做更精细化的区分，也就是将不同服务类型的服务提供方进行分组。需要获取与消息类型对应的服务提供方的服务类型，然后根据该服务类型对服务提供方进行归类或分组。

其中，服务类型是为了服务队列能更有效的提供服务，而将服务队列中的服务提供方进行的归类或分组。在服务提供方较多的情况下，将服务提供方队列中的服务提供方进行分组更能达到有效管理和高效分配的效果。也就是服务代理根据服务类型将服务提供方队列里的服务提供方的定位更加精细化。

其中，在没有区分服务类型的情况下，该服务提供方队列中的所有服务提供方被服务调用方选择到的概率均等。即在此情况下，该服务提供方队列中任意一个服务提供方被服务调用方选择到的几率是均等的。如果增加了服务类型，服务代理会根据服务类型，将服务提供方队列中的服务提供方进行相应的分组或排序，同一个服务类型的服务提供方会被更新在一起。这个服务类型的服务调用方最终会被分配给服务提供方队列中的与该服务类型相同的服务提供方。

例如，网络系统中，目前存在A、B、C、D共4个服务提供方，一个服务提供方队列E，这个服务提供方队列E中包括两种服务类型(即分为2组)，如数据库类型、Redis类型。数据库类型中有与A、B两个服务提供方对应的服务提供方标识，Redis类型中有与C、D两个服务提供方对应的服务提供方标识。如果这个时候新增一个服务提供方F的服务类型正好是这两个服务类型中的一个，比如数据库类型，那么服务代理会将与这个新增的服务提供方F对应的服务提供方标识增加到服务提供方队列E中服务类型为数据类型这个分组里面。此时在数据类型这个分组里会有与A、B、F三个服务提供方对应的服务提供方标识。

因为网络系统根据业务需求的变化进行调整的情形特别多，为了能更灵活的处理新增的服务类型。服务代理根据收到的新注册增加的服务提供方的服务状态变化信息，可以获取到服务类型，然后将该服务类型与服务提供方队列中的服务类型进行比较，如果没有相同的服务类型，则说明这是一个新的服务类型，这时候服务代理会先在服务提供方队里中增加这个消息类型的相关内容。

例如，前面的例子中提到，服务提供方队列E中包括两种服务类型即数据库类型和Redis类型。如果此时从收到的服务状态变化信息中获取的消息类型是网页类型，如前所述，因为服务提供方队列E中只有数据库类型和Redis类型，没有网页类型，所以需要将这各网页类型加入到服务提供方队列E中，这时候服务提供方队列E中的服务类型共有三种，即数据库类型、Redis类型和网页类型。

通过如上所述的方法，根据服务状态变化信息获取消息类型，进而根据消息类型对服务提供方队列进行更新或调整。而且服务代理根据服务类型，能将服务提供方队列进行细分，为服务调用方被更精准的服务提供方选择到提供了便利。在新增服务提供方的情况下能及时将新增的服务提供方加入到服务提供方队列中，在服务提供方离线的情况下，能及时将服务提供方队列中的该服务提供方删除。实现了负载均衡的自动化运行和维护，有效提高了效率。

图5是对应图2中实施例的根据所述服务提供方队列，为服务调用方均衡配置相应的服务提供方步骤的一种具体实现流程图。该步骤S250可以包括以下步骤。

在步骤S251中，获取服务调用方的服务类型。

服务调用方预先设置有服务类型，如数据库类型、Redis类型等。

其中，收到服务调用方之后，会先获取服务调用方的服务类型。

在步骤S253中，在服务提供方队列中查找服务类型对应的服务提供方标识。

依据步骤S251，获取到服务类型，在服务提供方队列中查找该服务类型，找到服务类型后，即可查到该服务类型里的服务提供方标识。此处对应的服务提供方标识是指与服务调用方的服务类型相匹配的服务提供方标识。

在步骤S255中，为服务调用方均衡配置与服务提供方标识对应的服务提供方。

根据前述步骤获取的服务调用方的服务类型，以及查找到的服务提供方标识，依据服务类型将匹配该类型的所有服务提供方标识进行均衡配置，即服务提供方队列中匹配该服务类型的服务提供方标识对应的所有服务提供方接到该服务调用方的几率是均等的。如果网络系统中本身并没有做服务类型的区分或者不需要服务类型，则服务提供方队列中所有的服务提供方标识对应的服务提供方接到该服务调用方的几率是均等的。

通过如上所述的方法，根据服务调用方的服务类型来查找匹配的服务提供方，对该匹配的服务提供方标识进行均衡处理。实现了负载均衡的自动化运行和维护，提高了效率。

图6是根据一示例性实施例示出的一种负载均衡示意图。下面对负载均衡进行一个示例性描述。

具体的，如图7所示，服务提供方410和服务提供方412会向注册中心411发送注册 请求，注册中心411会根据注册请求，对服务提供方410和服务提供方412进行注册，注册成 功后，注册中心411会向服务代理413发送针对该服务提供方410和服务提供方412的服务状 态变化信息。服务代理413收到该服务状态变化信息后，从该服务状态变化信息获取到的消 息类型为上线，服务代理413将该服务提供方410的服务提供方标识和服务提供方412的服 务提供方标识更新到iptables(即服务提供方队列)，更新后的iptables会响应服务调用方 414的请求，并根据服务调用方的情况选择iptables中的服务提供方，在图7中，服务调用方 414被分配给服务提供方410或服务提供方412的几率是均等的，即各50％。成功注册的服务 提供方410和服务提供方412会定时向注册中心发送心跳请求，通过该心跳请求告知注册中 心411服务提供方410和服务提供方412自身的状态情况，如是否在线(存活)。例如，注册中 心411在间隔一定的时间或者间隔一定的次数无法收到服务提供方410的心跳请求，就会向 服务代理413发送针对该服务提供方410的服务状态变化信息。服务代理413收到该服务状 态变化信息后，从该服务状态变化信息获取到的消息类型为离线，服务代理413将该服务提 供方410的服务提供方标识从iptables(即服务提供方队列)中删除，更新后的iptables会 响应服务调用方414的请求，并根据服务调用方的情况选择iptables中的服务提供方标识 对应的服务提供方，在图7中，服务调用方414最终会被分配给服务提供方412。

图7是根据一示例性实施例示出的增加一个服务提供方的负载均衡示意图。

具体的，如图7所示，例如，当前环境下服务提供方队列511里的服务类型A只有1个服务提供方1，该服务提供方1部署在节点B上，如果这时候在节点C上在部署了一个服务提供方2，服务代理会将服务提供方2根据其服务类型加入到服务提供方队列中，即加入到服务提供方队列的服务类型A中，如框图中512所示，在服务提供方1的服务提供方标识前面增加服务提供方2的服务提供方标识，即将服务提供方2的服务提供方标识排在服务提供方1的服务提供方标识的前面。此时服务提供方队列中服务类型A里共有两个服务提供方标识即服务提供方1的服务提供方标识和服务提供方2的服务提供方标识，服务提供方2的服务提供方标识排在首位，所以最终会将50％的概率分配服务提供方2，剩下的概率直接分配给剩余的服务提供方，在此处即将剩下的50％分配各服务提供方1。然后服务代理在服务提供方队列中配置服务提供方2的DNAT转发规则2和和服务提供方1的DNAT转发规则1，根据这些规则，转发规则1对应到节点C中的服务提供方1，转发规则2对应到节点B中的服务提供方2。在此情形下，节点A上服务类型A的服务调用方发送的请求，执行路径如下，服务调用方根据服务类型A找到服务队列中的服务提供方1的服务提供方标识和服务提供方2的服务提供方标识，因为服务提供方1和服务提供方2的概率各为50％，所以机会均等，假设这时候服务调用方的请求被分配给服务提供方队列中的服务提供方2，那么执行对应服务提供方2的转发规则，根据转发规则，通过服务提供方队列中的服务提供方2的服务提供方标识最终对应到节点B上的服务提供方2，即由节点B上的服务提供方2实际处理服务调用方的请求。

图8是根据一示例性实施例示出的一种负载均衡装置的框图。该负载均衡装置600，如图8所示，可以包括但不限于：获取模块610，更新模块630和配置模块650。

获取模块610，用于获取网络系统中服务提供方的服务状态变化信息。

更新模块630，用于按照服务状态变化信息对参与负载均衡的服务提供方队列进行更新。

配置模块650，用于根据服务提供方队列，为服务调用方均衡配置相应的服务提供方。

上述负载均衡装置中各个模块的功能和作用的实现过程具体详见上述负载均衡方法中对应步骤的实现过程，在此不再赘述。

图9是图8对应实施例示出的获取模块的细节进行描述的框图。该获取模块610，如图9所示，可以包括但不限于：监听单元611，接收单元613。

监听单元611，用于根据预置的时间间隔向注册中心发送监听状态变化的请求。

接收单元613，用于接收注册中心响应请求发送的服务状态变化信息。

图10是图8对应实施例示出的更新模块的细节进行描述的框图。该更新模块630，如图10所示，可以包括但不限于：消息类型单元631，队列调整单元633。

消息类型单元631，用于从服务状态变化信息获取消息类型。

队列调整单元633，按照所述消息类型对参与负载均衡的服务提供方队列进行更新。

图11是图8对应实施例示出的配置模块的细节进行描述的框图。该配置模块650，如图11所示，可以包括但不限于：服务类型单元651，查找单元653和均衡配置单元655。

服务类型单元651，用于获取服务调用方的服务类型。

查找单元653，用于在服务提供方队列中查找服务类型对应的服务提供方标识。

均衡配置单元655，用于为服务调用方均衡配置与所述服务提供方标识对应的服务提供方。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围执行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (8)

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

获取网络系统中服务提供方的服务状态变化信息；

按照所述服务状态变化信息对参与负载均衡的服务提供方队列进行更新；

根据所述服务提供方队列，为服务调用方均衡配置相应的服务提供方。

2.根据权利要求1所述的方法，其特征在于，所述获取网络系统中服务提供方的服务状态变化信息，包括：

根据预置的时间间隔向注册中心发送监听状态变化的请求；

接收所述注册中心响应所述请求发送的服务状态变化信息。

3.根据权利要求1所述的方法，其特征在于，所述按照所述服务状态变化信息对参与负载均衡的服务提供方队列进行更新，包括：

从所述服务状态变化信息获取消息类型；

按照所述消息类型对参与负载均衡的服务提供方队列进行更新。

4.根据权利要求1所述的方法，其特征在于，所述服务提供方具有对应的服务类型，所述根据所述服务提供方队列，为服务调用方均衡配置相应的服务提供方，包括：

获取服务调用方的服务类型；

在服务提供方队列中查找所述服务类型对应的服务提供方标识；

为服务调用方均衡配置与所述服务提供方标识对应的服务提供方。

5.一种负载均衡装置，其特征在于，所述装置包括：

获取模块，用于获取网络系统中服务提供方的服务状态变化信息；

更新模块，用于按照所述服务状态变化信息对参与负载均衡的服务提供方队列进行更新；

配置模块，用于根据所述服务提供方队列，为服务调用方均衡配置相应的服务提供方。

6.根据权利要求6所述的装置，其特征在于，所述获取模块包括：

监听单元，用于根据预置的时间间隔向注册中心发送监听状态变化的请求；

接收单元，用于接收所述注册中心响应所述请求发送的服务状态变化信息。

7.根据权利要求6所述的装置，其特征在于，所述更新模块包括：

消息类型单元，用于从所述服务状态变化信息获取消息类型；

队列调整单元，按照所述消息类型对参与负载均衡的服务提供方队列进行更新。

8.根据权利要求6所述的装置，其特征在于，所述服务提供方具有对应的服务类型，所述配置模块包括：

服务类型单元，用于获取服务调用方的服务类型；

查找单元，用于在服务提供方队列中查找所述服务类型对应的服务提供方标识；

均衡配置单元，用于为服务调用方均衡配置与所述服务提供方标识对应的服务提供方。