服务处理的方法、装置、电子设备和存储介质与流程

本发明实施例涉及一种通信技术领域，特别是一种服务处理的方法、装置、电子设备和存储介质。

背景技术：

在面向服务的架构(service-orientedarchitecture，soa)体系中，应用程序的不同功能单元称为服务。

soa是通过各个服务之间的接口以及对应的契约联系起来的。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同系统中的服务能够以一种统一和通用的方式进行交互。契约是在使用服务时必须遵守的约束。

随着全球信息化的浪潮，信息化产业不断发展、延伸，已经影响到众多的企业及个人，soa系统架构的出现给信息化带来一场新的革命。

服务交互遇到的一个问题是性能瓶颈，现有技术中解决性能瓶颈问题的主流方案是负载均衡。

负载均衡(loadbalance)是将工作任务分摊到所有操作单元上进行执行，从而共同完成工作任务。例如web(worldwideweb，全球广域网)服务器、ftp(filetransferprotocol，文件传输协议)服务器、企业关键应用服务器和其它关键任务服务器等共同完成工作任务。

现有技术的负载均衡方案是建立在现有网络结构之上，它可以扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

图1为现有技术中互联网分布式架构中各层负载均衡示意图。

如图1所示，主要有客户端层、反向代理层、站点层、服务层和数据层，每一个下游都有所有上游调用，每一个上游可均匀访问每一个下游，就能实现将请求/数据均匀分摊到所有操作单元上执行。

每一层的调用和访问均为动态的，以服务层为例，目前服务层的负载均衡，一般是通过“服务连接池”实现的，连接池是创建和管理一个连接的缓冲池的技术，这些连接准备好被任何需要它们的线程使用。连接池技术的思想非常简单，将连接作为对象存储在一个vector对象中，不同的请求就可以共享这些连接。

现有技术中的缺陷在于：当连接池的连接的数量达到上限后，新的调用请求就会等待，进而导致性能问题蔓延，从而无法实现负载均衡。

技术实现要素：

针对现有技术的缺陷，本发明实施例提供一种服务处理的方法、装置、电子设备和存储介质。

一方面，本发明实施例提供一种服务处理的方法，所述方法包括：

接收请求方发送的请求，所述请求包括第一需求的信息；

向请求方反馈提供方的信息，所述提供方是根据所述第一需求的信息和所有提供方的第一负载的信息确定的，以供请求方根据提供方的信息与提供方进行服务交互；

根据全局健康度，确定是否需要调整部分或全部提供方的负载，所述全局健康度是根据第二需求的信息和第二负载的信息联合确定的，所述第二需求的信息表示所有请求方当前需要的资源的数量，所述第二负载的信息表示所有提供方当前处理资源的数量。

另一方面，本发明实施例提供一种服务处理的装置，所述装置包括：

接收模块，用于接收请求方发送的请求，所述请求包括第一需求的信息；

反馈模块，用于向请求方反馈提供方的信息，所述提供方是根据所述第一需求的信息和所有提供方的第一负载的信息确定的，以供请求方根据提供方的信息与提供方进行服务交互；

调整模块，用于根据全局健康度，确定是否需要调整部分或全部提供方的负载，所述全局健康度是根据第二需求的信息和第二负载的信息联合确定的，所述第二需求的信息表示所有请求方当前需要的资源的数量，所述第二负载的信息表示所有提供方当前处理资源的数量。

另一方面，本发明实施例还提供一种电子设备，包括存储器、处理器、总线以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现以上方法的步骤。

另一方面，本发明实施例还提供一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如上方法的步骤。

由上述技术方案可知，本发明实施例提供的服务处理的方法、装置、电子设备和存储介质，所述方法在每一次为请求方分配提供方后，进行全局健康度的评估，根据全局健康度，及时发现负载不均衡的情况，并通过动态调整提供方的负载，以实现全局的负载均衡。

附图说明

图1为现有技术中互联网分布式架构中各层负载均衡示意图。

图2为本发明实施例提供的一种服务处理的方法的流程示意图；

