CN111475278B - 一种基于意向链驱动的弹性调度方法、装置及电子设备 - Google Patents

Abstract

本发明提供了一种基于意向链驱动实现的弹性调度方法，所述方法适用于多层云服务系统，其中，相邻两个层之间存在依赖关系，包括以下步骤：S101、依赖方和被依赖方协商提出基于自身需求的意向，其中，所述意向为表达业务需求的形式，通过所述意向细节来约束所述需求；S102、所述依赖方向被依赖方发送所述意向；S103、所述被依赖方基于所述意向和自身能力执行弹性调度；S104、所述被依赖方判断是否为最终依赖方，若是，则终止向下提交意向并基于所述意向和自身能力执行弹性调度；否则，作为新的依赖方回到步骤S101。本发明的技术方案提高了云服务系统用户的体验。

Description

一种基于意向链驱动的弹性调度方法、装置及电子设备

技术领域

本发明涉及云计算技术领域，具体涉及一种基于意向链驱动的弹性调度方法、装置及电子设备。

背景技术

DLA(Data Lake Analytics,)是一款新的阿里云数据计算分析型产品。为用户提供Serverless化的云上交互式查询分析服务。无需ETL，就可通过此服务在云上通过标准SQL直接对阿里云OSS、TableStore中的数据轻松进行查询和分析，以及无缝集成商业分析工具和应用程序。

在传统的数据库系统设计中，在一段时间内如果没有做扩缩容，整体物理资源是相对固定的，因而在这期间用户的SQL执行之间，在资源上有很多竞争的，因而如果希望大部分SQL执行质量较好，整体吞吐量大、资源利用率高、延时较小，通常需要分两部分的工作：1)Server端做大量的资源性能实时采集、资源切分、多级优先排队队列、组合调度策略等等，尽可能的平衡整体吞吐、资源利用率和单SQL的执行性能等因素；2)Client端更关心单SQL的执行性能，因此需要实时采集服务器端的各种资源水位，试图拟合出服务器端整体的性能走势，从而主动的在客户端形成一定程度的调度策略，尽可能的确保SQL在合适的时候、以较为充足的资源情况下执行。

在OLAP+大数据+千差万别的业务场景下，试图预估服务器整体性能趋势，变得越来越难，代价也越来越高，因而只能留有非常冗余的计算力，这造成了资源浪费。另一方面，传统数据库资源固定后，整体成本是相对固定的，因而每个SQL随着调用并发度越高而平均成本越低，但过高的并发度导致单个SQL的平均响应时间越长，整体服务质量下降。但从单个SQL来说，调用者除了减少调用之外对此无能为力，这显然又违背了其业务意愿。但传统数据库很难让用户为其每个SQL在性能和价格开销上主动做平衡选择，因此，SLA很难保证。

在新型的基于弹性计算而架构的云数据库系统中，资源的快速扩缩容是其基本的物理能力，因而基于此能力，是有机会实现比固定资源节约成本的数据库。但如果Server端完全按照SQL请求队列实时做快速扩缩容，整体的成本又是比固定资源模式大很多的，且很多时候也没必要，尤其在OLAP、adhoc场景下对时间的要求是有弹性的。基于弹性计算的数据对于SQL请求量的预估能力，则因价格不定较传统数据库更弱。同时，在云时代的到来，面对DLA这种无服务器化、支持大量异构数据源接入、完全面向云基础的数据库系统，用户侧的系统更加难以实时监控、准确拟合服务端的性能趋势，也就无法很好的预估SQL执行性能；而且成千上万、形形色色的企业用户、个人用户接入进来，因难以预测而越发加剧了上述的情况。

[术语解释]

Serverless：无服务器化，云计算平台上，用户无需感知服务器或者服务实例，只需感知云服务提供的服务本身；

云数据库：云计算平台上提供的数据库服务；

SQL：数据库的查询语言；

优化器：数据库查询语言执行计划的生成与优化选择模块；

