一种衡量计算机服务压力状态的通用系统及实现方法与流程

1.本技术涉及计算机技术领域，尤其涉及一种衡量计算机服务压力状态的通用系统及实现方法。


背景技术：

2.在计算机集群服务中，随着集群访问压力越来越大，需要对计算机集群进行扩容，增加计算机集群中的进行服务的计算机节点数量；当访问压力减少时，又需要对计算机集群进行缩容，即减少计算机集群中的进行服务的计算机数量。目前一般是由人工操作完成分布式计算机集群的扩容与缩容，不仅操作比较麻烦，更难做到分布式计算机集群的实时、快速地扩容与缩容，进而难以提供稳定的服务算力。而且，在使用计算机集群中各计算机节点的服务时需要只能包年或包月使用，当使用的服务算力低于计算机集群所提供的算力时，极易造成算力的浪费，也会造成租户费用的浪费，降低租户体验。


技术实现要素：

3.本技术实施例的目的在于提供一种衡量计算机服务压力状态的通用系统及实现方法，以提高计算机的资源调整的便捷性，同时有效避免了计算机集群所提供的算力的浪费以及租户费用的浪费。
4.第一方面，本技术实施例提供了一种衡量计算机服务压力状态的通用系统，该系统包括：获取模块，用于获取第一服务相关的服务指标数据；其中，服务指标数据包括用于运行第一服务的至少一个计算机节点中每个计算机节点的每秒查询率；数据处理模块，用于基于所述服务指标数据，确定服务指标最大值，并使用所述服务指标最大值得到目标服务数据，其中，所述目标服务数据包括服务冗余度或目标算力成本值。
5.因此，借助于上述技术方案，本技术实施例能够根据第一服务相关的服务指标数据，可以得到服务冗余度或目标算力成本值，进而可以为运行第一服务的计算机节点进行扩缩容提供准确有效的数据指标，还可以获取租户使用第一服务消耗的算力数据，避免了计算机集群所提供的算力的浪费以及租户费用的浪费，提升了租户体验。
6.在一个可能的实施例中，数据处理模块具体用于：基于服务指标最大值，计算所述服务冗余度，并判断服务冗余度是否在预设范围内，若确定服务冗余度不在预设范围内并且服务冗余小于预设范围，则生成用于增加运行第一服务的计算机节点的扩容指令，若确定服务冗余度不在预设范围内并且服务冗余大于预设范围，则生成用于减少运行第一服务的计算机节点的缩容指令。
7.因此，借助于上述技术方案，本技术实施例能够根据第一服务相关的服务指标数据，自动实现对运行第一服务的计算机节点进行扩缩容，从而不仅能够提高计算机节点资源调整的便捷性，还能够节约计算资源的使用成本。
8.在一个可能的实施例中，服务指标数据包括缓存的服务指标子数据和未缓存的服务指标子数据，并且缓存的服务指标子数据为获取模块缓存的数据，以及未缓存的服务指
标子数据为获取模块未缓存的数据；所述系统，还包括查询数据库；获取模块，具体用于：根据用于查询服务指标数据的指标查询信息，从本地缓存的数据中获取缓存的服务指标子数据，并从查询数据库中读取未缓存的服务指标子数据。
9.在一个可能的实施例中，服务指标数据是对原始服务指标数据进行处理后得到的；所述系统，还包括：采集模块，用于采集原始服务指标数据；分发模块，用于将原始服务指标数据存储到系统的分布式发布消息订阅模块内对应的主题中；存储模块，用于对分布式发布消息订阅模块内对应的主题中存储的原始服务指标数据进行格式化处理，得到格式化处理结果，并将格式化处理结果保存到查询数据库中。
10.在一个可能的实施例中，存储模块，包括：聚合模块，用于在确定原始服务指标数据大于等于预设数据的情况下，对分布式发布消息订阅模块内对应的主题中存储的原始服务指标数据进行聚合，得到聚合结果；存储子模块，用于对聚合结果进行进行格式化处理，得到格式化处理结果，并将格式化处理结果存储到查询数据库中。
11.在一个可能的实施例中，原始服务指标数据包括监控数据和流媒体数据，分布式发布消息订阅模块包括用于存储监控数据的监控主题和用于存储流媒体数据的流媒体主题。
12.在一个可能的实施例中，所述数据处理模块具体用于：基于所述服务指标最大值，获取单位算力成本值，并根据所述单位算力成本值得到所述目标算力成本值。
13.本技术实施例通过服务指标最大值可以得到单位算力成本值进而得到目标算力成本值，可以准确获取租户使用第一服务时所消耗的算力值，进而获取租户实际使用成本，避免了计算机算力资源的浪费的同时，也避免了租户使用成本的浪费，提升了租户体验。
14.在一个可能的实施例中，所述数据处理模块包括:获取子模块，用于获取与检测周期对应的检测特征值，以及获取算力成本特征值；求解子模块，用于将所述检测特征值与所述算力成本特征值相乘得到第一特征值，并求解所述第一特征值与所述服务指标最大值的比值，得到所述单位算力成本值；检测子模块，用于获取使用所述第一服务所消耗的实际算力成本值，其中，所述实际算力成本值是通过各检测周期内所使用的算力值得到的；处理子模块，用于将所述实际算力成本值与算力关联因子相乘，获取所述目标算力成本值，其中，所述算力关联因子是根据算力固定成本确定的。
15.本技术实施例通过获取与目标算力成本值相关的单位算力成本值、实际算力成本值和算力关联因子，得到最终的目标算力成本值，可以根据租户对第一服务的使用时长，得到准确度较高的实际使用算力，进而得到租户需要付出的成本代价，可以提升租户体验，避免计算机提供的算力资源较多时造成浪费的问题。
16.在一个可能的实施例中，所述获取子模块具体用于：设定所述检测周期，并将所述检测周期与单日时长的比值作为所述检测特征值；获取固定时间内的所述算力固定成本，将所述算力固定成本与所述固定时间的比值作为所述算力成本特征值。
17.本技术实施例通过上述实施例可以获取准确度较高的与目标算力成本相关联的数据，为后续获取目标算力成本提供数据基础。
18.在一个可能的实施例中，所述检测子模块具体用于：获取所述各检测周期内所使用的各算力值；将所述各算力值与所述单位算力成本值相乘，获取各检测周期成本值；对所述各检测周期成本值进行累加，获取所述实际算力成本值。
19.本技术实施例通过上述实施例可以获取准确度较高的租户使用第一服务所耗费的实际算力的实际算力成本。
20.第二方面，本技术实施例提供了一种衡量计算机服务压力状态的实现方法，所述实现方法应用于系统，所述系统包括获取模块和数据处理模块，衡量计算机服务压力状态的实现方法包括：获取模块获取第一服务相关的服务指标数据；其中，服务指标数据包括用于运行第一服务的至少一个计算机节点中每个计算机节点的每秒查询率；所述数据处理模块基于所述服务指标数据，确定服务指标最大值，并使用所述服务指标最大值得到目标服务数据，其中，所述目标服务数据包括服务冗余度或目标算力成本值。
21.在一个可能的实施例中，所述基于所述服务指标数据，确定服务指标最大值，并使用所述服务指标最大值得到目标服务数据，包括：服务指标数据，计算服务冗余度，并判断服务冗余度是否在预设范围内，若确定服务冗余度不在预设范围内并且服务冗余小于预设范围，则生成用于增加运行第一服务的计算机节点的扩容指令，若确定服务冗余度不在预设范围内并且服务冗余大于预设范围，则生成用于减少运行第一服务的计算机节点的缩容指令。
22.在一个可能的实施例中，服务指标数据包括缓存的服务指标子数据和未缓存的服务指标子数据，并且缓存的服务指标子数据为获取模块缓存的数据，以及未缓存的服务指标子数据为获取模块未缓存的数据，所述系统还包括查询数据库；其中，获取模块获取第一服务相关的服务指标数据，包括：获取模块根据用于查询服务指标数据的指标查询信息，从本地缓存的数据中获取缓存的服务指标子数据，并从查询数据库中读取未缓存的服务指标子数据。
23.在一个可能的实施例中，服务指标数据是对原始服务指标数据进行处理后得到的，所述系统还包括采集模块、分发模块、分布式发布消息订阅模块和存储模块；其中，衡量计算机服务压力状态的实现方法还包括：采集模块采集原始服务指标数据；分发模块将原始服务指标数据存储到系统的分布式发布消息订阅模块内对应的主题中；存储模块对分布式发布消息订阅模块内对应的主题中存储的原始服务指标数据进行格式化处理，得到格式化处理结果，并将格式化处理结果保存到查询数据库中。
24.在一个可能的实施例中，存储模块包括聚合模块和存储子模块；其中，存储模块对分布式发布消息订阅模块内对应的主题中存储的原始服务指标数据进行格式化处理，得到格式化处理结果，并将格式化处理结果保存到查询数据库中，包括：聚合模块在确定原始服务指标数据大于等于预设数据的情况下，对分布式发布消息订阅模块内对应的主题中存储的原始服务指标数据进行聚合，得到聚合结果；存储子模块对聚合结果进行进行格式化处理，得到格式化处理结果，并将格式化处理结果存储到查询数据库中。
25.在一个可能的实施例中，原始服务指标数据包括监控数据和流媒体数据，分布式发布消息订阅模块包括用于存储监控数据的监控主题和用于存储流媒体数据的流媒体主题。
26.在一个可能的实施例中，所述基于所述服务指标数据，确定服务指标最大值，并使用所述服务指标最大值得到目标服务数据，包括：基于所述服务指标最大值，获取单位算力成本值，并根据所述单位算力成本值得到所述目标算力成本值。
27.在一个可能的实施例中，所述基于所述服务指标最大值，获取单位算力成本值，并
根据所述单位算力成本值得到所述目标算力成本值，包括:获取与检测周期对应的检测特征值，以及获取算力成本特征值；将所述检测特征值与所述算力成本特征值相乘得到第一特征值，并求解所述第一特征值与所述服务指标最大值的比值，得到所述单位算力成本值；获取使用所述第一服务所消耗的实际算力成本值，其中，所述实际算力成本值是通过各检测周期内所使用的算力值得到的；将所述实际算力成本值与算力关联因子相乘，获取所述目标算力成本值，其中，所述算力关联因子是根据算力固定成本确定的。
28.在一个可能的实施例中，所述获取与检测周期对应的检测特征值，以及获取算力成本特征值，包括：设定所述检测周期，并将所述检测周期与单日时长的比值作为所述检测特征值；获取固定时间内的所述算力固定成本，将所述算力固定成本与所述固定时间的比值作为所述算力成本特征值。
29.在一个可能的实施例中，所述获取使用所述第一服务所消耗的实际算力成本值，包括：获取所述各检测周期内所使用的各算力值；将所述各算力值与所述单位算力成本值相乘，获取各检测周期成本值；对所述各检测周期成本值进行累加，获取所述实际算力成本值。
30.第三方面，本技术的一些实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现如第二方面任一实施例所述的方法。
31.第四方面，本技术的一些实施例提供一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其中，所述处理器执行所述程序时可实现如第二方面任一实施例所述的方法。
32.第五方面，本技术的一些实施例提供一种计算机程序产品，所述的计算机程序产品包括计算机程序，其中，所述的计算机程序被处理器执行时可实现如第二方面任一实施例所述的方法。
33.为使本技术实施例所要实现的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
34.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本技术的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
35.图1示出了本技术实施例提供的一种衡量计算机服务压力状态的通用系统的结构示意图；
36.图2示出了本技术实施例提供的衡量计算机服务压力状态的实现方法的流程图之一；
37.图3示出了本技术实施例提供的衡量计算机服务压力状态的实现方法的流程图之二；
38.图4示出了本技术实施例提供的一种电子设备示意图。
go sdk软件可将第一服务相关的原始服务指标数据推送给网关gateway。以及，该kafka软件可建立有租户拆分体系，以为系统的高可用性和可扩展性提供了重要支撑，从而该网关gateway可确定第一服务相关的原始服务指标数据所属的租户，并将第一服务相关的原始服务指标数据存储到kafka软件的指定主题topic中。其中，kafka软件是指标高链路可用的关键，以及当下游(例如，clickhouse数据库)存储异常时，kafka软件可起到临时存储指标的作用，以及该kafka软件还支持存储模块中的聚合模块对指标的二次聚合，从而降低了指标存储压力，为指标治理带来了可能。
50.应理解，该网关gateway可确定第一服务相关的原始服务指标数据所属的租户，并将第一服务相关的原始服务指标数据存储到kafka软件的指定主题topic中的具体过程可根据实际需求来进行设置，本技术实施例并不局限于此。
51.例如，该网关gateway确定第一服务相关的原始服务指标数据属于第一租户，并且由于原始服务指标数据可包括监控数据和流媒体数据，以及该kafka软件可建立有第一租户对应的监控主题topic和流媒体主题topic，从而该网关gateway可确定原始服务指标数据的具体类型，以及在确定原始服务指标数据的数据类型为监控数据的情况下，该网关gateway可将原始服务指标数据存储到第一租户对应的监控主题topic中；以及在确定原始服务指标数据的数据类型为流媒体数据的情况下，该网关gateway可将原始服务指标数据存储到第一租户对应的流媒体主题topic中。
52.这里需要说明的是，该kafka软件的租户相关的具体租户数量等均可根据实际需求来进行设置，本技术实施例并不局限于此。
53.以及，在将第一服务相关的原始服务指标数据存储到分布式发布消息订阅模块对应的主题topic中后，存储模块可对分布式发布消息订阅模块内对应的主题中存储的原始服务指标数据进行格式化处理，得到格式化处理结果，并将格式化处理结果保存到clickhouse数据库中。
54.应理解，存储模块的具体模块和其所包含的模块等均可根据实际需求来进行设置，本技术实施例并不局限于此。
55.可选地，在存储模块包括聚合模块和存储子模块以及聚合模块为大数据实时计算引擎flink以及存储子模块为消费者consumer的情况下，该flink可在确定原始服务指标数据大于等于预设数据的情况下，对分布式发布消息订阅模块内对应的主题中存储的原始服务指标数据进行聚合，得到聚合结果，以及该consumer可对聚合结果进行进行格式化处理，得到格式化处理结果，并通过批写入的方式将格式化处理结果存储到clickhouse数据库中。其中，预设数据的大小可根据实际需求来进行设置，本技术实施例并不局限于此。
56.因此，本技术实施例可针对原始服务指标数据的数据量过大的情况，从而可通过流失聚合链路(即flink)对原始服务指标数据进行聚合，并将聚合结果插入到存储链路(即consumer)中，以及该consumer会消费kafka中的数据，并将其存储到clickhouse数据库中。
57.这里需要说明的是，该consumer消费数据主要包括以下两种：一种是对原始服务指标数据进行格式化处理；另外一种是批写入的方式。
58.以及，存储子模块还可在确定原始服务指标数据小于预设数据的情况下，直接通过批写入的方式将其存储到clickhouse数据库中。
59.这里需要说明的是，该consumer是数据链路的关键一环，如果设计不合理，
consumer会成为链路的性能瓶颈。clickhouse友好的写入方式是批写入，因此consumer必须具有缓存功能；同时消费大量的数据会消耗大量内存，如果不控制批写入数据量会导致consumer内存溢出。
60.以及，本技术实施例中的系统的整套架构使用clickhouse存储是因为clickhouse的高可用，高性能，以及列式数据库与需求完美切合度的原因。例如，mysql等oltp数据库，在管理大规模数据时，查询和插入都会成为性能瓶颈；再例如，elasticsearch可以管理大规模数据，但重在检索，但未对聚合运算优化。然而，clickhouse列式数据库对于稀疏查询，聚合运算的场景十分适合。
61.以及，获取模块还可获取待查询的第一服务相关的服务指标数据，以及，数据处理模块基于所述服务指标数据，确定服务指标最大值，并使用所述服务指标最大值得到目标服务数据，其中，所述目标服务数据包括服务冗余度或目标算力成本值。其中，在本技术的一些实施例中在得到服务冗余度之后，需要判断服务冗余度是否在预设范围内，若确定服务冗余度不在预设范围内并且服务冗余小于预设范围，则生成用于增加运行第一服务的计算机节点的扩容指令(即进行扩容)，若确定服务冗余度不在预设范围内并且服务冗余大于预设范围，则生成用于减少运行第一服务的计算机节点的缩容指令(即进行缩容)。其中，第一服务为至少一个服务中任意的一个服务，服务指标数据包括用于运行第一服务的至少一个计算机节点中每个计算机节点的每秒查询率(queries-per-second，qps)；预设范围的具体范围可根据实际需求来进行设置，本技术实施例并不局限于此。例如，预设范围可以为200％至300％。
62.不难理解的是，计算机节点指的是计算机集群中的一个计算机设备。其中，计算机指的是可以提供算力资源或进行数据处理的任一类型的终端或其他节点设备，本技术在此不作具体限定。
63.应理解，获取模块的具体模块和数据处理模块的具体模块等均可根据实际需求来进行设置，本技术实施例并不局限于此。
64.例如，在获取模块为代理计算机节点proxy以及数据处理模块为redundancy keeper的情况下，该proxy可根据用于查询所述服务指标数据的指标查询信息，获取待查询的第一服务相关的服务指标数据，以及该redundancy keeper可基于待查询的第一服务相关的服务指标数据，获取服务指标最大值，然后再基于服务指标最大值得到最终的服务冗余度或目标算力成本值。
65.这里需要说明的是，该proxy降低存储查询压力，管理租户定额quota。以及，该clickhouse是列式数据库，指标数据是时序查询场景，这种场景下clickhouse查询放大十分严重，proxy会对时间分片，缓存数据稳定的时间段，clickhouse只需聚合计算最近时间的数据，系统压力大大减小。同时，不同租户的查询请求重要性不同，业务方查询重要性要高于平台方查询；不同租户查询应该互相隔离，proxy建立租户模型，管理租户quota，保证租户之间查询不会相互影响。
66.这里还需要说明的是，redundancy keeper可对接各类部署平台，计算/保持服务冗余度。redundancy keeper对具有流量潮汐特性的服务，提供高稳定性，高资源利用率保障。以及，该redundancy keeper会循环查询服务冗余度，当服务冗余度较低时，会触发服务扩容逻辑，保证服务稳定性。当服务冗余度较高时，会触发缩容逻辑，保证资源利用率。
67.还应理解，该proxy可根据用于查询服务指标数据的指标查询信息，获取待查询的第一服务相关的服务指标数据的具体过程可根据实际需求来进行设置，本技术实施例并不局限于此。
68.例如，在确定待查询的第一服务在预设时间段内相关的服务指标数据的情况下，该proxy可从本地缓存的数据中查询是有与待查询的第一服务相关并且处于预设时间段内的服务指标数据的情况下，若确定本次缓存的数据中包括全部的待查询的第一服务相关的服务指标数据，则可直接从本地的缓存数据中获取待查询的第一服务相关的服务指标数据；若确定本次缓存的数据中包括部分的待查询的第一服务相关的服务指标数据，则可从本地本地缓存的数据中获取缓存的服务指标子数据，并从clickhouse数据库中读取未缓存的服务指标子数据；若确定本次缓存的数据中不包含任何待查询的第一服务相关的服务指标数据，则直接从clickhouse数据库中读取服务指标数据。
69.还应理解，该redundancy keeper可基于待查询的第一服务相关的服务指标数据，计算服务冗余度的具体计算方式可根据实际需求来进行设置，本技术实施例并不局限于此。
70.例如，可通过如下公式计算冗余度：
71.计算机节点平均每秒查询率＝线上总每秒查询率/计算机节点数；
72.冗余度＝单机压力测试得到的每秒查询率/计算机节点平均每秒查询率；
73.其中，线上总每秒查询率为运行第一服务的所有计算机节点的上总每秒查询率；计算机节点数为运行第一服务的所有计算机节点的数量；单机压力测试得到的每秒查询率为通过对单个计算机节点进行压力测试得到的每秒查询率。其中，单个计算机节点可以为任意的一个计算机，也可以为指定的一个计算机。
74.还应理解，该redundancy keeper计算扩缩容计算机数量的具体方式可根据实际需求来进行设置，本技术实施例并不局限于此。
75.例如，可通过如下公式计算扩缩容计算机数量：
76.第一服务期望的计算机节点个数＝(配置的冗余度的上下限平均值/线上冗余度取到点的中值)*当前线上计算机节点数；
77.扩缩容计算机节点数＝(第一服务期望的计算机节点个数-运行第一服务的当前计算机节点数)*预设步长；
78.其中，配置的冗余度的上下限值为预设的冗余度区间的上下限的平均值。例如，在预设的冗余度区间为60％-70％的情况下，该配置的冗余度的上下限值为65％；线上冗余度取到点的中值是所有计算机节点的加权调用量(即metric qps)的平均值；当前线上计算机节点数是指计算机集群所包含的所有计算机的数量；预设步长的具体值可根据实际需求来进行设置，本技术实施例并不局限于此。例如，预设步长为30％。
79.还应理解，除了上述获取服务冗余度的方式之外，还可通过其他的方式来获取服务冗余度，本技术实施例并不局限于此。
80.可选地，加权调用量metric qps度量指标是把不同的qps请求对服务器资源占用时长过长纳入了考量，该方法将qps按照时长进行分段，每个分段确定与之对应的权重值，进而计算单机最大承载能力(也就是最大单机指标metric)。以及，该metric qps度量指标相对于简单qps更能精准地反映业务实际的负载情况。
81.以及，可通过如下公式计算服务冗余度：
[0082][0083][0084]
为了便于理解上述计算公式，下面通过具体的实施例来进行描述。
[0085]
例如，以5台计算机为例，分段规则及压测结果如下表1所示。
[0086]
表1
[0087]
耗时区间区间范围权重值压测时间内请求发生次数10-10ms0.14000210-50ms0.53000350-100ms220004100-500ms49005500ms8100
[0088]
在上表1所示的分段压测结果规则的基础上，可通过如下方式计算服务冗余度：
[0089][0090][0091]
因此，借助于上述技术方案，本技术实施例能够根据第一服务相关的服务指标数据，自动实现对运行第一服务的计算机节点进行扩缩容，从而不仅能够提高计算机的资源调整的便捷性，还能够节约计算资源的使用成本。
[0092]
应理解，上述系统仅是示例性的，本领域技术人员可根据实际需求对系统进行各种变形，修改或变形之后的内容也在本技术保护范围内。
[0093]
例如，虽然图1仅示出了一个存储模块和一个查询数据库，但本领域的技术人员可将其修改成两个存储模块和两个查询数据库等。
[0094]
请参见图2，图2示出了本技术的一些实施例提供的一种衡量计算机服务压力状态的实现方法的流程图。具体地，如图2所示的衡量计算机服务压力状态的实现方法可以应用于衡量计算机服务压力状态的通用系统，该系统包括获取模块和数据处理模块，该衡量计算机服务压力状态的实现方法包括：
[0095]
步骤s210，获取模块获取第一服务相关的服务指标数据；其中，服务指标数据包括用于运行第一服务的至少一个计算机节点中每个计算机节点的每秒查询率；
[0096]
步骤s220，数据处理模块基于服务指标数据确定服务指标最大值，并使用所述服务指标最大值得到计算服务冗余度，并判断服务冗余度是否在预设范围内，若确定服务冗余度不在预设范围内并且服务冗余小于预设范围，则生成用于增加运行第一服务的计算机节点的扩容指令，若确定服务冗余度不在预设范围内并且服务冗余大于预设范围，则生成用于减少运行第一服务的计算机节点的缩容指令。
[0097]
在一个可能的实施例中，服务指标数据包括缓存的服务指标子数据和未缓存的服
务指标子数据，并且缓存的服务指标子数据为获取模块缓存的数据，以及未缓存的服务指标子数据为获取模块未缓存的数据，衡量计算机服务压力状态的通用系统还包括查询数据库；
[0098]
其中，获取模块获取第一服务相关的服务指标数据，包括：
[0099]
获取模块根据用于查询服务指标数据的指标查询信息，从本地缓存的数据中获取缓存的服务指标子数据，并从查询数据库中读取未缓存的服务指标子数据。
[0100]
在一个可能的实施例中，服务指标数据是对原始服务指标数据进行处理后得到的，衡量计算机服务压力状态的通用系统还包括采集模块、分发模块、分布式发布消息订阅模块和存储模块；
[0101]
其中，衡量计算机服务压力状态的实现方法还包括：
[0102]
采集模块采集原始服务指标数据；
[0103]
分发模块将原始服务指标数据存储到系统的分布式发布消息订阅模块内对应的主题中；
[0104]
存储模块对分布式发布消息订阅模块内对应的主题中存储的原始服务指标数据进行格式化处理，得到格式化处理结果，并将格式化处理结果保存到查询数据库中。
[0105]
在一个可能的实施例中，存储模块包括聚合模块和存储子模块；
[0106]
其中，存储模块对分布式发布消息订阅模块内对应的主题中存储的原始服务指标数据进行格式化处理，得到格式化处理结果，并将格式化处理结果保存到查询数据库中，包括：
[0107]
聚合模块在确定原始服务指标数据大于等于预设数据的情况下，对分布式发布消息订阅模块内对应的主题中存储的原始服务指标数据进行聚合，得到聚合结果；
[0108]
存储子模块对聚合结果进行进行格式化处理，得到格式化处理结果，并将格式化处理结果存储到查询数据库中。
[0109]
在一个可能的实施例中，原始服务指标数据包括监控数据和流媒体数据，分布式发布消息订阅模块包括用于存储监控数据的监控主题和用于存储流媒体数据的流媒体主题。
[0110]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的方法的具体工作过程，可以参考前述系统的相关描述，在此不再过多赘述。
[0111]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统的具体工作过程，可以参考前述方法中的对应过程，在此不再过多赘述。
[0112]
由于上述本技术的一些实施例提供的衡量计算机服务压力状态的通用系统或实现方法可以将qps按照时长进行分段，每个分段确定与之对应的权重值，进而计算单机最大承载能力，以此精准地反映业务实际的负载情况。因此，在本技术的另一些实施例中还可以将上述的qps应用于：根据计算机节点算力进行计费的技术领域，也就是基于租户的算力需求，计算出租户应该实际付出的算力成本。该方法可以有效避免算力提供过多造成浪费的问题，以及避免租户付出的算力成本的浪费，提升租户体验。
[0113]
下面以某一平台的某个租户为第一服务所支付一个月的固定算力费用的场景为例，示例性阐述将本技术的另一些实施例提供的一种衡量计算机服务压力状态的实现方法应用至服务算力使用及使用费用的计算领域的实现过程。
[0114]
请参见附图3，附图3为本技术的另一些实施例提供的衡量计算机服务压力状态的实现方法流程图。下面示例性阐述该方法的具体实现过程。
[0115]
s310，获取第一服务相关的服务指标数据。
[0116]
在本技术的另一些实施例中，可以利用服务请求检测设备获取租户在多台计算机上对第一服务发送的请求次数(作为服务指标数据的一个具体示例)。其中，计算机的数量可以根据实际的情况进行设定，该步骤的目的是计算多台计算机中任一台计算机(作为计算机集群中任一计算机节点的一个具体示例)的服务指标最大值。
[0117]
例如，作为本技术的一个具体示例，利用服务请求检测设备，检测在预设时间内租户分别在五台计算机(作为多台计算机的一个具体示例)上对第一服务发送的请求次数。如表2所示。由表2可知，租户在前10ms内(也就是0-10ms)对第一服务的请求次数发生4000次，前10ms的请求次数所占据的权重值为0.1。租户在10ms-50ms内对第一服务的请求次数发生3000次，10ms-50ms的请求次数所占据的权重值为0.5。后续请求次数也可通过表2读取，在此不作赘述。
[0118]
表2
[0119][0120][0121]
s320，基于所述服务指标数据，确定服务指标最大值。
[0122]
在本技术的另一些实施例中，可以根据租户对第一服务在预定时间内发生的请求次数(也就是租户对第一服务的使用情况)，得到服务指标最大值。其中，服务指标最大值是通过单机最大加权调用量(也就是单机最大metric qps)来表征的，也就是单机最大加权调用量是根据表1中的服务指标数据得到的。
[0123]
例如，作为本技术的一个具体示例，通过上述实施例提供的单机指标metric的计算公式得到服务指标最大值。
[0124]
例如，通过如下公式获取单机最大metric qps：
[0125][0126]
s330，基于所述服务指标最大值，获取单位算力成本值；
[0127]
在本技术的另一些实施例中，上述在获取多台计算机的服务指标最大值后，还需要获取多台计算机中任一台的单位算力成本值。
[0128]
在本技术的另一些实施例中，s330还可以包括：s331，设定所述检测周期，并将所述检测周期与单日时长的比值作为所述检测特征值。s332，获取固定时间内的所述算力固定成本，将所述算力固定成本与所述固定时间的比值作为所述算力成本特征值。s333，将所
述检测特征值与所述算力成本特征值相乘得到第一特征值，并求解所述第一特征值与所述服务指标最大值的比值，得到所述单位算力成本值。
[0129]
例如，在本技术的另一些实施例中，将检测周期设置为t(例如，t为15s、20s或10s等)，每隔时间t对任一台计算机检测一次使用第一服务时消耗的算力值。单日时长以一天的24h(其中，24h为86400s)为标准。固定时间以一个月30天为标准(也可以是以年为标准，本技术在此不作具体限定)，算力固定成本为在固定时间内租户所需要支付的算力费用。
[0130]
例如，作为本技术的一个具体示例，通过如下公式获取单位算力成本值c
mqps
：
[0131][0132]
其中，算力固定成本与固定时间的比值为算力成本特征值，t与86400的比值为检测特征值。例如，租户使用第一服务一个月的算力固定成本为53元，t＝15秒，也就是每隔15秒对租户使用第一服务的情况进行检测，以此获取租户的实际使用时长。
[0133]
s340，基于单位算力成本值获取使用所述第一服务所消耗的实际算力成本值。
[0134]
在本技术的另一些实施例中s340可以包括：获取所述各检测周期内所使用的各算力值；将所述各算力值与所述单位算力成本值相乘，获取各检测周期成本值；对所述各检测周期成本值进行累加，获取所述实际算力成本值。
[0135]
例如，作为本技术的一个具体示例，通过如下公式获取实际算力成本值：
[0136][0137]
其中，mi为在第i个检测周期内租户对第一服务的实际使用第i算力值。其中，n为检测周期的个数，n是根据租户的实际使用总时长与t的比值得到的(不足一个周期的按一个周期算)。例如，租户的实际使用总时长为50s，50s包含3个完整的检测周期和剩余的5s，此时，也将5s以一个完整的检测周期算，也就是50s含有4个检测周期，n＝4，然后根据测得的租户在每个检测周期内使用的算力值，并累加即可得到实际算力成本值。
[0138]
s350，将所述实际算力成本值与算力关联因子相乘，获取所述目标算力成本值。
[0139]
在本技术的另一些实施例中，根据实际算力成本值和算力关联因子可以得到目标算力成本值。其中目标算力成本值用于表征租户使用第一服务的实际算力数据所产生的费用，该费用可以是固定算力费用中的中的部分费用或全部费用，具体是根据租户的使用情况决定的。
[0140]
例如，作为本技术的一个具体示例，通过如下公式获取目标算力成本值：
[0141]
目标算力成本值＝实际算力成本值*(1+x)
[0142]
其中，1+x为算力关联因子，x为第一服务算力固定成本的毛利率(由算力固定成本的实际情况确定的)。
[0143]
通过上述本技术的另一些实施例可知，在实际的应用场景中，可以根据租户使用的实际算力数据来支付相应的目标算力成本，该衡量计算机服务压力状态的实现方法可以在服务算力使用领域为租户提供合理的算力使用计费方式，即多用多消费，少用少消费，一方面可以避免提供的算力高于租户需求时造成的浪费，一方面还可以提升租户体验。
[0144]
在本技术的另一些实施例中，如图3所示的衡量计算机服务压力状态的实现方法可以应用于衡量计算机服务压力状态的通用系统，其中，该系统中的数据处理模块还可以用于：基于所述服务指标最大值，获取单位算力成本值，并根据所述单位算力成本值得到所述目标算力成本值。
[0145]
在本技术的另一些实施例中，所述数据处理模块包括：获取子模块，用于获取与检测周期对应的检测特征值，以及获取算力成本特征值；求解子模块，用于将所述检测特征值与所述算力成本特征值相乘得到第一特征值，并求解所述第一特征值与所述服务指标最大值的比值，得到所述单位算力成本值；检测子模块，用于获取使用所述第一服务所消耗的实际算力成本值，其中，所述实际算力成本值是通过各检测周期内所使用的算力值得到的；处理子模块，用于将所述实际算力成本值与算力关联因子相乘，获取所述目标算力成本值，其中，所述算力关联因子是根据算力固定成本确定的。
[0146]
在本技术的另一些实施例中，所述获取子模块具体用于：设定所述检测周期，并将所述检测周期与单日时长的比值作为所述检测特征值；获取固定时间内的所述算力固定成本，将所述算力固定成本与所述固定时间的比值作为所述算力成本特征值。
[0147]
在本技术的另一些实施例中，所述检测子模块具体用于：获取所述各检测周期内所使用的各算力值；将所述各算力值与所述单位算力成本值相乘，获取各检测周期成本值；对所述各检测周期成本值进行累加，获取所述实际算力成本值。
[0148]
本技术的一些实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现如上述实施例提供的方法中的任意实施例所对应方法的操作。
[0149]
本技术的一些实施例还提供了一种计算机程序产品，所述的计算机程序产品包括计算机程序，其中，所述的计算机程序被处理器执行时可实现如上述实施例提供的方法中的任意实施例所对应方法的操作。
[0150]
如图4所示，本技术的一些实施例提供一种电子设备400，该电子设备400包括：存储器410、处理器420以及存储在存储器410上并可在处理器420上运行的计算机程序，其中，处理器420通过总线430从存储器410读取程序并执行所述程序时可实现如上述任意实施例的方法。
[0151]
处理器420可以处理数字信号，可以包括各种计算结构。例如复杂指令集计算机结构、结构精简指令集计算机结构或者一种实行多种指令集组合的结构。在一些示例中，处理器420可以是微处理器。
[0152]
存储器410可以用于存储由处理器420执行的指令或指令执行过程中相关的数据。这些指令和/或数据可以包括代码，用于实现本技术实施例描述的一个或多个模块的一些功能或者全部功能。本公开实施例的处理器420可以用于执行存储器410中的指令以实现上述所示的方法。存储器410包括动态随机存取存储器、静态随机存取存储器、闪存、光存储器或其它本领域技术人员所熟知的存储器。
[0153]
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0154]
本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本技术的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
[0155]
另外，在本技术各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
[0156]
所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0157]
以上所述仅为本技术的优选实施例而已，并不用于限制本技术，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
[0158]
以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应所述以权利要求的保护范围为准。