Service traffic prediction capacity expansion method and device

Abstract

The invention discloses a service traffic prediction capacity expansion method and device, and the method comprises the steps: reading and analyzing each service code under a micro-service architecture, obtaining a calling relation between services, and generating a calling relation graph according to the calling relation; obtaining traffic data of the services, and updating the traffic weight of each service located at the downstream of the calling relation in the calling relation graph according to the traffic data of the services; a flow propagation model is constructed according to the calling relation graph and the flow weight, and future flow data of each service in the flow propagation model is predicted by using a preset time sequence model; and determining a resource gap of each service according to the future traffic data of each service, obtaining data to be expanded, and performing expansion processing on the service. The method comprises the following steps: acquiring a service dependency relationship, acquiring traffic data based on a static dependency relationship and a dynamic state, performing traffic time sequence analysis on each service, predicting traffic change and potential bottleneck of the service, accurately identifying the service to be expanded, avoiding the problem of blind expansion or improper resource allocation, and improving the resource utilization rate.

Description

Technical Field

[0001] The present application relates to the technical field of capacity expansion prediction, and in particular to a method and device for service traffic prediction and capacity expansion. Background Art

[0002] Microservice architecture refers to a single application that contains many small components or services that are loosely coupled and can be deployed separately. When a business adopts a microservice architecture, the business is more flexible, but the dependencies between services are more complex, making it difficult to estimate the traffic peak of each service, and it is also easy to cause resource waste or insufficient capacity.

[0003] The existing service capacity expansion mainly relies on the indicators of a single service execution, such as CPU usage, memory usage, etc., which have a lag. When peak traffic rushes in, the capacity expansion will begin, which may lead to overload or unavailability in a short period of time. In addition, due to the reliance on indicators of a single service execution, the cascade relationship between upstream and downstream services is not considered. The transmission of traffic pressure may lead to errors in prediction or omission of bottleneck services, which may also cause problems in the overall business. Summary of the invention

[0004] In view of the above problems, embodiments of the present application are proposed to provide a method and device for service traffic prediction and expansion that overcome the above problems or at least partially solve the above problems.

[0005] According to a first aspect of an embodiment of the present application, a service traffic prediction and expansion method is provided, which includes:

[0006] Read and parse the service codes under the microservice architecture, obtain the call relationship between services, and generate a call relationship graph based on the call relationship;

[0007] Obtain the traffic data of the service, and update the traffic weight of each service located downstream of the call relationship in the call relationship graph according to the traffic data of the service;

[0008] A traffic propagation model is constructed based on the call relationship graph and traffic weights, and the future traffic data of each service in the traffic propagation model is predicted using a preset timing model.

[0009] The resource gap of each service is determined according to the future traffic data of each service, and the data to be expanded is obtained, so as to expand the service according to the data to be expanded.

[0010] Optionally, reading and parsing each service code under the microservice architecture, obtaining the call relationship between each service, and generating a call relationship graph according to the call relationship further includes:

[0011] Read and parse the service code in at least one code repository to obtain an abstract syntax tree of each service code;

[0012] Traverse the abstract syntax tree of each service code to determine the calling relationship between services;

[0013] A call relationship graph is generated based on the call relationship between each service; wherein the call relationship graph includes the upstream and downstream call relationships between services and the number of calls.

[0014] Optionally, obtaining traffic data of the service, and updating the traffic weight of each service located downstream of the call relationship in the call relationship graph according to the traffic data of the service further includes:

[0015] Based on the gateway tracking, the traffic data of the service is obtained, and according to the upstream and downstream call relationships and the corresponding number of calls in the call relationship graph, the traffic data of each service located downstream of the call relationship is calculated according to the time window, so as to update the service traffic weight of the call relationship graph according to the traffic data.

[0016] Optionally, according to the upstream and downstream call relationships and the corresponding call times in the call relationship graph, the flow data of each service located downstream of the call relationship is calculated according to the time window and further includes:

[0017] If a downstream service has an upstream service, the product of the traffic data of the upstream service and the corresponding number of calls is calculated as the traffic data of the downstream service;

[0018] If a downstream service has multiple upstream services, the sum of the traffic data of the multiple upstream services multiplied by the corresponding number of calls is accumulated as the traffic data of the downstream service.

[0019] Optionally, constructing a traffic propagation model according to the call relationship graph and the traffic weight, and using a preset time series model to predict the future traffic data of each service in the traffic propagation model further includes:

[0020] Get the traffic weight of each service in each time window;

[0021] Build a traffic propagation model based on the call relationship graph and the traffic weights of each service in each time window to determine the traffic transmission path and load pressure distribution of each time window in upstream and downstream services;

[0022] The preset time series model is used to predict the future traffic data corresponding to the future time window of each service in the traffic propagation model based on the historical time window.

[0023] Optionally, determining the resource gap of each service according to the future traffic data of each service, obtaining the data to be expanded, and performing capacity expansion processing on the service according to the data to be expanded further includes:

