CN115022173A - 一种服务扩容的方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供了一种服务扩容的方法、装置、设备及存储介质。该方法包括：从预配置的多扩容模式中，确定兜底扩容模式和当前服务下已标定的目标扩容模式；利用所述兜底扩容模式和所述目标扩容模式，对所述当前服务进行联合扩容。本申请会预先配置出可适用于不同服务场景下的多种扩容模式，确保服务扩容的全面适用性，并实现不同场景下服务的自动扩容，采用兜底扩容模式和目标扩容模式的联合扩容方式，提高服务扩容的准确性。

Description

一种服务扩容的方法、装置、设备及存储介质

技术领域

本申请实施例涉及数据处理技术领域，具体涉及一种服务扩容的方法、装置、设备及存储介质。

背景技术

随着互联网技术的快速发展，在面向外部用户的服务集群上运行的服务实例的部署迭代频率越来越高。在网络流量不断增加时，所带来的服务开销也会随之增大，因此需要通过服务扩容，也就是扩充对应承压的服务实例数量，来分摊网络流量带来的压力，从而降低每个服务实例的负载。

目前，通常可以依赖人工进行流量评估，从而手动实现服务扩容；但是服务扩容效率较低且易出错。或者，云原生内的k8s具备一定的服务伸缩能力，仅支持在中央处理器(Central Processing Unit，简称为CPU)维度下进行服务扩容，存在一定的扩容局限性，无法满足大量的服务扩容场景。

发明内容

本申请提供一种服务扩容的方法、装置、设备及存储介质，实现不同场景下服务的自动扩容，提高服务扩容的准确性和全面适用性。

第一方面，本申请实施例提供了一种服务扩容的方法，该方法包括：

从预配置的多扩容模式中，确定兜底扩容模式和当前服务下已标定的目标扩容模式；

利用所述兜底扩容模式和所述目标扩容模式，对所述当前服务进行联合扩容。

第二方面，本申请实施例提供了一种服务扩容的装置，该装置包括：

扩容模式确定模块，用于从预配置的多扩容模式中，确定兜底扩容模式和当前服务下已标定的目标扩容模式；

服务扩容模块，用于利用所述兜底扩容模式和所述目标扩容模式，对所述当前服务进行联合扩容。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括：

处理器和存储器，所述存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，以执行本申请第一方面中提供的服务扩容的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，用于存储计算机程序，所述计算机程序使得计算机执行如本申请第一方面中提供的服务扩容的方法。

第五方面，本申请实施例提供了一种计算机程序产品，包括计算机程序/指令，其特征在于，该计算机程序/指令被处理器执行时实现如本申请第一方面中提供的服务扩容的方法。

本申请实施例提供的一种服务扩容的方法、装置、设备及存储介质，会预先配置出可适用于不同服务场景下的多种扩容模式，确保服务扩容的全面适用性。对于当前服务，首先从预配置的多扩容模式中，确定出兜底扩容模式和当前服务下已标定的目标扩容模式，然后利用兜底扩容模式和目标扩容模式对当前服务进行联合扩容，从而实现不同场景下服务的自动扩容，采用兜底扩容模式和目标扩容模式的联合扩容方式，提高服务扩容的准确性。

附图说明

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

图1为本申请实施例示出的一种服务扩容的方法的流程图；

图2为本申请实施例示出的服务扩容过程的原理示意图；

图3为本申请实施例示出的另一种服务扩容的方法的流程图；

图4为本申请实施例示出的压测扩容模式下的流量调度过程的原理示意图；

图5为本申请实施例示出的预测扩容模式下采用的BP神经网络的示意图；

图6为本申请实施例示出的计划扩容模式下预编排的任务执行计划的示例性框图；

图7为本申请实施例示出的一种服务扩容的装置的原理框图；

图8是本申请实施例提供的电子设备的示意性框图。

具体实施方式

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

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

考虑到手动扩容和单一策略下扩容存在的扩容易出错和扩容局限性问题，本申请设计了一种新的服务扩容方式。针对存在扩容需求的各种服务场景，会预先配置多种扩容模式，从而确定服务扩容的全面适用性。然后，对于存在扩容需求的任一服务，利用多扩容模式中的兜底扩容模式和当前服务下已标定的目标扩容模式，对当前服务进行联合扩容，从而实现不同场景下服务的自动扩容，提高服务扩容的准确性。

