一种负载调度方法及装置与流程

本申请涉及信息技术领域，特别是涉及一种负载调度方法及装置。

背景技术：

随着信息技术的不断发展，在信息传输过程中，为了更好的满足用户各种服务请求，负载调度是不可或缺的。

其中，负载均衡中场使用健康监听方式，监听服务器的服务健康状态来实现更好的调度需求，目前，在监听服务器时会使用定时发送监听消息至服务器的方法，而发送监听消息的次数是预置的，当在预设次数的监听消息都没有发送成功，则将该服务器的预置权重值重置为0，以避免再将新的服务请求发送到该服务器。如此虽然可以避免对故障服务器发送服务请求，但是在健康监听检查的时间段内，即没有进行完成预设次数的健康监听的时间段内，故障服务器的权重值仍没有设置为0，因为依然会被调度到，造成用户发送的服务请求得不到响应，降低了用户体验。

技术实现要素：

鉴于上述问题，本申请提供负载调度方法、装置和系统，可以通过向后台服务器进行健康探测的结果，动态调整对应所述后台服务器的负载均衡权重，并按照权重设置分配用户访问请求，解决现有技术中无法准确得知服务器状态，而将新的服务请求发送到故障服务器而得不到响应的问题。

为了解决上述问题，本申请实施例公开了一种负载调度方法，包括：

在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重；在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一后台服务器；其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。

本申请实施例还提供了一种负载调度方法，其特征在于，包括：对后台服务器进行健康探测操作；根据健康探测操作的结果，调整所述后台服务器的负载均衡权重；根据所述负载均衡权重，调整相应后台服务器被分发访问请求的概率；其中，所述负载均衡权重与所述概率正相关。

本申请实施例公开了一种负载调度装置，包括：

权重调整模块，用于在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重；负载调度模块，用于在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一后台服务器；其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。

相应的，本申请实施例还提供了一种负载调度装置，其特征在于，包括：健康探测模块，用于对后台服务器进行健康探测操作；负载均衡权重调整模块，用于根据健康探测操作的结果，调整所述后台服务器的负载均衡权重；请求概率调度模块，用于根据所述负载均衡权重，调整相应后台服务器被分发访问请求的概率；其中，所述负载均衡权重与所述概率正相关。

本申请实施例公开了一种负载调度系统，其特征在于，包括：至少一台虚拟服务器，和多台后台服务器；每台虚拟服务器分别与所述多台后台服务器连接；所述虚拟服务器包括：权重调整模块，用于在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重；负载调度模块，用于在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一后台服务器；其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。

相应的，申请实施例还公开了一种负载调度系统，其特征在于，包括：至少一台虚拟服务器，和多台后台服务器；每台虚拟服务器分别与所述多台后台服务器连接；所述虚拟服务器包括：健康探测模块，用于对后台服务器进行健康探测操作；负载均衡权重调整模块，用于根据健康探测操作的结果，调整所述后台服务器的负载均衡权重；请求概率调度模块，用于根据所述负载均衡权重，调整相应后台服务器被分发访问请求的概率；其中，所述负载均衡权重与所述概率正相关。

申请实施例还公开了一种装置，其特征在于，包括：一个或多个处理器；和其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行如前述的一种负载调度方法。

申请实施例还公开了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行如前述的一种负载调度方法。

本申请实施例包括以下优点：

本申请实施例通过在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重；在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一后台服务器；其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。实现了动态设置服务器权重，并按照该权重调度服务器的功能，从而解决了现有技术中无法准确得知服务器状态，而将服务请求发送到故障服务器而得不到响应的问题。

附图说明

图1是本申请的一种负载调度方法实施例的步骤流程图；

图1a是本申请实施例中的负载均衡集群架构示意图；

图2是本申请的一种负载调度方法可选实施例的步骤流程图；

图2a是本申请的一种健康探测消息发送示意图；

图3是本申请的另一种负载调度方法可选实施例的步骤流程图；

图4是本申请的一种负载调度装置实施例的结构框图；

图5为本申请的一种负载调度装置实施例的结构框图；

图6是本申请的另一种负载调度装置实施例的结构框图；

图7是本申请的一种负载调度系统实施例的结构框；

图8是本申请的另一种负载调度系统实施例的结构框；

图9是本申请实施例提供的一种服务器结构示意图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

lvs(linuxvirtualserver，linux虚拟服务器)，是一个虚拟的服务器集群系统，用于负载均衡，可根据当前实例的负载调度当前的访问到后端的服务器。

实例为对应负载均衡的一个vip(virtualip，虚拟地址)，用户可以创建一个负载均衡的实例，一个负载均衡的实例可以创建多个负载均衡的监听。用户所连接的目标地址实际上是一个vip，而负载平衡服务器在接到该请求的时候将会将其目标地址转化为服务实例所在的rip(realip实际地址)，并将源地址更改为loadbalancer(负载均衡服务器)所在的地址。这样在对请求处理完毕后，服务实例将会把响应发送到负载平衡服务器。此时负载平衡服务器再将响应的地址更改为vip，并将该响应返回给用户。

监听：一个实例下的监听为负载均衡的vip与端口的组合，不同的端口可对应不同的服务。

rs(realserver，后端真实服务器)，一个监听后面通常会对应多个后端的rs来实现服务器的高可用性。

