Capacity adjustment method and device and storage medium

Abstract

The invention discloses a capacity adjustment method and device and a storage medium, and relates to the technical field of resource management. According to the method, the target service API corresponding to the application end is determined, and the request quantity characteristic of the application end is determined according to the request quantity and the response time of the target service API in unit time and the thread count corresponding to the application end; then, traversing downstream dependent APIs of the target service APIs, and determining operation complexity characteristics of the application end according to request quantities and response time of the target service APIs and the downstream dependent APIs in unit time; then, the CPU utilization rate of the application end is determined according to the request quantity feature and the operation complexity feature; if the CPU utilization rate of the application end is larger than the preset threshold value, the application end is expanded, the overall capacity requirement of the application end is reflected more accurately by comprehensively considering the influence of the request quantity and the operation complexity of the request on the CPU utilization rate of the application end, and the capacity of the application end is adjusted in time.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of resource management, and particularly relates to a capacity adjustment method, device and storage medium. BACKGROUND

[0002] During the growth period of a business product, an application system needs to cope with the increase of request quantity. At present, the solution to this situation is usually an elastic expansion scheme for coping with the sudden increase of request quantity of a single node, that is, the peak QPS (Queries Per Second) of a single server node is monitored, and when the peak QPS exceeds a certain threshold, expansion is performed, and when the peak QPS decreases, the capacity is reduced. However, in the real production environment of a business service, a single application system usually uses multiple server nodes, and the request types received by each server node and the downstream dependency relationship between each service node differ in CPU consumption. The above scheme only roughly adjusts the capacity according to the request quantity index of a single node, and cannot accurately reflect the change of the overall capacity demand of the application system in the complex scene of the production environment, resulting in the incapability of timely adjusting the capacity.

[0003] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0004] The main purpose of the present application is to provide a capacity adjustment method, device and storage medium, aiming at solving the technical problem that the current capacity adjustment scheme cannot timely adjust the capacity.

[0005] To achieve the above purpose, the present application provides a capacity adjustment method, which comprises the following steps: determining a target service API corresponding to an application end, and determining a request quantity characteristic of the application end according to the request quantity and response time of the target service API within a unit time and the thread quantity corresponding to the application end; traversing a downstream dependent API of each target service API, and determining a computational complexity characteristic of the application end according to the request quantity and response time of the target service API and the downstream dependent API within the unit time; determining the CPU utilization of the application end according to the request quantity characteristic and the computational complexity characteristic; if the CPU utilization of the application end is greater than a preset threshold, expanding the application end.

[0006] In an embodiment, after the step of determining the target service API corresponding to the application end, the method further comprises the following steps: determining each downstream dependent API of the target service API and the calling time period corresponding to the downstream dependent API. calling start time and calling end time of the to-be-deleted API within a calling time period of other downstream dependent APIs, wherein the other downstream dependent APIs are downstream dependent APIs other than the to-be-deleted API; deleting the to-be-deleted API from the downstream dependent APIs of the target service API.

[0007] In an embodiment, before the step of determining the request quantity feature of the application end according to the predicted request quantity and response time of the target service API and the thread quantity corresponding to the application end, the method further comprises: creating a topology graph of the target business based on a mapping relationship between an upstream service unit and a downstream service unit corresponding to the target business code, wherein a node of the topology graph is a service unit, and the service unit corresponds to a service API one by one; traversing the nodes in the topology graph, and determining a transfer rate between each node according to a historical request quantity distribution of each node, wherein the transfer rate represents a probability of a request flowing from a current node being traversed into a downstream node; determining a predicted request quantity of a head node according to a target business request increment and the historical request quantity distribution; determining a request quantity of a service API corresponding to each node in a unit of time according to the predicted request quantity of the head node and the transfer rate between each node.

[0008] In an embodiment, the step of traversing the nodes in the topology graph and determining the transfer rate between each node according to the historical request quantity distribution of each node comprises: if a corresponding relationship between the current node and a downstream node is one-to-one or one-to-many, determining the transfer rate between the current node and the downstream node according to a difference between a historical request quantity of the downstream node and a historical request quantity of the current node; if the corresponding relationship between the current node and the downstream node is many-to-one, determining the transfer rate between the current node and the downstream node according to a difference between a historical request quantity flowing from the current node into the downstream node and the historical request quantity of the current node.

[0009] In an embodiment, the step of determining the predicted request quantity of the head node according to the target business request increment and the historical request quantity distribution comprises: determining a time period of increasing the target business, wherein a business type of the target business is consistent with a business type of the target business code; determine a historical request amount of the head node in each sub time period within the releasing time period according to the historical request amount distribution of the head node, and a total historical request amount in the releasing time period; determine a releasing weight of the head node in each sub time period according to a quotient of the historical request amount in the sub time period and the total historical request amount in the releasing time period; determine a predicted request amount of the head node in each sub time period according to the target service request increment and the releasing weight.

[0010] In an embodiment, after the step of creating a topology graph of the target service based on the mapping relationship between the target service code and the upstream service unit and the downstream service unit, the method further comprises: if the service API corresponding to the node of the topology graph is an asynchronous request service API, and the service unit corresponding to the node is consistent with the service unit corresponding to the upstream node of the node, the node is deleted.

[0011] In an embodiment, after the step of determining the CPU utilization of the application end according to the request amount feature and the operation complexity feature, the method further comprises: determine a memory rising rate of the application end according to the memory change rate of the service unit corresponding to each target service API in the unit time; if the memory rising rate or the CPU utilization is greater than the preset threshold, the application end is scaled out.