OLAP：联机分析处理；

adhoc：点对点模式；

OSS：对象存储；

OTS：开放结构化数据服务；

ETL：数据仓库技术；

TableStore：表格存储；

RDS：关系型数据库服务；

SLA：服务等级协议；

API：应用程序接口。

发明内容

本发明的一个目的是提供一种基于意向链驱动实现的弹性调度方法，在一定程度上解决上述用户遇到的问题，让用户和业务更适应于云时代的到来。

为了达到上述目的，本发明的实施例提供了一种基于意向链驱动实现的弹性调度方法，所述方法适用于多层云服务系统，其中，相邻两个层之间存在依赖关系，所述方法包括以下步骤：

S101、依赖方和被依赖方协商提出基于自身需求的意向，其中，所述意向为表达业务需求的形式，通过所述意向细节来约束所述需求；

S102、所述依赖方向被依赖方发送所述意向；

S103、所述被依赖方基于所述意向和自身能力执行弹性调度；

S104、所述被依赖方判断是否为最终依赖方，若是，则终止向下提交意向并基于所述意向和自身能力执行弹性调度；否则，作为新的依赖方回到步骤S101。

进一步地，所述执行弹性调度，具体为：根据所述意向，结合自身的服务能力和弹性场景，从而针对性的进行弹性调度，尽可能的满足用户的意向需求；其中，弹性场景包括扩缩容能力，弹性调度包括做扩容或者缩容执行。

进一步地，步骤S101中，所述依赖方从自身的需求出发，除了发起核心调用外，还对被依赖方提出了具体的意向。

进一步地，所述意向为规划函数集模型，或者所述意向为SQL条件。

进一步地，所述约束包括必须满足的约束、尽量满足的约束。

进一步地，所述意向与核心调用之间存在以下关系：意向是为了辅佐核心调用能够更好的完成，尽可能满足用户的需求的情况下完成；意向不影响核心调用的执行和语义的正确性。

一种基于意向链驱动实现的弹性调度方法，所述方法适用于多层云服务系统，相邻两个层之间存在依赖关系，所述方法包括以下步骤：

步骤S201、用户层基于自身的需求提出第一意向，所述意向是一种表达业务需求的形式，通过意向细节来约束一次需求；

步骤S202，用户层向服务层发起核心请求和第一意向；

步骤S203，服务层基于所述第一意向和自身能力执行弹性调度；

步骤S204，服务层基于自身需求提出第二意向，并提交给下一层；

步骤S205，下一层判断是否为最底层，若否，则执行步骤S206；若是，则执行步骤S207；

步骤S206，下一层基于所述第二意向和自身能力执行弹性调度，并基于自身需求生成第三意向，并向下提交，然后，回到步骤S205；

步骤S207，下一层终止向下提交意向并基于所述意向和自身能力执行弹性调度。

进一步地，所述执行弹性调度，具体为：根据所述意向，结合自身的服务能力和弹性场景，从而针对性的进行弹性调度，尽可能的满足用户的意向需求；其中，弹性场景包括扩缩容能力，弹性调度包括做扩容或者缩容执行。

进一步地，所述意向为规划函数集模型，或者所述意向为SQL条件。

进一步地，所述约束包括必须满足的约束、尽量满足的约束。

进一步地，所述意向与核心调用之间存在以下关系：意向是为了辅佐核心调用能够更好的完成，尽可能满足用户的需求的情况下完成；意向不影响核心调用的执行和语义的正确性。进一步地，所述云平台为基于FPGA的异构计算平台。

本发明实施例还提供了一种基于意向链驱动实现的弹性调度装置，所述装置应用于多层云服务系统，相邻两个层之间存在依赖关系，所述装置包括如下模块：

生成模块，用于依赖方和被依赖方协商提出基于核心需求的意向；其中，意向是一种表达业务需求的形式，通过意向细节来约束一次需求；

发送模块，用于依赖方向被依赖发送所述意向；