[0024] According to the future traffic data corresponding to the future time window of each service, the future resource data is converted according to the preset conversion rules;

[0025] Determine the resource gap of each service based on future resource data and obtain the data to be expanded; the data to be expanded includes the time to be expanded, the service to be expanded, the type of resources to be expanded, and the number of resources to be expanded;

[0026] According to the data to be expanded, expansion instructions are built based on the container orchestration tool to expand the service to be expanded.

[0027] Optionally, the method further comprises:

[0028] The idle resources of each service are determined according to the future traffic data of each service, so as to perform resource transfer according to the idle resources.

[0029] According to a second aspect of an embodiment of the present application, a service traffic prediction and expansion device is provided, comprising:

[0030] The call relationship graph module is suitable for reading and parsing the service codes under the microservice architecture, obtaining the call relationship between services, and generating a call relationship graph based on the call relationship;

[0031] A traffic weight module, adapted to obtain traffic data of a service and update the traffic weight of each service located downstream of the call relationship in the call relationship graph according to the traffic data of the service;

[0032] A prediction module is adapted to construct a traffic propagation model according to a call relationship graph and traffic weights, and to predict future traffic data of each service in the traffic propagation model using a preset timing model;

[0033] The capacity expansion module is suitable for determining the resource gap of each service according to the future traffic data of each service, obtaining the data to be expanded, and performing capacity expansion processing on the service according to the data to be expanded.

[0034] According to a third aspect of an embodiment of the present application, there is provided a computing device, comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus;

[0035] The memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute operations corresponding to the above-mentioned service traffic prediction and expansion method.

[0036] According to a fourth aspect of an embodiment of the present application, a computer storage medium is provided, wherein at least one executable instruction is stored in the storage medium, and the executable instruction enables a processor to perform operations corresponding to the above-mentioned service traffic prediction and expansion method.

[0037] According to a fifth aspect of the embodiments of the present application, a computer program product is provided, including at least one executable instruction, and the executable instruction causes a processor to perform operations corresponding to the service traffic prediction and expansion method as described above.

[0038] According to the service traffic prediction and expansion method and device provided by the present application, by obtaining the dependency relationship between services, constructing a service call relationship graph that is updated in real time, and performing traffic time series analysis on each service based on the static dependency relationship and dynamically obtained traffic data, predicting the traffic changes and potential bottlenecks of services, accurately identifying the services to be expanded, avoiding problems such as blind expansion or improper resource allocation, improving resource utilization rate, and reducing costs.

[0039] The above description is only an overview of the technical solution of the present application. In order to be able to understand the technical means of the present application more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features and advantages of the present application more obvious and understandable, the following specifically describes the embodiments of the present application. Description of the Drawings

[0040] By reading the following detailed description of the preferred embodiments, various other advantages and benefits will become clear to those of ordinary skill in the art. The drawings are only for the purpose of showing the preferred embodiments and are not considered to be a limitation of the present application. And throughout the drawings, the same reference numerals are used to represent the same components. In the drawings:

[0041] Figure 1 A flowchart of a service traffic prediction and expansion method according to an embodiment of the present application is shown;

[0042] Figure 2 A flowchart of a service traffic prediction and expansion method according to another embodiment of the present application is shown;

[0043] Figure 3 A schematic structural diagram of a service traffic prediction and expansion device according to an embodiment of the present application is shown;

[0044] Figure 4 A schematic structural diagram of a computing device according to an embodiment of the present application is shown. Detailed Embodiments

[0045] The exemplary embodiments of the present application will be described in more detail below with reference to the drawings. Although the exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present application and to fully convey the scope of the present application to those skilled in the art.

[0046] First, the terms involved in one or more embodiments of the present application are explained.

[0047] Ast: Abstract Syntax Tree, is an abstract representation of source code, which expresses the grammatical structure of the program in a tree structure, and each node represents a grammatical element in the source code. Through AST, the logical structure of the code can be parsed, analyzed and operated without directly processing the source code text.

[0048] ARIMA: AutoRegressive Integrated Moving Average, a statistical model used to analyze and predict time series data. It combines autoregressive (AR), difference (I) and moving average (MA) components to model the trend and periodicity of time series, and is suitable for processing univariate, stable or linear time series data.

[0049] LSTM: Long Short-Term Memory, a deep learning model, is a variant of recurrent neural network (RNN). It solves the long-term dependency problem that occurs in traditional RNN when processing time series data, that is, as the time step increases, information may be lost or decayed. It is suitable for processing complex nonlinear time series, especially multivariate or large-scale data.

[0050] Request volume: The client initiates a request to the service run by the server. The size of the request volume is generally measured by the number of requests per second.

[0051] Figure 1 A flow chart of a method for predicting and expanding service traffic according to an embodiment of the present application is shown. Figure 1 As shown, the method comprises the following steps:

