用于电网数据中台服务的弹性资源调度方法和系统

技术领域

本申请涉及计算机系统领域，具体涉及一种用于电网数据中台服务的弹性资源调度方法和系统。

背景技术

电网的数据中台电网的数据中台包含的业务非常多。不同服务间包含着隐式的调用。一个请求调用各个服务所形成的请求路径，i可以形成一个有向无环图(DAG)。传统弹性资源调度是检测到一个服务处于高峰期，便会为其分配更多的资源。但是电网数据中台中的服务间会有很多隐式的依赖关系，简单粗暴地为某个服务扩容会造成不必要的浪费且资源分配不够精准。

发明内容

为解决上述问题，本申请提供一种用于电网数据中台服务的弹性资源调度方法，包括：

获取电网数据中台服务的请求日志；

解析所述请求日志，获取服务的请求路径；

通过所述请求路径，获取各个服务之间的调用关系；

根据服务器剩余资源和所述调用关系，在满足服务的基础每秒查询率条件下，为所述服务分配弹性资源。

优选的，解析所述请求日志，获取服务的请求路径，包括：

通过广度优先搜索算法BFS解析所述请求日志，获取每条请求调用各个服务所形成的请求路径；及所述请求路径包含的各个节点；

使用字符标识所述各个节点；

将每条路径经过的节点组成字符串；

使用所述字符串标识所述服务的请求路径。

优选的，还包括：

获取每个节点被访问的次数和请求路径被访问的次数。

优选的，通过所述请求路径，获取各个服务之间的调用关系，包括：

根据所述请求路径，获取各个服务之间的相交的节点；

通过所述相交的节点，获取各个服务之间的调用关系。

优选的，根据所述资源占用情况和调用关系，在满足服务的基础每秒查询率QPS条件下，为服务分配弹性资源，包括：

当服务器剩余资源充足时，计算服务器剩余资源和可回收的资源；

回收服务器过剩的服务资源；

为每个待分配资源的服务的节点，及与所述待分配资源的服务存在调用关系的服务的节点，分配过剩的服务资源，所述过剩的服务资源大于或等于其节点的基础每秒查询率QPS的一半所需的服务资源；

当服务器剩余资源不足时，对低峰期服务的资源进行回收；

计算高峰期服务需要资源占总高峰期服务需要资源的比例；

获取待分配的高峰期服务的请求路径的节点数，根据所述节点数需求的机器数占总需求机器数的比例，分配剩余的资源。

本申请同时提供一种用于电网数据中台服务的弹性资源调度系统，包括：

请求日志获取模块，用于获取电网数据中台服务的请求日志；

请求路径获取模块，用于解析所述请求日志，获取服务的请求路径；

调用关系获取模块，用于通过所述请求路径，获取各个服务之间的调用关系；

资源分配模块，用于根据服务器剩余资源和所述调用关系，在满足服务的基础每秒查询率条件下，为所述服务分配弹性资源。

优选的，请求日志获取模块，包括：

解析子模块，用于通过广度优先搜索算法BFS解析所述请求日志，获取每条请求调用各个服务所形成的请求路径；及所述请求路径包含的各个节点；

标识子模块，用于使用字符标识所述各个节点；

字符串组成子模块，用于将每条路径经过的节点组成字符串；

标识子单元，用于使用所述字符串标识所述服务的请求路径。

优选的，还包括：

访问次数获取子模块，用于获取每个节点被访问的次数和请求路径被访问的次数。

优选的，调用关系获取模块，包括：

相交节点获取子模块，用于根据所述请求路径，获取各个服务之间的相交的节点；

调用关系获取子模块，用于通过所述相交的节点，获取各个服务之间的调用关系。

优选的，资源分配模块，包括：

第一资源计算子模块，用于当服务器剩余资源充足时，计算服务器剩余资源和可回收的资源；

第一回收子模块，用于回收服务器过剩的服务资源；

第一资源分配子模块，用于为每个待分配资源的服务的节点，及与所述待分配资源的服务存在调用关系的服务的节点，分配过剩的服务资源，所述过剩的服务资源大于或等于其节点的基础每秒查询率QPS的一半所需的服务资源；

第二回收子模块，用于当服务器剩余资源不足时，对低峰期服务的资源进行回收；