健康检查：lvs负载均衡设备会定期的对后端对rs进行访问探测，用户可以设置健康检查不可用的探测次数，如果访问探测失败次数达到用户设置的不健康检测阈值，就认为后端的rs此时不可用，会将该rs的负载均衡权重置为0以隔离该rs，当健康检查探测成功后又会重新设置rs的负载均衡权重。在本申请实施例中，每次健康检查过程都是独立的，对于每次健康检查都会设置一个连续探测失败次数的不健康阈值。比如不健康阈值为n次，那么连续探测n次都失败，则该rs不可用，而在任意第l次探测成功，则表示该rs可用。

为了能够保证从负载平衡服务器所派发的数据包能被它后面的服务器集群正常处理，负载平衡服务器需要周期性地发送状态查询请求以探测到底哪些服务实例正在有效地工作。这种状态查询请求常常会超出很多人的认知：如果服务实例崩溃但是承载它的操作系统正常工作，那么该操作系统仍然会正常响应负载平衡服务器所发出的ping(packetinternetgroper，网络探测包)命令，只是此时tcp(transmissioncontrolprotocol，传输控制协议)连接会失败；如果服务实例并没有崩溃，而只是挂起，那么它仍然可以接受tcp连接，只是无法接收http(hypertexttransferprotocol，超文本传输协议)请求。由于这种状态查询请求实际上是特定于服务实例的具体实现。一旦负载平衡服务器发现其所管理的某个服务实例不再有效，那么它就不会再将任何新建的数据转发给该服务实例，直到该服务实例回归正常状态。在这种情况下，其它各个服务实例就需要分担失效服务器所原本承担的工作。

本申请实施例通过在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重，通过上述动态调整服务器权重后，在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一权重较高的后台服务器。解决了现有技术中无法准确得知服务器状态，而将服务请求发送到故障服务器而得不到响应的问题，提高了服务器的可用性。

参照图1示出了本申请的一种负载调度方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重；

本申请实施例中，负载均衡服务(baiduloadbalance)可以将来自互联网或内网的流量分发至多台后端服务器，实现业务系统的水平扩展提升服务能力，并通过健康检查剔除不可用的主机提升业务系统可用性。l3/4负载平衡服务器的工作原理非常简单：在数据到达时，负载平衡服务器将根据自身算法以及osi模型三四层所包含的数据决定需要处理该数据的服务实例并将其转发。这里的l3/4实际上指的就是负载平衡服务器会根据osi模型中的第三层网络层(networklayer)和第四层传输层(transportlayer)所包含的数据来进行负载平衡操作。在这种负载平衡服务器中，这些数据主要包含数据包的ip头和tcp、udp等协议的协议头。其中，负载均衡的关键步骤就是探知服务器当前的健康状态，所以由负载均衡服务器向一后台服务器发送健康探测消息后，若健康探测消息发送成功，则服务器工作正常，若发送不成功，则说明该服务器故障。

实际应用中，用户开启健康检查功能后，当后端某台rs健康检查出现异常时，lvs会自动将新的请求分发到其它健康检查正常的rs上；而当该rs恢复正常运行时，lvs会将其自动恢复到对外或对内的服务中。每个rs有一个用户配置的权重weigth值来表示其是否可用以及被选中的优先级，当weight为0时代表当前rs不可用，当为weight时表示后端rs可用，当连续n次对后端某个rs健康检查失败后，每次健康监测失败后会将预设权重值减少一定的数值，知道第n次都监测失败后，lvs会把rs的负载均衡权重设置为0，这时该rs不对外提供服务，新建的访问连接会自动调度到其他后端rs上，如图1a所示的，负载均衡集群架构图，其中，负载均衡机器集群一般由多台机器组成，用户申请的服务vip会在多台lvs(虚拟服务器)集群上进行等价路由宣告，这样用户访问vip服务时会被引到某台lvs机器，在lvs机器上有该实例监听下所有rs的对应列表，lvs会根据调度算法将该次用户访问的连接调度到某个rs上。

在本申请实施例中，服务器可以定期启动健康检查流程，每次健康检查流程是独立的，对于一个rs而言，除了依赖前一次健康检查流程得到的rs的负载均衡权重，探测次数都是从0开始计数。比如不健康阈值设置为n次，那么前述健康探测操作连续失败的次数达到n次，则后端rs不可用。如果在不超过不健康阈值的情况下，有一次健康探测操作成功，则表明该rs可用，则将该rs的负载均衡权重还原为初始的weigth值。

步骤102，在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一后台服务器；其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。

本申请实施例中，根据步骤101的描述，当通过健康监测的失败次数的逐步降低服务器的预设权重值后，在负载均衡服务器接收到用户发送的服务请求时，在将服务请求调度到服务器时首先选择权重值较高的服务器，而规避权重值为0的服务器，并且权重值越高，被调度的几率就越大，反之越小，其中根据权重值进行调度服务器的调度规则是根据用户需求预先设置的，本发明实施例对此不加限制。

在本申请实施例中，在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重，通过上述动态调整服务器权重后，在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一权重较高的后台服务器，其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。解决了现有技术中无法准确得知服务器状态，而将服务请求发送到故障服务器而得不到响应的问题，提高了服务器的可用性。

参照图2，示出了本申请的一种负载调度方法可选实施例的步骤流程图，具体可以包括如下步骤：

步骤201，在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则在上次健康探测操作后对应所述后台服务器的负载均衡权重的基础上，根据健康探测操作连续失败总次数和设定变量值，降低所述负载均衡权重。

本申请实施例中，在向服务器发送健康监测消息，若所述消息发送失败则确定健康监测操作失败，根据预设的调度规则，计算该服务器的权重值的设置，通常情况下，预设的调度规则中包含权重降低的计算方法，并且该计算方法主要是根据健康探测操作连续失败总次数和设定变量值，以及服务器的现有权重相关。

