CN112822298B - 业务服务扩缩容方法、装置、介质和电子设备 - Google Patents

Abstract

本发明涉及业务服务扩缩容方法、装置、介质和电子设备，方法包括：接收业务请求，将业务请求转发至对应的业务服务；获取业务请求携带的指定接口标识信息以及预设关联关系，关系包括不同的业务服务的业务标识与每个业务服务的接口的接口标识信息之间的映射关系；基于指定接口标识信息和预设关联关系，确定业务请求对应的目标业务标识；将目标业务标识添加入业务请求，将业务请求推送入消息队列；从消息队列获取多个业务请求，基于预设业务指标计算多个业务请求的业务指标参数；在业务指标参数满足预设扩缩容条件时，对目标业务标识指示的业务服务进行扩缩容。本发明方案对业务服务本身无侵入性，节省开发成本，提高服务性能，服务伸缩灵活性好。

Description

业务服务扩缩容方法、装置、介质和电子设备

技术领域

本公开实施例涉及通信技术领域，尤其涉及一种业务服务扩缩容方法，业务服务扩缩容装置，以及实现业务服务扩缩容方法的计算机可读存储介质和电子设备。

背景技术

随着面向微服务架构以及云计算技术的提出并逐渐走向商用化，对现有系统资源的稳定管理和有效利用是大规模集群部署和管理的关键问题。以Kubernetes为核心的平台即服务PaaS（Platform as a Service）平台可以实现对现有系统资源的稳定管理和有效利用。其中，CPU、内存等计算资源一直是PaaS平台中十分重要的软硬件计算资源, 尤其是面对服务于企业级的亿万次调用时，成本更是昂贵，同时为了保证系统服务在各种业务高峰、极限情况下的可用性，还要投入大量的人力资源去实时维护系统服务的可用性。

相关技术中，Kubernetes内置的HPA(Horizontal Pod Autoscaler)，技术可实现基于CPU和内存指标实现了对服务的扩缩容调整。目前HPA技术的做法是在运行业务服务的Pod上开发实现metrics接口，通过这个接口可以定时收集监控数据进行计算，然后根据用户在HPA上配置的指标类型实时收集对应数据并与目标阈值做比较，符合条件则对业务服务的Deployment组件中的Pod副本数进行调整来达到动态服务伸缩的目的。

但是，目前的HPA技术需要付出开发成本去实现对应的监控接口如metrics接口，这会对业务服务有侵入性，造成对业务服务的潜在影响，且增加开发成本，同时频繁调用业务服务的metrics接口查询收集数据会对业务服务产生一定的性能损耗，难以应对大规模流量。另外，Kubernetes原生的HPA功能有限，只支持基于CPU和内存的服务伸缩，对业务层面的一些监控指标不支持，无法基于业务层面的一些监控指标进行服务伸缩，不够灵活。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开实施例提供了一种业务服务扩缩容方法，业务服务扩缩容装置，以及实现业务服务扩缩容方法的计算机可读存储介质和电子设备。

第一方面，本公开实施例提供了一种业务服务扩缩容方法，包括：

接收业务请求，将所述业务请求转发至对应的业务服务，所述业务请求携带指定接口标识信息；

获取所述业务请求携带的指定接口标识信息以及预设关联关系，所述预设关联关系包括不同的业务服务的业务标识与每个所述业务服务的接口的接口标识信息之间的映射关系；

基于所述指定接口标识信息和所述预设关联关系，确定所述业务请求对应的目标业务标识；

将所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入消息队列；

从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，多个所述业务请求均携带所述目标业务标识；

在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。

在本公开的一些实施例中，所述预设业务指标包括请求的每秒查询率，所述从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，包括：

从所述消息队列中获取预设时长内的多个业务请求；

基于所述预设时长内的多个业务请求计算所述每秒查询率。

在本公开的一些实施例中，所述基于所述预设时长内的多个业务请求计算所述每秒查询率，包括：

计算所述预设时长内的多个业务请求的数量；

基于所述数量以及所述预设时长得到所述每秒查询率。

在本公开的一些实施例中，所述预设业务指标包括请求响应耗时，所述方法还包括：