比例计算子模块，用于计算高峰期服务需要资源占总高峰期服务需要资源的比例；

第二资源分配子模块，用于获取待分配的高峰期服务的请求路径的节点数，根据所述节点数需求的机器数占总需求机器数的比例，分配剩余的资源。

附图说明

图1是本申请提供的一种用于电网数据中台服务的弹性资源调度方法的流程示意图；

图2是本申请涉及的弹性资源调度方法简化流程图；

图3是本申请涉及的日志采集示意图；

图4是本申请涉及的请求路径转换为唯一标识的流程图；

图5是本申请涉及的资源不足时的服务分类；

图6是本申请涉及的实验服务调用示意图；

图7是本申请涉及的电网数据中台服务的弹性资源调度方法的应用流程图；

图8是本申请提供的一种用于电网数据中台服务的弹性资源调度系统的结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

图1是本申请提供一种用于电网数据中台服务的弹性资源调度方法的流程示意图，所述方法包括如下步骤：

步骤S101，获取电网数据中台服务的请求日志。

本申请提供的用于电网数据中台服务的弹性资源调度方法，基于实时日志解析对弹性资源进行分配，该方法通过日志解析来获得服务之间的调用关系来进行弹性资源分配。其方法简化流程图如图2所示，包括：

1)日志采集。

2)日志解析。

3)弹性资源分配。

为了提高日志采集和日志的效率，采用Redis集群来存储日志，日志解析也是通过Redis集群来获得日志详情。日志过期了，系统会将其从Redis集群中取出，封装成文件存储到HDFS集群中。

日志采集是日志采集的基础。为了能反映出服务间的依赖关系，本文采用 Redis来记录日志。每个请求包含一个唯一的RequestID，该请求的日志会被记录到Redis中，并用该RequestID来标识。请求路径上的所有节点都将日志插入到key为RequestID的内容中。图3是日志采集的示例。

步骤S102，解析所述请求日志，获取服务的请求路径。

通过广度优先搜索算法BFS解析所述请求日志，获取每条请求调用各个服务所形成的请求路径；及所述请求路径包含的各个节点；使用字符标识所述各个节点；将每条路径经过的节点组成字符串；使用所述字符串标识所述服务的请求路径。以及，获取每个节点被访问的次数和请求路径被访问的次数。

日志解析是弹性资源分配的依据。弹性资源分配是为请求路径上所有节点进行资源分配。为了区分不同的请求路径，本文采用BFS算法来请求日志进行解析，每个请求路径都会形成一个DAG(有向无环图)。如图4所示，日志的请求路径中包含4个节点，分别是A、B、C、D。A节点分别访问了B、C，B 和C节点分分别访问了D节点，D节点是请求路径的终点。解析完请求会将 DAG存储为字符串的形式，该字符串是唯一的，用于标识请求路径。如图右部分所示，括号内是子节点列表，按照字符顺序排序，节点与节点用“；”隔开。

日志解析的流程分以下几个步骤：

1、采用BFS算法解析请求日志，并按照字母排序节点记录成唯一的标识。

2、记录唯一标识的访问次数。

3、分别记录每个节点的被访问的次数。

步骤S103，通过所述请求路径，获取各个服务之间的调用关系；

根据所述请求路径，获取各个服务之间的相交的节点；通过所述相交的节点，获取各个服务之间的调用关系。

步骤S104，根据服务器剩余资源和所述调用关系，在满足服务的基础每秒查询率条件下，为所述服务分配弹性资源。

弹性资源调度分为两种情况，分别是资源充足时的弹性资源分配和资源不足时的弹性资源分配。另外说明一下，服务上线时，测试每个节点最大可承受的QPS(每秒查询率)，称为服务的基础QPS。

当服务器剩余资源充足时，计算服务器剩余资源和可回收的资源；回收服务器过剩的服务资源；为每个待分配资源的服务的节点，及与所述待分配资源的服务存在调用关系的服务的节点，分配过剩的服务资源，所述过剩的服务资源大于或等于其节点的基础每秒查询率QPS的一半所需的服务资源；

