CN115643180B

CN115643180B - 一种弹性扩容方法及装置

Info

Publication number: CN115643180B
Application number: CN202211672680.2A
Authority: CN
Inventors: 李继永; 刘祥德; 毛波; 陈志浩
Original assignee: Beijing Digital City Research Center
Current assignee: Beijing Digital City Research Center
Priority date: 2022-12-26
Filing date: 2022-12-26
Publication date: 2023-03-28
Anticipated expiration: 2042-12-26
Also published as: CN115643180A

Abstract

本申请实施例公开了一种弹性扩容方法及装置，在该方法中，采集网络数据；根据预设的时间窗口计算网络数据的指标；根据指标计算扩容的服务器数量。由此可见，利用本申请实施例提供的方案，通过对网络数据进行研判，并提前做好规划。在服务器的压力峰值即将到达之前，既可预测到，并可以对服务器提前进行弹性扩容，降低服务器的负载压力，从而保证系统的正常稳定运行。

Description

一种弹性扩容方法及装置

技术领域

本申请涉及计算机应用技术领域，尤其涉及一种弹性扩容方法及装置。

背景技术

服务器的数量与日常的网络流量存在一定的比例关系。当遇到突发情况，如618、双11、热点事件等时候，网络流量往往成倍的激增，相应的服务器的负载也会对应有相当高的压力变化。

目前的扩容方法往往会有成倍的冗余数量，此时每个服务器的负载基本都很低，就会造成资源的浪费。并且现有的扩容方法具有一定的滞后性，会导致系统不稳定或服务崩溃。

发明内容

本申请实施例提供了一种弹性扩容方法及装置，可以对服务器提前进行弹性扩容，降低服务器的负载压力，从而保证系统的正常稳定运行。

本申请第一方面提供了一种弹性扩容方法所述方法包括：

采集当前服务器的网络数据,所述网络数据包括：网络流量数据、所述服务器对应的处理器负载数据；

根据预设的时间窗口计算所述网络数据的增长指标；

根据所述增长指标和当前的服务器数量计算扩容后的服务器数量。

可选的，所述根据预设的时间窗口计算所述网络数据的增长指标包括：

当所述预设的时间窗口为多个时，按照预设的时间窗口对所述网络数据进行分区，得到每个时间窗口对应的网络流量数据，以及每个时间窗口对应的处理器负载数据；

根据每个时间窗口对应的时间权重和所述每个时间窗口对应的网络流量数据计算每个时间窗口的网络流量增长率；

根据所述每个时间窗口对应的处理器负载数据计算每个时间窗口的处理器负载增长率。

可选的，所述根据预设的时间窗口计算所述网络数据的增长指标后，所述方法还包括：

若所述处理器负载增长率在预设的控制范围内，则不进行扩容；

若所述处理器负载增长率超出所述预设的控制范围，且所述网络流量增长率的波动值小于或等于预设的阈值，则不进行扩容；

所述根据所述增长指标计算需要扩容的服务器数量，包括：若所述处理器负载增长率超出所述预设的控制范围，且所述网络流量增长率的波动值大于所述预设的阈值，则根据所述网络流量增长率和/或所述处理器负载增长率，以及所述当前的服务器数量计算扩容后的服务器数量。

可选的，所述根据所述增长指标和当前的服务器数量计算扩容后的服务器数量，包括：

若所述处理器负载增长率与所述网络流量增长率相等，则所述扩容后的服务器数量的计算公式如下：

;

其中，所述

为扩容后的服务器数量；所述

为当前的服务器数量；所述

为所述网络流量增长率；所述

为预设的冗余量；

若所述处理器负载增长率与所述网络流量增长率不相等，则所述扩容后的服务器数量的计算公式如下：

;

其中，所述

为扩容后的服务器数量；所述

为当前的服务器数量；所述

为所述网络流量增长率；所述

为所述处理器负载增长率；所述

为所述

；所述

为预设的冗余量。

可选的，所述方法还包括：

若所述扩容后的服务器对应的处理器负载与扩容前的服务器对应的处理器负载保持平衡，则输出评估结果，所述评估结果用于指示服务器扩容成功；