图3为本发明又一实施例提供的服务交互示意图；

图4为本发明又一实施例提供的服务交互的流程示意图；

图5为本发明又一实施例提供的一种服务处理的装置的结构示意图；

图6为本发明又一实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本发明实施例一部分实施例，而不是全部的实施例。

术语解释：

服务管理平台：本发明实施例提供的服务处理的方法在服务处理的装置上实现，服务处理的装置为管理交互的双方的服务管理平台。

可选地，服务管理平台是本发明实施例新增的平台，用于管理各服务的请求和提供，维持负载均衡。

提供方：为请求方提供某种服务的功能单元。

请求方：需要某种服务的功能单元。

图2示出了本发明实施例提供的一种服务处理的方法的流程示意图。

如图2所示，本发明实施例提供的方法具体包括以下步骤：

步骤11、接收请求方发送的请求，所述请求包括第一需求的信息；

可选地，请求方若需请求提供方提供某种服务，先确定所述第一需求的信息。

可选地，所述第一需求的信息可反映请求方需要的资源的数量。若请求方的请求的资源量大，则所述第一需求的信息大。

可选地，请求方预先估计该服务消耗的资源的数量，即第一需求的信息，向服务管理平台发起请求，以请求分配提供方。

可选地，服务管理平台收到所述请求后，缓存登记请求方第一需求的信息。

步骤12、向请求方反馈提供方的信息，所述提供方是根据所述第一需求的信息和所有提供方的第一负载的信息确定的，以供请求方根据提供方的信息与提供方进行服务交互；

可选地，服务管理平台预先获取所有提供方的第一负载的信息，每一第一负载的信息表示一个提供方当前的处理资源，即能够用于进行处理的资源的数量，可反映一个提供方当前提供服务的能力。

可选地，根据第一需求的信息和所有第一负载的信息，确定为请求方提供服务的提供方。

可选地，从所有提供方的第一负载的信息中，选择一个与请求方的第一需求的信息相应的第一负载的信息对应的提供方。

例如，所述第一需求的信息较大，为请求方提供能力较强，第一负载的信息较大的提供方。

可选地，获取筛选的提供方的信息，反馈给请求方。

可选地，请求方收到提供方的信息后，与提供方建立连接，进行服务交互。

可选地，服务交互是指提供方将消耗自身的资源，为请求方提供服务。

步骤13、根据全局健康度，确定是否需要调整部分或全部提供方的负载，所述全局健康度是根据第二需求的信息和第二负载的信息联合确定的，所述第二需求的信息表示所有请求方当前需要的资源的数量，所述第二负载的信息表示所有提供方当前处理资源的数量。

可选地，全局健康度是服务管理平台监控的一个指标，用于衡量全局的负载均衡程度。全局是指在服务管理平台注册的各个提供方的负载和各个请求方的需求。

可选地，提供方在进行服务交互后，向服务管理平台发送最新的负载的信息，服务管理平台根据所有提供方的负载信息，得到第二负载的信息。请求方在进行服务交互后，向服务管理平台发送需求的信息，服务管理平台根据所有请求方的需求信息，得到第二需求的信息。

可选地，每一次为请求方分配提供方后，提供方为请求方提供服务，提供方的第一负载的信息将减小，则所有提供方的能够处理的资源的数量总和将减小，处理能力下降，第二负载的信息减小。相应地，请求方的第一需求被满足，则所有请求方的需要的资源的数量总和将减小，第二需求的信息减小。

可选地，若服务管理平台判断获知第二需求的信息大于第二负载的信息，表示各个请求方当前的需要的资源的数量大于各个提供方当前能够处理的资源的数量，则全局健康度低，表示全局负载不均衡。

可选地，若判断全局健康度低，可通知提供方新增空闲资源，使提供方提高负载。

可选地，若服务管理平台判断获知第二需求的信息等于第二负载的信息，表示各个请求方当前服务的需要的资源的数量可由各个提供方来提供，则全局健康度高，表示全局负载均衡。