图1为本申请实施例示出的一种服务扩容的方法的流程图。参照图1，该方法具体可以包括如下步骤：

S110、从预配置的多扩容模式中，确定兜底扩容模式和当前服务下已标定的目标扩容模式。

为了实现不同场景下服务的自动扩容，本申请可以通过分析不同场景下的服务扩容需求，预先配置出可适用于不同场景下的多种扩容模式。

应当理解的是，本申请中的服务可以为面向外部用户的各类应用支持的服务，例如专注于业务前台的面向C端用户(To Customer，简称为ToC)类型下的服务，ToC类型服务主要用于负责直接提供给个人用户使用的产品，如应用程序、公众号、小程序等。而且，服务扩容可以为通过扩充用于承担相应服务运行压力的服务实例数量，来分摊相应服务带来的流量压力，从而降低每个服务实例的负载压力，从而确保服务运行的高效性。

作为本申请中的一种可选实现方案，本申请中的多扩容模式可以包括自动扩容模式、压测扩容模式、预测扩容模式和计划扩容模式四种。

接下来对四种扩容模式的基本扩容功能进行说明：

1)自动扩容模式可以为：通过实时判断服务在线流量是否超出所设定的流量阈值，来对服务进行自动扩容。此时，自动扩容模式可适用于任一种服务场景，支持服务扩容的全面执行，因此可以作为其他扩容模式的兜底方案。也就是说，该自动扩容模式为本申请中的兜底扩容模式。

2)压测扩容模式可以为：通过定期调度流量来测试服务运行极限，以此确定服务稳定性。然后，在服务压测过程中，通过判断是否触达自动扩容模式，来对服务进行联动扩容。此时，压测扩容模式可适用于抢红包、秒杀等突发服务场景下，通过支持在此类服务场景下进行提前扩容来确保服务容量充足，进而确保此类场景下服务的稳定性。

3)预测扩容模式可以为：通过预测服务运行过程中的未来流量趋势，联合自动扩容模式进行对服务进行提前扩容，避免自动扩容模式由于数据加载时间过长而无法及时扩容的问题。此时，预测扩容模式可适用于涉及服务数据加载时间过长而使服务扩容时间过长的服务场景下，支持通过预测服务的未来流量趋势来提前扩容，进而确保服务扩容的成功率。

4)计划扩容模式可以为：对于服务下存在的各种定时作业，提前扩容出专用于执行此类定时作业的服务实例，从而为存在周期性扩容需求的服务单独提供定时扩容。此时，计划扩容模式可适用于定时类服务的场景下，例如涉及对账、贷后跑批等服务。

需要说明的是，对于上述四种扩容模式，如图2所示，本申请会将用户在各个扩容模式下定义的相关配置数据存放在配置服务(Config-server)内，且配置服务(Config-server)所使用的底层数据库可以为关系型数据库管理***MySQL数据库。

在本申请中，对于不同场景下的各个服务，可以按照所处服务场景预先为每一服务标定出匹配的扩容模式。也就是针对线上托管的各个服务，可以按照各个服务场景，将每一服务与预配置的多扩容模式中的各个扩容模式关联起来。进而，在当前服务运行过程中，首先可以从预配置的多扩容模式中，确定出兜底扩容模式。同时，根据当前服务下已标定的扩容模式信息，可以从多扩容模式中确定出当前服务可适用的目标扩容模式。

S120，利用兜底扩容模式和目标扩容模式，对当前服务进行联合扩容。

在确定出兜底扩容模式和当前服务下可适用的目标扩容模式后，考虑到兜底扩容模式为通过实时判断服务在线流量是否超出预设流量阈值下的实时扩容方案。因此可以在当前服务运行过程中，通过实时分析当前服务的在线流量，来判断当前是否需要进行服务扩容，以确保服务扩容的及时性。

而且，考虑到目标扩容模式在当前服务的实时运行过程中，会定期提前分析当前服务在未来一段时间内的流量状态。因此，在当前服务运行过程中，可以定期根据提前分析好的未来流量状态，提前为当前服务扩充相应的服务实例，从而在先确保当前服务的运行高效性。

