接口容量评估方法、装置和系统与流程

1.本公开实施例涉及一种接口容量评估方法、装置和系统。


背景技术：

2.进行容量评估是控制服务器成本的重要环境。通常通过对服务进行压测来获知服务当前的容量水平，再考虑新需求的使用模型，动态去考虑是否现有资源足够支撑这次变更。
3.现有容量评估方法仅适用于整体用户的容量评估，不能对每个接口的容量进行准确评估。


技术实现要素：

4.有鉴于此，本技术提供一种接口容量评估方法、装置和系统，能够准确评估每个接口当前可调用的容量。
5.为解决上述技术问题，本技术的技术方案是这样实现的：
6.在一个实施例中，提供了一种接口容量评估方法，所述方法包括：
7.接收到业务端发送的评估接口容量的请求时，获取记录的最新周期的cpu占比和所述接口的总调用量；
8.根据所述cpu占比和所述接口的总调用量计算所述接口的第一可用容量；
9.若确定所述请求中携带的需求量小于所述第一可用容量，则向所述业务端发送所述接口的第一可用容量满足调用的响应；
10.其中，所述cpu占比和所述接口的总调用量为对应周期中所有接口的总调用量最大的时间段对应的cpu占比和所述接口的总调用量，每个周期划分为多个相同时长的连续时间段
11.在另一个实施例中，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如所述接口容量评估的方法。
12.在另一个实施例中，提供一种接口容量评估系统，所述系统包括：
13.业务端以及所述电子设备，其中，所述业务端与所述电子设备信号连接。
14.在另一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现所述接口容量评估方法的步骤。
15.在另一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现所述接口容量评估方法。
16.由上面的技术方案可见，上述实施例中通过历史记录的cpu占比，以及接口的调用量来评估当前接口的可用容量，能够准确评估每个接口当前可调用的容量。
附图说明
17.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
18.图1为本技术实施例一中接口容量评估流程示意图；
19.图2为本技术实施例二中接口容量评估流程示意图；
20.图3为本技术实施例中接口容量评估装置结构示意图；
21.图4为本技术实施例中接口容量评估系统示意图；
22.图5为本发明实施例提供的电子设备的实体结构示意图。
具体实施方式
23.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
24.本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例，例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他步骤或单元。
25.下面以具体实施例对本发明的技术方案进行详细说明。下面几个具体实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。
26.本技术实施例中提供一种接口容量评估方法，通过历史记录的cpu占比，以及接口的调用量来评估当前接口的可用容量，能够准确评估每个接口当前可调用的容量。
27.本技术实施例中周期记录相关信息，具体实现时将每个周期划分为多个时长相同的连续时间段，周期记录对应周期中每个接口的调用量，以所述时间段为单位统计每个接口的总调用量，并获取所有接口的总调用量最大的时间段对应的cpu占比。
28.在具体实现时，由于仅使用调用总量最高的时间段对应的cpu占比和接口的调用总量计算，因此，针对每个周期可以仅记录调用总量最高的时间段的cpu占比，以及每个接口的总调用量；也可以记录每个时间段的总调用量，cpu占比，以及接口的总调用量；待需要评估的时候再获取总调用量的最大的时间段的cpu占比，以及接口的总调用量。
29.这里的周期可以根据实际需要设置周期，对周期的长短不进行具体限制，如1天、1周等。
30.在具体实现时，可以每周期采集实际数据进行数据记录，也可以在一个周期中没有新的调用量增加，或没有原先的调用量减少时，直接使用前一个周期的数据作为当前周期的相关数据。
31.具体实现时，可以设置一分钟为一个时间段，但不限于该设置。
32.在具体实现时，记录每个接口的实时调用量，针对每个时间段可以通过接口名称做聚合，计算该时间段的总调用量，确定总调用量最高的时间段去获取对应时间段的cpu占比。
33.针对多软件服务混合部署的情况，通过如下方式记录对应数据：
34.第一种：单台服务器部署多种服务，针对该台服务器记录所有服务在接口上的调用量。
35.在具体实现时，当服务器内混合部署了多个服务，记录所述多个服务的整个周期内的调用量，并使用所有服务的调用量计算对应接口的总调用量，即使用的cpu占比，以及接口的调用总量是所有服务运行时的cpu占比，以及接口的调用量，不是仅使用调用的服务对应的数据进行容量评估。
36.第二种：当混合部署的多个服务部署的服务器个数不同时，使用调用总量最大的服务器上的记录获取对应周期的cpu占比，以及接口的总调用量。
37.当混合部署的多个服务部署的服务器个数不同时，可能出现部分服务器调用总量偏高，使用对应周期对应时间段调用总量最高的服务器来进行容量评估，可以避免木桶效应，避免一台过载挂掉之后引起血崩。
38.混合部署多种服务时，多个服务在对应周期中被调用的趋势变化一致时更实用。
39.本技术实施例中的接口可以为api接口。
40.下面结合附图，详细描述接口容量评估过程。
41.实施例一
42.参见图1，图1为本技术实施例一中接口容量评估流程示意图。具体步骤为：
43.步骤101，接收到业务端发送的评估接口容量的请求时，获取记录的最新周期的cpu占比和所述接口的总调用量。
44.其中，所述cpu占比和所述接口的总调用量为对应周期中所有接口的总调用量最大的时间段对应的cpu占比和所述接口的总调用量，每个周期划分为多个相同时长的连续时间段。
45.步骤102，根据所述cpu占比和所述接口的总调用量计算所述接口的第一可用容量。
46.本步骤中根据所述cpu占比和所述接口的总调用量计算所述接口的第一可用容量，包括：
47.计算预设cpu占比阈值与最新周期的cpu占比的差值；
48.计算最新周期对应的所述接口对应的总调用量与所述差值的乘积；
49.计算所述乘积与预设cpu占比阈值的比值作为所述第一可用容量。
50.如预设cpu占比阈值为50％，最新周期的cpu占比为30％，最新周期的所述接口的总调用量为70，则第一可用容量为：
51.70
×
(50％-30％)/50％。
52.步骤103，若确定所述请求中携带的需求量小于所述第一可用容量，则向所述业务端发送所述接口的第一可用容量满足调用的响应。
53.当需求量小于第一可用容量时，说明所请求的接口的剩余容量完全能够满足发送
请求的业务端的调用，则响应所述业务端可调用对应接口，并给出第一可用容量可调用的指示，即不受其他接口容量增加与减少的影响的前提下即可进行对应接口的调用，具体实现时，还可以将第一可用容量的具体指发送给业务端，由业务端进一步进行业务判断，以最终决定是否调用，若调用时可使用的调用量。
54.本技术实施例中在所有接口都同等增加调用量时，剩余的资源将会平均服务于每个接口的前提下，通过历史记录的cpu占比，以及接口的调用量来评估当前接口的可用容量，能够准确评估每个接口当前可调用的容量。
55.实施例二
56.参见图2，图2为本技术实施例二中接口容量评估流程示意图。具体步骤为：
57.步骤201，接收到业务端发送的评估接口容量的请求时，获取记录的最新周期的cpu占比和所述接口的总调用量。
58.其中，所述cpu占比和所述接口的总调用量为对应周期中所有接口的总调用量最大的时间段对应的cpu占比和所述接口的总调用量，每个周期划分为多个相同时长的连续时间段。
59.步骤202，根据所述cpu占比和所述接口的总调用量计算所述接口的第一可用容量。
60.本步骤中根据所述cpu占比和所述接口的总调用量计算所述接口的第一可用容量，包括：
61.计算预设cpu占比阈值与最新周期的cpu占比的差值；
62.计算最新周期对应的所述接口对应的总调用量与所述差值的乘积；
63.计算所述乘积与预设cpu占比阈值的比值作为所述第一可用容量。
64.假设预设cpu占比阈值为50％，最新周期的cpu占比为40％，最新周期的所述接口的总调用量为70，则第一可用容量为：
65.70
×
(50％-40％)/50％。
66.步骤203，确定所述请求中携带的需求量小于所述第一可用容量，如果是，执行步骤204；否则，执行步骤205。
67.步骤204，向所述业务端发送所述接口的第一可用容量满足调用的响应，结束本流程。
68.当需求量小于第一可用容量时，说明所请求的接口的剩余容量完全能够满足发送请求的业务端的调用，则响应所述业务端可调用对应接口，并给出第一可用容量可调用的指示，即不受其他接口容量增加与减少的影响的前提下即可进行对应接口的调用，具体实现时，还可以将第一可用容量的具体指发送给业务端，由业务端进一步进行业务判断，以最终决定是否调用，若调用时可使用的调用量。
69.步骤205，基于所述接口之外的接口都不增加调用量的前提下，计算所述接口的第二可用容量。
70.本步骤中计算所述接口的第二可用容量的具体实现为：
71.计算所述接口的最新周期的总调用量与最新周期的前一周期的总调用量的差值作为第一差值；
72.计算所述接口的预设cpu占比阈值与最新周期对应的cpu占比的差值作为第二差
值；
73.计算所述接口的最新周期对应的cpu占比与所述最新周期的前一周期对应的cpu占比的差值作为第三差值；
74.计算所述第一差值与所述第二差值的乘积；
75.计算所述乘积与所述第三差值的比值作为所述接口的第二可用容量。
76.假设预设cpu占比阈值为50％，最新周期的cpu占比为40％，最新周期的所述接口的总调用量为70，最新周期的上一周期的cpu占比为20，最新周期的上一周期所述接口对应的总调用量为50，则第二可用容量为：
77.(70-50)
×
(50％-40％)/(40％-20％)。
78.步骤206，确定所述需求量是否小于所述第二可用容量，如果是，执行步骤207；否则，执行步骤208。
79.步骤207，向所述业务端发送所述接口的第二可用容量满足调用的响应，结束本流程。
80.所述需求量小于所述第二可用容量，说明在所述接口之外的接口都不增加调用量的前提下，所述接口可提供的最大可调用量可以满足业务端调用所述接口的需求，此时，响应所述业务端在所述接口之外的接口都不增加调用量的前提下，所述接口可提供的最大调用量即第二可用量可以满足所述业务端调用所述接口的需求，使业务端根据实际需要确定是否进行调用；
81.并且在具体实现时，还可以将第二可调用量携带在响应中发送给业务端，由业务端，由业务端进一步确定是否进行调用。
82.步骤208，向所述业务端发送所述接口不满足调用需求的响应。
83.本技术实施例中在所有接口都同等增加调用量时，服务器剩余的资源将会平均服务于每个接口的前提下评估当前的第一可调用量；若第一可调用量不能满足用户需求量时，基于所述接口之外的接口都不增加调用量的前提下(可以控制不再接受其他接口的调用量申请。那么所有剩余资源将全部用于新增接口调用)，通过历史记录的cpu占比，以及接口的调用量来评估当前接口的第二可用容量，能够准确评估每个接口当前可调用的容量，供用户确定是否进行接口的调用。
84.实施例三
85.在具体实现时若同时接收到多个评估接口容量的请求时，将所述多个请求合并进行接口容量评估。
86.如同时接收到请求a和请求b，对应的需求量为ga和gb。
87.若请求的是针对同一接口的调用，则将ga gb作为针对该接口的需求量按照实施例二的方式进行容量评估。
88.若请求的不是针对同一接口的调用，则先分别在对应接口上按照各自的需求量按照实施例一中的调用方式进行容量评估，若存在不满足需求量的情况，则将ga gb作为任一接口的需求量按照步骤205的方式进行容量评估。
89.实施例四
90.针对最新周期若已进行过接口容量评估，且评估结果为需求量小于第一可用容量，或需求量小于第二可用容量时，若再次接收到评估接口容量的请求，则确定所述请求中
携带的需求量与上一周期中对应接口的最大可调用量的差值是否大于预设阈值，如果是，针对所述请求进行接口容量评估；否则，等待当前周期结束后再针对所述请求进行接口容量评估。
91.如当前周期接收到第一条请求，按照实施例二进行接口容量评估；
92.若评估结果为需求量小于第一可用容量，或需求量不小于第二可用容量，且接收到第二条请求，则确定所述第二条请求中携带的需求量与上一周期中对应接口的最大可调用量的差值是否大于预设阈值，如果是，使用最新周期记录的数据信息进行容量评估；否则，等待当前周期结束后再进行容量评估。
93.当接收到第三条、第四条等等请求时，按照处理第二条请求的方式进行处理。
94.针对上一周期若已进行过接口容量评估，且评估结果为需求量大于第二可用容量时，再次接收到评估接口容量的请求时，不对该请求进行容量评估，等待当前周期结束后再进行容量评估。
95.基于同样的发明构思，本技术实施例中还提供一种接口容量评估装置。参见图3，图3为本技术实施例中接口容量评估装置结构示意图。所述装置包括：记录单元301、接收单元302、获取单元303、计算单元304、确定单元305和响应单元306；
96.记录单元301，用于将每个周期划分为多个相同时长的连续时间段；记录每个周期的中所有接口的总调用量最大的时间段对应的cpu占比和每个接口的总调用量；
97.接收单元302，用于接收业务端发送的评估接口容量的请求；
98.获取单元303，用于当接收单元302接收到业务端发送的评估接口容量的请求时，获取记录单元301记录的最新周期的cpu占比和所述接口的总调用量；
99.计算单元304，用于根据获取单元303获取的所述cpu占比和所述接口的总调用量计算所述接口的第一可用容量；
100.确定单元305，用于确定所述请求中携带的需求量是否小于计算单元计算的第一可用容量；
101.响应单元306，用于若确定单元305确定所述请求中携带的需求量小于所述第一可用容量，则向所述业务端发送所述接口的第一可用容量满足调用的响应。
102.在另一个实施例中，
103.计算单元304，进一步用于若确定单元305确定所述请求中携带的需求量不小于所述第一可用容量，则基于所述接口之外的接口都不增加调用量的前提下，计算所述接口的第二可用容量；
104.确定单元305，进一步用于确定所述需求量是否小于所述第二可用容量；
105.响应单元306，进一步用于当确定单元305确定所述需求量小于所述第二可用容量时，向所述业务端发送所述接口的第二可用容量满足调用的响应；否则，向所述业务端发送所述接口不满足调用需求的响应。
106.在另一个实施例中，
107.计算单元304，具体用于计算所述接口的第一可用容量时，包括：
108.计算预设cpu占比阈值与最新周期的cpu占比的差值；
109.计算最新周期对应的所述接口对应的总调用量与所述差值的乘积；
110.计算所述乘积与预设cpu占比阈值的比值作为所述第一可用容量。
111.在另一个实施例中，
112.计算单元304，具体用于计算所述接口的第二可用容量时，包括：
113.计算所述接口的最新周期的总调用量与最新周期的前一周期的总调用量的差值作为第一差值；
114.计算所述接口的预设cpu占比阈值与最新周期对应的cpu占比的差值作为第二差值；
115.计算所述接口的最新周期对应的cpu占比与所述最新周期的前一周期对应的cpu占比的差值作为第三差值；
116.计算所述第一差值与所述第二差值的乘积；
117.计算所述乘积与所述第三差值的比值作为所述接口的第二可用容量。
118.在另一个实施例中，
119.记录单元301，具体用于周期记录对应周期中每个接口的调用量，以所述时间段为单位统计每个接口的总调用量，并获取所述时间段对应的cpu占比。
120.在另一个实施例中，
121.当单台服务器混合部署多种服务，针对该台服务器记录所有服务在接口上的调用量；
122.当混合部署的多个服务部署的服务器个数不同时，使用调用总量最大的服务器上的记录进行cpu占比，以及接口的总调用量的计算。
123.在另一个实施例中，
124.若同时接收到多个评估接口容量的请求时，将所述多个请求合并进行接口容量评估。
125.在另一个实施例中，
126.针对上一周期若已进行过接口容量评估，且评估结果为需求量小于第一可用容量，或需求量小于第二可用容量时，再次接收到评估接口容量的请求时，确定所述请求中携带的需求量与上一周期中对应接口的最大可调用量的差值是否大于预设阈值，如果是，针对所述请求进行接口容量评估；否则，等待当前周期结束后再针对所述请求进行接口容量评估。
127.上述实施例的单元可以集成于一体，也可以分离部署；可以合并为一个单元，也可以进一步拆分成多个子单元。
128.在另一个实施例中，还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述接口容量评估方法的步骤。
129.本技术实施例中还提供以一种接口容量评估系统。参见图4，图4为本技术实施例中接口容量评估系统示意图。所述系统包括：业务端和电子设备；其中，所述业务端与所述电子设备信号连接。
130.所述电子设备用于实现上述接口容量评估方法，业务端用于向所述电子设备发送接口容量评估请求，并接收响应。
131.在另一个实施例中，还提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被处理器执行时可实现所述接口容量评估方法中的步骤。
132.在另一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现所述接口容量评估方法。
133.图5为本发明实施例提供的电子设备的实体结构示意图。如图5所示，该电子设备可以包括：处理器(processor)510、通信接口(communications interface)520、存储器(memory)530和通信总线540，其中，处理器510，通信接口520，存储器530通过通信总线540完成相互间的通信。处理器510可以调用存储器530中的逻辑指令，以执行如下方法：
134.接收到业务端发送的评估接口容量的请求时，获取记录的最新周期的cpu占比和所述接口的总调用量；
135.根据所述cpu占比和所述接口的总调用量计算所述接口的第一可用容量；
136.若确定所述请求中携带的需求量小于所述第一可用容量，则向所述业务端发送所述接口的第一可用容量满足调用的响应；
137.其中，所述cpu占比为对应周期中所有接口的总调用量最大的时间段对应的cpu占比，所述接口的总调用量为所述时间段对应的所述接口的总调用量，每个周期划分为多个相同时长的连续时间段。
138.此外，上述的存储器530中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
139.以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
140.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
141.以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。