CN109936592A - 服务处理的方法、装置、电子设备和存储介质 - Google Patents
服务处理的方法、装置、电子设备和存储介质 Download PDFInfo
- Publication number
- CN109936592A CN109936592A CN201711352796.7A CN201711352796A CN109936592A CN 109936592 A CN109936592 A CN 109936592A CN 201711352796 A CN201711352796 A CN 201711352796A CN 109936592 A CN109936592 A CN 109936592A
- Authority
- CN
- China
- Prior art keywords
- information
- provider
- load
- demand
- requesting party
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明实施例提供一种服务处理的方法、装置、电子设备和存储介质。所述方法包括接收请求方发送的请求，请求包括第一需求的信息；向请求方反馈提供方的信息，提供方是根据第一需求的信息和所有提供方的第一负载的信息确定的，以供请求方根据提供方的信息与提供方进行服务交互；根据全局健康度，确定是否需要调整部分或全部提供方的负载，全局健康度是根据第二需求的信息和第二负载的信息联合确定的，第二需求的信息表示所有请求方当前需要的资源的数量，第二负载的信息表示所有提供方当前处理资源的数量。所述方法在每一次为请求方分配提供方后进行全局健康度的评估，及时发现负载不均衡的情况，并通过动态调整提供方的负载实现全局负载均衡。
Description
技术领域
本发明实施例涉及一种通信技术领域，特别是一种服务处理的方法、装置、电子设备和存储介质。
背景技术
在面向服务的架构(Service-Oriented Architecture，SOA)体系中，应用程序的不同功能单元称为服务。
SOA是通过各个服务之间的接口以及对应的契约联系起来的。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同系统中的服务能够以一种统一和通用的方式进行交互。契约是在使用服务时必须遵守的约束。
随着全球信息化的浪潮，信息化产业不断发展、延伸，已经影响到众多的企业及个人，SOA系统架构的出现给信息化带来一场新的革命。
服务交互遇到的一个问题是性能瓶颈，现有技术中解决性能瓶颈问题的主流方案是负载均衡。
负载均衡(Load Balance)是将工作任务分摊到所有操作单元上进行执行，从而共同完成工作任务。例如Web(World Wide Web，全球广域网)服务器、FTP(File TransferProtocol，文件传输协议)服务器、企业关键应用服务器和其它关键任务服务器等共同完成工作任务。
现有技术的负载均衡方案是建立在现有网络结构之上，它可以扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
图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)来实现根据本发明实施例的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。
虽然结合附图描述了本发明的实施方式，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。
Claims (10)
1.一种服务处理的方法，其特征在于，所述方法包括：
接收请求方发送的请求，所述请求包括第一需求的信息；
向请求方反馈提供方的信息，所述提供方是根据所述第一需求的信息和所有提供方的第一负载的信息确定的，以供请求方根据提供方的信息与提供方进行服务交互；
根据全局健康度，确定是否需要调整部分或全部提供方的负载，所述全局健康度是根据第二需求的信息和第二负载的信息联合确定的，所述第二需求的信息表示所有请求方当前需要的资源的数量，所述第二负载的信息表示所有提供方当前处理资源的数量。
2.根据权利要求1所述的方法，其特征在于：所述第一负载的信息是根据提供方的当前处理队列的剩余长度和实时处理速度确定的；所述第二负载的信息是根据各个提供方的当前处理队列的剩余长度和实时处理速度确定的。
3.根据权利要求1所述的方法，其特征在于：所述第一需求的信息是根据请求方的当前请求队列的剩余长度和实时请求速度确定的；所述第二需求的信息是根据各个请求方的当前请求队列的剩余长度和实时请求速度确定的。
4.根据权利要求1所述的方法，其特征在于:向请求方反馈提供方的信息的步骤具体为：
将收到的所有提供方的第一负载的信息从大到小排序，得到排名；
向请求方反馈排名第一的第一负载的信息对应的提供方的信息。
5.根据权利要求4所述的方法，其特征在于：向请求方反馈排名第一的第一负载的信息对应的提供方的信息的步骤之后，所述方法包括：
重新进行所有提供方的第一负载的信息的排名。
6.根据权利要求1所述的方法，其特征在于：根据全局健康度，确定是否需要调整提供方的处理能力步骤具体为：
若第二负载的信息大于第二需求的信息，通知部分或全部提供方降低负载；
若第二负载的信息等于第二需求的信息，不对提供方的负载进行调整；
若第二负载的信息小于第二需求的信息，通知部分或全部提供方提高负载。
7.根据权利要求1所述的方法，其特征在于：根据全局健康度，确定是否需要调整提供方的处理能力步骤具体为：
若第二负载的信息小于第二需求的信息一个门限值，发送告警信息。
8.一种服务处理的装置，其特征在于，所述装置包括：
接收模块，用于接收请求方发送的请求，所述请求包括第一需求的信息；
反馈模块，用于向请求方反馈提供方的信息，所述提供方是根据所述第一需求的信息和所有提供方的第一负载的信息确定的，以供请求方根据提供方的信息与提供方进行服务交互；
调整模块，用于根据全局健康度，确定是否需要调整部分或全部提供方的负载，所述全局健康度是根据第二需求的信息和第二负载的信息联合确定的，所述第二需求的信息表示所有请求方当前需要的资源的数量，所述第二负载的信息表示所有提供方当前处理资源的数量。
9.一种电子设备，其特征在于，包括存储器、处理器、总线以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1-7任意一项的步骤。
10.一种存储介质，其上存储有计算机程序，其特征在于：所述程序被处理器执行时实现如权利要求1-7任意一项的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711352796.7A CN109936592A (zh) | 2017-12-15 | 2017-12-15 | 服务处理的方法、装置、电子设备和存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711352796.7A CN109936592A (zh) | 2017-12-15 | 2017-12-15 | 服务处理的方法、装置、电子设备和存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN109936592A true CN109936592A (zh) | 2019-06-25 |
Family
ID=66980410
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711352796.7A Pending CN109936592A (zh) | 2017-12-15 | 2017-12-15 | 服务处理的方法、装置、电子设备和存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109936592A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110941535A (zh) * | 2019-11-22 | 2020-03-31 | 山东超越数控电子股份有限公司 | 一种硬盘负载均衡方法 |
Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101222424A (zh) * | 2007-12-24 | 2008-07-16 | 中国电信股份有限公司 | 内容分发网络和该网络中基于内容的调度方法 |
| CN101605092A (zh) * | 2009-07-10 | 2009-12-16 | 浪潮电子信息产业股份有限公司 | 一种基于内容的负载均衡系统 |
| CN101640684A (zh) * | 2009-08-21 | 2010-02-03 | 中国电信股份有限公司 | 内容分发方法、网络系统、gslb设备和域名服务器 |
| CN103246592A (zh) * | 2013-05-13 | 2013-08-14 | 北京搜狐新媒体信息技术有限公司 | 一种监控采集系统及方法 |
| US20130332597A1 (en) * | 2012-06-11 | 2013-12-12 | Cisco Technology, Inc | Reducing virtual ip-address (vip) failure detection time |
| CN103491123A (zh) * | 2012-06-14 | 2014-01-01 | 中国移动通信集团贵州有限公司 | 一种基于域名访问的负载均衡方法、系统及负载均衡器 |
| CN103873497A (zh) * | 2012-12-11 | 2014-06-18 | 中国电信股份有限公司 | 用于调度信息的方法、装置和系统 |
| CN103944940A (zh) * | 2013-01-21 | 2014-07-23 | 华耀(中国)科技有限公司 | 动态配置代理服务器的设备及方法 |
| CN104111874A (zh) * | 2014-02-13 | 2014-10-22 | 西安未来国际信息股份有限公司 | 一种云计算环境中虚拟主机的高并发高可靠负载均衡软件架构设计 |
| US20150106523A1 (en) * | 2013-10-15 | 2015-04-16 | Vmware, Inc. | Distributed global load-balancing system for software-defined data centers |
| CN106713375A (zh) * | 2015-07-21 | 2017-05-24 | 中国移动通信集团重庆有限公司 | 云资源的调配方法及装置 |
| CN106797405A (zh) * | 2016-12-14 | 2017-05-31 | 华为技术有限公司 | 分布式负载均衡系统、健康检查方法和服务节点 |
| CN107026877A (zh) * | 2016-01-29 | 2017-08-08 | 华为技术有限公司 | 云平台中管理资源的方法和装置 |
| CN107317889A (zh) * | 2017-08-21 | 2017-11-03 | 深圳市视维科技股份有限公司 | 一种智能dns调度系统及调度方法 |
-
2017
- 2017-12-15 CN CN201711352796.7A patent/CN109936592A/zh active Pending
Patent Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101222424A (zh) * | 2007-12-24 | 2008-07-16 | 中国电信股份有限公司 | 内容分发网络和该网络中基于内容的调度方法 |
| CN101605092A (zh) * | 2009-07-10 | 2009-12-16 | 浪潮电子信息产业股份有限公司 | 一种基于内容的负载均衡系统 |
| CN101640684A (zh) * | 2009-08-21 | 2010-02-03 | 中国电信股份有限公司 | 内容分发方法、网络系统、gslb设备和域名服务器 |
| US20130332597A1 (en) * | 2012-06-11 | 2013-12-12 | Cisco Technology, Inc | Reducing virtual ip-address (vip) failure detection time |
| CN103491123A (zh) * | 2012-06-14 | 2014-01-01 | 中国移动通信集团贵州有限公司 | 一种基于域名访问的负载均衡方法、系统及负载均衡器 |
| CN103873497A (zh) * | 2012-12-11 | 2014-06-18 | 中国电信股份有限公司 | 用于调度信息的方法、装置和系统 |
| CN103944940A (zh) * | 2013-01-21 | 2014-07-23 | 华耀(中国)科技有限公司 | 动态配置代理服务器的设备及方法 |
| CN103246592A (zh) * | 2013-05-13 | 2013-08-14 | 北京搜狐新媒体信息技术有限公司 | 一种监控采集系统及方法 |
| US20150106523A1 (en) * | 2013-10-15 | 2015-04-16 | Vmware, Inc. | Distributed global load-balancing system for software-defined data centers |
| CN104111874A (zh) * | 2014-02-13 | 2014-10-22 | 西安未来国际信息股份有限公司 | 一种云计算环境中虚拟主机的高并发高可靠负载均衡软件架构设计 |
| CN106713375A (zh) * | 2015-07-21 | 2017-05-24 | 中国移动通信集团重庆有限公司 | 云资源的调配方法及装置 |
| CN107026877A (zh) * | 2016-01-29 | 2017-08-08 | 华为技术有限公司 | 云平台中管理资源的方法和装置 |
| CN106797405A (zh) * | 2016-12-14 | 2017-05-31 | 华为技术有限公司 | 分布式负载均衡系统、健康检查方法和服务节点 |
| CN107317889A (zh) * | 2017-08-21 | 2017-11-03 | 深圳市视维科技股份有限公司 | 一种智能dns调度系统及调度方法 |
Non-Patent Citations (1)
| Title |
|---|
| 郭政慧: "一种基于健康度的负载均衡算法在图书馆多媒体中的应用", 《现代图书情报技术》 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110941535A (zh) * | 2019-11-22 | 2020-03-31 | 山东超越数控电子股份有限公司 | 一种硬盘负载均衡方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Kaur et al. | A systematic study of load balancing approaches in the fog computing environment | |
| Peng et al. | Random task scheduling scheme based on reinforcement learning in cloud computing | |
| Lu et al. | Join-idle-queue: A novel load balancing algorithm for dynamically scalable web services | |
| CN107450982B (zh) | 一种基于系统状态的任务调度方法 | |
| Al-Khafajiy et al. | Fog computing framework for internet of things applications | |
| CN110308995A (zh) | 一种边缘云计算服务系统边缘云节点部署装置 | |
| CN102299959A (zh) | 一种数据库集群系统的负载均衡实现方法和装置 | |
| CN109600798A (zh) | 一种网络切片中多域资源分配方法及装置 | |
| CN111353663A (zh) | 任务分配方法、装置、设备及其存储介质 | |
| Dreibholz et al. | Towards a lightweight task scheduling framework for cloud and edge platform | |
| CN104378412A (zh) | 云环境下意识到用户周期性资源需求的动态负载均衡方法 | |
| Khoshkholghi et al. | Edge intelligence for service function chain deployment in NFV-enabled networks | |
| CN107197039B (zh) | 一种基于cdn的paas平台服务包分发方法及系统 | |
| Rathod et al. | Scalability of M/M/c queue based cloud-fog distributed internet of things middleware | |
| Chunlin et al. | Efficient load-balancing aware cloud resource scheduling for mobile user | |
| CN109936592A (zh) | 服务处理的方法、装置、电子设备和存储介质 | |
| Kundroo et al. | Node-based horizontal pod autoscaler in kubeedge-based edge computing infrastructure | |
| Eswaran et al. | Multiservice load balancing with hybrid particle swarm optimization in cloud-based multimedia storage system with QoS provision | |
| Kadhim et al. | Hybrid load-balancing algorithm for distributed fog computing in internet of things environment | |
| N. Toosi et al. | GreenFog: A framework for sustainable fog computing | |
| US10691700B1 (en) | Table replica allocation in a replicated storage system | |
| CN110727511B (zh) | 应用程序的控制方法、网络侧设备和计算机可读存储介质 | |
| Badidi et al. | A queuing model for service selection of multi-classes QoS-aware web services | |
| CN109413117A (zh) | 分布式数据计算方法、装置、服务器及计算机存储介质 | |
| CN113613261B (zh) | 基于合作队列博弈的边缘计算网络中的任务卸载分配方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190625 |
|
| RJ01 | Rejection of invention patent application after publication |