然而，由于当前服务在运行过程中的实时流量状态会受到实时服务请求的影响，使得当前服务在某一时刻下的实时流量状态与前期为该时刻提前分析的流量状态之间可能存在一定差异，导致利用目标扩容模式对当前服务进行提前扩容后，可能仍未满足当前服务在当该时刻下的扩容需求。因此，本申请在利用目标扩容模式对当前服务进行在先扩容的基础上，还会进一步结合兜底扩容模式，在目标扩容模式的在先扩容未达到扩容需求时，及时对当前服务进行再次扩容，从而通过不同扩容模式对服务的联合扩容，确保服务扩容的准确性。

此外，针对不同场景下的服务对于执行及时性的要求，本申请可以为各个服务设定对应的优先级，以确保服务运行的高效性。而且，对于同一优先级下的不同服务而言，在首次划分服务优先级的时候，还会在优先级的基础上，进一步为同一优先级下的不同服务多标记一个标识，用于区分同一优先级下不同服务的等级。例如某一服务的优先级标签为2-100，即代表优先级为2的服务，其在第二优先级下的等级权重赋值为100。

作为本申请中的一种可选实现方案，本申请在对当前服务进行联合扩容之前，还会根据当前服务的服务优先级，确定当前服务的适配资源池，以在适配资源池内对当前服务进行联合扩容。

也就是说，对于用于提供部署服务实例的资源池，也会按照服务对于执行及时性的要求，来划分出多个不同优先级的资源池。优先级越高的资源池内部署的服务实例执行效率越高，而优先级越低的资源池内部署的服务实例执行效率也相应越低。示例性的，如图2中的在线资源池和混部资源池，在线资源池的优先级高于混部资源池。进而，在对当前服务进行联合扩容前，首先分析当前服务的服务优先级。然后，从预设定的不同优先级下的多个资源池中确定出与该服务优先级适合的适配资源池。进而，在利用兜底扩容模式和目标扩容模式对当前服务进行联合扩容时，可以直接在该适配资源池内部署当前服务本次扩充的服务实例，使得扩容后的服务实例满足当前服务对于执行及时性的要求，确保服务扩容的准确性。

本申请实施例提供的技术方案，会预先配置出可适用于不同服务场景下的多种扩容模式，确保服务扩容的全面适用性。对于当前服务，首先从预配置的多扩容模式中，确定出兜底扩容模式和当前服务下已标定的目标扩容模式，然后利用兜底扩容模式和目标扩容模式对当前服务进行联合扩容，从而实现不同场景下服务的自动扩容，采用兜底扩容模式和目标扩容模式的联合扩容方式，提高服务扩容的准确性。

作为本申请中的一种可选实现方案，为了确保服务扩容的全面适用性，本申请会利用预配置的多扩容模式中的兜底扩容模式和当前服务下已标定的目标扩容模式对当前服务进行联合扩容。此时，在当前服务的运行过程中，除了对利用兜底扩容模式进行实时扩容时所需要的当前服务实时流量状态进行监控分析之外，还需要对利用目标扩容模式进行在先扩容时预先确定的当前服务在未来时段的流量状态进行监控分析。如图2所示，在将用户在各个扩容模式下定义的相关配置数据存放在配置服务(Config-server)内后，会通过规则引擎(Rule-engine)来获知用户已配置的各个扩容模式。然后，结合通过监控服务(Monitor-server)对当前服务所收集的服务流量使用情况，也就是相应流量监控数据，来判断是否触发某一扩容模式。在触发利用某一扩容模式对当前服务进行扩容时，会通过调度器(Scheduler)按照规则引擎(Rule-engine)的规则，从多个资源池中选择出当前服务的适配资源池，例如在线资源池(Online-service)和混部资源池(Mixed-service)。进而，在适配资源池内扩充相应数量的服务实例，以实现当前服务的准确扩容。并且，通过监控代理(Monitor-agent)在当前服务运行过程中，实时监控各个服务实例的流量情况，并将当前服务在服务维度以及机器维度下的各个流量监控数据上报给监控服务(Monitor-server)，以便由规则引擎(Rule-engine)持续判断在当前服务运行过程中是否触发某一扩容模式。接下来对利用兜底扩容模式和目标扩容模式对当前服务进行联合扩容的具体过程进行详细的解释说明。

图3为本申请实施例示出的另一种服务扩容的方法的流程图。参照图3，该方法具体可以包括如下步骤：

S310，从预配置的多扩容模式中，确定兜底扩容模式和当前服务下已标定的目标扩容模式。