当服务器剩余资源不足时，对低峰期服务的资源进行回收；计算高峰期服务需要资源占总高峰期服务需要资源的比例；获取待分配的高峰期服务的请求路径的节点数，根据所述节点数需求的机器数占总需求机器数的比例，分配剩余的资源。例如，回收的低峰期服务的资源有50台服务器，当前剩余资源的 50台服务器，共有剩余资源100台服务器，现在有A、B、C，三个服务需要分配资源。根据服务的节点数据，确定A需要300台机器、B需要150台、C 需要150台，现有的100台服务器肯定不能满足三个服务对服务器的需求，所以，根据三个服务对服务器的需求比是2:1:1，分配剩余资源，那么A被分配了50台，B被分配了25台，C被分配了25台。

具体分配方法是，资源充足时，会给每个服务分配两倍的服务器资源，即使服务的每个节点的平均QPS维持在服务基础QPS的一半。为了服务的稳定性，当服务的QPS约为基础QPS的80％时，系统便为该服务分配资源。服务的QPS低于基础QPS的50％时，系统会将服务的多余的资源进行回收。

资源充足时的弹性资源分配流程分为以下几个步骤：

1)计算服务剩余的服务器资源和可回收的服务器资源

2)判断资源分配是否是资源充足的情况。

3)回收服务资源过剩的服务的资源。

4)将每个需要分配资源的服务添加到分配队列中。

5)按照顺序为每个服务分配资源。

资源不足时的弹性资源分配某种程度上是没有意义的，此时应该对整个数据中心进行扩容。资源不足的情况分为两种。第一种，系统中有部分服务处于高分期和小部分服务处于低峰期。此时可以将低峰期的服务资源分配给高峰期。第二种，服务中心中的绝大多数的服务都处于高峰期。此时弹性资源分配是没有意义的。资源不足时，本文将平均QPS低于基础QPS的80％定义为低峰期服务，高峰期服务是QPS大于等于基础QPS的服务。资源不足时的服务分类如图5所示。

资源不足时的弹性资源分配分两个步骤：

1)计算服务剩余的服务顺资源和可回收的服务器资源；

2)判断资源分配是否是资源充足的情况；

3)对低峰期服务的资源回收。回收策略是，将低峰期的服务的平均QPS 维持在基础QPS的80％左右，剩余的资源进行回收。

4)计算高峰期服务的每个服务需要的资源；

5)计算每个高峰服务需要资源占总高峰期服务需要资源的比例；

6)将高峰期服务及其分配资源的比例封装成任务添加到队列中；

7)为队列中的服务进行弹性资源分配。

为验证本发明的效果，下面分两个实验进行测试。

实验一，资源充足情况下的弹性资源分配。

实验二，资源不足情况下的弹性资源分配。

实验中的服务采用Django来搭建，每个服务只包含请求和转发，中间会有一个计算模块。每个服务的计算模块的计算量不同，这样可以模拟不同的服务。实验环境是一台16G、8核、100G存储的服务器。服务器上部署版本号为1.15 的Kubernetes和版本号为1.7的Docker。实验中一共部署了10个服务，每个服务采用Kubernetes中的Service和Deployment来部署。10个服务的依赖关系如图6所示。

由图6可知，服务1、2、3是对外服务，剩下的服务都是基础服务。服务 1、4、5、8组成了一个请求路径。服务2、5、6、9组成了一个请求路径。服务3、6、7、10组成了一个请求路径。为了便于测试，本文将服务1-10的默认QPS设置为50。

实验一：

为了模拟真实服务场景，本文给服务1、2、3分别给了QPS为50的基础流量。在系统资源充足的情况下，服务1、2、3、4、7在集群中都包含两个工作节点，服务5、6、8、9、10都包含4个节点。实验对服务1的请求路径采用不同的QPS进行压测，实验记录请求路径上的服务平稳时的节点数以及服务恢复平稳的耗时。压测是在基础的流量上进行的。

表1实验一测试结果

由上表可知，对服务1所处的请求路径进行压测，服务仅耗时约2.5S便达到了稳定状态。服务1、4、5、8恢复正常状态时的节点数符合预期。因此，本所申请在资源充足情况下的调度是符合预期的。

实验二：