可选地，若判断全局健康度高，不进行处理，在下一次为请求方分配提供方后，重新评估全局健康度。

本发明实施例中，由服务管理平台对提供方和请求方的服务交互进行管理，由服务管理平台决策为请求方提供服务的提供方，然后请求方与提供方建立连接，服务管理平台可获知请求方的第一需求的信息和提供方的第二负载的信息，为进行全局健康度的评估提供数据支持，在每一次为请求方分配提供方后，进行全局健康度的评估，并根据全局健康度，确定是否需要调整提供方的负载。

提供方和请求方的资源均为动态的，若对请求方和提供方都进行调整，则全局负载波动频繁，反而无法保存均衡，在本发明实施例中，通过动态调整其中一方，即提供方的负载，保持了全局性能平稳。

本实施例提供的服务处理的方法，在每一次为请求方分配提供方后，进行全局健康度的评估，根据全局健康度，及时发现负载不均衡的情况，并通过动态调整提供方的负载，以实现全局的负载均衡。

在上述实施例的基础上，本发明又一实施例提供的服务处理的方法，所述第一负载的信息是根据提供方的当前处理队列的剩余长度和实时处理速度确定的；所述第二负载的信息是根据各个提供方的当前处理队列的剩余长度和实时处理速度确定的。

可选地，提供方包括处理队列，具有预设的总长度，确定当前剩余长度，作为提供方的空闲资源。

可选地，实时处理速度是提供方当前的处理速度，当前处理队列的处理速度快，则处理能力较强，第一负载的信息大。

可选地，综合考虑空闲资源以及处理速度，得到对应的第一负载的信息，空闲资源以及处理速度均与第一负载的信息呈正比。

可选地，所述第二负载的信息表示所有提供方当前的处理能力之和，每一提供方的处理能力的计算方式同样可根据当前剩余长度和实时处理速度来确定。

本实施例其他步骤与前述实施例步骤相似，本实施例不再赘述。

本实施例提供的服务处理的方法，通过获取提供方的第一负载的信息，以供后续根据第一需求的信息和所有第一负载的信息，确定为请求方提供服务的提供方。

在上述实施例的基础上，本发明又一实施例提供的服务处理的方法，所述第一需求的信息是根据请求方的当前请求队列的剩余长度和实时请求速度确定的；所述第二需求的信息是根据各个请求方的当前请求队列的剩余长度和实时请求速度确定的。

可选地，请求方与提供方进行服务交互，也将消耗自身的资源。请求方包括请求队列，具有预设的总长度，将当前剩余长度作为请求方的空闲资源。

可选地，实时请求速度是请求方当前的处理速度，当前对请求队列的请求速度快，表示对提供方的处理能力要求高，第一需求的信息大。

可选地，综合考虑空闲资源以及处理速度，得到对应的第一需求的信息，空闲资源以及请求速度均与第一需求的信息呈正比。

可选地，所述第二需求的信息表示所有请求方需求的资源之和，每一请求方的需求的计算方式同样可根据当前剩余长度和实时请求速度来确定。

本实施例其他步骤与前述实施例步骤相似，本实施例不再赘述。

本实施例提供的服务处理的方法，通过获取请求方的第一需求的信息，以供后续根据第一需求的信息和所有第一负载的信息，确定为请求方提供服务的提供方。

在上述实施例的基础上，本发明又一实施例提供的服务处理的方法，向请求方反馈提供方的信息的步骤具体为：

将收到的所有提供方的第一负载的信息从大到小排序，得到排名；

向请求方反馈排名第一的第一负载的信息对应的提供方的信息。

可选地，服务管理平台通过获取每一提供方的第一负载的信息，实时将收到的所有提供方的第一负载的信息从大到小排序，得到当前的处理能力的排名。

可选地，在确定请求方的第一需求的信息后，为请求方提供实时排名第一的提供方的信息，使得该提供方为请求方提供服务，可以尽快完成一次服务交互。

本实施例其他步骤与前述实施例步骤相似，本实施例不再赘述。