可选的，在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则以上次健康探测操作后对应所述后台服务器的负载均衡权重，减去所述健康探测操作失败总次数与设定变量值之积的结果，作为所述后台服务器新的负载均衡权重。

在实际应用中，若所述健康探测消息为第n次发送至所述后台服务器，且发送失败，则记录n的数值。另外，计算变量值d＝w/n，其中w为所述服务器的预设的初始权重值，当上次健康探测后，rs可用，则其出售的负载均衡权重值为w，其中0＜n≤n，所述n为预设探测不健康阈值，然后根据计算得到的d值重新标记所述后台服务器的权重wn，重新标记的后台服务器的权重值wn＝w-nd。例如，当预设的服务器初始权重值为100，预设的不健康阈值为10次，那么第一次探测失败后，根据上述公式计算，新的权重值为90，第二次失败权重值则设置为80，以此类推，当连续第10次探测失败，那么该服务器的权重值则设置为0。

优选的，本申请实施例中，所述设定变量值通过所述后台服务器的初始负载均衡权重与连续健康探测操作失败次数的失败阈值的正相关关系获得。

本申请实施例中，后台服务器的初始负载均衡权重越大，则设定变量值越大，且连续健康探测操作失败次数越大，则设定变量值越小。

所述设定变量值为对应所述后台服务器的初始负载均衡权重与连续健康探测操作失败次数的失败阈值的比值。

本申请实施例中，设定的变量值，即为d＝w/n，计算该值是通过该服务器预设的初始权重值与预设的不健康阈值的比值，并与健康探测操作连续失败次数的乘积所得，例如，当预设初始权重值为100，预设的不健康阈值为10次，d＝100/10＝10，当第八次探测失败后，再利用初始权重值减去8d得到当前新的权重值则为20。若所述访问探测消息发送成功，则重置所述后台服务器权重值wn为初始权重值w＝100。例如，在经过第八次健康探测失败后，第九次探测成功，则将该服务器的权重值恢复为初始权重值，即100。

优选的，由虚拟服务器中的探测实例的监听线程进行所述健康探测操作。

本申请实施例中，为了能够保证从负载平衡服务器所派发的数据包能被它后面的服务器集群正常处理，负载平衡服务器需要周期性地发送健康探测请求到后台服务器，其中，虚拟服务器发在发送探测请求时，其监听线程会监听各后台服务器的权重，当在健康探测请求发送不成功时，就将监听到的服务器权重进行修改，当然，负载均衡系统中，往往存在多个虚拟服务器，每个服务器对应多个探测实例，当一个虚拟服务器工作状态不正常时，其负责的探测实例工作将会由其他虚拟服务器负责，如图1a所描述的，一个虚拟服务器的探测实例又针对多个后台服务器，其监听线程发送的探测请求也是针对多个后台服务器同时发送的。

优选的，本申请实施例中，当所述探测实例为tcp类型实例时，所述向一后台服务器进行一次健康探测操作包括：

步骤s201，向一后台服务器发送tcp连接报文；当接收到针对所述tcp连接报文的响应不为sync+ack报文时，表示所述健康探测操作失败。

本申请实施例中，在基于传输层(tcp/udp)的应用开发中，为了最后的程序优化，应避免端到端的任何一个节点上出现ip分片。tcp的mss协商机制加上序列号确认机制，基本上能够保证数据的可靠传输。在负载平衡服务器中，负载平衡探测消息中主要包含数据包的ip头和tcp、udp(userdatagramprotocol)，用户数据报协议)等协议的协议头，当探测消息将包含tcp连接报文发送到对象服务器，在预设时间内没有接收到sync+ack响应报文，或者完全没有接收到响应时，则确认该健康探测操作失败，如图2a描述的，lvs会定期向后端rs发syn包尝试建立tcp连接，如果后端rs回复sync+ack说明后端服务正常，如果后端没有回复sync+ack表示该次健康检查探测失败，这就叫做三次握手。如果打算让双方都做好准备的话，一定要发送三次报文，而且只需要三次报文就可以了。

优选的，本申请实施例中，当所述探测实例为udp类型实例时，所述向一后台服务器进行一次健康探测操作包括：

步骤s202，向一后台服务器发送udp探测报文；当接收到针对所述udp探测报文的响应不为icmp(internetcontrolmessageprotocol，因特网控制消息协议))不可达报文时，表示所述健康探测操作失败。

本申请实施例中，udp协议在ip协议的基础上，只增加了传输层的端口(sourceport+destinationport)、udp数据包长(length＝header+data)以及检验和(checksum)。因此，基于udp开发应用程序时，数据包需要结合ip分片情况考虑。对于以太局域网，往往取udp数据包长length<＝mtu-sizeof(ipheader)＝1480，故udp数据负载量小于或等于1472(length-udpheader)。tcp三次握手建立连接，客户端首先向服务器申请打开某一个端口(用syn段等于1的tcp报文)，然后服务器端发回一个ack报文通知客户端请求报文收到，客户端收到确认报文以后再次发出确认报文确认刚才服务器端发出的确认报文，至此，连接的建立完成。