[0012] In an embodiment, after the step of determining the memory rising rate of the application end according to the memory change rate of the service unit corresponding to each target service API, the method further comprises: determine a resource pool utilization of the application end according to the number of request tasks and the execution time of the request tasks in the resource pool of the application end in the unit time, and the number of resources in the resource pool, the resource pool comprising at least one of a thread pool and a database connection pool; if the memory rising rate, the resource pool utilization or the CPU utilization is greater than the preset threshold, the application end is scaled out.

[0013] In addition, to achieve the above object, the application further provides a capacity adjustment device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the capacity adjustment method as described above.

[0014] In addition, to achieve the above object, the application further provides a storage medium, which is a computer readable storage medium, and a computer program is stored on the storage medium, and the computer program is executed by a processor to implement the steps of the capacity adjustment method.

[0015] The application provides a capacity adjustment method. The request amount feature of an application end is determined by determining the target service API corresponding to the application end, according to the request amount and response time of the target service API in a unit time, and the thread number corresponding to the application end. Then, the operation complexity feature of the application end is determined by traversing the downstream dependent API of each target service API, according to the request amount and response time of the target service API and the downstream dependent API in a unit time. Next, the CPU utilization of the application end is determined according to the request amount feature and the operation complexity feature. If the CPU utilization of the application end is greater than a preset threshold, the application end is expanded in capacity. The influence of the request amount and the operation complexity of the request on the CPU utilization of the application end is comprehensively considered, so that the overall capacity demand of the application end is more accurately reflected, and the capacity of the application end is accurately adjusted. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which are incorporated into and form a part of the specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the application.

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0018] Figure 1 A flowchart is provided for the capacity adjustment method embodiment one of the present application; Figure 2 A flowchart is provided for the capacity adjustment method embodiment two of the present application; Figure 3 An asynchronous thread concurrency diagram is provided for the embodiment two of the present application; Figure 4 A flowchart is provided for the capacity adjustment method embodiment three of the present application; Figure 5 A topology diagram construction diagram is provided for the embodiment three of the present application; Figure 6 A flowchart is provided for the capacity adjustment method embodiment four of the present application; Figure 7 A flowchart is provided for the capacity adjustment method embodiment five of the present application; Figure 8The flowchart provided for the capacity adjustment method embodiment six of the present application; Figure 9 The resource pool schematic diagram provided for the embodiment six of the present application; Figure 10 The device structure schematic diagram of the hardware running environment involved in the capacity adjustment method in the embodiment of the present application.

[0019] The object realization, functional features and advantages of the present application will be further explained with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0020] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application, and are not used to limit the present application.

[0021] In order to better understand the technical solutions of the present application, the following will be described in detail in combination with the drawings and specific embodiments in the specification. It should be noted that all the actions of obtaining signals, information or data in the present application are carried out under the premise of complying with the corresponding data protection regulations and policies of the place, and with the authorization of the corresponding device owner.

[0022] During the growth period of the business product of the application system, the increase of request amount needs to be responded. At present, the solution to this situation is usually the elastic expansion scheme for responding to the sudden increase of request amount of a single node, that is, the peak QPS (Queries Per Second) change of a single server node is monitored, when the peak QPS exceeds a certain threshold, the server node is expanded, and when the peak QPS decreases, the capacity of the server node is reduced. However, in the real production environment of business service, a single application system usually uses multiple server nodes, and the request types received by each server node and the downstream dependency relationship between each service node have differences in CPU consumption. The above-mentioned scheme only roughly adjusts the capacity according to the request amount index of a single node, and cannot accurately reflect the change of the overall capacity demand of the application system in the complex scene of the production environment, resulting in untimely expansion or contraction operation.

[0023] In view of the above problems, the present application provides a capacity adjustment method, which determines the target service API corresponding to the application end, determines the request amount characteristic of the application end according to the request amount and response time of the target service API per unit time, and the number of threads corresponding to the application end; then, traverses the downstream dependent API of each target service API, and determines the operation complexity characteristic of the application end according to the request amount and response time of the target service API and the downstream dependent API per unit time; then, the CPU utilization of the application end is determined according to the request amount characteristic and the operation complexity characteristic; if the CPU utilization of the application end is greater than a preset threshold, the application end is expanded.

[0024] The capacity adjustment method not only evaluates the request processing capability of the application end through the request volume and response time of the target service API, but also evaluates the actual operation complexity of the target service API of the application end in processing requests according to the request volume and response time of the downstream dependent API of the target service API. By comprehensively considering the influence of the request volume and the operation complexity of the request on the CPU utilization of the application end, the overall capacity demand of the application end can be more accurately reflected, so as to accurately adjust the capacity of the application end.

[0025] It should be noted that the execution subject of the embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device, an application system, etc. that can realize the above functions.

[0026] Based on this, the first embodiment of the present application provides a capacity adjustment method, which is described with reference to Figure 1 In the embodiment, the capacity adjustment method comprises steps S10-S40: Step S10, determine the target service API corresponding to the application end, determine the request volume characteristics of the application end according to the request volume and response time of the target service API within a unit time, and the thread number corresponding to the application end.

[0027] The target service API corresponding to the application end refers to those key service interfaces directly called by the application end in the distributed system. These APIs are the bridge between the application end and the backend service, responsible for processing requests from the front end and returning the results to the front end. For example, in an e-commerce application system, the target service API may include user login interface, commodity query interface, order submission interface, etc.