若所述扩容后的服务器对应的处理器负载低于扩容前的服务器对应的处理器负载，则在下一次计算所述扩容后的服务器数量时，减小所述冗余量；

若所述扩容后的服务器对应的处理器负载高于扩容前的服务器对应的处理器负载，则在下一次计算所述扩容后的服务器数量时，增加所述冗余量。

可选的，所述方法还包括：

根据所述网络数据的增长指标查询与所述增长指标最接近的历史数据；

对所述历史数据进行正态分布计算，得到正态分布结果；

根据所述正态分布结果对所述扩容后的服务器数量进行优化。

可选的，所述根据所述正态分布结果对所述扩容后的服务器数量进行优化包括：

若所述扩容后的服务器数量处于所述正态分布结果的中位数，则所述扩容后的服务器数量不变；

若所述扩容后的服务器数量处于所述正态分布结果的左侧，则对所述扩容后的服务器数量进行增加；

若所述扩容后的服务器数量处于所述正态分布结果的右侧，则对所述扩容后的服务器数量进行缩减。

可选的，所述方法还包括；

根据优化够的扩容后的服务器数量确定需要扩容的服务器数量

根据所述需要扩容的服务器数量生成扩容指令，所述扩容指令包括需要扩容的服务器数量、需要扩容的服务器规格；

向服务器集群发送将所述扩容指令，以便所述服务器集群进行所述服务器的扩容；

并将所述扩容指令进行存储，根据存储的扩容指令生成历史数据。

本申请第二方面提供了一种弹性扩容装置，包括：

采集单元，用于采集服务器的网络数据,所述网络数据包括：网络流量数据、所述服务器对应的处理器负载数据；

计算单元，用于根据预设的时间窗口计算所述网络数据的增长指标；

所述计算单元，还用于根据所述增长指标和当前的服务器数量计算扩容后的服务器数量。

可选的，所述计算单元，具体用于：

本申请实施例公开了一种弹性扩容方法。在该方法中，采集网络数据；根据预设的时间窗口计算网络数据的指标；根据指标计算扩容的服务器数量。由此可见，利用本申请实施例提供的方案，通过对网络数据进行研判，并提前做好规划。在服务器的压力峰值即将到达之前，既可预测到，并可以对服务器提前进行弹性扩容，降低服务器的负载压力，从而保证系统的正常稳定运行。

附图说明

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

图1为本申请实施例提供的一种弹性扩容系统的结构示意图；

图2为本申请实施例提供的一种弹性扩容方法的流程示意图；

图3为本申请实施例提供的一种弹性扩容装置的结构示意图。

具体实施方式

为方便理解，首先对本申请实施例的应用场景进行介绍。

目前，大部分的应用都是以微服务的方式进行部署，各个服务之间通过http协议或rpc协议进行通讯。服务器的数量与日常的网络流量存在一定的比例关系。当遇到突发情况(如618、双11、热点事件等)时，网络流量往往成倍的激增，相应的服务器的负载也会有相当高的压力变化。网络流量的变化分为有规律的和突发的。

对于有规律的情况，一般每天的早、中、晚3个时间段的流量较大；电商的活动期间（如618、双11等）等流量也会比较大。而突发情况是不规律的，不能预测的（如微博热点新闻、突发事件等）。对于有规律的情况，可以通过一系列的技术手段（如压力测试）对系统压力进行评估测试，提前进行扩容，以保证系统的稳定。对于突发情况，因为事前不能预测，不能及时的进行扩容，往往会造成系统瘫痪、宕机等情况发生。

现有的解决上述问题的主要方法是分为事前事中事后：事前，根据压测情况，提前进行扩容部署；事中，对数据进行采集并监控，当到达一个固定的阈值后，通过短信、邮件等发送告警信息，人工对数据情况进行研判，进行扩容；事后，人工对进行评估总结，以便下次参考。

然而，目前通过提前压测然后进行扩容的情况，都是人工根据经验进行处理的，为了保证系统稳定，往往会有成倍的冗余数量，此时每个服务器的负载基本都很低，造成了资源的浪费。