调度模块，用于被依赖方基于所述意向和自身能力执行弹性调度；

判断模块，用于判断是否为最终依赖方，若是，则终止向下提交意向，并触发本层的调度模块；否则，作为新的依赖方触发本层的意向生成模块。

本发明实施例还提供了一种基于意向链驱动实现的弹性调度装置，所述装置应用于多层云服务系统，相邻两个层之间存在依赖关系，所述装置包括如下模块：

第一意向生成模块，位于用户层，用于基于自身的需求提出第一意向，所述意向是一种表达业务需求的形式，通过意向细节来约束一次需求；

第一发送模块，位于用户层，用于向服务层发起核心请求和第一意向；

第一调度模块，位于服务层，用于基于所述第一意向和自身能力执行弹性调度；

第二意向生成模块，位于服务层，用于基于自身需求提出第二意向；

第二发送模块，位于服务层，用于将第二意向向下提交；

判断模块，位于下一层，用于判断是否为最底层，若否，则触发第二调度模块和第三意向生成模块；若是，则触发第二调度模块；

第二调度模块，位于下一层，用于基于所述第二意向和自身能力执行弹性调度；

第三意向生成模块，位于下一层，用于基于自身需求生成第三意向；

第三发送模块，用于将第三意向向下提交。

本发明实施例还提供了一种电子设备，所述设备包括：

存储装置；

一个或多个处理器；

其中，存储装置用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现前述的基于意向链驱动实现的弹性调度方法。

本发明实施例还提供了一种计算机程序产品，包括计算机程序指令，当所述指令由处理器执行时，用于实现前述的基于意向链驱动实现的弹性调度方法。

本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序被执行时，实现前述的基于意向链驱动实现的弹性调度方法。

本发明实施例还提供了一种云服务系统，所述系统包括前述的基于意向链驱动实现的弹性调度装置。

与现有技术相比，本发明出意向的概念，由“硬性决策”改成“柔性意向”，因此服务端可以大量暴露内部可用的指标，且由客户端选择相关的意向来“辅助”当前请求，且服务端可以跟进意向约束和自身的状态、性能条件、价格因素等，尽可能去满足意向，从而尽可能的完成请求而不是报错。从用户侧提出的SQL请求以及其对应的意向约束条件，最终会一步步地往更底层、更基础的服务渗透需求，形成新的请求和意向约束条件，最终从端到端的形成了整个请求链+意向链。意向链包含了客户端对当前请求的意向，意向因人而异，因客户端的需求而异，具有很强的弹性，因而每个层次服务端，可以自行根据自身的压力情况、稳定性情况、用户的价格和性能需求、总体排队的量，以及它的下一层服务端的服务情况来弹性调度、扩缩容、限流等执行。

附图说明

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

图1为DLA的计算服务集群架构示意图。

图2为端到端的服务依赖示意图。

图3为本发明的用户与DLA之间基于意向的弹性调度执行过程示意图。

图4为本发明的DLA与底层数据源之间基于意向的调度执行过程示意图。

图5为本发明的基于意向链驱动的弹性调度执行过程示意图。

图6为本发明实施例一的方法流程图。

图7为本发明实施例二的方法流程图。

图8为本发明实施例三的装置的框图。

图9为本发明实施例四的装置的框图。

具体实施方式

为了便于本领域普通技术人员理解和实施本发明，下面结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为DLA的计算服务集群架构示意图。节点角色包括Frontnode和Computenode。多个Frontnode挂载在SLB负载均衡设备后，实现请求处理的负载均衡。多个Frontnode对等服务，形成Frontnode Pool。Frontnode节点接收Query查询请求，进行Query解析、执行计划生成与优化。分布式执行计划生成后，被分发和调度到多个Computenode计算节点进行执行。多个Computenode组成计算集群的Computenode Pool。整个架构采用存储、计算分离的架构，计算节点Computenode从数据源Data Source读取数据。