[0028] It can be understood that the request volume reflects the number of requests received by the target service API in a unit of time. In the business growth period, with the increase of the number of users and business activities, the request volume will increase significantly. If the request volume of a certain target service API in a unit of time is too high, it may cause the processing capacity of the API to reach a bottleneck, thereby affecting the performance of the entire application end. The response time of the target service API can represent the processing capacity of the API or the performance of the backend service. The thread is the smallest unit of operation scheduling that the operating system of the application end can perform. In the application end, the number of threads reflects the number of requests that the application end can handle at the same time. The number of threads directly affects the concurrent processing capacity of the application end. If the number of threads is insufficient, even if the request volume and response time of the target service API are within the normal range, the application end may not be able to efficiently process requests due to insufficient thread resources. Therefore, by considering the number of threads of the application end, the request processing load of the application end can be more accurately evaluated, thereby providing a more comprehensive perspective for capacity adjustment and avoiding misjudgment caused by the one-sidedness of local indicators.

[0029] Optionally, historical request data received by each target service API of the application end in a historical same period time period is obtained, the request volume and the response time of the target service API after that are predicted according to the historical request data, the current number of threads is obtained from the current running environment of the application end, the average load of each thread is calculated, and the request volume feature of the application end is obtained. The request volume feature of the application end represents the contribution of the request processing load of the application end to the CPU consumption, and is positively correlated with the CPU utilization.

[0030] Illustratively, the historical request data of the target service API is collected from the log system, the monitoring system or the database of the application end, including the request timestamp, the request volume, the response time, etc. The average request volume, the peak request volume and the request volume fluctuation range of the target service API in a unit of time, such as per hour or per day, are calculated. The average response time of the target service API in the unit of time is calculated. A model suitable for time series prediction is selected, such as an autoregressive integrated moving average model, a long short-term memory network, etc. The selected model is trained using the above historical request data, and the model parameters are adjusted to optimize the prediction effect. Then the request volume and the response time to be received by each target service API of the current application end are predicted by the trained model.

[0031] Optionally, the predicted request volume, response time and number of threads in a unit of time can be weighted and summed using a weighted average method to obtain the request volume feature of the application end.

[0032] Optionally, the QPS and the corresponding average response time of each target service API are predicted, the request volume feature F1 of the application end is determined according to the quotient of the product of the QPS and the average response time of the target service API and the number of threads, for example:

[0033] wherein n is the number of target service APIs; represents the request amount per second of the i-th target service API; is the average response time, in seconds; represents the maximum number of threads in the current running environment. The unit of time corresponding to the request amount and the response time can also be replaced by other units such as per minute or per hour.

[0034] Step S20, traversing the downstream dependent API of each target service API, determining the computational complexity feature of the application end according to the request amount and the response time of the target service API and the downstream dependent API in the unit of time.

[0035] Optionally, the downstream dependent API of each target service API is queried through the service registry center of the application end, and then the predicted request amount and response time of the downstream dependent API in the unit of time are determined. In the micro-service architecture, the service registry center such as Eureka, Consul, ZooKeeper, etc. maintains a registration table of service instances, which records the addresses and dependency relationships of each service. Each service API will register its own information in the registry center when starting, and also obtain the addresses and service information of its downstream dependent API from the registry center.

[0036] Optionally, the service calling relationship in the code can also be scanned by static code analysis tools such as SonarQube, FindBugs or custom scripts to determine the downstream dependent API of each target service API, and then determine the request amount and response time of the downstream dependent API in the unit of time.

[0037] After determining the request amount and response time of the target service API and the downstream dependent API in the unit of time, the computational complexity feature of the application end is calculated according to the request amount and the response time of the target service API and the downstream dependent API in the unit of time. The computational complexity feature of the application end represents the contribution of the computational complexity of the target service API of the application end to the CPU consumption, which is in a positive proportional relationship with the CPU utilization.

[0038] Optionally, the product of the request quantity and the response time of the downstream dependent API per unit time is taken as the operation complexity feature of each downstream dependent API, and all downstream dependent APIs are summed up to obtain the total downstream dependent operation complexity. Similarly, the product of the request quantity and the response time of the target service API per unit time is taken as the operation complexity feature of each target service API, and all target service APIs are summed up to obtain the total operation complexity. Then, according to the proportion of the total downstream dependent operation complexity and the total operation complexity, the proportion of the downstream dependent API in the entire application operation complexity is measured to determine the proportion of the application end itself operation complexity in the total operation complexity, reflecting the actual operation burden of the application end itself to process requests.

[0039] Exemplarily, the expression of the complexity feature F2 of the application end can be as follows:

[0040] wherein, is the request quantity per second of the oth downstream dependent API of the target service API, is the average response time of the oth downstream dependent API, in seconds. It can be understood that, can represent the number of times that the target service API calls its oth downstream dependent API per second. This is an index for measuring the frequency of interaction between the target service API and the downstream dependent API. The numerator part calculates the total operation complexity of all downstream dependent APIs, and the denominator part calculates the total operation complexity of. While represents the proportion of the application end itself operation complexity in the total operation complexity, if the value of is high, it means that the application end itself operation complexity accounts for a large proportion in the total operation complexity, and the processing capacity of the application end needs to be improved, if the value of is low, it means that the operation complexity of the downstream dependent API accounts for a large proportion, and the performance of the downstream dependent server may need to be optimized.