本实施例提供的服务处理的方法，通过向请求方反馈排名第一的第一负载的信息对应的提供方的信息，可以尽快完成一次服务交互。

在上述实施例的基础上，本发明又一实施例提供的服务处理的方法，向请求方反馈排名第一的第一负载的信息对应的提供方的信息的步骤之后，所述方法包括：

重新进行所有提供方的第一负载的信息的排名。

可选地，提供方在为请求方提供服务后，动态计算提供方自身的处理能力。

可选地，提供方向服务管理平台发送当前的处理能力，服务管理平台收到提供方的处理能力，登记至本地。

可选地，服务管理平台实时更新提供方的排名，后续请求方进行请求时，为请求方提供最新的排名第一的提供方。

本实施例其他步骤与前述实施例步骤相似，本实施例不再赘述。

本实施例提供的服务处理的方法，实时更新提供方的第一负载的信息的排名，可准确为请求方分配提供方。

在上述实施例的基础上，本发明又一实施例提供的服务处理的方法，根据全局健康度，确定是否需要调整提供方的处理能力步骤具体为：

若第二负载的信息大于第二需求的信息，通知部分或全部提供方降低负载；

若第二负载的信息等于第二需求的信息，不对提供方的负载进行调整；

若第二负载的信息小于第二需求的信息，通知部分或全部提供方提高负载。

可选地，若第二需求的信息小于第二负载的信息，表示提供方的能够处理的资源的数量远大于请求方需要的资源的数量，则认为全局健康度为优秀。

可选地，确定全局健康度为优秀，也表示当前提供方的空闲资源较多，需通知部分或全部提供方可降低资源，使得提供方的负载降低。

可选地，若第二负载的信息等于第二需求的信息，表示提供方当前可为请求方提供服务，则认为全局健康度为良好，无需对提供方的负载进行调整。

可选地，若第二负载的信息小于第二需求的信息，表示提供方当前无法及时为请求方提供服务，则认为全局健康度为一般，需通知部分或全部提供方增加用于处理资源的数量，提高负载。

根据全局健康度，确定是否需要调整提供方的处理能力步骤具体为：

若第二负载的信息小于第二需求的信息一个门限值，发送告警信息。

可选地，若第二负载的信息小于第二需求的信息，则表示提供方当前无法及时为请求方提供服务，在第二负载的信息小于第二需求的信息一个门限值，表示提供方当前的确已经无法为请求方提供服务，可能请求方等待的时间较长，则认为全局健康度为糟糕，需向运维人员发送告警信息。

本实施例其他步骤与前述实施例步骤相似，本实施例不再赘述。

本实施例提供的服务处理的方法，实时监测全局健康度，以及时发现负载不均衡的情况，动态的调整提供方的负载。

为了更充分理解本发明的技术内容，在上述实施例的基础上，详细说明本实施例提供的服务处理的方法。

图3为本发明又一实施例提供的服务交互示意图。

如图3所示，主要涉及服务管理平台、服务提供方、服务请求方。

具体说明如下：

服务管理平台

服务管理平台进行全局处理能力监控与调度，服务管理平台基于每一次请求实时计算全局健康度和服务提供方健康度，其中全局健康度用于全局运行监控并指导服务提供方动态队列调整，服务提供方健康度排名(也就是前述排名)用于指导服务请求方获取实时最佳提供方服务id。

服务提供方

服务提供方向服务管理平台注册服务名称及服务方id。服务提供方向服务管理平台动态登记其处理能力，含本方当前队列总长度、剩余长度、实时处理速度等。

处理队列

服务提供方向处理队列，可以根据服务管理平台所计算的全局健康度进行长度动态调整，且其动态长度是服务管理平台计算全局健康度和服务提供方健康度的依据之一。

服务请求方

服务请求方向服务管理平台注册请求服务名称及请求方id。服务请求方向服务管理平台实时请求，由该平台告知该服务对应健康度最佳服务方id并登记其动态请求需求，含本方当前队列总长度、实时请求速度等。服务请求方向获取最佳提供方id后，向其发起请求并建立服务连接。

请求队列