在实际应用时，发送udp报文时，首先处理udp套接字，通过调用函数udp_new()进行申请，然后调用udp_bind()绑定在udp端口上，在这个调用过程中，我们必须编写一个用于处理这个udp套接字接收到的数据报文的函数，并把这个函数作为udp_bind()的参数，以后当套接字接收到数据报文时会自动调用这个函数，我们将在后面介绍这个函数怎么调用的。绑定结束之后，必须调用udp_connect()将数据报文的目的地址绑定在udp的数据结构中，最后就是调用udp_send()把数据报文发送出去，在负载均衡服务器通过udp发送健康探测消息时，lvs会发送udp探测报文，当后端rs回icmp端口不可达时认为探测成功否则探测失败。

优选的，本申请实施例中，当所述探测实例为http类型实例时，所述向一后台服务器进行一次健康探测操作包括：

步骤s203，向一后台服务器发送httphead请求；当接收到针对所述httphead请求的http状态码不为200时，表示所述健康探测操作失败。

本申请实施例中，http定义了与服务器交互的不同方法，主要有8种可能的请求方法：get检索uri(uniformresourceidentifier，通用资源标志符)中标识资源的一个简单请求；head与get方法相同，服务器只返回状态行和头标，并不返回请求文档；post服务器接受被写入客户端输出流中的数据的请求；put服务器保存请求数据作为指定uri新内容的请求；delete服务器删除uri中命名的资源的请求；options关于服务器支持的请求方法信息的请求；traceweb服务器反馈http请求和其头标的请求；connect已文档化但当前未实现的一个方法，预留做隧道处理。在本实施例中，lvs会发送httphead请求，而当服务器响应时，其状态行的信息为http的版本号，状态码，及解释状态码的简单说明。现将5类状态码详细列出：客户方错误为100；成功为200，重定向为300，客户方错误400，服务器错误500，所以如果后端rs回复的http状态码为200，则认为健康检查探测成功。用户可以设置健康检查的不健康阀值，当对后端rs健康检查探测失败次数达到不健康阀值的时候，lvs会认为该rs不可用，会将该rs的weight设置为0，直到该rs的将康检查成功之前该rs将不再会被调度到。

步骤202，确定所述访问请求对应的服务；

本申请实施例中，在负载均衡时，当收到用到的服务请求时，首先要确定服务请求对应的服务，此时负载平衡服务器以及各个服务实例必须在同一个网段上并使用同一个ip，用户所连接的目标地址实际上是一个虚拟地址(vip，virtualip)。而负载平衡服务器在接到该请求的时候将会将其目标地址转化为服务实例所在的实际地址(rip，realip)，并将源地址更改为loadbalancer所在的地址。这样在对请求处理完毕后，服务实例将会把响应发送到负载平衡服务器。此时负载平衡服务器再将响应的地址更改为vip，并将该响应返回给用户，所以，在接收到数据的时候，负载平衡服务器将直接对这些数据包进行转发，而各个服务实例在处理完数据包之后可以将响应返回给负载平衡服务器，其中根据数据包中包含的ip地址对应的vip与端口的组合，可以查询到对应的服务器。

步骤203，从所述提供所述服务的后端服务器中，按照预置的调度规则选择一台后台服务器以分配所述访问请求。

本申请实施例中，当确定了提供用户需求的服务的服务器后，则首先判断该服务器目前标记的权重值，根据该权重值确定调度该服务器的概率，通常情况下，提供一个服务可以通过若干服务器实现，在调度这些服务器时，通过其权重值进行判断。

在实际应用中，roundrobin(轮询调度)算法是最常用也是表现最好的负载平衡算法。如果各个服务实例的容量并不相同，那么负载平衡服务器会使用weightedroundrobin(权重轮询调度)算法，即根据各个服务实例的实际能力来安比例地分配负载。如果单纯地使用roundrobin算法，那么具有关联关系的各个请求将可能被分配到不同的服务实例上。因此很多负载平衡服务器允许根据数据的特定特征对这些负载进行分配，如使用一种哈希算法来对用户所在的ip(interworkingprotocol，互通协议)进行计算，并以计算结果决定需要分配到的服务实例。当然，也需要考虑某个服务器实例失效的情况。如果负载平衡系统中的某个服务器实例失效，那么哈希算法中的哈希值空间将发生变化，进而导致原本的服务实例分配结果将不再有效。在这种情况下，所有的请求将重新分配服务器实例。另外，在某些情况下，用户的ip也可能在各个请求之间发生变化，进而导致它所对应的服务实例发生更改。

在实际应用中，负载均衡算法不限于上述描述，根据用户需求以及服务特征、硬件性能可以是任何可以实现复杂均衡的算法完成的，对此本发明实施例不加以限制。

步骤204，当所述负载均衡权重减少到设定权重阈值后，隔离所述后台服务器。

本申请实施例中，若所述wn＝w-d的值为零，则标记所述后台服务器为故障服务器，根据预设的权重计算规则，当在预设健康监测次数完成时，所有的健康探测都失败了，那么，就根据规则，服务器的权重值为0，则该服务器将不提供任何服务，即将该服务器进行隔离。与此同时，发出故障通知，相关技术人员收到通知后可以进行故障排除工作，当故障排除后可以手动将该服务器的权重值设置为初始值。

在本申请实施例中，通过在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则以上次健康探测操作后对应所述后台服务器的负载均衡权重，减去所述健康探测操作失败总次数与设定变量值之积的结果，作为所述后台服务器新的负载均衡权重，然后确定所述访问请求对应的服务，从所述提供所述服务的后端服务器中，按照预置的调度规则选择一台后台服务器以分配所述访问请求，当所述负载均衡权重减少到设定权重阈值后，隔离所述后台服务器。实现了根据健康监测动态调节服务器的权重值，并根据权重值进行负载调度，解决了现有技术中无法准确得知服务器状态，而将服务请求发送到故障服务器而得不到响应的问题，提高了服务器的可用性。