S320，利用目标扩容模式预确定的服务流量状态，对当前服务进行基础扩容。

作为本申请中的一种可选实现方案，考虑到目标扩容模式在当前服务的实时运行过程中，会定期提前分析当前服务在未来一段时间内可能出现的流量状态。因此，按照目标扩容模式下定期对当前服务提前分析的未来可能存在的流量状态，可以提前确定出当前服务在后续运行过程中可能出现的服务流量状态，也就是本申请中预确定的服务流量状态。然后，结合兜底扩容模式中设定的服务流量极值，来判断预确定的服务流量状态是否存在超出该服务流量极值的情况。进而，在提前分析出当前服务在后续运行过程中存在扩容需求时，可以对当前服务提前进行相应的在先扩容操作，确保服务扩容后的运行高效性，避免出现服务扩容不及时的问题。

示例性的，本申请中的目标扩容模式可以为压测扩容模式、预测扩容模式和计划扩容模式中的一种。接下来分别对利用压测扩容模式、预测扩容模式或计划扩容模式对当前服务进行基础扩容的过程进行说明。

一、目标扩容模式为压测扩容模式

在抢红包、秒杀等突发的服务场景下，通常要求线上服务能够通过提前扩容使得服务容量充足，以确保服务运行稳定性。因此，本申请可以采用压测扩容模式来定期调度流量，以测试出现突发服务时的稳定性。

作为本申请中的一种可选实现方案，本申请中利用压测扩容模式对当前服务进行基础扩容，具体可以为：逐步向当前服务下的待压测机房调度服务流量；基于待压测机房调度后的实时流量参数和兜底扩容模式内的服务流量极值，对当前服务进行基础扩容。

也就是说，对于运行有当前服务下各个服务实例的各个互联网数据中心(Internet Data Center，简称为IDC)所表示的各个机房，如图4所示，本申请可以从当前服务下的各个机房中选出其中一个机房，作为待压测机房。然后，逐步向该待压测机房内不断调度相应的服务流量，使得待压测机房的服务流量不断增加。进而，通过不断增加待压测机房内的服务流量，来测试服务运行极限，以在待压测机房调度后的实时流量参数超出兜底扩容模式内的服务流量极值时，提前对当前服务进行相应扩容操作，使得当前服务在出现突发情况之前能够实现基础的在先扩容，避免在出现突发服务时才开始执行扩容而存在扩容不及时的问题。

示例性的，本申请可以通过切机房和模拟流量这两种方式中的其中一种方式，来逐步向当前服务下的待压测机房调度服务流量。因此，待压测机房内调度的服务流量可以为当前服务下其他机房内的服务流量或者当前服务下的模拟流量。

其一，在切机房方式中，如图4所示，可以通过在F5层面，逐步将当前服务下除待压测机房之外的其他机房(如图4中的IDC1)负责的服务流量不断切换到待压测机房(如图4中的IDC2)内。此时，切机房方式中的流量切换过程为：1％->5％->10％->20％->50％->100％。然后，在待压测机房内的服务流量逐步增加的过程中，如果待压测机房内部署的服务实例上的实时流量参数超出兜底扩容模式内的服务流量极值，那么通过兜底扩容模式对当前服务进行基础扩容。

需要说明的是，为了确保当前服务的运行准确性，本申请还会在逐步向待压测机房调度服务流量之前，提前设定一个钩子回调检查，用于在流量调度过程中，实时检测当前服务的核心指标是否存在异常。进而，如果在切机房调度流量过程中当前服务的核心指标出现异常，则触发熔断操作，以终止通过切机房方式向待压测机房调度服务流量，并控制当前服务回退到切机房前的状态，从而确保当前服务的准确运行。

其二，考虑到部分服务存在子***甚至模块级别的压测扩容场景，而其对于切机房方式的压测扩容模式不够精细。因此，本申请可以采用模拟流量的方式，来逐步向待压测机房调度相应的服务流量。其中，本申请中的模拟流量可以为自行构造的流量，也可以为对当前服务回放的线上日志，对模拟流量的类型不作限定。