[0041] It can be understood that in actual business services, different request types such as computation-intensive and I / O-intensive and downstream dependent relationships have significant differences in the consumption of the application end CPU. Only relying on the QPS of the single service node associated with the application end cannot truly reflect the actual consumption of the business request to the application end CPU.

[0042] Specifically, taking a compute-intensive request as an example, such a request is mainly CPU operation, such as mathematical calculation, encryption and decryption, image processing, etc., which needs to continuously occupy CPU cores for high-intensity calculation, and the CPU utilization is high, that is, the QPS of the compute-intensive request is low but the actual CPU occupation is high, which needs to be expanded in advance. The I / O intensive request is mainly input / output operation, such as database query, file reading and writing, network communication, etc., and the CPU needs to wait for the completion of the I / O operation. The CPU is in an idle state when waiting for I / O, and the utilization is low. That is, the QPS of the I / O intensive request is high but the actual CPU occupation is low, and it may not need to be expanded. For example, 1000 times of compute-intensive request may cause CPU overload, while 1000 times of I / O intensive request may only have a CPU utilization of 30%.

[0043] The downstream dependency relationship of each service also causes different consumption of CPU at the application end. Taking an e-commerce application end as an example, the request received by it usually forms a long chain through multiple intermediate services, such as user request→order service→payment service→logistics service. The CPU consumption of each intermediate service is superimposed, and the long chain may cause the overall CPU load to be much higher than the single node QPS performance; The traditional single node QPS elastic expansion scheme cannot reflect the difference in actual CPU occupation rate caused by the above-mentioned situations, which may cause inaccurate load prediction and incorrect adjustment of the capacity of the application end. In step S20, by traversing the downstream dependent API, the product of the request quantity and the response time of each downstream dependent API is calculated to cover all calling relationships. And F2 represents the contribution of the operation complexity of the target service API itself to the CPU consumption, which more accurately evaluates the capacity demand of the application end. The higher F2 is, the more compute-intensive requests there are, and the higher the proportion of CPU consumption of the target service API; the lower F2 is, the more CPU consumption is caused by downstream services or I / O waiting, and the smaller the direct impact of the target service API on CPU.

[0044] Optionally, in order to realize high availability, the application end usually adopts multi-availability zone deployment and database and table splitting strategies. Multi-availability zone deployment means that different instances of the application end are deployed in different availability zones to ensure that when a failure occurs in a certain availability zone, the instances in other availability zones can still continue to provide services. Database and table splitting means that the data in the database is stored in multiple databases or tables to improve data processing capacity and availability. Due to the existence of multi-availability zone deployment and database and table splitting, different instances of the same application end may bear different proportions of request quantity. In order to accurately evaluate the request quantity characteristics of each site such as different availability zones or different database shards, the request quantity characteristics and operation complexity characteristics of each site can be calculated respectively.

[0045] Step S30, determining the CPU utilization of the application end according to the request quantity feature and the operation complexity feature.

[0046] Optionally, the influence weight of the request quantity feature and the operation complexity feature on the CPU utilization is determined through analysis of historical data or experience judgment. The request quantity feature and the operation complexity feature are weighted and summed according to the influence weight to obtain the CPU utilization of the application end.

[0047] Optionally, a suitable model is selected according to the data complexity, the model is trained through historical CPU utilization and corresponding historical request quantity feature and historical operation complexity feature, and a mapping relationship between the request quantity feature and the operation complexity feature and the CPU utilization is constructed. The trained model is used for real-time prediction to determine the CPU utilization of the application end.

[0048] Step S40, if the CPU utilization of the application end is greater than a preset threshold, the application end is scaled out.

[0049] Optionally, the step of scaling out can be to upgrade the hardware configuration of the existing server, such as increasing the number of CPU cores, increasing the memory capacity, or upgrading to faster storage devices.

[0050] Optionally, the step of scaling out can also be to increase the number of server instances, for example, on a cloud platform, new virtual machine instances can be created, and the application can be deployed to these new instances. In a local data center, new physical or virtual servers can be manually configured and started.

[0051] Optionally, the load can also be reduced by optimizing the application code and the database to indirectly achieve the effect of scaling out. For example, the application code can be optimized to reduce resource consumption, such as improving algorithm efficiency, reducing unnecessary calculations, and optimizing database queries. In terms of databases, read-write separation, database sharding, adding indexes, or using caching mechanisms can be used to reduce database load.

[0052] Compared with the traditional capacity adjustment scheme, in the present embodiment, in addition to the request quantity feature, the CPU consumption of the request is quantified through the operation complexity feature, the influence of the request quantity and the operation complexity of the request on the CPU utilization of the application end is considered comprehensively, and the overall capacity demand of the application end can be more accurately reflected, so that the capacity of the application end can be adjusted in time and accurately.

[0053] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as the above embodiment one can refer to the above introduction, and the following will not be described in detail. On this basis, please refer to Figure 2 , after the step of determining the target service API corresponding to the application end, the capacity adjustment method further includes steps S11-S13: Step S11, determine each of the downstream dependent APIs of the target service API, and the calling time period corresponding to the downstream dependent API.

[0054] Step S12, the calling start time and the calling end time of the downstream dependent API within the calling time period of other downstream dependent APIs are determined as the to-be-deleted API, wherein the other downstream dependent APIs are downstream dependent APIs other than the to-be-deleted API.

[0055] Step S13, the to-be-deleted API is deleted from the downstream dependent APIs of the target service API.