参照图3，示出了本申请的一种负载调度方法可选实施例的步骤流程图，具体可以包括如下步骤：

步骤301，对后台服务器进行健康探测操作。

本申请实施例中，负载均衡服务(baiduloadbalance)可以将来自互联网或内网的流量分发至多台后端服务器，实现业务系统的水平扩展提升服务能力，并通过健康检查剔除不可用的主机提升业务系统可用性，其中，负载均衡的关键步骤就是探知服务器当前的健康状态，所以由负载均衡服务器向一后台服务器发送健康探测消息后，若健康探测消息发送成功，则服务器工作正常，若发送不成功，则说明该服务器故障。

优选的，本申请实施例中，由虚拟服务器中的探测实例的监听线程进行所述健康探测操作。

本申请实施例中，为了能够保证从负载平衡服务器所派发的数据包能被它后面的服务器集群正常处理，负载平衡服务器需要周期性地发送健康探测请求到后台服务器，其中，虚拟服务器发在发送探测请求时，其监听线程会监听各后台服务器的权重，当在健康探测请求发送不成功时，就将监听到的服务器权重进行修改，当然，负载均衡系统中，往往存在多个虚拟服务器，每个服务器对应多个探测实例，当一个虚拟服务器工作状态不正常时，其负责的探测实例工作将会由其他虚拟服务器负责，如图1a所描述的，一个虚拟服务器的探测实例又针对多个后台服务器，其监听线程发送的探测请求也是针对多个后台服务器同时发送的。

优选的，本申请实施例中，当所述探测实例为tcp类型实例时，所述向一后台服务器进行一次健康探测操作包括：

步骤a301，向一后台服务器发送tcp连接报文；当接收到针对所述tcp连接报文的响应不为sync+ack报文时，表示所述健康探测操作失败。

本申请实施例中，在基于传输层(tcp/udp)的应用开发中，为了最后的程序优化，应避免端到端的任何一个节点上出现ip分片。tcp的mss协商机制加上序列号确认机制，基本上能够保证数据的可靠传输。在负载平衡服务器中，负载平衡探测消息中主要包含数据包的ip头和tcp、udp(userdatagramprotocol)，用户数据报协议)等协议的协议头，当探测消息将包含tcp连接报文发送到对象服务器，在预设时间内没有接收到sync+ack响应报文，或者完全没有接收到响应时，则确认该健康探测操作失败，如图2a描述的，lvs会定期向后端rs发syn包尝试建立tcp连接，如果后端rs回复sync+ack说明后端服务正常，如果后端没有回复sync+ack表示该次健康检查探测失败，这就叫做三次握手。如果打算让双方都做好准备的话，一定要发送三次报文，而且只需要三次报文就可以了。

优选的，本申请实施例中，当所述探测实例为udp类型实例时，所述向一后台服务器进行一次健康探测操作包括：

步骤a302，向一后台服务器发送udp探测报文；当接收到针对所述udp探测报文的响应不为icmp(internetcontrolmessageprotocol，因特网控制消息协议))不可达报文时，表示所述健康探测操作失败。

本申请实施例中，udp协议在ip协议的基础上，只增加了传输层的端口(sourceport+destinationport)、udp数据包长(length＝header+data)以及检验和(checksum)。因此，基于udp开发应用程序时，数据包需要结合ip分片情况考虑。对于以太局域网，往往取udp数据包长length<＝mtu-sizeof(ipheader)＝1480，故udp数据负载量小于或等于1472(length-udpheader)。tcp三次握手建立连接，客户端首先向服务器申请打开某一个端口(用syn段等于1的tcp报文)，然后服务器端发回一个ack报文通知客户端请求报文收到，客户端收到确认报文以后再次发出确认报文确认刚才服务器端发出的确认报文，至此，连接的建立完成。

在实际应用时，发送udp报文时，首先处理udp套接字，通过调用函数udp_new()进行申请，然后调用udp_bind()绑定在udp端口上，在这个调用过程中，我们必须编写一个用于处理这个udp套接字接收到的数据报文的函数，并把这个函数作为udp_bind()的参数，以后当套接字接收到数据报文时会自动调用这个函数，我们将在后面介绍这个函数怎么调用的。绑定结束之后，必须调用udp_connect()将数据报文的目的地址绑定在udp的数据结构中，最后就是调用udp_send()把数据报文发送出去，在负载均衡服务器通过udp发送健康探测消息时，lvs会发送udp探测报文，当后端rs回icmp端口不可达时认为探测成功否则探测失败。

优选的，本申请实施例中，当所述探测实例为http类型实例时，所述向一后台服务器进行一次健康探测操作包括：

步骤a303，向一后台服务器发送httphead请求；当接收到针对所述httphead请求的http状态码不为200时，表示所述健康探测操作失败。