需要说明的是，由于模拟流量会在当前服务下的服务实例中执行，因此需要与当前服务下的真实流量数据进行区分。例如，如果当前服务中有依赖到类似于MySQL、redis等数据库来做持久化存储，则需要在模拟流量中提前标记好脏数据特征和模拟流量下的数据过期时间，从而避免污染当前服务线上的真实数据。而且，如果当前服务中有用到机器学习/深度学习构建的模型，也需要通过标记模拟流量中的数据，以在模型训练时对模拟流量进行规避筛选，避免采用模拟类型的模拟流量对模型训练而影响到模型的准确率。

二、目标扩容模式为预测扩容模式

在涉及服务数据加载时间过长而使服务扩容时间过长的服务场景下，本申请可以通过预测扩容模式来预测当前服务的未来流量趋势，从而实现提前扩容，进而确保服务扩容的成功率。

作为本申请中的一种可选实现方案，本申请中利用预测扩容模式对当前服务进行基础扩容，具体可以为：基于当前服务的历史服务流量，预测对应的未来流量趋势；基于未来流量趋势和兜底扩容模式内的服务流量极值，提前对当前服务进行基础扩容。

可选的，本申请中可以采用滤波算法和神经网络两种方式，来根据当前服务的历史服务流量，预测对应的未来流量趋势。然后，根据未来流量趋势中的最大流量参数和兜底扩容模式内的服务流量极值的比对情况，提前对当前服务进行基础扩容。

其一，对于当前服务下较为线性的历史服务流量，可以采用卡尔曼滤波算法来预测当前服务的未来流量走势，并且会分析服务启动的实际时长。

其二，对于当前服务下非线性的历史服务流量，可以预先训练一个反向传播(BackPropagation，简称为BP)神经网络，用于预测当前服务下未来流量趋势的时间序列。

其中，如图5所示，本申请中BP神经网络的输入参数可以有时间点、进程CPU利用率、内存(Memory Device，简称为MEM)利用率、耗时(cost time)、服务每秒查询率(Queries-per-second，简称为QPS)、连接数和模块启动时间。输出参数为当前服务在某个时间点对应的CPU利用率。而且，会确定好BP神经网络内输入层节点数和输出层节点数。隐含层可以采用经验公式

其中l为隐含层神经元个数，n为输入层神经元个数，m为输出层神经元个数，α为1到10之间的常数。本申请中n＝6，m＝1，采用上述公式可以确定隐含层神经元个数l在4到13之间，本申请中可以选择隐含层神经元个数为6。然后，选择S型正切函数tansig作为激励函数，来训练BP神经网络。

三、目标扩容模式为计划扩容模式

在涉及对账、贷后跑批等定时类任务的服务场景下，计划扩容模式支持业务侧对于当前服务下存在的各个定时作业的自定义编排，即由用户自行决策作业启动的时间点以及先后顺序。如图6所示，本申请可以通过自定义一个有向无环图(Directed AcyclicGraph，简称为DAG)，来编排当前服务下各个定时作业(job)的执行计划顺序，从而得到对应的任务执行计划。如图6所示，job1会在2:00AM启动，job2会在2:10AM启动，job3会在2:30AM启动。然后，当job1完成后才能触发job4，当job2和job3都完成后才能触发job5，最后job4和job5都完成后触发job6的执行。

作为本申请中的一种可选实现方案，本申请中利用预测扩容模式对当前服务进行基础扩容，具体可以为：基于当前服务下预编排的任务执行计划，对当前服务进行基础扩容，以在扩容后的服务实例上运行任务执行计划；如果任务执行计划执行完成，则销毁本次扩容后的服务实例。

也就是说，对于当前服务下的各个定时作业，可以提前获取预编排的任务执行计划，该任务执行计划中包含了各个定时作业的执行时间和执行顺序。然后，在最早的作业启动时间前，可以按照当前服务下预编排的各个任务执行计划，可以提前扩容出专用于执行各个任务执行计划的多个服务实例。然后在定时启动各个作业时，可以由扩容出的服务实例专门来运行该任务执行计划内的此类定时作业。考虑到利用计划扩容模式扩容出的服务实例具备任务专用特性，不支持除任务执行计划外的其他服务作业使用。因此，在本申请中任务执行计划内的各个定时作业均全部执行完成后，则及时销毁本次扩容后的服务实例，以释放相应的服务资源。

需要说明的是，由于利用计划扩容模式扩容出的服务实例对服务执行效率的要求较低，使得计划扩容模式下当前服务的服务优先级较低。因此，在实际扩容时，会被调度器(scheduler)调度到优先级较低的资源池(例如混部资源池)内执行实际的扩容操作。