[0056] It should be noted that some application ends use thread pool asynchronous concurrency to reduce API response time. As shown in Figure 3 Since the I / O waiting time of thread 3 in the custom thread pool includes the I / O waiting time of thread 1 and thread 2 (the dashed box area in the figure) when concurrent calling, directly traversing the downstream dependent APIs to calculate the operation complexity feature according to the method provided in the above embodiment 1 will cause feature distortion. At this time, the downstream dependent API contained by other APIs needs to be identified and excluded in the calculation process of the operation complexity feature.

[0057] Exemplarily, the calling time period corresponding to each downstream dependent API of the target service API is obtained first, and the to-be-deleted API whose calling time period is contained by other downstream dependent APIs is identified. By deleting these APIs, repeated calculation in the calculation of operation complexity can be avoided, and the accuracy of the operation complexity feature can be improved.

[0058] Based on the above embodiments of the present application, in the third embodiment of the present application, the same or similar contents as the above embodiments can be referred to the above introduction, and will not be repeated hereinafter. On this basis, please refer to Figure 4 , after step S10, the capacity adjustment method further includes steps S50-S80: Step S50, based on the mapping relationship between the target business code corresponding upstream service unit and downstream service unit, a topology graph of the target business is created, the nodes of the topology graph are service units, and the service units correspond one by one to service APIs.

[0059] It should be noted that the mapping relationship between upstream and downstream service units corresponding to the target business code refers to the process in which an upstream service unit, after completing its specific business function, will call one or more downstream service units according to certain rules to complete subsequent business logic processing. This calling relationship reflects the information flow and functional collaboration between services, and reflects the sequence and dependencies of the business process. Based on the mapping relationship between upstream and downstream service units corresponding to the target business code, a topology diagram of the target business can be constructed.

[0060] For example, refer to Figure 5 The diagram shown is as follows. Figure 5 A mapping table is provided to the upstream and downstream service units corresponding to the business code "BusinessId_test", with each service unit corresponding to a service API. For example, the upstream service unit "ServiceUnitId_A" corresponds to the upstream API "Api_A". Based on the mapping table of upstream and downstream service units corresponding to the business code "BusinessId_test", a topology diagram of the target business corresponding to the business code can be constructed.

[0061] Step S60: Traverse the nodes in the topology graph and determine the transmission rate between nodes based on the historical request volume distribution of each node. The transmission rate represents the probability that a request flows from the current traversed node into the downstream node.

[0062] By traversing the nodes in the topology graph, the transfer rate between nodes can be determined based on the historical request volume distribution of each node. The transfer rate represents the probability that a request flows from the current traversed node to a downstream node. It reflects the flow pattern of requests between different service units in the business process, helping to assess the load distribution corresponding to the business and providing a basis for application capacity planning and performance optimization. For example, if it is found that the transfer rate from the "order submission" node to the "payment service" node is high, but the processing capacity of the payment application where the "payment service" resides is limited, then it can be predicted that the "payment service" may become the performance bottleneck for processing the business under high concurrency, thus allowing for early scaling and optimization of the payment application.

[0063] Optionally, if the correspondence between the current node and the downstream node is one-to-one or one-to-many, the transmission rate between the current node and the downstream node is determined based on the difference between the historical request volume of the downstream node and the historical request volume of the current node.

[0064] For example, if the correspondence between the current node A and the downstream node B is one-to-one, then the transmission rate between the current node A and the downstream node B is... It can be represented as:

[0065] wherein, represents the request amount of the target service received by the node B, represents the request amount of the target service received by the node A.

[0066] If the correspondence between the current node A and the downstream node B is one-to-many, it means that the upstream node synchronously calls multiple downstream nodes. At this time, the transfer rate between the current node A and each downstream node B can be calculated by using the calculation method corresponding to the one-to-one relationship.

[0067] Optionally, if the correspondence between the current node and the downstream node is many-to-one, the transfer rate between the current node and the downstream node is determined according to the difference between the historical request amount flowing from the current node to the downstream node and the historical request amount of the current node.

[0068] Exemplarily, if the correspondence between the current node A and the downstream node B is many-to-one, the transfer rate between the current node A and the downstream node B can be calculated as follows: may be expressed as:

[0069] wherein, represents the request amount flowing from the current node A to the downstream node B.

[0070] Step S70, determining the predicted request amount of the head node according to the target service request increment and the historical request amount distribution.

[0071] It can be understood that the above method can calculate the transfer rate between other intermediate nodes in the topology diagram except the head node, and then use DFS to predict the request amount of the intermediate nodes according to the transfer rate. However, the head node cannot calculate the transfer rate. Therefore, the embodiment determines the predicted request amount of the head node according to the target service request increment and the historical request amount distribution.

[0072] Optionally, step S70 includes steps S71-S74: Step S71, determining the amount time period of the target service, the service type of the target service being consistent with the service type of the target service code.

[0073] Step S72, determining the historical request amount of the head node in each sub time period and the historical request total amount in the amount time period according to the historical request amount distribution of the head node, the each sub time period being in the amount time period.

[0074] Exemplarily, given an initial request amount of a target service, a target service request increment, and a volume release time period. The volume release time period is a time period artificially set according to service demand in capacity adjustment and request amount prediction. In this time period, the initial request amount and the preset target service request increment are set to simulate a real service scenario, so as to predict the request amount change and load of the service-related application end.