本申请实施例中，http定义了与服务器交互的不同方法，主要有8种可能的请求方法：get检索uri(uniformresourceidentifier，通用资源标志符)中标识资源的一个简单请求；head与get方法相同，服务器只返回状态行和头标，并不返回请求文档；post服务器接受被写入客户端输出流中的数据的请求；put服务器保存请求数据作为指定uri新内容的请求；delete服务器删除uri中命名的资源的请求；options关于服务器支持的请求方法信息的请求；traceweb服务器反馈http请求和其头标的请求；connect已文档化但当前未实现的一个方法，预留做隧道处理。在本实施例中，lvs会发送httphead请求，而当服务器响应时，其状态行的信息为http的版本号，状态码，及解释状态码的简单说明。现将5类状态码详细列出：客户方错误为100；成功为200，重定向为300，客户方错误400，服务器错误500，所以如果后端rs回复的http状态码为200，则认为健康检查探测成功。用户可以设置健康检查的不健康阀值，当对后端rs健康检查探测失败次数达到不健康阀值的时候，lvs会认为该rs不可用，会将该rs的weight设置为0，直到该rs的将康检查成功之前该rs将不再会被调度到。

步骤302，根据健康探测操作的结果，调整所述后台服务器的负载均衡权重；

本申请实施例中，用户开启健康检查功能后，当后端某台rs健康检查出现异常时，lvs会自动将新的请求分发到其它健康检查正常的rs上；而当该rs恢复正常运行时，lvs会将其自动恢复到对外或对内的服务中。每个rs有一个用户配置的权重weigth值来表示其是否可用以及被选中的优先级，当weight为0时代表当前rs不可用，当为weight时表示后端rs可用，当连续n次对后端某个rs健康检查失败后，每次健康监测失败后会将预设权重值减少一定的数值，知道第n次都监测失败后，lvs会把rs的负载均衡权重设置为0，这时该rs不对外提供服务，新建的访问连接会自动调度到其他后端rs上，如图1a所示的，负载均衡集群架构图，其中，负载均衡机器集群一般由多台机器组成，用户申请的服务vip会在多台lvs(虚拟服务器)集群上进行等价路由宣告，这样用户访问vip服务时会被引到某台lvs机器，在lvs机器上有该实例监听下所有rs的对应列表，lvs会根据调度算法将该次用户访问的连接调度到某个rs上。

在实际应用中，服务器可以定期启动健康检查流程，每次健康检查流程是独立的，对于一个rs而言，除了依赖前一次健康检查流程得到的rs的负载均衡权重，探测次数都是从0开始计数。比如不健康阈值设置为n次，那么前述健康探测操作连续失败的次数达到n次，则后端rs不可用。如果在不超过不健康阈值的情况下，有一次健康探测操作成功，则表明该rs可用，则将该rs的负载均衡权重还原为初始的weigth值。

优选的，确定所述访问请求对应的服务；

本申请实施例中，在负载均衡时，当收到用到的服务请求时，首先要确定服务请求对应的服务，此时负载平衡服务器以及各个服务实例必须在同一个网段上并使用同一个ip，用户所连接的目标地址实际上是一个虚拟地址(vip，virtualip)。而负载平衡服务器在接到该请求的时候将会将其目标地址转化为服务实例所在的实际地址(rip，realip)，并将源地址更改为loadbalancer所在的地址。这样在对请求处理完毕后，服务实例将会把响应发送到负载平衡服务器。此时负载平衡服务器再将响应的地址更改为vip，并将该响应返回给用户，所以，在接收到数据的时候，负载平衡服务器将直接对这些数据包进行转发，而各个服务实例在处理完数据包之后可以将响应返回给负载平衡服务器，其中根据数据包中包含的ip地址对应的vip与端口的组合，可以查询到对应的服务器。

优选的，从所述提供所述服务的后端服务器中，按照预置的调度规则选择一台后台服务器以分配所述访问请求。

本申请实施例中，当确定了提供用户需求的服务的服务器后，则首先判断该服务器目前标记的权重值，根据该权重值确定调度该服务器的概率，通常情况下，提供一个服务可以通过若干服务器实现，在调度这些服务器时，通过其权重值进行判断。

在实际应用中，roundrobin(轮询调度)算法是最常用也是表现最好的负载平衡算法。如果各个服务实例的容量并不相同，那么负载平衡服务器会使用weightedroundrobin(权重轮询调度)算法，即根据各个服务实例的实际能力来安比例地分配负载。如果单纯地使用roundrobin算法，那么具有关联关系的各个请求将可能被分配到不同的服务实例上。因此很多负载平衡服务器允许根据数据的特定特征对这些负载进行分配，如使用一种哈希算法来对用户所在的ip(interworkingprotocol，互通协议)进行计算，并以计算结果决定需要分配到的服务实例。当然，也需要考虑某个服务器实例失效的情况。如果负载平衡系统中的某个服务器实例失效，那么哈希算法中的哈希值空间将发生变化，进而导致原本的服务实例分配结果将不再有效。在这种情况下，所有的请求将重新分配服务器实例。另外，在某些情况下，用户的ip也可能在各个请求之间发生变化，进而导致它所对应的服务实例发生更改。

在实际应用中，负载均衡算法不限于上述描述，根据用户需求以及服务特征、硬件性能可以是任何可以实现复杂均衡的算法完成的，对此本发明实施例不加以限制。

优选的，步骤302，包括子步骤3021；

子步骤3021，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，降低对应所述后台服务器的负载均衡权重。

本申请实施例中，在向服务器发送健康监测消息，若所述消息发送失败则确定健康监测操作失败，根据预设的调度规则，降低该服务器的权重值的设置。

优选的，子步骤3021，具体包括：子步骤30211；

子步骤30211，若所述健康探测操作失败，则在上次健康探测操作后对应所述后台服务器的负载均衡权重的基础上，根据健康探测操作连续失败总次数和设定变量值，降低所述负载均衡权重。