[0052] Step S101, read and parse each service code under the microservice architecture, obtain the calling relationship between each service, and generate a calling relationship graph according to the calling relationship.

[0053] In the microservice architecture, multiple loosely coupled services are coordinated and combined to achieve the corresponding business scenarios. There are call relationships between multiple services. If the call dependency of the service is obtained through manual configuration, operation log analysis, etc., there may be risks such as human errors and omissions. The operation log may not cover the untriggered path, resulting in incomplete and inaccurate call dependency. Furthermore, when the service version is updated, the call dependency will also change, and manual configuration, operation log analysis, etc. cannot be updated in time.

[0054] Based on the above problems, this embodiment reads each service code and parses each service code, such as using a syntax parsing library to parse the service code, so that the abstract syntax tree AST of the service code can be obtained in real time. Based on the abstract syntax tree AST, the call relationship between each service can be extracted, and a mesh call relationship graph is generated according to the call relationship between each service. The call relationship graph includes the upstream and downstream call relationships between services, such as service A calls service B, service C calls service B, and the call relationship graph includes upstream service A and downstream service B, and there is a call relationship between the two services, and upstream service C and downstream service B, and there is a call relationship between the two services. Further, the number of calls that service A calls service B can be determined based on the service code. When service A calls service B twice and service C calls service B three times, the call relationship graph also includes service A calling service B, and the number of calls is 2 times; service C calls service B, and the number of calls is 3 times. The above is an example, which is set according to the implementation situation and is not limited here.

[0055] Furthermore, the generated call relationship graph can be synchronously updated when the service code is updated, and the updated service code can be read to regenerate the call relationship graph to ensure the accuracy of the call relationship graph.

[0056] Step S102, obtaining traffic data of the service, and updating the traffic weight of each service located downstream of the call relationship in the call relationship graph according to the traffic data of the service.

[0057] Traffic data, such as the number of requests when users access services, can be obtained through methods such as gateways and link tracking to obtain traffic data for each service. However, in addition to the traffic data generated by user access, each service will also have traffic data such as intranet access. The resources occupied by intranet access and user access are different. Considering the above problems, this embodiment adopts a gateway monitoring method to obtain real-time traffic data of gateway-related services. Based on the real-time traffic data of gateway-related services, according to the upstream and downstream call relationships between services in the call relationship graph, the traffic data of each service located downstream of the call relationship is calculated in turn, and the traffic weight of each service end in the call relationship graph is updated.

[0058] Specifically, based on gateway monitoring, the real-time traffic data of service A is obtained, and the traffic data of each service located downstream of service A is calculated according to the call relationship graph. For example, if service B located downstream of service A is called twice, the traffic data of service A can be multiplied by 2 to obtain the traffic data of service B. If service B has other upstream services, the product of the traffic data of each upstream service and the number of calls can be accumulated according to the call relationship, and the final sum is used as the traffic data of service B. The traffic weight of service B in the call relationship graph is updated according to the traffic data of service B. The above is an example. According to the call relationship graph of the implementation situation, the traffic data of each downstream service is calculated in turn, and the traffic weight of each service in the call relationship graph is updated according to the traffic data, until the update of the traffic weight of each service in the entire call relationship graph is completed.

[0059] Based on the call relationship graph obtained by static code analysis, the traffic weight of each service can be obtained more accurately, so as to predict the future traffic data of each service based on the accurate traffic weight.

[0060] Furthermore, after updating the traffic weight of each service in the call relationship graph, the traffic weight of each service can be stored according to the time window to obtain the traffic curve corresponding to the time window, which is convenient for subsequent traffic prediction based on the traffic curve. The size of the time window is set according to the implementation situation and is not limited here.

[0061] Step S103, constructing a traffic propagation model according to the call relationship graph and the traffic weight, and using a preset timing model to predict the future traffic data of each service in the traffic propagation model.

[0062] A traffic propagation model can be constructed based on the call relationship graph and the traffic weights of each service. The traffic propagation model records the propagation paths between services in multiple time windows, the distribution of traffic load pressure, etc., and reflects the traffic change trends of each service in multiple time windows.

[0063] According to the traffic propagation model, the traffic weights of each service in different time windows based on the preset time series model can be used to predict the future traffic data of each service at a future time point based on the time series. The preset time series model can use time series models such as the autoregressive integral moving average model ARIMA or the long short-term memory network LSTM, which can accurately predict the future traffic data of each service at a future time point, making it convenient to accurately expand the capacity of specific services in the subsequent expansion.

[0064] Step S104, determining the resource gap of each service according to the future traffic data of each service, obtaining the data to be expanded, and performing capacity expansion processing on the service according to the data to be expanded.

[0065] After predicting the future traffic data of each service, the corresponding required resources can be determined based on the future traffic data. The required resources are compared with the current resource information of each service to determine the resource gap of each service.