服务请求方请求队列，其动态长度是服务管理平台计算全局健康度的依据之一。

图4为本发明又一实施例提供的服务交互的流程示意图。

如图4所示，以服务请求方y通过服务管理平台与服务提供方x建立服务连接为例，具体说明基于动态队列的跨平台服务交互流程。

具体说明如下：

步骤1，服务提供方x向服务管理平台注册服务名称及服务方id；

步骤2，服务请求方y向服务管理平台注册请求服务名称及请求方id；

步骤3，服务提供方x动态计算本方处理能力(含当前队列总长度、剩余长度、实时处理速度等)；

步骤4，服务提供方x向服务管理平台登记本方处理能力；

步骤5，服务管理平台更新服务提供方健康度排名；

步骤6，服务请求方y动态计算本方需求情况(含当前队列总长度、实时请求速度等)；

步骤7，服务请求方y向服务管理平台请求分配服务方，并登记本方需求情况；

步骤8，服务管理平台向服务请求方y反馈实时健康度最佳服务方id；

步骤9，服务管理平台更新全局健康度(优秀-需通知服务提供方调减队列，良好-无需调整，一般-需通知服务提供方调增队列，糟糕-需向运维人员告警)；

步骤10，服务请求方y根据实时健康度最佳服务方id与服务提供方x建立服务连接；

步骤11，服务提供方x动态计算本方处理能力(含当前队列总长度、剩余长度、实时处理速度等)；

步骤12，服务提供方x向服务管理平台登记本方处理能力；

步骤13，服务管理平台更新服务提供方健康度排名；

步骤14，若全局健康度优秀则通知服务提供方调减队列长度，若全局健康度一般则通知服务提供方调增队列长度；

步骤15，若全局健康度糟糕，则向运维人员告警。

至此，一次服务连接完成，并基于全局健康度进行了服务提供方队列动态调整或运维告警。

本发明实施例针对存在多个服务提供方和服务请求方的情况下，设计具有全局负载均衡机制的服务管理方，进行全局健康度动态更新以及服务提供方健康度实时计算反馈，很好的解决服务提供方和请求方均为动态的情况下的全局负载均衡问题。

图5为本发明又一实施例提供的一种服务处理的装置的结构示意。

参照图5，在上述实施例的基础上，本实施例提供的服务处理的装置，所述装置包括接收模块51、反馈模块52和调整模块53，其中：

接收模块51用于接收请求方发送的请求，所述请求包括第一需求的信息；反馈模块52用于向请求方反馈提供方的信息，所述提供方是根据所述第一需求的信息和所有提供方的第一负载的信息确定的，以供请求方根据提供方的信息与提供方进行服务交互；调整模块53用于根据全局健康度，确定是否需要调整部分或全部提供方的负载，所述全局健康度是根据第二需求的信息和第二负载的信息联合确定的，所述第二需求的信息表示所有请求方当前需要的资源的数量，所述第二负载的信息表示所有提供方当前处理资源的数量。

可选地，请求方若需请求提供方提供某种服务，先确定所述第一需求的信息。

可选地，所述第一需求的信息可反映请求方需要的资源的数量。若请求方的请求的资源量大，则所述第一需求的信息大。

可选地，请求方预先估计该服务消耗的资源的数量，即第一需求的信息，向接收模块51发起请求，以请求分配提供方。

可选地，接收模块51收到所述请求后，缓存登记请求方第一需求的信息。

可选地，反馈模块52预先获取所有提供方的第一负载的信息，每一第一负载的信息表示一个提供方当前能够处理多少资源，即处理资源的数量，可反映一个提供方当前能够成功提供服务的能力。

可选地，根据第一需求的信息和所有第一负载的信息，确定为请求方提供服务的提供方。

可选地，从所有提供方的第一负载的信息中，选择一个与请求方的第一需求的信息相应的第一负载的信息对应的提供方。

例如，所述第一需求的信息较大，为请求方提供能力较强，第一负载的信息较大的提供方。

可选地，获取筛选的提供方的信息，反馈给请求方。