为了模拟真实的资源不足情况下的弹性资源分配，实验对整个服务资源量做了上限限制，集群中最多可以构建45个容器。与上个实验一样，实验分别给服务1、2、3所对应的请求路径QPS为50的基础流量。那么，服务1、2、 3、4、7在集群中都包含两个工作节点，服务5、6、8、9、10都包含4个节点。实验分别对服务1、2、3所对应的请求路径进行压测，保证每个请求路径上的 QPS约为200。此时，系统的资源不能满足所有服务。实验记录每个服务最终分配的节点数以及服务恢复稳定的耗时。

表2实验服务调用示例

在集群中资源不足的情况下，资源分配是按照每个服务所有需要的机器数占总需求机器数的比例来分配剩余的机器数的。由上表的测试结果可知，每个服务的节点分配是正确的，服务恢复稳定仅耗时约4.3S。因此，资源不足时的弹性资源分配也是符合预期的。

具体实施步骤如图7所示：

步骤一：节点被访问时，节点会将日志记录到Redis集群中。日志信息包含RequestID、父节点信息等信息。

步骤二：日志解析中设置定时任务。每隔一分钟便解析日志的信息，会将不同的请求路径解析成一个唯一的标志，同时记录每个节点被访问的次数和请求路径被访问的次数。

步骤三：弹性资源调度也是一个定时任务。执行时分6个子步骤。

1、计算集群的剩余资源。

2、计算可回收的资源。

3、计算需要分配给高峰期服务的资源。

4、判断资源分配时资源充足的分配还是资源不足的分配。

5、回收低峰期服务的资源。

按照不同的模式为高峰期服务分配资源。

本于同一发明构思，本申请同时提供一种用于电网数据中台服务的弹性资源调度系统800，如图8所示，包括：

请求日志获取模块810，用于获取电网数据中台服务的请求日志；

请求路径获取模块820，用于解析所述请求日志，获取服务的请求路径；

调用关系获取模块830，用于通过所述请求路径，获取各个服务之间的调用关系；

资源分配模块840，用于根据服务器剩余资源和所述调用关系，在满足服务的基础每秒查询率条件下，为所述服务分配弹性资源。

优选的，请求日志获取模块，包括：

解析子模块，用于通过广度优先搜索算法BFS解析所述请求日志，获取每条请求调用各个服务所形成的请求路径；及所述请求路径包含的各个节点；

标识子模块，用于使用字符标识所述各个节点；

字符串组成子模块，用于将每条路径经过的节点组成字符串；

标识子单元，用于使用所述字符串标识所述服务的请求路径。

优选的，还包括：

访问次数获取子模块，用于获取每个节点被访问的次数和请求路径被访问的次数。

优选的，调用关系获取模块，包括：

相交节点获取子模块，用于根据所述请求路径，获取各个服务之间的相交的节点；

调用关系获取子模块，用于通过所述相交的节点，获取各个服务之间的调用关系。

优选的，资源分配模块，包括：

第一资源计算子模块，用于当服务器剩余资源充足时，计算服务器剩余资源和可回收的资源；

第一回收子模块，用于回收服务器过剩的服务资源；

第一资源分配子模块，用于为每个待分配资源的服务的节点，及与所述待分配资源的服务存在调用关系的服务的节点，分配过剩的服务资源，所述过剩的服务资源大于或等于其节点的基础每秒查询率QPS的一半所需的服务资源；；

第二回收子模块，用于当服务器剩余资源不足时，对低峰期服务的资源进行回收；

比例计算子模块，用于计算高峰期服务需要资源占总高峰期服务需要资源的比例；

第二资源分配子模块，用于获取待分配的高峰期服务的请求路径的节点数，根据所述节点数需求的机器数占总需求机器数的比例，分配剩余的资源。

本申请提供的一种用于电网数据中台服务的弹性资源调度方法和系统，在检测出服务的负载同时检测出服务的依赖关系，可以更准确地进行资源分配。电网数据中台节省很多硬件成本。解决盲目为某个服务扩容会造成不必要的浪费且资源分配不够精准的问题。

最后应当说明的是：以上实施例仅用以说明本申请的技术方案而非对其保护范围的限制，尽管参照上述实施例对本申请进行了详细的说明，所属领域的普通技术人员应当理解：本领域技术人员阅读本申请后依然可对申请的具体实施方式进行种种变更、修改或者等同替换，这些变更、修改或者等同替换，其均在其申请待批的权利要求范围之内。