[0066] Based on the resource gap, the data for each service to be expanded can be determined, and then the capacity of each service can be expanded based on the data to be expanded, thereby avoiding problems such as redundant resources for some services and insufficient resources for other services, and ensuring the normal operation of the services.

[0067] According to the service traffic prediction and expansion method provided in this application, by obtaining the dependencies between services, a real-time updated service call relationship graph is constructed, and based on static dependencies and dynamically acquired traffic data, traffic timing analysis is performed on each service to predict service traffic changes and potential bottlenecks, accurately identify services to be expanded, avoid blind expansion or improper resource allocation, improve resource utilization, and reduce costs.

[0068] Figure 2 A flow chart of a method for predicting and expanding service traffic according to an embodiment of the present application is shown. Figure 2 As shown, the method comprises the following steps:

[0069] Step S201, read and parse the service code in at least one code repository, obtain the abstract syntax tree of each service code, traverse the abstract syntax tree of each service code, determine the calling relationship between each service, and generate a calling relationship graph based on the calling relationship between each service.

[0070] The microservice architecture contains multiple services, and the corresponding service code data is large. There may be multiple code repositories to store different service codes. The large number of service codes and different storage locations increase the difficulty of obtaining the calling relationship between services.

[0071] For the service codes in each code repository, you can first read and statically parse them separately to obtain the abstract syntax tree AST of each service code. The abstract syntax tree AST includes the syntax structure of the service code. For the abstract syntax tree AST of each service code, you can parse each abstract syntax tree AST separately by traversing, and combine the function calls required by the implementation situation during parsing, such as identifying the function calls of protocols such as grpc and http, and then determine the call relationship between services. At the same time, count the number of calls to determine the number of calls between services. According to the obtained call relationship between services, such as service A calling service B, service B calling service E, service F calling service A, etc., combine them according to the upstream and downstream positions of the call relationship to generate a call relationship graph. The call relationship graph includes the upstream and downstream call relationships between services and the number of calls. The call relationship graph can be a mesh structure graph. A service can be called by one or more services, and a service can call one or more services, etc., which are not limited here.

[0072] Furthermore, the number of calls in the call relationship graph refers to the number of times an upstream service calls a downstream service. If a downstream service is called by multiple upstream services, it is necessary to record the number of times the downstream service calls each upstream service separately in the call relationship graph, rather than the total number, so that the traffic weight of the service can be accurately determined later.

[0073] Step S202, based on gateway tracking, obtains service traffic data, and according to the upstream and downstream call relationships and the corresponding call times in the call relationship graph, calculates the traffic data of each service located downstream of the call relationship according to the time window, so as to update the service traffic weight of the call relationship graph according to the traffic data.

[0074] When predicting the traffic of each service, it is necessary to obtain accurate traffic data of each service. However, in the microservice framework, the traffic data of each service includes not only user access traffic but also intranet access data, which makes it impossible to accurately obtain the peak traffic data of each service. The expansion of each service often depends on the indicators of a single service during operation, such as the CPU occupancy rate and memory occupancy rate of the service currently being executed. The lag of the indicators makes it impossible to expand the capacity in time, and most of the expansion is estimated expansion, which cannot accurately expand the services that need to be expanded, resulting in some service resource redundancy, wasting computing resources, and insufficient resources for other services. Furthermore, when expanding, only the operating indicators of a single service are considered, and the call dependency between services is not considered. The transmission of traffic pressure may lead to problems such as misprediction or missed judgment of bottleneck services.

[0075] Taking the above problems into consideration, this embodiment obtains accurate real-time traffic data generated by accessing services based on gateway tracking, and uses the upstream and downstream call relationships and the corresponding call times in the call relationship graph to accurately calculate the traffic data of each service in the microservice architecture. The gateway can be used to obtain accurate traffic data when the service is called. Based on the accurate traffic data, according to the upstream and downstream call relationships and the call times in the call relationship graph, the accurate traffic data of the downstream services can be calculated. For services located downstream, if there is an upstream service for the downstream service, the product of the traffic data of the upstream service and the corresponding call times is calculated, which can be used as the traffic data of the downstream service. For example, when the upstream service of service C is only service D, the product obtained by multiplying the traffic data of service D and the number of calls of service D to service C can be used as the traffic data of service C. If there are multiple upstream services for a downstream service, the sum of the products of the traffic data of multiple upstream services and the corresponding number of calls is accumulated as the traffic data of the downstream service. For example, the upstream services of service E include service F, service G, etc. Product 1 is obtained based on the traffic data of service F and the number of calls of service F calling service E, and product 2 is obtained based on the traffic data of service G and the number of calls of service G calling service E. The sum of product 1 and product 2 is used as the traffic data of service E. According to the calling relationship of each service in the calling relationship graph, the traffic data of the downstream service is calculated in turn based on the traffic data of the upstream service until the traffic data of each service in the calling relationship graph is obtained. The calculated traffic data can be used as the traffic weight of each service to distinguish it from the traffic data of each service obtained by actual monitoring. More accurate traffic weights are used to predict the future traffic data of each service to ensure the accuracy of the prediction.