S330，利用兜底扩容模式内已配置的服务流量极值和当前服务的实时流量参数，对当前服务进行辅助扩容。

在利用目标扩容模式对当前服务进行在先扩容的基础上，考虑到目标扩容模式的在先扩容可能会存在未达到实际扩容需求的情况。因此，本申请可以进一步结合兜底扩容模式，通过对当前服务的实时流量参数和兜底扩容模式内的服务流量极值进行比对，来判断目标扩容模式的在先扩容是否达到实际扩容需求。在当前服务的实时流量参数超出兜底扩容模式内的服务流量极值时，说明目标扩容模式的在先扩容未达到实际扩容需求，那么进一步及时对当前服务进行辅助扩容，从而通过不同扩容模式对服务的联合扩容，确保服务扩容的准确性。

作为本申请中的一种可选实现方案，本申请中的兜底扩容模式为自动扩容模式。因此，利用兜底扩容模式对当前服务进行辅助扩容，具体可以为：如果当前服务的实时流量参数大于兜底扩容模式内的服务流量极值，则基于当前服务下的当前服务实例数量和预设迭代扩容规则，对当前服务进行迭代扩容。

其中，兜底扩容模式内的服务流量极值包括服务流量使用率、服务响应时间和服务每秒查询率中的至少一个。

应当理解的是，本申请可以通过设定当前服务进程的CPU均值、最小值、最大值等，来配置上述服务流量使用率。例如，在当前服务的进程CPU利用率达到50％的时候，可以对当前服务进行扩容。而且，通过设定当前服务进程的响应时间的均值、90分位值或99分位值，来配置上述服务响应时间。

根据本申请的一方面，通过服务流量使用率、服务响应时间和服务每秒查询率中的至少一个，来判断当前服务的实时流量参数是否大于兜底扩容模式内的服务流量极值。然后，在确定对当前服务进行扩容时，本申请可以基于当前服务下的当前服务实例数量，按照预设迭代扩容规则，来判断每次需要扩容出的服务实例数量，并分析扩容后的实时流量参数是否低于扩容预期值。如果分析扩容后的实时流量参数高于扩容预期值，那么基于当前服务实例数量继续扩容，如此递归迭代扩容下去，直至实时流量参数低于扩容预期值。

需要说明的是，本申请中的预设迭代扩容规则包括基于当前服务实例数量的倍数迭代和比例迭代两种。

1)倍数迭代：可以优先基于当前服务下现有的当前服务实例数量，先扩容一倍数量的服务实例，再比较实时流量参数以及扩容期望值之间的差异；若仍然高于扩容期望值的一倍以上，则会继续按照一倍扩容；若高于扩容期望值一倍以下，则按照0.5倍*当前服务实例数量进行扩容。如此递归迭代扩容下去，直至实时流量参数低于扩容期望值后停止对当前服务进行扩容。

2)比例迭代：如果当前服务下的当前服务实例数量大于10个，那么每次按照当前的服务实例总数*10％的数量进行迭代扩容，直至实时流量参数不超过扩容预期值；如果当前服务下的当前服务实例数量小于10，则按照每次最多扩容1个服务实例进行迭代，直至实时流量参数不超过扩容期望值。

其中，扩容期望值为支持当前服务进行高效运行的期望流量参数，例如若兜底扩容模式内的服务流量极值为服务流量使用率，且极值为50％，也就是如果当前服务的服务流量使用率高于50％，那么需要对当前服务进行扩容。此时，扩容期望值为30％的服务流量使用率，也就是通过扩容，将当前服务的服务流量使用率降低到30％以下。

本申请实施例提供的技术方案，会预先配置出可适用于不同服务场景下的多种扩容模式，确保服务扩容的全面适用性。对于当前服务，首先从预配置的多扩容模式中，确定出兜底扩容模式和当前服务下已标定的目标扩容模式，然后利用兜底扩容模式和目标扩容模式对当前服务进行联合扩容，从而实现不同场景下服务的自动扩容，采用兜底扩容模式和目标扩容模式的联合扩容方式，提高服务扩容的准确性。

图7为本申请实施例示出的一种服务扩容的装置的原理框图。如图7所示，该装置700可以包括：