图2是端到端的服务依赖示意图。用户从提交一个SQL给DLA；DLA在内部做解析、执行等过程，再将相应的资源请求提交给底层的数据源；底层数据源在内部也会有关键链路上的依赖，并将它们的资源请求提交给更底层的服务；以此类推。总之，相邻两个层之间有依赖关系，并且相互之间有各自的API，一层层地下推资源请求。

图3是用户与DLA之间基于意向的弹性调度执行过程示意图。对于相同的SQL、相同的数据集，但是用户请求时的意向不一样，例如，有些服务于偏在线实时业务、有些服务于偏离线分析的业务，DLA的服务端根据用户的意向，结合本身的服务能力和弹性场景(如扩缩容能力)，从而针对性的进行弹性调度(如做扩容expansion或者缩容shrink执行)，尽可能的满足用户的意向需求。

其中，意向(intention)是一种表达业务需求的形式，通过意向细节来约束一次需求本身。本发明将原本由客户端来强制指定、必须要满足的调用相关的参数条件，改成柔性的意向组合，由服务器端来自主判断、尽可能去满足，类似这种形式的，都可以归为意向。

图4是DLA与底层数据源之间基于意向的调度执行过程示意图。DLA请求OTS时，OTS基于意向并结合自身状态，对表数据做分区(partition)，分区的大小因意向和服务端的能力而柔性决定。

在OLAP领域中存储与计算分离架构下，很多SQL都是需要高并发、大吞吐的拖取底层数据源的数据，然后汇总到上层计算层中参与计算。一般在DLA中的表，都会对应底层数据源中的一大块数据区，比如OSS中可能是一个超大的文件，或者超多的子目录和子文件，比如TableStore和RDS中就是一些超大的表。通常因为底层数据源的表数据太大，串行查询显然不可取，需要做partition然后并行查询。如果切分数太少，则并发度很低，计算很慢；但切分过细又导致上层的调度任务太多，从而导致上层计算性能问题。另外，任务太多也会给TableStore带来非常大的并发压力，会导致TableStore拒绝服务等问题。传统的固定分片大小或者固定分片数目，都太过简单和静态，不能最佳的反映和匹配客户端的需求以及服务端的能力。因此DLA侧通过提交客户端的意向(其中继承与融合了最顶端用户的SQL需求)，TableStore服务端分析自身的服务能力，尽可能的满足DLA的意向来实现partition并提供给DLA做计算。

图5是本发明的基于意向链驱动的弹性调度执行过程示意图。其中，意向链是从端到端不同层次之间的意向层层推进后形成的完整链条，不断的由用户侧向系统侧演化和深入。本发明的意向链驱动弹性调度是基于意向链来驱动调度，从端到端一层层的下推意向，同时一层层的基于意向规划的需求，来调度资源参与计算，最终满足意向中表达的需求。

从图2中可知，不同层次之间有依赖，依赖方通过被依赖方提供的标准API，来调用被依赖方的服务和资源等，从而完成相应的业务逻辑。如前面背景介绍中所说，传统数据库领域里，依赖方很难精确的预测和判断服务端实时的服务能力、服务压力等，依赖端很难确保其SQL一定是满足自身需求而执行的；到了以无服务器化、弹性调度而设计和实现的云数据库领域，这个问题则更为明显。

因此，本发明提出一个新的思路：不同层次的依赖方和被依赖方，由协商形式提出一个基于核心需求出发的执行意向模型，依赖方从自身的需求出发，除了发起核心的请求外，还对被依赖方提出了具体的意向要求，而不再需要主动去监控、探测、预测服务端的服务能力。比如用户和DLA之间，可以提出以下意向模型：

QueryTime<＝100ms,required；Cost<＝10$,optional。

上述意向模型的解释如下：用户希望他的SQL执行时间必须不超过100ms，执行成本尽可能不超过10美金。