[0076] For the traffic weight of each service, the traffic weight of different time windows will be different due to the different access request volumes. Therefore, different time windows can be divided. For example, 10 minutes can be used as a time window. The traffic weights in each time window can be calculated and recorded. The traffic weights of services corresponding to different time windows can be obtained, so that the future traffic data of each service can be predicted based on the traffic weights of historical time windows.

[0077] Step S203, constructing a traffic propagation model according to the call relationship graph and the traffic weight, and using a preset timing model to predict the future traffic data of each service in the traffic propagation model.

[0078] According to the traffic weights of each service in different time windows, combined with the call relationship graph and the traffic weights of each service in each time window, a traffic propagation model can be constructed. The traffic propagation model is used to determine the transmission path and load pressure distribution of the traffic in each time window in the upstream and downstream services, reflecting the traffic carried by each service in different time windows, as well as the correlation of traffic transmission between services. The traffic propagation model can accurately record the traffic trough, peak and other data in each time window for each service, so that future traffic data can be predicted based on the traffic weights of each service in the microservice architecture in different time windows recorded by the traffic propagation model.

[0079] The prediction of future traffic data of each service can use the preset time series model to obtain the future traffic data corresponding to the future time window of each service in the traffic propagation model based on the historical time window prediction, so as to determine the traffic trough and traffic peak of each service in the future time window. The preset time series model can use different time series models, such as the autoregressive integrated moving average model ARIMA or the long short-term memory network LSTM and other time series models, which are not limited here.

[0080] During the prediction, predictions are made for each service in the traffic propagation model in order to accurately determine the traffic troughs and traffic peaks of each service, accurately expand the capacity of the expansion services, and avoid expanding all services, resulting in redundant resources and waste.

[0081] Step S204, determining the resource gap of each service according to the future traffic data of each service, obtaining the data to be expanded, and performing capacity expansion processing on the service according to the data to be expanded.

[0082] After predicting the future traffic data corresponding to the future time windows of each service, the future traffic data corresponding to the future time windows of each service are converted into future resource data according to preset conversion rules. The preset conversion rules can be determined based on the specific implementation of each service, and the future traffic data are converted into required resources, such as CPU, memory, bandwidth and other different resources. For different resource types, the required resource quantity is determined.

[0083] By comparing the future resource data with the resource data currently possessed by each service, the resource gap of each service can be determined and the data to be expanded can be obtained. The data to be expanded includes the time to be expanded, the service to be expanded, the type of resource to be expanded, and the number of resources to be expanded. The time to be expanded is determined based on the future time window, which can be the previous time window required for the predicted traffic, etc. It is set according to the implementation situation to ensure that the predicted traffic can be coped with after the expansion. The service to be expanded is the service that needs to be expanded after the resource comparison. When the service to be expanded can be accurately determined to be expanded, only the service to be expanded is expanded to avoid resource waste. The types of resources to be expanded include different resources such as CPU, memory, bandwidth, etc. Only the required resources can be expanded, and there is no need to expand all resource types. The number of resources to be expanded can be accurately expanded to avoid resource waste.

[0084] Based on the data to be expanded, we can accurately locate the specific services, the time point of expansion, the specific resources for expansion, and the required quantity, so as to achieve accurate expansion of the required services within the required time, ensure the normal operation of the services, and avoid expanding services that do not need to be expanded, resulting in problems such as waste of resources.

[0085] According to the data to be expanded, expansion instructions can be constructed based on container orchestration tools, such as Kubernetes' pod containers. Expansion instructions can include execution time (determined by the time to be expanded), execution object (determined by the service to be expanded), and expansion size (determined by the type of resources to be expanded and the number of resources to be expanded), so as to expand the service to be expanded. After the expansion instructions can be constructed based on the container orchestration tool, the corresponding expansion instructions can be executed. The expansion instructions can also be adjusted or revoked according to the real-time changing traffic propagation model (real-time update of the call relationship graph, adjustment of traffic weight, etc.), so as to flexibly respond to traffic changes and expand more flexibly. The above is an example, which is set according to the implementation situation and is not limited here.

[0086] Step S205, determining the idle resources of each service according to the future traffic data of each service, so as to perform resource transfer according to the idle resources.

[0087] In addition to expanding the services to be expanded, the idle resources of each service can also be determined based on the predicted future traffic data of each service. For example, if the predicted future traffic data of each service includes traffic troughs, the service may not need a large number of resources at this time, and the idle resources can be transferred to the services to be expanded, which can achieve effective resource utilization and save expansion costs.