记录接收到所述业务请求时的第一时间数据；

记录接收到响应信息时的第二时间数据，所述响应信息由所述业务服务响应所述业务请求生成；

将所述第一时间数据、所述第二时间数据以及所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入所述消息队列；

所述从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，包括：

从所述消息队列获取多个业务请求之后，获取多个所述业务请求中每个所述业务请求中的第一时间数据、第二时间数据；

基于每个所述业务请求的第一时间数据、第二时间数据计算每个所述业务请求的请求响应耗时。

在本公开的一些实施例中，所述业务指标参数满足预设扩缩容条件包括：

多个所述业务请求的请求响应耗时的百分位数值等于预设数值。

在本公开的一些实施例中，所述在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作，包括：

在所述业务指标参数满足预设扩缩容条件时，生成报警通知消息，所述报警通知消息中携带所述目标业务标识；

将所述报警通知消息发送至预设的服务监控组件，以使所述服务监控组件基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。

在本公开的一些实施例中，所述将所述业务请求推送入消息队列，包括：

同步或异步将所述业务请求推送入所述消息队列。

第二方面，本公开实施例提供一种业务服务扩缩容装置，包括：

路由模块，用于接收业务请求，将所述业务请求转发至对应的业务服务，所述业务请求携带指定接口标识信息；

信息获取模块，获取所述业务请求携带的指定接口标识信息以及预设关联关系，所述预设关联关系包括不同的业务服务的业务标识与每个所述业务服务的接口的接口标识信息之间的映射关系；

业务标识确定模块，用于基于所述指定接口标识信息和所述预设关联关系，确定所述业务请求对应的目标业务标识；

请求处理模块，用于将所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入消息队列；

指标计算模块，用于从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，多个所述业务请求均携带所述目标业务标识；

扩缩容模块，用于在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。

第三方面，本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任一实施例所述业务服务扩缩容方法的步骤。

第四方面，本公开实施例提供一种电子设备，包括：

处理器；以及

存储器，用于存储计算机程序；

其中，所述处理器配置为经由执行所述计算机程序来执行上述任一实施例所述业务服务扩缩容方法的步骤。

本公开实施例提供的技术方案与现有技术相比具有如下优点：

本公开实施例提供的技术方案，业务请求转发至对应的业务服务后，获取所述业务请求携带的指定接口标识信息以及预设关联关系，所述预设关联关系包括不同的业务服务的业务标识与每个所述业务服务的接口的接口标识信息之间的映射关系；基于所述指定接口标识信息和所述预设关联关系，确定所述业务请求对应的目标业务标识；将所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入消息队列；从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，多个所述业务请求均携带所述目标业务标识；在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。这样，本实施例上述方案仅需在逻辑层面预先构建上述映射关系，基于映射关系可确定业务请求对应的目标业务标识，然后将目标业务标识添加入业务请求，之后将业务请求推送入消息队列，再从消息队列中获取业务请求并计算业务指标参数来实现扩缩容，其采用了与现有HPA技术不同的方式实现业务服务的扩缩容，无需在运行业务服务的Pod上开发监控接口，节省开发成本，同时对业务服务本身无侵入性，方便对不同业务服务进行扩缩容，简单高效，大为提高服务性能。另外，将业务请求推送入消息队列，再从消息队列中获取多个业务请求，基于预设业务指标计算多个业务请求的业务指标参数来实现扩缩容，可以缓冲大量业务请求，较好应对大规模流量，也支持了基于业务层面的一些业务指标参数进行服务伸缩，灵活性较好。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

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

图1为本公开实施例业务服务扩缩容方法流程图；

图2为本公开实施例业务服务扩缩容方法应用场景示意图；

图3为本公开实施例中预设关联关系示意图；

图4为本公开另一实施例业务服务扩缩容方法流程图；

图5为本公开实施例业务服务扩缩容装置示意图；

图6为本公开实施例实现业务服务扩缩容方法的电子设备示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

应当理解，在下文中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

图1为本公开实施例提供了一种业务服务扩缩容方法，可以应用于如图2所示的应用场景，该应用场景包括客户端（图未示）和平台即服务PaaS平台，该业务服务扩缩容方法可以由PaaS平台执行，具体可以包括以下步骤：