而对于日常的应用，都会配置有资源告警，当资源使用率达到一定阈值后，会向运维人员发送短信，然后进行人工扩容。对于突发情况，在人工收到告警短信，再进行处理，中间往往已经过去了一段时间，滞后性相当严重，很有可能导致系统不稳定或服务崩溃。

而在目前流行的Kubernetes容器化部署方案中，可以制定一定的策略，在资源使用率达到一定的阈值之后，实现服务器数量的增加。但是，这种策略有一定的滞后性，只有在系统已经出现资源使用率高的情况下才会触发，没有提前扩容，在大规模的服务应用中，某一个服务的崩溃，极有可能会形成雪崩效应。

在进行云渲染的过程中，服务端承受巨大的压力，在客户端流量增多后，因为每个服务器承受的压力有限，在用户数增多的情况下，需要不断的增加服务器数量。造成大量的重复手工劳动，较差的用户体验。即使在冗余大量服务器的前提下，如果遇到极端情况，仍然会出现这个问题。

因此，发明人希望可以通过对各种资源指标的整合，通过本申请记载的技术方案，对数据集资源进行研判，并提前做好规划。在服务器的压力峰值即将到达之前，既可预测到，并可以对其提前进行弹性扩容，降低服务器的负载压力，从而保证系统的正常稳定运行。

可结合图1进行理解，图1为本申请实施例提供的一种弹性扩容系统的结构示意图。

如图1所示，网络数据采集器对网络数据进行采集后，将网络数据发送至流量预测器，通过流量预测器计算网络数据的增长指标。流量预测期将就计算得到的增长指标发送给指标分析器。指标分析器从历史数据服务中获取历史数据，并从服务器数据采集器中获取服务器数据，根据获取的历史数据、服务器数据和增长指标进行综合计算，得到需要扩容的服务器数量，并生成扩容指令，将扩容指令发送给指令中心，指令中心向服务器集群发送扩容指令；服务器集群收到扩容指令后，开始服务器的扩容。指令中心同时将扩容指令发送给历史数据服务进行存储。扩容结果反馈器对扩容后的服务器负载进行评估，并将评估结果返回指标分析器，为后续扩容的优化提供样本数据和参考依据。

参见图2，该图为本申请实施例提供的一种弹性扩容方法的流程示意图。本申请实施例提供的弹性扩容方法，例如可以通过如下步骤S201-203实现。

S201：采集当前服务器的网络数据。

具体的，网络数据包括网络流量数据、服务器对应的处理器负载数据。其中，处理器负载包括中央处理器（central processing unit，简称CPU）负载和图形处理器（graphics processing unit，GPU）。

S202：根据预设的时间窗口计算网络数据的增长指标。

在本申请实施例中，当预设的时间窗口为多个时，按照预设的时间窗口对网络数据进行分区，得到每个时间窗口对应的网络流量数据，以及每个时间窗口对应的处理器负载数据；根据每个时间窗口对应的时间权重和每个时间窗口对应的网络流量数据计算每个时间窗口的网络流量增长率；根据每个时间窗口对应的处理器负载数据计算每个时间窗口的处理器负载增长率。

具体的，首先定义时间权重，得到一个时间权重定义表，如下：

时间	权重(Weight)
		7:00-9:00	1.5
11:00-14:00	2
		17:00-18:00	1.5
19:00-23:00	2
		其他时间	1

如上表所示，根据实际网络流量情况对各个时间段的时间权重进行赋值，上午7时至9时的时间权重为1.5；上午11时至下午14时的时间权重为2；下午17时至下午18时的时间权重为1.5；晚上19时至完整23时的时间权重为2，其他时间的时间权重为1。

需要说明的是，本申请并不限制时间权重的定义，可以根据实际情况对时间进行区分，并根据实际情况对各个时间段进行赋值。例如：可以将凌晨0时至2时的时间权重赋值为1.5等。

按照时间窗口对网络数据进行分区，计算每个时间窗口的平均峰值，其中，时间窗口可以是30分钟，1小时，2小时，3小时等，本申请不对时间窗口的取值进行限定，可根据实际情况确定时间窗口的取值。