[0088] Specifically, according to the predicted future traffic data of each service, it is converted into future resource data according to the preset conversion rules. By comparing the future resource data with the resource data currently possessed by each service, the idle resources of each service can be determined. The idle resource data includes idle time, idle service, idle resource type, idle resource quantity, etc. Then, the container orchestration tool, such as the pod container of kubernetes, can be used to construct resource transfer instructions to transfer idle resources to the service to be expanded. The resource transfer instruction may include execution time (determined according to idle time), execution object (determined according to idle service), transfer size (determined according to idle resource type and idle resource quantity), and resource transfer processing is performed on the idle service. Correspondingly, when the idle service needs to be expanded in a certain future time window, the idle service becomes the service to be expanded, and the service to be expanded is expanded, so that resources can flow effectively between the idle service and the service to be expanded, thereby improving the effective utilization of resources. The above is an example, which is set according to the implementation situation and is not limited here.

[0089] Therein, step S204 and step S205 are not limited in the execution order, and corresponding steps are executed according to the implementation situation.

[0090] According to the service traffic prediction and expansion method provided by the present application, the static service code can be read in real time, the call dependency relationship between the static codes can be obtained, the call relationship diagram between the services that can be updated in real time can be constructed, and the upstream and downstream call relationships and the number of calls between the services can be determined. Based on the gateway to obtain accurate real-time traffic data, based on the static service call relationship and the dynamic real-time traffic data, the traffic data of each service under the microservice architecture can be accurately calculated, and the traffic weight of each service in the call relationship diagram can be obtained. A traffic propagation model is constructed based on the traffic weights and call relationship diagrams of services in multiple time windows, the traffic changes of services in different time windows are recorded, and the traffic of each service is analyzed in a time series using a preset timing model. The traffic changes of each service in the future time window are predicted, and potential bottlenecks, traffic troughs, etc. can be determined. The services to be expanded can be accurately identified and determined, and accurate resource expansion can be performed based on the services to be expanded at the time to be expanded. It can also determine the idle resources of the service, transfer the idle resources, effectively utilize the idle resources, avoid resource waste, and accurately provide resources to the services to be expanded to ensure the normal operation of the services.

[0091] Figure 3 The schematic diagram of the structure of the service flow prediction and expansion device provided by an embodiment of the present application is shown. Figure 3 As shown, the device comprises:

[0092] The call relationship graph module 310 is adapted to read and parse each service code under the microservice architecture, obtain the call relationship between each service, and generate a call relationship graph according to the call relationship;

[0093] The traffic weight module 320 is adapted to obtain traffic data of the service and update the traffic weight of each service located downstream of the call relationship in the call relationship graph according to the traffic data of the service;

[0094] The prediction module 330 is adapted to construct a traffic propagation model according to the call relationship graph and the traffic weight, and to predict the future traffic data of each service in the traffic propagation model using a preset time series model;

[0095] The capacity expansion module 340 is adapted to determine the resource gap of each service according to the future traffic data of each service, obtain the data to be expanded, and perform capacity expansion processing on the service according to the data to be expanded.

[0096] Optionally, the call graph module 310 is further adapted to:

[0097] Read and parse the service code in at least one code repository to obtain an abstract syntax tree of each service code;

[0098] Traverse the abstract syntax tree of each service code to determine the calling relationship between services;

[0099] A call relationship graph is generated based on the call relationship between each service; wherein the call relationship graph includes the upstream and downstream call relationships between services and the number of calls.

[0100] Optionally, the traffic weight module 320 is further adapted to:

[0101] Based on the gateway tracking, the traffic data of the service is obtained, and according to the upstream and downstream call relationships and the corresponding number of calls in the call relationship graph, the traffic data of each service located downstream of the call relationship is calculated according to the time window, so as to update the service traffic weight of the call relationship graph according to the traffic data.

[0102] Optionally, the traffic weight module 320 is further adapted to:

[0103] If a downstream service has an upstream service, the product of the traffic data of the upstream service and the corresponding number of calls is calculated as the traffic data of the downstream service;

[0104] If a downstream service has multiple upstream services, the sum of the traffic data of the multiple upstream services multiplied by the corresponding number of calls is accumulated as the traffic data of the downstream service.

[0105] Optionally, the prediction module 330 is further adapted to:

[0106] Get the traffic weight of each service in each time window;

[0107] Build a traffic propagation model based on the call relationship graph and the traffic weights of each service in each time window to determine the traffic transmission path and load pressure distribution of upstream and downstream services in each time window;

[0108] The preset time series model is used to predict the future traffic data corresponding to the future time window of each service in the traffic propagation model based on the historical time window.

[0109] Optionally, the expansion module 340 is further adapted to:

[0110] According to the future traffic data corresponding to the future time window of each service, the future resource data is converted according to the preset conversion rules;

[0111] Determine the resource gap of each service based on future resource data and obtain the data to be expanded; the data to be expanded includes the time to be expanded, the service to be expanded, the type of resources to be expanded, and the number of resources to be expanded;

[0112] According to the data to be expanded, expansion instructions are built based on the container orchestration tool to expand the service to be expanded.