步骤S101：接收业务请求，将所述业务请求转发至对应的业务服务，所述业务请求携带指定接口标识信息。

示例性的，在不同的应用场景下，业务请求可以不同，例如在电商购物场景下，业务请求可以是支付请求等。业务服务即PaaS平台上响应处理业务请求返回处理结果信息的单元，如支付业务服务响应支付请求返回支付成功信息等，但也不限于此。PaaS平台上可以部署不同的多个业务服务，每个业务服务可实现不同的功能。通常，每个业务服务可以具有至少一个接口如API接口。每个接口可以具有唯一的接口标识信息如统一资源定位符URL（Uniform Resource Locator）。而业务请求中可以携带指定接口标识信息如指定URL，以便后续确认该业务请求是发送至哪个业务服务的。

具体的，在一个实施例中，客户端（Client）可以发送业务请求到PaaS平台，PaaS平台的路由网关接收到业务请求后，可以基于预先配置的路由规则将业务请求转发至对应的业务服务，由业务服务响应业务请求，这些可以参考现有技术理解，此处不再赘述。

步骤S102：获取所述业务请求携带的指定接口标识信息以及预设关联关系，所述预设关联关系包括不同的业务服务的业务标识与每个所述业务服务的接口的接口标识信息之间的映射关系。

示例性的，结合图3中所示，一个服务可以在PaaS平台上根据服务的不同功能用途部署多个不同的业务服务如业务服务1和业务服务1，每一个业务服务在某一个功能范围内一般会开发多个接口如API接口，如业务服务1对应接口1和接口2，而业务服务2对应接口3和接口4。每一个接口拥有全局唯一的接口标识信息如接口URL，这样预先建立上述预设关联关系，就可保证服务和业务服务的关系是一对多，业务服务和接口的关系是一对多，每个接口的接口URL是唯一的，通过URL就可以唯一确定归属于接口的业务服务的业务信息如业务标识，业务标识可以是唯一ID，但也不限于此。

具体的，PaaS平台的路由网关可以获取业务请求携带的指定接口标识信息如指定URL，同时获取预先建立的上述预设关联关系。

步骤S103：基于所述指定接口标识信息和所述预设关联关系，确定所述业务请求对应的目标业务标识。

具体的，在一个实施例中，路由网关获取业务请求携带的指定接口标识信息如指定URL，以及预先建立的上述预设关联关系之后，在所述预设关联关系中匹配与指定URL相同的接口URL，进而可以基于匹配的接口URL确定业务请求对应的目标业务标识，

示例性的，例如业务请求1携带URL是“/a/b/c”，业务请求2携带URL也是“/a/b/c”，预设关联关系中接口URL“/a/b/c”对应业务标识1，则业务请求1和业务请求2对应的目标业务标识均是业务标识1，业务标识1标识业务服务1，也即业务请求1和业务请求2均是发送至业务服务1的请求。

步骤S104：将所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入消息队列。

示例性的，消息队列可以是Kafka消息队列，但不限于此。具体的，PaaS平台的路由网关会匹配业务请求对应的目标业务标识之后，添加补全每一个业务请求归属的业务服务的信息如目标业务标识，然后将添加后的业务请求推入消息队列，随着时间的进行，会有大量这样的业务请求进入消息队列，本实施例方案可以基于消息队列缓冲PaaS平台的大量业务请求，从而可以较好应对大规模流量而基本可不对业务服务自身运行造成影响，提高服务性能。

步骤S105：从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，多个所述业务请求均携带所述目标业务标识。

示例性的，预设业务指标可以是自定义的业务层面的业务指标，如请求的每秒查询率QPS（Queries-per-second）等，但不限于此。当消息队列中积累大量业务请求后，可以从消息队列获取多个业务请求，多个所述业务请求均携带目标业务标识，如携带业务标识1，这里表示针对某一个业务服务如业务标识1指示的业务服务1，获取发送至业务服务1的所有业务请求，如100个业务请求均是发送至业务服务1的，经过上述步骤处理后，消息队列中这100个业务请求均具有添加的业务标识1。之后可基于预设业务指标如每秒查询率计算多个所述业务请求的业务指标参数如每秒查询率的具体数值。