[0075] First, the volume release time period is divided into two or more sub-time periods according to a preset time interval. Then, according to the historical request amount distribution of the head node, the historical request amount data of the head node in the same period as the volume release time period and each sub-time period is determined. The historical request amount of the head node in each sub-time period and the total historical request amount in the volume release time period are determined.

[0076] Step S73, according to the quotient of the historical request amount in the sub-time period and the total historical request amount in the volume release time period, the volume release weight of the head node in each sub-time period is determined.

[0077] Step S74, according to the target service request increment and the volume release weight, the predicted request amount of the head node in each sub-time period is determined.

[0078] Exemplarily, assuming that the volume release time period is a day, the day is divided into multiple sub-time periods according to minute intervals, and then the volume release weight of the head node per minute in the day is determined, and the target service request increment is distributed to each minute according to the calculated volume release weight per minute in the day.

[0079] After distributing the target service request increment to each sub-time period according to the target service request increment and the volume release weight, the initial request amount is distributed to each sub-time period according to the volume release weight, and the predicted request amount of the head node in each sub-time period is determined according to the request increment and the initial request amount distributed in each sub-time period.

[0080] Optionally, the initial request amount is distributed to each sub-time period according to the historical request amount distribution in the same period as the volume release time period, and the predicted request amount of the head node in each sub-time period is obtained.

[0081] Step S80, according to the predicted request amount of the head node and the transfer rate between the nodes, the request amount of the service API corresponding to each node in the unit time is determined.

[0082] After obtaining the predicted request amount of the head node, the request amount of the service API corresponding to each node can be calculated according to the transfer rate between the nodes calculated before.

[0083] It can be understood that a single business process can be implemented by multiple different application ends in cooperation, and after the request amount of the service API corresponding to each service unit is predicted, the target service API request amount of each application end can be determined in the actual production environment, and then the capacity of each application end can be evaluated.

[0084] Based on the above embodiments of the application, in the fourth embodiment of the application, the same or similar contents as the above embodiments can be referred to the above introduction, and will not be described in detail. On this basis, please refer to Figure 6 , after step S50, the capacity adjustment method further comprises step S90: Step S90: if the service API corresponding to the node of the topology graph is an asynchronous request service API, and the service unit corresponding to the node is consistent with the service unit corresponding to the upstream node of the node, the node is deleted.

[0085] The service registry center usually records the related attributes of the service API, including whether it is an asynchronous request type. For example, when the service provider registers the service, the asynchronous attribute of the service API such as "async" is identified and registered to the service registry center. Through the interaction with the service registry center such as HTTP request or RPC call, the asynchronous request identification of these asynchronous service APIs can be obtained.

[0086] Exemplarily, the asynchronous request identification of each service API is obtained from the configuration information or service metadata of the service registry center. Each node in the topology graph is traversed, for each node, firstly check whether the service API corresponding to the node has the asynchronous request identification, if yes, further judge whether the service unit corresponding to the node is consistent with the service unit corresponding to the upstream node of the node. If both conditions are met, that is, the service API corresponding to the node is an asynchronous request service API, and the service unit corresponding to the node is consistent with the service unit corresponding to the upstream node, the node is deleted from the topology graph.

[0087] By deleting the nodes in the topology graph which are asynchronous request service APIs and have consistent service units with the upstream nodes, the redundant information in the topology graph can be reduced, the topology graph is clearer and simpler, and the actual calling relationship and key path of the business system can be more accurately reflected, which is convenient for subsequent analysis and decision-making.

[0088] Optionally, the nodes with empty service units, or the nodes with ZA24 framework, or the nodes without request amount data can be further modified and the topology graph is adjusted.

[0089] Exemplarily, the modification strategy of the topology graph can refer to the following table:

[0090] In the above table, the publishing unit corresponding to the node refers to the actual deployment instance or cluster of the service unit, which is the smallest physical deployment unit carrying the service running, and different publishing units of the same service unit provide the same API capability. The application name corresponding to the node refers to the name of the application end actually deployed by the service unit corresponding to the node. Null filling refers to filling the missing service unit related information of the current node according to the service unit related information of the downstream node.

[0091] Based on the above embodiments of the present application, in the fifth embodiment of the present application, the same or similar contents as the above embodiments can be referred to the above introduction, and the subsequent will not be described in detail. On this basis, please refer to Figure 7 , after step S30, the capacity adjustment method further comprises steps S100-S110: Step S100, according to the memory change rate of the service unit corresponding to each target service API in the unit time, the memory increase rate of the application end is determined.

[0092] Step S110, if the memory increase rate or the CPU utilization rate is greater than the preset threshold, the application end is expanded.

[0093] For those online application ends that users can directly interact with through terminals or networks, due to the existence of Java virtual machine garbage collection mechanism, the application end memory usage rate basically does not fluctuate with the change of request volume, unless there is memory leakage in the application program. In order to evaluate the memory capacity of the application end, the quotient of the sum of the maximum memory change rate sine value of the service unit corresponding to each target service API of the application end in the unit time and the number of target service APIs is defined as the memory change rate up_rate of the service unit corresponding to the target service API:

[0094] wherein, is the memory change rate of the service unit corresponding to the jth point target service API. If the memory increase rate is greater than the preset threshold, it is determined that there is memory leakage. If the memory usage rate is continuously high or there is memory leakage, it is determined that the application end needs to be expanded.