[0113] Optionally, the device further comprises: a resource transfer module 350 adapted to determine the idle resources of each service according to the future traffic data of each service, so as to perform resource transfer according to the idle resources.

[0114] The description of each module above refers to the corresponding description in the method embodiment and will not be repeated here.

[0115] According to the service traffic prediction and expansion device provided in the present application, by obtaining the dependencies between services, a real-time updated service call relationship graph is constructed, and based on static dependencies and dynamically acquired traffic data, traffic timing analysis is performed on each service to predict service traffic changes and potential bottlenecks, accurately identify services to be expanded, avoid blind expansion or improper resource allocation, improve resource utilization, and reduce costs.

[0116] The present application also provides a non-volatile computer storage medium, which stores at least one executable instruction, and the executable instruction can execute operations corresponding to the service traffic prediction and expansion method in any of the above method embodiments.

[0117] The present application also provides a computer program product, which includes at least one executable instruction or computer program, and the executable instruction or computer program can enable a processor to perform operations corresponding to the service traffic prediction and expansion method in any of the above method embodiments.

[0118] Figure 4 A schematic diagram of the structure of a computing device according to an embodiment of the present application is shown. The specific embodiment of the present application does not limit the specific implementation of the computing device.

[0119] like Figure 4 As shown, the computing device may include: a processor (processor) 402 , a communications interface (Communications Interface) 404 , a memory (memory) 406 , and a communication bus 408 .

[0120] in:

[0121] The processor 402 , the communication interface 404 , and the memory 406 communicate with each other via a communication bus 408 .

[0122] The communication interface 404 is used to communicate with other devices such as clients or other servers.

[0123] The processor 402 is used to execute the program 410, and specifically can execute the relevant steps in the above-mentioned service traffic prediction and expansion method embodiment.

[0124] Specifically, the program 410 may include program codes, which include computer operation instructions.

[0125] The processor 402 may be a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the present application. The one or more processors included in the computing device may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0126] The memory 406 is used to store the program 410. The memory 406 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0127] Program 410 can be specifically used to enable processor 402 to execute the service traffic prediction and expansion method in any of the above-mentioned method embodiments. The specific implementation of each step in program 410 can refer to the corresponding descriptions in the corresponding steps and units in the above-mentioned service traffic prediction and expansion embodiments, which will not be repeated here. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working process of the above-described devices and modules can refer to the corresponding process description in the above-mentioned method embodiments, which will not be repeated here.

[0128] The algorithm or display provided here is not inherently related to any specific computer, virtual system or other device. Various general systems can also be used together with the teaching based on this. According to the above description, it is obvious to construct the structure required for this type of system. In addition, the application is not directed to any specific programming language either. It should be understood that various programming languages ​​can be utilized to realize the content of the application described here, and the above description of specific languages ​​is to disclose the preferred embodiment of the application.

[0129] In the description provided herein, a large number of specific details are described. However, it is understood that the embodiments of the present application can be practiced without these specific details. In some instances, well-known methods, structures and techniques are not shown in detail so as not to obscure the understanding of this description.

[0130] Similarly, it should be understood that in order to streamline the present application and help understand one or more of the various inventive aspects, in the above description of the exemplary embodiments of the present application, the various features of the present application are sometimes grouped together into a single embodiment, figure, or description thereof. However, the disclosed method should not be interpreted as reflecting the following intention: the claimed application requires more features than the features clearly stated in each claim. More specifically, as reflected in the claims below, the inventive aspects are less than all the features of the single embodiment disclosed above. Therefore, the claims following the specific embodiment are hereby expressly incorporated into the specific embodiment, wherein each claim itself serves as a separate embodiment of the present application.

[0131] Those skilled in the art will appreciate that the modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments may be combined into one module or unit or component, and in addition they may be divided into a plurality of submodules or subunits or subcomponents. Except that at least some of such features and / or processes or units are mutually exclusive, all features disclosed in this specification (including the accompanying claims, abstracts and drawings) and all processes or units of any method or device disclosed in this manner may be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstracts and drawings) may be replaced by an alternative feature providing the same, equivalent or similar purpose.

[0132] In addition, those skilled in the art will appreciate that, although some embodiments herein include certain features included in other embodiments but not other features, the combination of features of different embodiments is meant to be within the scope of the present application and form different embodiments. For example, in the claims below, any one of the claimed embodiments may be used in any combination.

[0133] The various component embodiments of the present application can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. It should be understood by those skilled in the art that a microprocessor or digital signal processor (DSP) can be used in practice to implement some or all functions of some or all components of the present application. The present application can also be implemented as a device or apparatus program (e.g., computer program and computer program product) for executing a part or all of the methods described herein. Such a program implementing the present application can be stored on a computer-readable medium, or can have the form of one or more signals. Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0134] It should be noted that the above embodiments illustrate the present application rather than limit the present application, and that those skilled in the art may design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference symbol between brackets shall not be constructed as a limitation on the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "one" or "an" preceding an element does not exclude the presence of multiple such elements. The present application may be implemented by means of hardware including several different elements and by means of a suitably programmed computer. In a unit claim that lists several devices, several of these devices may be embodied by the same hardware item. The use of the words first, second, and third, etc. does not indicate any order. These words may be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be understood as limitations on the order of execution.