步骤S106：在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。

示例性的，满足预设扩缩容条件可以是业务指标参数达到预设指标参数值，预设指标参数值可以根据需要设置，对此不作限制。本实施例中可以在满足该预设扩缩容条件时，基于所述目标业务标识如业务标识1对该业务标识1指示的业务服务1进行扩缩容操作，如调整运行业务服务1的Pod副本数量。扩缩容操作的具体过程可以参考现有技术理解，此处不再赘述。

本实施例上述方案仅需在逻辑层面预先构建上述映射关系，基于映射关系可确定业务请求对应的目标业务标识，然后将目标业务标识添加入业务请求，之后将业务请求推送入消息队列，再从消息队列中获取业务请求并计算业务指标参数来实现扩缩容，其采用了与现有HPA技术不同的方式实现业务服务的扩缩容，无需在运行业务服务的Pod上开发监控接口，节省开发成本，同时对业务服务本身无侵入性，方便对不同业务服务进行扩缩容，简单高效，大为提高服务性能。另外，将业务请求推送入消息队列，再从消息队列中获取多个业务请求，基于预设业务指标计算多个业务请求的业务指标参数来实现扩缩容，可以缓冲大量业务请求，较好应对大规模流量，也支持了基于业务层面的一些业务指标参数进行服务伸缩，灵活性较好。

可选的，在本公开的一些实施例中，所述预设业务指标可以包括请求的每秒查询率QPS，其是对一个业务服务在规定时间内所处理流量多少的衡量标准，常常用来衡量服务性能。相应的，步骤S105中从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，具体可以包括：

步骤i）：从所述消息队列中获取预设时长内的多个业务请求。

示例性的，预设时长可以自定义设置，如2秒时长，本实施例中对此不作限制。

在一个实施例中，通过在PaaS平台设置监控服务（monitor-server）组件，由monitor-server组件定期将消息队列中的业务请求按照时间序列推送入PaaS平台的系统监控报警组件Prometheus，Prometheus组件可以获取例如2秒时长内的多个业务请求如100个业务请求。

步骤ii）：基于所述预设时长内的多个业务请求计算所述每秒查询率。

具体的，Prometheus组件可以基于例如2秒时长内的多个业务请求如100个业务请求计算业务服务1的每秒查询率。

可选的，在本公开的一些实施例中，步骤ii）中基于所述预设时长内的多个业务请求计算所述每秒查询率，具体可包括：计算所述预设时长内的多个业务请求的数量；基于所述数量以及所述预设时长得到所述每秒查询率。

示例性的，每秒查询率QPS=100/2=50，也即每秒有50个业务请求到达业务服务1。

步骤ii）之后，即可进入步骤S106执行。

本实施例中可以自定义设置监控业务层面的监控指标如QPS等，基于该监控指标来实现服务伸缩，扩展了服务伸缩的监控指标范围。同时仅需在逻辑层面配置即可实现，灵活性好，无需对Kubernetes原生的HPA进行较大的改进，开发成本较低。

可选的，在一些实施例，可以由PaaS平台的全文搜索引擎Elasticsearch将业务请求数据持久化存储，而不是本地存储避免了历史数据的丢失。

可选的，在本公开的另一些实施例中，所述预设业务指标可以包括请求响应耗时，所述方法还可以包括以下步骤：

步骤a）：记录接收到所述业务请求时的第一时间数据。

具体的，路由网关可以在接收到所述业务请求时，记录此时的第一时间数据。

步骤b）：记录接收到响应信息时的第二时间数据，所述响应信息由所述业务服务响应所述业务请求生成。

具体的，路由网关可以在收到业务服务响应所述业务请求返回的响应信息时，记录此时的第二时间数据。

步骤c）：将所述第一时间数据、所述第二时间数据以及所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入所述消息队列。

相应的，步骤S105中从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，具体可以包括以下步骤：

步骤d）：从所述消息队列获取多个业务请求之后，获取多个所述业务请求中每个所述业务请求中的第一时间数据、第二时间数据。