可选地，请求方收到提供方的信息后，与提供方建立连接，进行服务交互。

可选地，服务交互是指提供方将消耗自身的资源，为请求方提供服务。

可选地，全局健康度是调整模块53监控的一个指标，用于衡量全局的负载均衡程度。全局是指注册的各个提供方的负载和各个请求方的需求。

可选地，提供方在进行服务交互后，向接收模块51发送最新的负载的信息，根据所有提供方的负载信息，得到第二负载的信息。请求方在进行服务交互后，向接收模块51发送需求的信息，根据所有请求方的需求信息，得到第二需求的信息。

可选地，每一次为请求方分配提供方后，提供方为请求方提供服务，提供方的第一负载的信息将减小，则所有提供方的能够处理的资源的数量总和将减小，处理能力下降，第二负载的信息减小。相应地，请求方的第一需求被满足，则所有请求方的需要的资源的数量总和将减小，第二需求的信息减小。

可选地，若调整模块53判断获知第二需求的信息大于第二负载的信息，表示各个请求方当前的需要的资源的数量大于各个提供方当前能够处理的资源的数量，则全局健康度低，表示全局负载不均衡。

可选地，若判断全局健康度低，可通知提供方新增空闲资源，使提供方提高负载。

可选地，若调整模块53判断获知第二需求的信息等于第二负载的信息，表示各个请求方当前服务的需要的资源的数量可由各个提供方来提供，则全局健康度高，表示全局负载均衡。

可选地，若判断全局健康度高，不进行处理，在下一次为请求方分配提供方后，重新评估全局健康度。

本发明实施例中，由调整模块53对提供方和请求方的服务交互进行管理，由调整模块53决策为请求方提供服务的提供方，然后请求方与提供方建立连接，调整模块53可获知请求方的第一需求的信息和提供方的第二负载的信息，为进行全局健康度的评估提供数据支持，在每一次为请求方分配提供方后，进行全局健康度的评估，并根据全局健康度，确定是否需要调整提供方的负载。

若提供方和请求方的资源均为动态的，若对请求方和提供方都进行调整，则全局负载波动频繁，反而无法保存均衡，在本发明实施例中，通过动态调整其中一方，即提供方的负载，保持了全局性能平稳。

本实施例提供的服务处理的装置，可用于执行上述方法实施例的方法，本实施不再赘述。

本实施例提供的服务处理的装置，在每一次为请求方分配提供方后，调整模块进行全局健康度的评估，根据全局健康度，及时发现负载不均衡的情况，并通过动态调整提供方的负载，以实现全局的负载均衡。

图6示出了本发明又一实施例提供的一种电子设备的结构示意图。

参阅图6，本发明实施例提供的电子设备，所述电子设备包括存储器(memory)61、处理器(processor)62、总线63以及存储在存储器61上并可在处理器上运行的计算机程序。其中，所述存储器61、处理器62通过所述总线63完成相互间的通信。

所述处理器62用于调用所述存储器61中的程序指令，以执行所述程序时实现如图2的方法。

在另一种实施方式中，所述处理器执行所述程序时实现如下方法：

所述第一负载的信息是根据提供方的当前处理队列的剩余长度和实时处理速度确定的；

所述第二负载的信息是根据各个提供方的当前处理队列的剩余长度和实时处理速度确定的。

在另一种实施方式中，所述处理器执行所述程序时实现如下方法：

所述第一需求的信息是根据请求方的当前请求队列的剩余长度和实时请求速度确定的；

所述第二需求的信息是根据各个请求方的当前请求队列的剩余长度和实时请求速度确定的。

在另一种实施方式中，所述处理器执行所述程序时实现如下方法：

向请求方反馈提供方的信息的步骤具体为：

将收到的所有提供方的第一负载的信息从大到小排序，得到排名；

向请求方反馈排名第一的第一负载的信息对应的提供方的信息。

在另一种实施方式中，所述处理器执行所述程序时实现如下方法：

向请求方反馈排名第一的第一负载的信息对应的提供方的信息的步骤之后，所述方法包括：