扩容模式确定模块710，用于从预配置的多扩容模式中，确定兜底扩容模式和当前服务下已标定的目标扩容模式；

服务扩容模块720，用于利用所述兜底扩容模式和所述目标扩容模式，对所述当前服务进行联合扩容。

进一步的，所述服务扩容模块720，可以包括：

目标扩容单元，用于利用所述目标扩容模式预确定的服务流量状态，对所述当前服务进行基础扩容；

兜底扩容单元，用于利用所述兜底扩容模式内已配置的服务流量极值和所述当前服务的实时流量参数，对所述当前服务进行辅助扩容。

进一步的，如果所述目标扩容模式为压测扩容模式，则所述目标扩容单元，可以具体用于：

逐步向所述当前服务下的待压测机房调度服务流量；

基于所述待压测机房调度后的实时流量参数和所述兜底扩容模式内的服务流量极值，对所述当前服务进行基础扩容；

其中，所述待压测机房内调度的服务流量为所述当前服务下其他机房内的服务流量或者所述当前服务下的模拟流量。

进一步的，如果所述目标扩容模式为预测扩容模式，则所述目标扩容单元，可以具体用于：

基于所述当前服务的历史服务流量，预测对应的未来流量趋势；

基于所述未来流量趋势和所述兜底扩容模式内的服务流量极值，提前对所述当前服务进行基础扩容。

进一步的，如果所述目标扩容模式为计划扩容模式，则所述目标扩容单元，可以具体用于：

基于所述当前服务下预编排的任务执行计划，对所述当前服务进行基础扩容，以在扩容后的服务实例上运行所述任务执行计划；

如果所述任务执行计划执行完成，则销毁本次扩容后的服务实例。

进一步的，所述兜底扩容单元，可以具体用于：

如果所述当前服务的实时流量参数大于所述兜底扩容模式内的服务流量极值，则基于所述当前服务下的当前服务实例数量和预设迭代扩容规则，对所述当前服务进行迭代扩容；

其中，所述兜底扩容模式内的服务流量极值包括服务流量使用率、服务响应时间和服务每秒查询率中的至少一个。

进一步的，所述服务扩容的装置700，还可以包括：

资源池适配模块，用于根据所述当前服务的服务优先级，确定所述当前服务的适配资源池，以在所述适配资源池内对所述当前服务进行联合扩容。

本申请实施例中，会预先配置出可适用于不同服务场景下的多种扩容模式，确保服务扩容的全面适用性。对于当前服务，首先从预配置的多扩容模式中，确定出兜底扩容模式和当前服务下已标定的目标扩容模式，然后利用兜底扩容模式和目标扩容模式对当前服务进行联合扩容，从而实现不同场景下服务的自动扩容，采用兜底扩容模式和目标扩容模式的联合扩容方式，提高服务扩容的准确性。

应理解的是，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，图7所示的装置700可以执行本申请提供的方法实施例，并且装置700中的各个模块的前述和其它操作和/或功能分别为了实现本申请实施例的各个方法中的相应流程，为了简洁，在此不再赘述。

上文中结合附图从功能模块的角度描述了本申请实施例的装置700。应理解，该功能模块可以通过硬件形式实现，也可以通过软件形式的指令实现，还可以通过硬件和软件模块组合实现。具体地，本申请实施例中的方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路和/或软件形式的指令完成，结合本申请实施例公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。可选地，软件模块可以位于随机存储器，闪存、只读存储器、可编程只读存储器、电可擦写可编程存储器、寄存器等本领域的成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法实施例中的步骤。

图8是本申请实施例提供的电子设备800的示意性框图。

如图8所示，该电子设备800可包括：

存储器810和处理器820，该存储器810用于存储计算机程序，并将该程序代码传输给该处理器820。换言之，该处理器820可以从存储器810中调用并运行计算机程序，以实现本申请实施例中的方法。

例如，该处理器820可用于根据该计算机程序中的指令执行上述方法实施例。

在本申请的一些实施例中，该处理器820可以包括但不限于：

通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(FieldProgrammable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等等。

在本申请的一些实施例中，该存储器810包括但不限于：

易失性存储器和/或非易失性存储器。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double DataRate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synch link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)。