步骤e）：基于每个所述业务请求的第一时间数据、第二时间数据计算每个所述业务请求的请求响应耗时。

示例性的，请求响应耗时即第一时间数据、第二时间数据的差值，表示业务服务收到业务请求到返回相应处理结果的时长。

在一个实施例中，步骤S104中所述将所述业务请求推送入消息队列，具体可以包括：同步或异步将所述业务请求推送入所述消息队列。

本实施例中，可以异步将所述业务请求推送入所述消息队列，这样可以适用基于请求响应耗时来进行扩缩容的需要。

进一步的，在上述实施例的基础上，本公开的一些实施例中，步骤S106中所述业务指标参数满足预设扩缩容条件可以包括：多个所述业务请求的请求响应耗时的百分位数值等于预设数值。

具体的，百分位数值是一个统计学中的术语，如果将一组数据从小到大排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数值。

假设有100个业务请求，按照计算的请求响应耗时从小到大排列，位置为X的值，即为PX值。示例性的，P1就是响应时间最小的请求，P10就是排第十位置的请求，P100就是响应时间最长的请求。本实施例中可以计算P95值、P99值。

举例来说，例如100个业务请求按照响应耗时从小到大排列，P95值假设为200ms，表示对95%的用户业务请求的响应耗时在200ms以下，只有5%的用户业务请求的响应耗时大于200ms，据此，可以掌握更精确的服务响应耗时信息。通过测量与优化百分位数值，就可保证绝大多数用户的使用体验。

具体的，S106中在多个业务请求的请求响应耗时的百分位数值如P95值等于预设数值时，即可触发对业务服务1进行扩缩容操作。

本实施例中可以自定义设置监控业务层面的监控指标如P95值，P99值等，基于这些指标来实现服务伸缩，扩展了服务伸缩的监控指标范围。同时仅需在逻辑层面配置即可实现，灵活性好，无需对Kubernetes原生的HPA进行较大的改进，开发成本较低。

可选的，在上述各个实施例的基础上，结合图4中所示，本公开的一些实施例中，步骤S106中在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作，具体可以包括以下步骤：

步骤S401：在所述业务指标参数满足预设扩缩容条件时，生成报警通知消息，所述报警通知消息中携带所述目标业务标识。

具体的，Prometheus组件可以在所述业务指标参数如QPS等于预设QPS值时，生成报警通知消息。或者，在上述P95值等于预设数值时，生成报警通知消息。报警通知消息中携带目标业务标识如业务标识1。

步骤S402：将所述报警通知消息发送至预设的服务监控组件，以使所述服务监控组件基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。

具体的，Prometheus组件将报警通知消息发送至服务监控组件monitor-server，monitor-server组件获取报警通知消息中的业务标识1，基于业务标识1对该业务标识1指示的业务服务1进行扩缩容操作。

需要说明的是，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。另外，也易于理解的是，这些步骤可以是例如在多个模块/进程/线程中同步或异步执行。

基于同一发明构思，如图5中所示，本公开实施例提供一种业务服务扩缩容装置，包括：

路由模块501，用于接收业务请求，将所述业务请求转发至对应的业务服务，所述业务请求携带指定接口标识信息；

信息获取模块502，获取所述业务请求携带的指定接口标识信息以及预设关联关系，所述预设关联关系包括不同的业务服务的业务标识与每个所述业务服务的接口的接口标识信息之间的映射关系；

业务标识确定模块503，用于基于所述指定接口标识信息和所述预设关联关系，确定所述业务请求对应的目标业务标识；

请求处理模块504，用于将所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入消息队列；

指标计算模块505，用于从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，多个所述业务请求均携带所述目标业务标识；

扩缩容模块506，用于在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。