本申请实施例中，若所述健康探测消息为第n次发送至所述后台服务器，且发送失败，则记录n的数值。另外，计算变量值d＝w/n，其中w为所述服务器的预设的初始权重值，当上次健康探测后，rs可用，则其出售的负载均衡权重值为w，其中0＜n≤n，所述n为预设探测不健康阈值，然后根据计算得到的d值重新标记所述后台服务器的权重wn，重新标记的后台服务器的权重值wn＝w-nd。例如，当预设的服务器初始权重值为100，预设的不健康阈值为10次，那么第一次探测失败后，根据上述公式计算，新的权重值为90，第二次失败权重值则设置为80，以此类推，当连续第10次探测失败，那么该服务器的权重值则设置为0。

优选的，当所述负载均衡权重减少到设定权重阈值后，隔离所述后台服务器。

本申请实施例中，若所述wn＝w-d的值为零，则标记所述后台服务器为故障服务器，根据预设的权重计算规则，当在预设健康监测次数完成时，所有的健康探测都失败了，那么，就根据规则，服务器的权重值为0，则该服务器将不提供任何服务，即将该服务器进行隔离。与此同时，发出故障通知，相关技术人员收到通知后可以进行故障排除工作，当故障排除后可以手动将该服务器的权重值设置为初始值。

子步骤3022若所述健康探测操作成功，则根据健康探测操作连续成功总次数，调高对应所述后台服务器的负载均衡权重。

本申请实施例中，在向服务器发送健康监测消息，若所述消息发送成功则确定健康监测操作成功，根据预设的调度规则，调高该服务器的权重值的设置。

优选的，子步骤3022，具体包括：子步骤30212；

子步骤30212，若所述健康探测操作成功，则在上次健康探测操作后对应所述后台服务器的负载均衡权重的基础上，根据健康探测操作连续失败总次数和设定变量值，调高所述负载均衡权重。

本申请实施例中，若所述健康探测消息为第n次发送至所述后台服务器，且发送失败，则记录n的数值。另外，计算变量值d＝w/n，其中w为所述服务器的预设的初始权重值，当上次健康探测后，rs可用，则其出售的负载均衡权重值为w，其中0＜n≤n，所述n为预设探测不健康阈值，然后根据计算得到的d值重新标记所述后台服务器的权重wn，重新标记的后台服务器的权重值wn＝w+nd。例如，当预设的服务器初始权重值为100，预设的不健康阈值为10次，那么第一次探测成功后，根据上述公式计算，新的权重值为110，第二次成功权重值则设置为120，以此类推，当然，用户可以根据需求设置一个权重上限，以防止服务器故障后检测时效过长的问题，例如，如果一个服务器的权重值在经过多次成功的健康检测后升至1000，那么如果一旦故障，则需要100次失败的健康检测才能确定为故障，对设置的阈值本发明实施例不加以限制。当然，如果连续探测成功n次后，后台服务器的权重到达最高阈值，则可以不再调高其权重。比如后台服务器的权重为初始权重值时，可以不调高后台服务器的权重。

优选的，所述设定变量值通过所述后台服务器的初始负载均衡权重与连续健康探测操作失败次数的失败阈值的正相关关系获得。

本申请实施例中，设定的变量值，即为d＝w/n，计算该值是通过该服务器预设的初始权重值与预设的不健康阈值的比值，并与健康探测操作连续失败次数的乘积所得，例如，当预设初始权重值为100，预设的不健康阈值为10次，d＝100/10＝10，当第八次探测失败后，再利用初始权重值减去8d得到当前新的权重值则为20。若所述访问探测消息发送成功，则重置所述后台服务器权重值wn为初始权重值w＝100。例如，在经过第八次健康探测失败后，第九次探测成功，则将该服务器的权重值恢复为初始权重值，即100。

步骤303，根据所述负载均衡权重，调整相应后台服务器被分发访问请求的概率；其中，所述负载均衡权重与所述概率正相关。

本申请实施例中，当通过健康监测的失败次数的逐步降低服务器的预设权重值后，在负载均衡服务器接收到用户发送的服务请求时，在将服务请求调度到服务器时首先选择权重值较高的服务器，而规避权重值为0的服务器，并且权重值越高，被调度的几率就越大，反之越小，其中根据权重值进行调度服务器的调度规则是根据用户需求预先设置的，本发明实施例对此不加限制。

在本申请实施例中，通过对后台服务器进行健康探测操作；根据健康探测操作的结果，调整所述后台服务器的负载均衡权重；根据所述负载均衡权重，调整相应后台服务器被分发访问请求的概率；其中，所述负载均衡权重与所述概率正相关，解决了现有技术中无法准确得知服务器状态，而将服务请求发送到故障服务器而得不到响应的问题，提高了服务器的可用性。

参照图4，示出了本申请的一种负载调度装置实施例的结构框图，具体可以包括如下模块：

权重调整模块401，用于在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重；

负载调度模块402，用于在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一后台服务器；其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。

在本申请实施例中，在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重，通过上述动态调整服务器权重后，在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一权重较高的后台服务器，其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。解决了现有技术中无法准确得知服务器状态，而将服务请求发送到故障服务器而得不到响应的问题，提高了服务器的可用性。

参照图5，示出了本申请的一种负载调度装置实施例的结构框图，具体可以包括如下模块：

权重调整模块401，用于在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重；

优选的，所述权重调整模块401，具体包括：探测子模块4011，用于在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则以上次健康探测操作后对应所述后台服务器的负载均衡权重，减去所述健康探测操作失败总次数与设定变量值之积的结果，作为所述后台服务器新的负载均衡权重。