Claims

1. A service traffic prediction and expansion method, comprising: Read and parse each service code under the microservice architecture, obtain the call relationship between each service, and generate a call relationship graph based on the call relationship; Obtaining traffic data of the service, and updating the traffic weight of each service located downstream of the call relationship in the call relationship graph according to the traffic data of the service; A traffic propagation model is constructed according to the call relationship graph and the traffic weight, and future traffic data of each service in the traffic propagation model is predicted using a preset timing model; The resource gap of each service is determined according to the future traffic data of each service, and the data to be expanded is obtained, so as to perform capacity expansion processing on the service according to the data to be expanded.

2. The method according to claim 1, wherein: The reading and parsing of each service code under the microservice architecture to obtain the calling relationship between each service, and generating a calling relationship graph according to the calling relationship further includes: Read and parse the service code in at least one code repository to obtain an abstract syntax tree of each service code; Traverse the abstract syntax tree of each service code to determine the calling relationship between services; A call relationship graph is generated according to the call relationship between each service; wherein the call relationship graph includes the upstream and downstream call relationships between services and the number of calls.

3. The method according to claim 1 or 2, wherein: The acquiring of the traffic data of the service and updating the traffic weight of each service located downstream of the call relationship in the call relationship graph according to the traffic data of the service further includes: Based on the gateway tracking, the traffic data of the service is obtained, and according to the upstream and downstream call relationships and the corresponding call times in the call relationship graph, the traffic data of each service located downstream of the call relationship is calculated according to the time window, so as to update the service traffic weight of the call relationship graph according to the traffic data.

4. The method according to claim 3, wherein: The calculating, according to the upstream and downstream call relationships and the corresponding call times in the call relationship graph, the flow data of each service located downstream of the call relationship according to the time window further includes: If a downstream service has an upstream service, the product of the traffic data of the upstream service and the corresponding number of calls is calculated as the traffic data of the downstream service; If a downstream service has multiple upstream services, the sum of the traffic data of the multiple upstream services multiplied by the corresponding number of calls is accumulated as the traffic data of the downstream service.

5. The method according to any one of claims 1 to 4, wherein: The step of constructing a traffic propagation model according to the call relationship graph and the traffic weight, and using a preset timing model to predict the future traffic data of each service in the traffic propagation model further includes: Get the traffic weight of each service in each time window; A traffic propagation model is constructed based on the call relationship graph and the traffic weights of each service in each time window to determine the transmission path and load pressure distribution of the traffic in each time window in the upstream and downstream services; The preset time series model is used to predict the future traffic data corresponding to the future time window of each service in the traffic propagation model according to the historical time window.

6. The method according to any one of claims 1 to 5, wherein: Determining the resource gap of each service according to the future traffic data of each service, obtaining the data to be expanded, and performing capacity expansion processing on the service according to the data to be expanded further includes: According to the future traffic data corresponding to the future time window of each service, converting it into future resource data according to a preset conversion rule; Determine the resource gap of each service according to the future resource data, and obtain the data to be expanded; the data to be expanded includes the time to be expanded, the service to be expanded, the type of resources to be expanded, and the number of resources to be expanded; According to the data to be expanded, an expansion instruction is constructed based on a container orchestration tool to expand the service to be expanded.

7. The method according to any one of claims 1 to 6, wherein: The method further comprises: The idle resources of each service are determined according to the future traffic data of each service, so as to perform resource transfer according to the idle resources.

8. A service traffic prediction and expansion device, comprising: The call relationship graph module is suitable for reading and parsing each service code under the microservice architecture, obtaining the call relationship between each service, and generating a call relationship graph according to the call relationship; A traffic weight module, adapted to obtain traffic data of a service, and update the traffic weight of each service located downstream of the call relationship in the call relationship graph according to the traffic data of the service; A prediction module, adapted to construct a traffic propagation model according to the call relationship graph and the traffic weight, and to predict the future traffic data of each service in the traffic propagation model using a preset timing model; The capacity expansion module is adapted to determine the resource gap of each service according to the future traffic data of each service, obtain the data to be expanded, and perform capacity expansion processing on the service according to the data to be expanded.

9. A computing device comprising: A processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform operations corresponding to the service traffic prediction and expansion method as described in any one of claims 1-7.

10. A computer storage medium, wherein at least one executable instruction is stored in the storage medium, and the executable instruction enables a processor to perform operations corresponding to the service traffic prediction and expansion method as described in any one of claims 1-7.

11. A computer program product, comprising at least one executable instruction, wherein the executable instruction enables a processor to perform operations corresponding to the service traffic prediction and expansion method as described in any one of claims 1-7.

Images