在本申请的一些实施例中，该计算机程序可以被分割成一个或多个模块，该一个或者多个模块被存储在该存储器810中，并由该处理器820执行，以完成本申请提供的方法。该一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述该计算机程序在该电子设备中的执行过程。

如图8所示，该电子设备还可包括：

收发器830，该收发器830可连接至该处理器820或存储器810。

其中，处理器820可以控制该收发器830与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。收发器830可以包括发射机和接收机。收发器830还可以进一步包括天线，天线的数量可以为一个或多个。

应当理解，该电子设备中的各个组件通过总线***相连，其中，总线***除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。

本申请实施例还提供了一种计算机存储介质，其上存储有计算机程序，该计算机程序被计算机执行时使得该计算机能够执行上述方法实施例的方法。或者说，本申请实施例还提供一种包含指令的计算机程序产品，该指令被计算机执行时使得计算机执行上述方法实施例的方法。

当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例该的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如数字视频光盘(digital video disc，DVD))、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。例如，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。

以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以该权利要求的保护范围为准。

Claims (10)

1.一种服务扩容的方法，其特征在于，包括：

从预配置的多扩容模式中，确定兜底扩容模式和当前服务下已标定的目标扩容模式；

利用所述兜底扩容模式和所述目标扩容模式，对所述当前服务进行联合扩容。

2.根据权利要求1所述的方法，其特征在于，所述利用所述兜底扩容模式和所述目标扩容模式，对所述当前服务进行联合扩容，包括：

利用所述目标扩容模式预确定的服务流量状态，对所述当前服务进行基础扩容；

利用所述兜底扩容模式内已配置的服务流量极值和所述当前服务的实时流量参数，对所述当前服务进行辅助扩容。

3.根据权利要求2所述的方法，其特征在于，如果所述目标扩容模式为压测扩容模式，则所述利用所述目标扩容模式预确定的服务流量状态，对所述当前服务进行基础扩容，包括：

逐步向所述当前服务下的待压测机房调度服务流量；

基于所述待压测机房调度后的实时流量参数和所述兜底扩容模式内的服务流量极值，对所述当前服务进行基础扩容；

其中，所述待压测机房内调度的服务流量为所述当前服务下其他机房内的服务流量或者所述当前服务下的模拟流量。

4.根据权利要求2所述的方法，其特征在于，如果所述目标扩容模式为预测扩容模式，则所述利用所述目标扩容模式预确定的服务流量状态，对所述当前服务进行基础扩容，包括：

基于所述当前服务的历史服务流量，预测对应的未来流量趋势；

基于所述未来流量趋势和所述兜底扩容模式内的服务流量极值，提前对所述当前服务进行基础扩容。

5.根据权利要求2所述的方法，其特征在于，如果所述目标扩容模式为计划扩容模式，则所述利用所述目标扩容模式预确定的服务流量状态，对所述当前服务进行基础扩容，包括：

基于所述当前服务下预编排的任务执行计划，对所述当前服务进行基础扩容，以在扩容后的服务实例上运行所述任务执行计划；

如果所述任务执行计划执行完成，则销毁本次扩容后的服务实例。

6.根据权利要求2所述的方法，其特征在于，所述利用所述兜底扩容模式内已配置的服务流量极值和所述当前服务的实时流量参数，对所述当前服务进行辅助扩容，包括：

如果所述当前服务的实时流量参数大于所述兜底扩容模式内的服务流量极值，则基于所述当前服务下的当前服务实例数量和预设迭代扩容规则，对所述当前服务进行迭代扩容；

其中，所述兜底扩容模式内的服务流量极值包括服务流量使用率、服务响应时间和服务每秒查询率中的至少一个。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述方法还包括：

根据所述当前服务的服务优先级，确定所述当前服务的适配资源池，以在所述适配资源池内对所述当前服务进行联合扩容。

8.一种服务扩容的装置，其特征在于，包括：

扩容模式确定模块，用于从预配置的多扩容模式中，确定兜底扩容模式和当前服务下已标定的目标扩容模式；

服务扩容模块，用于利用所述兜底扩容模式和所述目标扩容模式，对所述当前服务进行联合扩容。

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

处理器和存储器，所述存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，以执行权利要求1-7中任一项所述的服务扩容的方法。

10.一种计算机可读存储介质，其特征在于，用于存储计算机程序，所述计算机程序使得计算机执行如权利要求1-7中任一项所述的服务扩容的方法。

Images