定义一个时间窗口的网络流量为T，则第n个时间窗口的网络流量为

,第n-1 个时间窗口的流量为

，则当前时间窗口的网络流量增长率如下：

;

根据每个时间窗口对应的时间权重和每个时间窗口对应的网络流量数据计算每个时间窗口的网络流量增长率，具体计算公式如下：

;

其中，

表示第n个时间窗口对应的时间权重；

表示第n-1个时间窗口对应的时间权重；

表示第n个时间窗口的网络流量；

表示第n-1个时间窗口的网络流量。

根据每个时间窗口对应的处理器负载数据计算每个时间窗口的处理器负载增长率，具体公式如下：

;

其中，

表示在第n个时间窗口的处理器负载；

表示第n-1个时间窗口的处理器负载。

S203：根据增长指标和当前的服务器数量计算扩容后的服务器数量。

在本申请实施例的一种实现方式中，若处理器负载增长率在预设的控制范围内，则不进行扩容；若处理器负载增长率超出预设的控制范围，且网络流量增长率的波动值小于或等于预设的阈值，则认为是偶发情况，或软件的异常情况导致，因此也不进行扩容。

若处理器负载增长率超出预设的控制范围，且网络流量增长率的波动值大于预设的阈值，则根据网络流量增长率和/或处理器负载增长率，以及当前的服务器数量计算扩容后的服务器数量。

具体的，若处理器负载增长率与网络流量增长率相等，则扩容后的服务器数量的计算公式如下：

;

其中，

为扩容后的服务器数量；

为当前的服务器数量；

为网络流量增长率；

为预设的冗余量。其中，冗余量为初始阈值，后续会根据动态评估进行优化。需要说明的是，本申请不对冗余量的取值进行限定，冗余量的可以为20%、30%等，具体根据实际情况确定。

若处理器负载增长率与网络流量增长率不相等，则扩容后的服务器数量的计算公式如下：

;

其中，

为扩容后的服务器数量；

为当前的服务器数量；

为网络流量增长率；

为处理器负载增长率；

为

；

为预设的冗余量。

在本申请实施例的一种实现方式中，根据网络数据的增长指标查询与增长指标最接近的历史数据；对历史数据进行正态分布计算，得到正态分布结果；根据正态分布结果对扩容后的服务器数量进行优化。

具体的，将当前的网络流量峰值、网络流量增长率、处理器负载增长率作为参数，从历史数据中查询与之最接近的扩容方案，及扩容效果反馈。对最接近的历史数据进行正态分布计算，得到正态分布结果。

若扩容后的服务器数量处于正态分布结果的中位数，则扩容后的服务器数量不变；若扩容后的服务器数量处于正态分布结果的左侧，则表示在历史数据中，该扩容后的服务器负载仍处于高位，因此对扩容后的服务器数量进行增加；若扩容后的服务器数量处于正态分布结果的右侧，则表示在历史数据中，该扩容后的服务器负载处于低位，因此对扩容后的服务器数量进行缩减。

在本申请实施例的一种实现方式中，根据优化够的扩容后的服务器数量确定需要扩容的服务器数量根据需要扩容的服务器数量生成扩容指令，扩容指令包括需要扩容的服务器数量、需要扩容的服务器规格；向服务器集群发送将扩容指令，以便服务器集群进行服务器的扩容；并将扩容指令进行存储，根据存储的扩容指令生成历史数据。

在本申请实施例的一种实现方式中，若扩容后的服务器对应的处理器负载与扩容前的服务器对应的处理器负载保持平衡，则输出评估结果，评估结果用于指示服务器扩容成功；若扩容后的服务器对应的处理器负载低于扩容前的服务器对应的处理器负载，则表示此次扩容的服务器数量过多，应降低冗余量，在下一次计算扩容后的服务器数量时，减小冗余量；若扩容后的服务器对应的处理器负载高于扩容前的服务器对应的处理器负载，则表示扩容的数量较少，需要对比时间窗口、网络流量、服务器负载、扩容数量等，在后续的时间窗口或者相同的流量及负载中，在计算扩容的服务器数量时，增加冗余量。