本实施例上述方案仅需在逻辑层面预先构建上述映射关系，基于映射关系可确定业务请求对应的目标业务标识，然后将目标业务标识添加入业务请求，之后将业务请求推送入消息队列，再从消息队列中获取业务请求并计算业务指标参数来实现扩缩容，其采用了与现有HPA技术不同的方式实现业务服务的扩缩容，无需在运行业务服务的Pod上开发监控接口，节省开发成本，同时对业务服务本身无侵入性，方便对不同业务服务进行扩缩容，简单高效，大为提高服务性能。另外，将业务请求推送入消息队列，再从消息队列中获取多个业务请求，基于预设业务指标计算多个业务请求的业务指标参数来实现扩缩容，可以缓冲大量业务请求，较好应对大规模流量，也支持了基于业务层面的一些业务指标参数进行服务伸缩，灵活性较好。

可选的，在本公开的一些实施例中，所述预设业务指标包括请求的每秒查询率，所述指标计算模块从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，具体可包括：从所述消息队列中获取预设时长内的多个业务请求；基于所述预设时长内的多个业务请求计算所述每秒查询率。

可选的，在本公开的一些实施例中，所述指标计算模块基于所述预设时长内的多个业务请求计算所述每秒查询率，具体可包括：计算所述预设时长内的多个业务请求的数量；基于所述数量以及所述预设时长得到所述每秒查询率。

可选的，在本公开的一些实施例中，所述预设业务指标包括请求响应耗时，所述装置还包括记录模块，用于：记录接收到所述业务请求时的第一时间数据；记录接收到响应信息时的第二时间数据，所述响应信息由所述业务服务响应所述业务请求生成。相应的，请求处理模块，还用于将所述第一时间数据、所述第二时间数据以及所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入所述消息队列。所述指标计算模块从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，具体可包括：从所述消息队列获取多个业务请求之后，获取多个所述业务请求中每个所述业务请求中的第一时间数据、第二时间数据；基于每个所述业务请求的第一时间数据、第二时间数据计算每个所述业务请求的请求响应耗时。

可选的，在本公开的一些实施例中，所述业务指标参数满足预设扩缩容条件包括：多个所述业务请求的请求响应耗时的百分位数值等于预设数值。

可选的，在本公开的一些实施例中，所述扩缩容模块在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作，具体可包括：在所述业务指标参数满足预设扩缩容条件时，生成报警通知消息，所述报警通知消息中携带所述目标业务标识；将所述报警通知消息发送至预设的服务监控组件，以使所述服务监控组件基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。

可选的，在本公开的一些实施例中，所述请求处理模块将所述业务请求推送入消息队列，具体可包括：同步或异步将所述业务请求推送入所述消息队列。

关于上述实施例中的装置，其中各个模块执行操作的具体方式以及带来的相应技术效果已经在有关该方法的实施例中进行了对应的详细描述，此处将不做详细阐述说明。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。作为模块或单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现木公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本公开实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一项实施例所述业务服务扩缩容方法的步骤。

示例性的，该可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

所述计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

本公开实施例还提供一种电子设备如服务器或服务器集群，如图6中所示，电子设备可包括处理器601以及存储器602，存储器602用于存储计算机程序。其中，所述处理器601配置为经由执行所述计算机程序来执行上述任一项实施例中所述业务服务扩缩容方法的步骤。

所描述的实施例中的各方面、实施方式、实现或特征能够单独使用或以任意组合的方式使用。所描述的实施例中的各方面可由软件、硬件或软硬件的结合实现。所描述的实施例也可以由存储有计算机可读代码的计算机可读介质体现，该计算机可读代码包括可由至少一个计算装置执行的指令。所述计算机可读介质可与任何能够存储数据的数据存储装置相关联，该数据可由计算机系统读取。用于举例的计算机可读介质可以包括只读存储器、随机存取存储器、CD-ROM、HDD、DVD、磁带以及光数据存储装置等。所述计算机可读介质还可以分布于通过网络联接的计算机系统中，这样计算机可读代码就可以分布式存储并执行。