意向是灵活的、可协商的，根据不同层次的需求和实现能力而来。服务端自身有足够多的信息和机制，来判断和预测自身的性能水位，在执行计划上如何满足用户意向中的条件和约束。比如用户的SQL提交给DLA，DLA中通过生成执行计划，可以预估DLA内部的执行能力，需要为用户当前的意向申请和保留多少资源，对于DLA自身的依赖(比如OSS、TableStore、RDS等)，同样提出了自身的意向需求，进一步提交给下一层次的被依赖方，寄希望于他们在资源、调度、执行上以意向为基准来完成请求。而这些被依赖方，也可以作为新的依赖方发起他们的意向需求，或者作为最终依赖方而终止向下提交意向，不同层次之间的意向具有渗透性，形成了意向链来驱动整个执行过程中的弹性资源、弹性调度等过程。

用户意向的表达方式有很多，并不局限于规划函数集模型，也可以是其他形式，如SQL条件。关键在于是依赖方主动向被依赖方提出了执行意向(比如成本、性能或其他)。并且意向是灵活的，要依据被依赖方的能力而真正落地，这些意向中有些必须满足(required)，有些尽量满足(optional)，或者其他形式的约束，因此被依赖方尽可能去满足用户的执行意向，但也可能无法满足意向。意向的最初产生，可以是依赖方和被依赖方相互协商形成，并最终形成通用标准，然后被更多的依赖方来使用，提出意向。

意向与核心调用之间存在以下关系：意向是为了辅佐核心调用能够更好的完成，尽可能满足用户的需求的情况下完成；意向可有可无，并不影响核心调用的执行和语义的正确性。

实施例一

参阅图6，本发明实施例一提供一种基于意向链驱动实现的弹性调度方法，所述方法适用于多层云服务系统，相邻两个层之间存在依赖关系，所述方法包括以下步骤：

步骤S101、依赖方和被依赖方协商提出基于核心需求的意向。

该步骤中，所述依赖方从自身的需求出发，除了发起核心请求外，还对被依赖方提出了具体的意向。意向是一种表达业务需求的形式，通过意向细节来约束一次需求。

步骤S102，依赖方向被依赖方发送所述意向。

步骤S103，被依赖方基于所述意向和自身能力执行弹性调度。

步骤S104，被依赖方判断是否为最终依赖方，若是，则终止向下提交意向并基于所述意向和自身能力执行弹性调度；否则，作为新的依赖方执行步骤S101。

实施例二

参阅图7，本发明实施例二提供了一种基于意向链驱动实现的弹性调度方法，所述方法适用于多层云服务系统，相邻两个层之间存在依赖关系，所述方法包括以下步骤：

步骤S201、用户层基于自身的需求提出第一意向，所述意向是一种表达业务需求的形式，通过意向细节来约束一次需求。

步骤S202，用户层向服务层发起核心请求和第一意向。

步骤S203，服务层基于所述第一意向和自身能力执行弹性调度。

步骤S204，服务层基于自身需求提出第二意向，并提交给下一层。

步骤S205，下一层判断是否为最底层，若否，则执行步骤S206；若是，则执行步骤S207。

步骤S206，下一层基于所述第二意向和自身能力执行弹性调度，并基于自身需求生成第三意向，并向下提交，然后，回到步骤S205。

步骤S207，下一层终止向下提交意向并基于所述意向和自身能力执行弹性调度。

实施例三

参阅图8，本发明实施例三提供了一种基于意向链驱动实现的弹性调度装置，所述装置应用于多层云服务系统，相邻两个层之间存在依赖关系，所述装置包括如下模块：

生成模块301，用于依赖方和被依赖方协商提出基于核心需求的意向。其中，意向是一种表达业务需求的形式，通过意向细节来约束一次需求。

发送模块302，用于依赖方向被依赖发送所述意向。

调度模块303，用于被依赖方基于所述意向和自身能力执行弹性调度。

判断模块304，用于判断是否为最终依赖方，若是，则终止向下提交意向，并触发本层的调度模块302；否则，作为新的依赖方触发本层的意向生成模块301。