优选的，所述设定变量值为对应所述后台服务器的初始负载均衡权重与连续健康探测操作失败次数的失败阈值的比值。

优选的，由虚拟服务器中的探测实例的监听线程进行所述健康探测操作。

优选的，当所述探测实例为tcp类型实例时，所述探测子模块，包括：

tcp连接报文发送子模块，用于向一后台服务器发送tcp连接报文；当接收到针对所述tcp连接报文的响应不为sync+ack报文时，表示所述健康探测操作失败。

优选的，当所述探测实例为udp类型实例时，所述探测子模块，包括：

udp探测报文发送子模块，用于向一后台服务器发送udp探测报文；当接收到针对所述udp探测报文的响应不为icmp不可达报文时，表示所述健康探测操作失败。

优选的，当所述探测实例为http类型实例时，所述探测子模块，包括：

httphead请求发送子模块，用于向一后台服务器发送httphead请求；当接收到针对所述httphead请求的http状态码不为200时，表示所述健康探测操作失败。

负载调度模块402，用于在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一后台服务器；其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。

优选的，所述负载调度模块402，具体包括：

请求确定子模块4021，用于确定所述访问请求对应的服务；

调度子模块4022，用于从所述提供所述服务的后端服务器中，按照预置的调度规则选择一台后台服务器以分配所述访问请求。

隔离子模块4023，用于当所述负载均衡权重减少到设定权重阈值后，隔离所述后台服务器。

在本申请实施例中，通过在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则以上次健康探测操作后对应所述后台服务器的负载均衡权重，减去所述健康探测操作失败总次数与设定变量值之积的结果，作为所述后台服务器新的负载均衡权重，然后确定所述访问请求对应的服务，从所述提供所述服务的后端服务器中，按照预置的调度规则选择一台后台服务器以分配所述访问请求，当所述负载均衡权重减少到设定权重阈值后，隔离所述后台服务器。实现了根据健康监测动态调节服务器的权重值，并根据权重值进行负载调度，解决了现有技术中无法准确得知服务器状态，而将服务请求发送到故障服务器而得不到响应的问题，提高了服务器的可用性。

参照图6，示出了本申请的一种负载调度装置实施例的结构框图，具体可以包括如下模块：

健康探测模块501，用于对后台服务器进行健康探测操作；

负载均衡权重调整模块502，用于根据健康探测操作的结果，调整所述后台服务器的负载均衡权重；

请求概率调度模块503，用于根据所述负载均衡权重，调整相应后台服务器被分发访问请求的概率；其中，所述负载均衡权重与所述概率正相关。

参照图7，示出了本申请的一种负载调度系统的结构框图，具体可以包括：

至少一台虚拟服务器701，和多台后台服务器702；每台虚拟服务器分别与所述多台后台服务器连接；

所述虚拟服务器701包括：

权重调整模块7011，用于在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重；

负载调度模块7012，用于在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一后台服务器；其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。

参照图8，示出了本申请的一种负载调度系统的结构框图，具体可以包括：

至少一台虚拟服务器801，和多台后台服务器802；每台虚拟服务器分别与所述多台后台服务器连接；

所述虚拟服务器801包括：

健康探测模块8011，用于对后台服务器进行健康探测操作；

负载均衡权重调整模块，用于根据健康探测操作的结果，调整所述后台服务器的负载均衡权重；

请求概率调度模块8012，用于根据所述负载均衡权重，调整相应后台服务器被分发访问请求的概率；其中，所述负载均衡权重与所述概率正相关。

图9是本申请实施例提供的另一种服务器结构示意图。参见图9，服务器900可以用于实施上述实施例中提供的交易服务器侧的打印处理方法。该服务器900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessingunits，cpu)922(例如，一个或一个以上处理器)和存储器932，一个或一个以上存储应用程序942或数据944的存储介质930(例如一个或一个以上海量存储设备)。其中，存储器932和存储介质930可以是短暂存储的或持久存储的。存储在存储介质930的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器522可以设置为与存储介质930通信，在服务器900上执行存储介质930中的一系列指令操作。

服务器900还可以包括一个或一个以上电源926，一个或一个以上有线或无线网络接口950，一个或一个以上输入输出接口958，一个或一个以上键盘956，和/或，一个或一个以上操作系统941，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm等等。其中，中央处理器922可以在服务器900上执行以下操作的指令：

在向一后台服务器进行一次健康探测操作后，若所述健康探测操作失败，则根据健康探测操作连续失败总次数，动态的降低对应所述后台服务器的负载均衡权重；

在接收到客户端的访问请求后，按照预置的调度规则分配所述访问请求至一后台服务器；其中，所述调度规则包括：将访问请求优先分发给负载均衡权重高的后台服务器的概率，高于负载均衡权重低的后台服务器的概率。

中央处理器922还可以在服务器900上执行以下操作的指令：

对后台服务器进行健康探测操作；

根据健康探测操作的结果，调整所述后台服务器的负载均衡权重；

根据所述负载均衡权重，调整相应后台服务器被分发访问请求的概率；其中，所述负载均衡权重与所述概率正相关。

当然，中央处理器922可以在服务器900上执行以下操作的指令还可以包括前述任一实施例的步骤方法。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在一个示例中提供了一种装置，包括：一个或多个处理器；和，其上存储的有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行如本申请实施例中负载调度方法。

在一个示例中还提供了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行如本申请实施例中负载调度方法。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

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

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

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

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种负载调度方法和一种负载调度装置，以及一种服务器，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。