上述技术描述可参照附图，这些附图形成了本申请的一部分，并且通过描述在附图中示出了依照所描述的实施例的实施方式。虽然这些实施例描述的足够详细以使本领域技术人员能够实现这些实施例，但这些实施例是非限制性的；这样就可以使用其它的实施例，并且在不脱离所描述的实施例的范围的情况下还可以做出变化。比如，流程图中所描述的操作顺序是非限制性的，因此在流程图中阐释并且根据流程图描述的两个或两个以上操作的顺序可以根据若干实施例进行改变。作为另一个例子，在若干实施例中，在流程图中阐释并且根据流程图描述的一个或一个以上操作是可选的，或是可删除的。另外，某些步骤或功能可以添加到所公开的实施例中，或两个以上的步骤顺序被置换。所有这些变化被认为包含在所公开的实施例以及权利要求中。

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

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

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

接收业务请求，将所述业务请求转发至对应的业务服务，所述业务请求携带指定接口标识信息；

获取所述业务请求携带的指定接口标识信息以及预设关联关系，所述预设关联关系包括不同的业务服务的业务标识与每个所述业务服务的接口的接口标识信息之间的映射关系；

基于所述指定接口标识信息和所述预设关联关系，确定所述业务请求对应的目标业务标识；

将所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入消息队列；

从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，多个所述业务请求均携带所述目标业务标识；

在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。

2.根据权利要求1所述的业务服务扩缩容方法，其特征在于，所述预设业务指标包括请求的每秒查询率，所述从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，包括：

从所述消息队列中获取预设时长内的多个业务请求；

基于所述预设时长内的多个业务请求计算所述每秒查询率。

3.根据权利要求2所述的业务服务扩缩容方法，其特征在于，所述基于所述预设时长内的多个业务请求计算所述每秒查询率，包括：

计算所述预设时长内的多个业务请求的数量；

基于所述数量以及所述预设时长得到所述每秒查询率。

4.根据权利要求1所述的业务服务扩缩容方法，其特征在于，所述预设业务指标包括请求响应耗时，所述方法还包括：

记录接收到所述业务请求时的第一时间数据；

记录接收到响应信息时的第二时间数据，所述响应信息由所述业务服务响应所述业务请求生成；

将所述第一时间数据、所述第二时间数据以及所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入所述消息队列；

所述从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，包括：

从所述消息队列获取多个业务请求之后，获取多个所述业务请求中每个所述业务请求中的第一时间数据、第二时间数据；

基于每个所述业务请求的第一时间数据、第二时间数据计算每个所述业务请求的请求响应耗时。

5.根据权利要求4所述的业务服务扩缩容方法，其特征在于，所述业务指标参数满足预设扩缩容条件包括：

多个所述业务请求的请求响应耗时的百分位数值等于预设数值。

6.根据权利要求1~5任一项所述的业务服务扩缩容方法，其特征在于，所述在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作，包括：

在所述业务指标参数满足预设扩缩容条件时，生成报警通知消息，所述报警通知消息中携带所述目标业务标识；

将所述报警通知消息发送至预设的服务监控组件，以使所述服务监控组件基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。

7.根据权利要求1~5任一项所述的业务服务扩缩容方法，其特征在于，所述将所述业务请求推送入消息队列，包括：

同步或异步将所述业务请求推送入所述消息队列。

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

路由模块，用于接收业务请求，将所述业务请求转发至对应的业务服务，所述业务请求携带指定接口标识信息；

信息获取模块，获取所述业务请求携带的指定接口标识信息以及预设关联关系，所述预设关联关系包括不同的业务服务的业务标识与每个所述业务服务的接口的接口标识信息之间的映射关系；

业务标识确定模块，用于基于所述指定接口标识信息和所述预设关联关系，确定所述业务请求对应的目标业务标识；

请求处理模块，用于将所述目标业务标识添加入所述业务请求，之后将所述业务请求推送入消息队列；

指标计算模块，用于从所述消息队列获取多个业务请求，基于预设业务指标计算多个所述业务请求的业务指标参数，多个所述业务请求均携带所述目标业务标识；

扩缩容模块，用于在所述业务指标参数满足预设扩缩容条件时，基于所述目标业务标识对该目标业务标识指示的业务服务进行扩缩容操作。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1~7任一项所述业务服务扩缩容方法的步骤。

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

处理器；以及

存储器，用于存储计算机程序；

其中，所述处理器配置为经由执行所述计算机程序来执行权利要求1~7任一项所述业务服务扩缩容方法的步骤。

Images