重新进行所有提供方的第一负载的信息的排名。

在另一种实施方式中，所述处理器执行所述程序时实现如下方法：

根据全局健康度，确定是否需要调整提供方的处理能力步骤具体为：

若第二负载的信息大于第二需求的信息，通知部分或全部提供方降低负载；

若第二负载的信息等于第二需求的信息，不对提供方的负载进行调整；

若第二负载的信息小于第二需求的信息，通知部分或全部提供方提高负载。

在另一种实施方式中，所述处理器执行所述程序时实现如下方法：

根据全局健康度，确定是否需要调整提供方的处理能力步骤具体为：

若第二负载的信息小于第二需求的信息一个门限值，发送告警信息。

本实施例提供的电子设备，可用于执行上述方法实施例的方法对应的程序，本实施不再赘述。

本实施例提供的电子设备，通过所述处理器执行所述程序时实现在每一次为请求方分配提供方后，进行全局健康度的评估，根据全局健康度，及时发现负载不均衡的情况，并通过动态调整提供方的负载，以实现全局的负载均衡。

本发明又一实施例提供的一种存储介质，所述存储介质上存储有计算机程序，所述程序被处理器执行时实现如图2的步骤。

在另一种实施方式中，所述程序被处理器执行时实现如下方法：

所述第一负载的信息是根据提供方的当前处理队列的剩余长度和实时处理速度确定的；

所述第二负载的信息是根据各个提供方的当前处理队列的剩余长度和实时处理速度确定的。

在另一种实施方式中，所述程序被处理器执行时实现如下方法：

所述第一需求的信息是根据请求方的当前请求队列的剩余长度和实时请求速度确定的；

所述第二需求的信息是根据各个请求方的当前请求队列的剩余长度和实时请求速度确定的。

在另一种实施方式中，所述程序被处理器执行时实现如下方法：

向请求方反馈提供方的信息的步骤具体为：

将收到的所有提供方的第一负载的信息从大到小排序，得到排名；

向请求方反馈排名第一的第一负载的信息对应的提供方的信息。

在另一种实施方式中，所述程序被处理器执行时实现如下方法：

向请求方反馈排名第一的第一负载的信息对应的提供方的信息的步骤之后，所述方法包括：

重新进行所有提供方的第一负载的信息的排名。

在另一种实施方式中，所述程序被处理器执行时实现如下方法：

根据全局健康度，确定是否需要调整提供方的处理能力步骤具体为：

若第二负载的信息大于第二需求的信息，通知部分或全部提供方降低负载；

若第二负载的信息等于第二需求的信息，不对提供方的负载进行调整；

若第二负载的信息小于第二需求的信息，通知部分或全部提供方提高负载。

在另一种实施方式中，所述程序被处理器执行时实现如下方法：

根据全局健康度，确定是否需要调整提供方的处理能力步骤具体为：

若第二负载的信息小于第二需求的信息一个门限值，发送告警信息。

本实施例提供的存储介质，所述程序被处理器执行时实现上述方法实施例的方法，本实施不再赘述。

本实施例提供的存储介质，在每一次为请求方分配提供方后，进行全局健康度的评估，根据全局健康度，及时发现负载不均衡的情况，并通过动态调整提供方的负载，以实现全局的负载均衡。

本发明又一实施例公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如包括：

接收请求方发送的请求，所述请求包括第一需求的信息；

向请求方反馈提供方的信息，所述提供方是根据所述第一需求的信息和所有提供方的第一负载的信息确定的，以供请求方根据提供方的信息与提供方进行服务交互；

根据全局健康度，确定是否需要调整部分或全部提供方的负载，所述全局健康度是根据第二需求的信息和第二负载的信息联合确定的，所述第二需求的信息表示所有请求方当前需要的资源的数量，所述第二负载的信息表示所有提供方当前处理资源的数量。

本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。

本领域技术人员可以理解，实施例中的各步骤可以以硬件实现，或者以在一个或者所有处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本发明实施例的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。

虽然结合附图描述了本发明的实施方式，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。