实施例四

参阅图9，本发明实施例四提供了一种基于意向链驱动实现的弹性调度装置，所述装置应用于多层云服务系统，相邻两个层之间存在依赖关系，所述装置包括如下模块：

第一意向生成模块401，位于用户层，用于基于自身的需求提出第一意向，所述意向是一种表达业务需求的形式，通过意向细节来约束一次需求。

第一发送模块402，位于用户层，用于向服务层发起核心请求和第一意向。

第一调度模块403，位于服务层，用于基于所述第一意向和自身能力执行弹性调度。

第二意向生成模块404，位于服务层，用于基于自身需求提出第二意向。

第二发送模块405，位于服务层，用于将第二意向向下提交。

判断模块406，位于下一层，用于判断是否为最底层，若否，则触发第二调度模块407和第三意向生成模块408；若是，则触发第二调度模块407。

第二调度模块407，位于下一层，用于基于所述第二意向和自身能力执行弹性调度。

第三意向生成模块408，位于下一层，用于基于自身需求生成第三意向。

第三发送模块409，用于将第三意向向下提交。

所属领域的技术人员可以清楚的了解到，为了描述的方便和简洁，上述描述的装置、模块和单元的具体工作过程，可以参考前述方法实施例的对应过程，在此不再赘述。

另外，本发明实施例还公开了一种电子设备，其包括存储装置和一个或多个处理器，存储装置用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如实施例一至二的方法。

本发明实施例还公开了一种计算机程序产品，包括计算机程序指令，当指令由处理器执行时，用于实现如实施例一至二的方法。

本发明实施例还公开了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序被执行时，实现如实施例一至二的方法。

本发明实施例还公开了一种云服务系统，所述系统包括实施例三或四的的基于意向链驱动实现的弹性调度装置。

附图中的流程图和框图显示了根据本发明的多个实施例的方法、装置和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图和框图中的每个方框可以代表一个模块、程序段或代码的一部分，包含一个或多个用于实现逻辑功能的计算机可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。也要注意的是，框图和流程图中的每个方框或方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

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

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明，上述实施例仅是为说明所作的举例，而并非对实施方式的限定。对于本领域技术人员来说，在上述说明的基础上，还可以做出其它不同形式的变化或变动，而这些变化或变动将是显而易见的，处于本发明的保护范围之中。

Claims (16)

1.一种基于意向链驱动实现的弹性调度方法，所述方法适用于多层云服务系统，其中，相邻两个层之间存在依赖关系，其特征在于，所述方法包括以下步骤：

S101、依赖方和被依赖方协商提出基于自身需求的意向，其中，所述意向为表达业务需求的形式，通过所述意向的细节来约束所述需求；

S102、所述依赖方向被依赖方发送所述意向；

S103、所述被依赖方基于所述意向和自身能力执行弹性调度；

S104、所述被依赖方判断是否为最终依赖方，若是，则终止向下提交意向并基于所述意向和自身能力执行弹性调度；否则，作为新的依赖方回到步骤S101。

2.如权利要求1所述的方法，其特征在于，所述执行弹性调度，具体为：根据所述意向，结合自身的服务能力和弹性场景，从而针对性的进行弹性调度，尽可能的满足用户的意向需求；其中，弹性场景包括扩缩容能力，弹性调度包括做扩容或者缩容执行。

3.如权利要求1所述的方法，其特征在于，步骤S101中，所述依赖方从自身的需求出发，除了发起核心调用外，还对被依赖方提出了具体的意向。

4.如权利要求1所述的方法，其特征在于，所述意向为规划函数集模型，或者所述意向为SQL条件。

5.如权利要求1所述的方法，其特征在于，所述约束包括必须满足的约束、尽量满足的约束。

6.如权利要求1所述的方法，其特征在于，所述意向与核心调用之间存在以下关系：意向是为了辅佐核心调用能够更好的完成，尽可能满足用户的需求的情况下完成；意向不影响核心调用的执行和语义的正确性。