基于以上实施例提供的方法，本申请实施例还提供了一种弹性扩容装置，以下结合附图介绍该弹性扩容装置

参见图3，该图为本申请实施例提供的一种弹性扩容装置的结构示意图。

本申请实施例提供的弹性扩容装置，包括：采集单元301、计算单元302。

采集单元301，用于采集服务器的网络数据,网络数据包括：网络流量数据、服务器对应的处理器负载数据；

计算单元302，用于根据预设的时间窗口计算网络数据的增长指标；

计算单元302，还用于根据增长指标和当前的服务器数量计算扩容后的服务器数量。

在一种可能的实现方式中，计算单元302，具体用于：

当预设的时间窗口为多个时，按照预设的时间窗口对网络数据进行分区，得到每个时间窗口对应的网络流量数据，以及每个时间窗口对应的处理器负载数据；

根据每个时间窗口对应的时间权重和每个时间窗口对应的网络流量数据计算每个时间窗口的网络流量增长率；

根据每个时间窗口对应的处理器负载数据计算每个时间窗口的处理器负载增长率。

在一种可能的实现方式中，该装置，还包括：

判断单元，用于若处理器负载增长率在预设的控制范围内，则不进行扩容；若处理器负载增长率超出预设的控制范围，且网络流量增长率的波动值小于或等于预设的阈值，则不进行扩容；

计算单元302，具体用于若处理器负载增长率超出预设的控制范围，且网络流量增长率的波动值大于预设的阈值，则根据网络流量增长率和/或处理器负载增长率，以及当前的服务器数量计算扩容后的服务器数量。

在一种可能的实现方式中，计算单元302，具有用于：

若处理器负载增长率与网络流量增长率相等，则扩容后的服务器数量的计算公式如下：

;

其中，

为扩容后的服务器数量；

为当前的服务器数量；

为网络流量增长率；

为预设的冗余量；

;

其中，

为扩容后的服务器数量；

为当前的服务器数量；

为网络流量增长率；

为处理器负载增长率；

为

；

为预设的冗余量。

在一种可能的实现方式中，该装置还包括评估单元，用于：

若扩容后的服务器对应的处理器负载与扩容前的服务器对应的处理器负载保持平衡，则输出评估结果，评估结果用于指示服务器扩容成功；

若扩容后的服务器对应的处理器负载低于扩容前的服务器对应的处理器负载，则在下一次计算扩容后的服务器数量时，减小冗余量；

若扩容后的服务器对应的处理器负载高于扩容前的服务器对应的处理器负载，则在下一次计算扩容后的服务器数量时，增加冗余量。

在一种可能的实现方式中，该装置还包括优化单元，用于：

根据网络数据的增长指标查询与增长指标最接近的历史数据；

对历史数据进行正态分布计算，得到正态分布结果；

根据正态分布结果对扩容后的服务器数量进行优化。

在一种可能的实现方式中，优化单元，具有用于：

若扩容后的服务器数量处于正态分布结果的中位数，则扩容后的服务器数量不变；

若扩容后的服务器数量处于正态分布结果的左侧，则对扩容后的服务器数量进行增加；

若扩容后的服务器数量处于正态分布结果的右侧，则对扩容后的服务器数量进行缩减。

在一种可能的实现方式中，该装置还包括扩容单元，用于：

根据需要扩容的服务器数量生成扩容指令，扩容指令包括需要扩容的服务器数量、需要扩容的服务器规格；

向服务器集群发送将扩容指令，以便服务器集群进行服务器的扩容；

并将扩容指令进行存储，根据存储的扩容指令生成历史数据。

由于该装置是与以上方法实施例提供的弹性扩容方法对应的装置，该装置的各个单元的具体实现，均与以上方法实施例为同一构思，因此，关于该装置的各个单元的具体实现，可以参考以上方法实施例关于弹性扩容方法的描述部分，此处不再赘述。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等（如果存在）是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑业务划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各业务单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件业务单元的形式实现。

集成的单元如果以软件业务单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的业务可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些业务存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本发明的具体实施方式而已。

以上，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。