[0095] Based on the above embodiments of the present application, in the sixth embodiment of the present application, the same or similar contents as the above embodiments can be referred to the above introduction, and the subsequent will not be described in detail. On this basis, please refer to Figure 8 , after step S100, the capacity adjustment method further comprises steps S120-S130: In step S120, the resource pool usage of the application end is determined according to the number of requested tasks and the execution time of the application end in the unit time, and the number of resources in the resource pool, wherein the resource pool includes at least one of a thread pool and a database connection pool.

[0096] In step S130, if the memory growth rate, the resource pool usage or the CPU utilization is greater than the preset threshold, the application end is expanded.

[0097] As shown in the formula (1), the resource pool includes core resources and standby resources. When a task is submitted to the resource pool, if the number of resources in the resource pool is sufficient, the task can directly obtain the resources in the resource pool to execute the task. The performance turning point of the resource pool is the time when all the resources in the resource pool are used. At this time, the newly submitted task is either cached or rejected. To evaluate the performance of the resource pool, the product of the execution time of the requested task and the number of requested tasks in the unit time is divided by the number of resources in the resource pool, and the quotient is taken as the resource pool usage PR, for example: Figure 9

[0098] wherein, i is the i th task in the resource pool, e is the number of tasks in the resource pool in the unit time, and n is the maximum number of resources of the resource pool. When PR reaches 100%, the performance turning point of the resource pool occurs, and the response of the subsequent task will be slow.

[0099] Optionally, the resource pool can be a Tomcat thread pool. In the Tomcat thread pool, is the execution time of all target service APIs, and n is the maximum number of threads of the Tomcat.Considering the scheduling consumption of the Tomcat thread pool and the uneven distribution of tasks, when PR> preset threshold, the Tomcat thread pool reaches the performance turning point, and the preset threshold is less than or equal to 100%. Optionally, the resource pool can be a database connection pool. In the database connection pool,

[0100] is the execution time of all databases, and n is the maximum number of connections of the database connection pool.Considering the scheduling consumption of the database connection pool and the uneven distribution of tasks, when PR> preset threshold, the database connection pool reaches the performance turning point, and the preset threshold is less than or equal to 100%.

[0101] ​​The application provides a capacity adjustment device, comprising: at least one processor; and a memory connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the capacity adjustment method in the above embodiment one.

[0102] Reference will now be made to the following description Figure 10 which illustrates a structural diagram of a capacity adjustment device suitable for implementing embodiments of the application. The capacity adjustment device in the embodiments of the application can include, but is not limited to, mobile terminals such as notebook computers, digital broadcast receivers, personal digital assistants (PDA), tablet computers (PAD), portable multimedia players (PMP), vehicle-mounted terminals (for example, vehicle-mounted navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. Figure 10 The illustrated capacity adjustment device is merely an example and should not impose any limitation on the functions and use range of the embodiments of the application.

[0103] As shown in Figure 10 , the capacity adjustment device can include a processing apparatus 1001 (for example, a central processor, a graphic processor, or the like) that can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 1002 or loaded from a storage apparatus 1003 into a random access memory (RAM) 1004. Various programs and data required for operation of the capacity adjustment device are also stored in the random access memory 1004. The processing apparatus 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: input apparatuses 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, and the like; output apparatuses 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, and the like; the storage apparatus 1003 including, for example, a magnetic tape, a hard disk, and the like; and a communication apparatus 1009. The communication apparatus 1009 can allow the capacity adjustment device to perform wireless or wired communication with other devices to exchange data. Although the capacity adjustment device having various systems is shown in the figure, it should be understood that all the illustrated systems are not required to be implemented or provided. More or less systems can be alternatively implemented or provided.

[0104] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for executing the method shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiments disclosed in the present application are executed.

[0105] The capacity adjustment device provided by the present application adopts the capacity adjustment method in the above-mentioned embodiments, and can solve the technical problem that the current capacity adjustment scheme cannot adjust the capacity in time. Compared with the prior art, the capacity adjustment device provided by the present application has the same beneficial effects as the capacity adjustment method provided by the above-mentioned embodiments, and other technical features in the capacity adjustment device are the same as the features disclosed in the previous embodiment method, which will not be described here.

[0106] It should be understood that various parts of the present application can be realized by hardware, software, firmware or a combination thereof. In the description of the above-mentioned embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0107] The above is merely specific implementation of the present application, but the protection scope of the present application is not limited thereto, any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0108] The present application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e. computer program) for executing the capacity adjustment method in the above-mentioned embodiments.

[0109] The computer readable storage medium provided in the present application may, for example, be a U disk, but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination of the above. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection having one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read only memory (ROM), an erasable programmable read only memory (EPROM) or a flash memory, an optical fiber, a portable compact disk read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present embodiment, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted in any suitable medium, including but not limited to an electrical wire, an optical cable, a radio frequency (RF), and the like, or any suitable combination of the above.

[0110] The above computer readable storage medium can be included in the capacity adjustment device, or can exist separately without being assembled into the capacity adjustment device.

[0111] The above computer readable storage medium carries one or more programs, which, when executed by the capacity adjustment device, enable the capacity adjustment device to write computer program code for performing the operations of the present application in one or more programming languages or combinations thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" language or similar programming languages. The program code can be executed entirely on the user computer, partially on the user computer, or as a separate software package, partially on the user computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user computer through any kind of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, through the Internet using an Internet service provider).

[0112] The flow and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flow and block diagrams can represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may be executed in the reverse order, depending on the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or operations, or combinations of special purpose hardware and computer instructions.