7.一种基于意向链驱动实现的弹性调度方法，所述方法适用于多层云服务系统，其中，相邻两个层之间存在依赖关系，其特征在于，所述方法包括以下步骤：

步骤S201、用户层基于自身的需求提出第一意向，所述意向是一种表达业务需求的形式，通过意向细节来约束一次需求；

步骤S202，用户层向服务层发起核心请求和第一意向；

步骤S203，服务层基于所述第一意向和自身能力执行弹性调度；

步骤S204，服务层基于自身需求提出第二意向，并提交给下一层；

步骤S205，下一层判断是否为最底层，若否，则执行步骤S206；若是，则执行步骤S207；

步骤S206，下一层基于所述第二意向和自身能力执行弹性调度，并基于自身需求生成第三意向，并向下提交，然后，回到步骤S205；

步骤S207，下一层终止向下提交意向并基于所述意向和自身能力执行弹性调度。

8.如权利要求7所述的方法，其特征在于，所述执行弹性调度，具体为：根据所述意向，结合自身的服务能力和弹性场景，从而针对性的进行弹性调度，尽可能的满足用户的意向需求；其中，弹性场景包括扩缩容能力，弹性调度包括做扩容或者缩容执行。

9.如权利要求7所述的方法，其特征在于，所述意向为规划函数集模型，或者所述意向为SQL条件。

10.如权利要求7所述的方法，其特征在于，所述约束包括必须满足的约束、尽量满足的约束。

11.如权利要求7所述的方法，其特征在于，所述意向与核心调用之间存在以下关系：意向是为了辅佐核心调用能够更好的完成，尽可能满足用户的需求的情况下完成；意向不影响核心调用的执行和语义的正确性。

12.一种基于意向链驱动实现的弹性调度装置，所述装置应用于多层云服务系统，相邻两个层之间存在依赖关系，其特征在于，所述装置包括如下模块：

生成模块，用于依赖方和被依赖方协商提出基于核心需求的意向；其中，意向是一种表达业务需求的形式，通过意向细节来约束一次需求；

发送模块，用于依赖方向被依赖发送所述意向；

调度模块，用于被依赖方基于所述意向和自身能力执行弹性调度；

判断模块，用于判断是否为最终依赖方，若是，则终止向下提交意向，并触发本层的调度模块；否则，作为新的依赖方触发本层的意向生成模块。

13.一种基于意向链驱动实现的弹性调度装置，所述装置应用于多层云服务系统，相邻两个层之间存在依赖关系，其特征在于，所述装置包括如下模块：

第一意向生成模块，位于用户层，用于基于自身的需求提出第一意向，所述意向是一种表达业务需求的形式，通过意向细节来约束一次需求；

第一发送模块，位于用户层，用于向服务层发起核心请求和第一意向；

第一调度模块，位于服务层，用于基于所述第一意向和自身能力执行弹性调度；

第二意向生成模块，位于服务层，用于基于自身需求提出第二意向；

第二发送模块，位于服务层，用于将第二意向向下提交；

判断模块，位于下一层，用于判断是否为最底层，若否，则触发第二调度模块和第三意向生成模块；若是，则触发第二调度模块；

第二调度模块，位于下一层，用于基于所述第二意向和自身能力执行弹性调度；

第三意向生成模块，位于下一层，用于基于自身需求生成第三意向；

第三发送模块，用于将第三意向向下提交。

14.一种电子设备，其特征在于，所述设备包括：

存储装置；

一个或多个处理器；

其中，存储装置用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1-11中任一项所述的基于意向链驱动实现的弹性调度方法。

15.一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序被执行时，实现如权利要求1-11中任一项所述的基于意向链驱动实现的弹性调度方法。

16.一种云服务系统，其特征在于，所述系统包括如权利要求12或13所述的基于意向链驱动实现的弹性调度装置。

Images