[0113] The modules involved in the embodiments of the present application can be implemented in software or in hardware. In some cases, the names of the modules do not limit the modules themselves.

[0114] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e., a computer program) for executing the capacity adjustment method described above, and can solve the technical problem that the current capacity adjustment scheme cannot timely adjust the capacity. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the capacity adjustment method provided by the above embodiments, which will not be described here.

[0115] The present application also provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the capacity adjustment method as described above.

[0116] The computer program product provided by the present application can solve the technical problem that the current capacity adjustment scheme cannot timely adjust the capacity. Compared with the prior art, the computer program product provided by the present application has the same beneficial effects as the capacity adjustment method provided by the above embodiments, which will not be described here.

[0117] The above only describes some embodiments of the present application, and does not limit the patent scope of the present application. Any equivalent structural transformation made by using the content of the present application specification and drawings, or direct / indirect application in other related technical fields is included in the patent protection scope of the present application.

Claims

1. A capacity adjustment method characterized by, The capacity adjustment method comprises: determining a target service API corresponding to the application end, determining a request amount characteristic of the application end according to a request amount and a response time of the target service API within a unit time and a thread number corresponding to the application end; traversing a downstream dependent API of each target service API, determining a computation complexity characteristic of the application end according to a request amount and a response time of the target service API and the downstream dependent API within the unit time; determining a CPU utilization of the application end according to the request amount characteristic and the computation complexity characteristic; if the CPU utilization of the application end is greater than a preset threshold, expanding the application end.

2. The capacity adjustment method of claim 1, wherein, After the step of determining the target service API corresponding to the application end, the method further comprises: determining each downstream dependent API of the target service API and a calling time period corresponding to the downstream dependent API; taking a downstream dependent API whose calling start time and calling end time are within a calling time period of other downstream dependent API as a to-be-deleted API, wherein the other downstream dependent API is a downstream dependent API other than the to-be-deleted API; deleting the to-be-deleted API from the downstream dependent API of the target service API.

3. The capacity adjustment method of claim 1, wherein, Before the step of determining the target service API corresponding to the application end, determining a request amount characteristic of the application end according to a predicted request amount and a response time of the target service API and a thread number corresponding to the application end, the method further comprises: creating a topology graph of a target business based on a mapping relationship between an upstream service unit and a downstream service unit corresponding to a target business code, a node of the topology graph being a service unit, the service unit corresponding to a service API one by one; traversing a node in the topology graph, determining a transfer rate between each node according to a historical request amount distribution of each node, the transfer rate representing a probability of a request flowing from a current node being traversed into a downstream node; determining a predicted request amount of a head node according to a target business request increment and the historical request amount distribution; determining a request amount of a service API corresponding to each node within the unit time according to the predicted request amount of the head node and the transfer rate between each node.

4. The capacity adjustment method of claim 3, wherein, The step of traversing a node in the topology graph, determining a transfer rate between each node according to a historical request amount distribution of each node, comprises: if a corresponding relationship between the current node and a downstream node is one-to-one or one-to-many, determining the transfer rate between the current node and the downstream node according to a difference between a historical request amount of the downstream node and a historical request amount of the current node; if the corresponding relationship between the current node and a downstream node is many-to-one, determining the transfer rate between the current node and the downstream node according to a difference between a historical request amount flowing from the current node into the downstream node and a historical request amount of the current node.

5. The capacity adjustment method of claim 3, wherein, The step of determining a predicted request amount of a head node according to a target business request increment and a historical request amount distribution, comprises: determining a volume-increasing time period of the target business, a business type of the target business being consistent with a business type of the target business code; According to the historical request amount distribution of the head node, historical request amounts of the head node in each sub time period are determined, and a total historical request amount in the amount releasing time period is determined, the sub time periods being in the amount releasing time period; According to a quotient of the historical request amount in each sub time period and the total historical request amount in the amount releasing time period, an amount releasing weight of the head node in each sub time period is determined; According to the target service request increment and the amount releasing weight, a predicted request amount of the head node in each sub time period is determined.

6. The capacity adjustment method of claim 3, wherein, The method further comprises, after the step of creating a topology graph of the target service based on the mapping relationship between the target service code and the upstream service unit and the downstream service unit: If the service API corresponding to a node of the topology graph is an asynchronous request service API, and the service unit corresponding to the node is consistent with the service unit corresponding to an upstream node of the node, the node is deleted.

7. The capacity adjustment method of claim 1, wherein, The method further comprises, after the step of determining the CPU utilization of the application end according to the request amount feature and the operation complexity feature: According to a memory change rate of the service unit corresponding to each target service API in the unit time, a memory rise rate of the application end is determined; If the memory rise rate or the CPU utilization is greater than the preset threshold, the application end is scaled out.

8. The capacity adjustment method of claim 7, wherein, The method further comprises, after the step of determining the memory rise rate of the application end according to the memory change rate of the service unit corresponding to each target service API: According to a number of request tasks and an execution time of the request tasks in a resource pool of the application end in the unit time, and a resource number in the resource pool, a resource pool utilization of the application end is determined, the resource pool including at least one of a thread pool and a database connection pool; If the memory rise rate, the resource pool utilization, or the CPU utilization is greater than the preset threshold, the application end is scaled out.

9. A capacity adjusting device, characterized by, The device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the capacity adjustment method according to any one of claims 1 to 8.

10. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, the computer program being executable on a processor to implement the steps of the capacity adjustment method according to any one of claims 1 to 8.

Images