Service prediction model determination method and related device

Abstract

The invention discloses a service prediction model determination method and a related device, and the method comprises the steps: dividing historical call data, corresponding to a historical service period, of a micro-service system into internal call data and external call data, and constructing a training sample for model training through employing the external call data. The influence of the internal calling data on the load parameters is relatively fixed, and the influence of the external calling data on the load parameters is more dynamic, so that the external calling data is used for constructing the training sample, data simplification can be realized, and the calculation complexity in a model training process is reduced. After the target service prediction model is obtained, when a service prediction request is received, prediction load parameters corresponding to the micro-service system in the prediction service time period can be output through the target service prediction model according to external calling prediction data in the service prediction request, and prediction is achieved. It can be seen that the prediction data called internally is not used in the model application stage, and the calculation complexity in the model application process is reduced.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a service prediction model determination method and related devices. Background Art

[0002] In high-concurrency system design, an application (system) is usually split into several highly cohesive and low-coupling microservices. Each microservice can run independently and be deployed separately, and can obtain the required information by calling each other. This method of high-concurrency system design based on a distributed microservice architecture can improve development efficiency, as well as scalability and maintenance flexibility to cope with various sudden external conditions, so it is widely used.

[0003] As business development speed continues to accelerate and business data continues to grow, the requirements for the stability of microservice systems are also increasing. In order to be able to flexibly respond to business calls, the load parameters of the microservice system can usually be predicted to evaluate the capacity of the microservice system and facilitate flexible adjustments to avoid the problem of instability of the microservice system when calling business. Among them, the load parameters can be used to reflect the service resource usage of the microservice system.

[0004] In the related art, the model can be trained through the calling relationship of microservices in the microservice system and the load parameters of the microservices, and then the load parameters can be predicted using the obtained service prediction model. However, as the business grows, the complexity of the microservice system increases, and the number and calling relationship of microservices will become more complex, which will lead to a sharp increase in computational complexity. In this way, when the method provided in the related art is adopted, the computational complexity of the model training process and the model application process is relatively high. Summary of the invention

[0005] In order to solve the above technical problems, the present application provides a service prediction model determination method and related devices, which simplify data, reduce calculation complexity, and ensure prediction accuracy.

[0006] The embodiments of the present application disclose the following technical solutions:

[0007] On the one hand, an embodiment of the present application provides a method for determining a service prediction model, the method comprising:

[0008] Obtain the historical call data of the microservice system corresponding to the historical service period;

[0009] Divide the historical call data into internal call data and external call data, wherein the internal call data is used to identify the service calls within the microservice system during the historical service period, and the external call data is used to identify the service calls made by the external system to the microservice system during the historical service period;

[0010] Inputting the training samples constructed based on the external call data into the initial service prediction model, and outputting the sample load parameters corresponding to the microservice system in the historical service period through the initial service prediction model;

[0011] Based on the difference between the sample load parameter and the sample label of the training sample, the initial service prediction model is adjusted to obtain a target service prediction model, wherein the sample label is used to identify the historical load parameter of the microservice system corresponding to the historical service period;

[0012] When a service prediction request is received, the predicted load parameters corresponding to the microservice system in the predicted service period are output through the target service prediction model based on the external call prediction data in the service prediction request, and the external call prediction data is used to identify the business call of the external system to the microservice system in the predicted service period.

[0013] On the other hand, an embodiment of the present application provides a service prediction model determination device, the device comprising an acquisition unit, a division unit, an output unit and an adjustment unit:

[0014] The acquisition unit is used to acquire historical call data corresponding to the microservice system in the historical service period;

[0015] The division unit is used to divide the historical call data into internal call data and external call data, wherein the internal call data is used to identify the service calls within the microservice system during the historical service period, and the external call data is used to identify the service calls made by the external system to the microservice system during the historical service period;

[0016] The output unit is used to input the training samples constructed based on the external call data into the initial service prediction model, and output the sample load parameters corresponding to the microservice system in the historical service period through the initial service prediction model;

[0017] The adjustment unit is used to adjust the initial service prediction model based on the difference between the sample load parameter and the sample label of the training sample to obtain a target service prediction model, wherein the sample label is used to identify the historical load parameter corresponding to the microservice system in the historical service period;

[0018] The output unit is also used to output the predicted load parameters corresponding to the microservice system in the predicted service period through the target service prediction model when a service prediction request is received, based on the external call prediction data in the service prediction request, and the external call prediction data is used to identify the business call of the external system to the microservice system in the predicted service period.

[0019] In a possible implementation manner, the dividing unit is further configured to:

[0020] Based on the external call relationship corresponding to the microservice system in the historical service period, the external call data is filtered from the historical call data, and the call data other than the external call data in the historical call data is determined as the internal call data, wherein the external call relationship is used to identify the call relationship corresponding to the business call initiated by the external system to the microservice system in the historical service period.

[0021] In a possible implementation, the microservice system includes boundary microservices and non-boundary microservices, the external system is used to initiate a service call to the microservice system by calling the boundary microservice, the boundary microservice is used to call the non-boundary microservice to perform a service response to the service call initiated by the external system, and the acquisition unit is further used to:

[0022] The external call relationship is determined according to the call relationship of the boundary class microservice being called by the external system during the historical service period.

[0023] In a possible implementation, the historical call data is the number of historical calls.

[0024] In a possible implementation, the external system includes s external callers, the external call data is related to t microservices included in the microservice system, and each of the t microservices includes the same number of service interfaces, and the acquisition unit is further used to:

[0025] Count the total number of times the s external callers call the interface of the microservice during the historical service period;

[0026] According to the total number of interface calls corresponding to the t microservices, a t*1 external call number matrix is ​​constructed as the external call data, and the j-th matrix element in the external call number matrix is ​​used to represent the total number of interface calls corresponding to the j-th microservice.

[0027] In a possible implementation, the external system includes s external callers, the external call data is related to t microservices included in the microservice system, and the j-th microservice among the t microservices includes 1j service interfaces, and the acquisition unit is further used to:

[0028] Counting the number of times the s external callers respectively call the 1j service interfaces during the historical service period;

[0029] Based on the interface call times of the Ij service interfaces, a 1*Ij interface call times matrix corresponding to the j-th microservice is constructed, wherein the k-th matrix element in the interface call times matrix is ​​used to represent the total number of times the s external callers call the k-th service interface among the Ij service interfaces in the historical service period;

[0030] The external call data is determined according to the interface call number matrices corresponding to the t microservices.

[0031] In a possible implementation, the external call data is related to t microservices included in the microservice system, and the j-th microservice among the t microservices includes Ij service interfaces, and the maximum number of service interfaces included in a single microservice is Ix, and the acquisition unit is further used to:

[0032] According to the external call data corresponding to the Ij service interfaces and the size relationship between Ij and Ix, the external call sub-matrix corresponding to the j-th microservice is determined, the number of columns of the external call sub-matrix is ​​Ix, the Ix column matrix elements include Ij column matrix elements, the k-th column matrix elements in the Ij column matrix elements are used to represent the external call data corresponding to the k-th service interface in the Ij service interfaces, if Ij is less than Ix, the Ix-Ij column matrix elements in the Ix column matrix elements are used to represent the complementary data corresponding to the j-th microservice;

[0033] The external call data is determined based on the external call sub-matrices corresponding to the t microservices respectively.

[0034] In a possible implementation, the completion data corresponding to different microservices are the same.

[0035] In one possible implementation, the microservice system includes n microservices, the n microservices include t microservices, the sample labels are used to identify the historical load parameters corresponding to the n microservices in the historical service period, and the sample load parameters are used to identify the load parameter prediction results corresponding to the n microservices in the historical service period.

[0036] On the other hand, an embodiment of the present application provides a computer device, the computer device comprising a processor and a memory:

[0037] The memory is used to store a computer program and transmit the computer program to the processor;

[0038] The processor is configured to execute the method described in any one of the preceding aspects according to instructions in the computer program.

[0039] On the other hand, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store a computer program. When the computer program is executed by a computer device, the computer device executes the method described in any of the above aspects.

[0040] On the other hand, an embodiment of the present application provides a computer program product, including a computer program, which, when executed on a computer device, enables the computer device to execute the method described in any one of the aforementioned aspects.

[0041] It can be seen from the above technical solution that the historical call data corresponding to the microservice system in the historical service period is divided into internal call data and external call data, and the external call data is used to construct training samples for model training. Among them, the internal call data can be used to identify the business calls within the microservice system in the historical service period, and the external call data can be used to identify the business calls of the external system to the microservice system in the historical service period. Since the internal business logic and call relationship are relatively stable, that is, the internal call data is relatively stable, and the impact on the load parameters is relatively fixed, and the business logic and call relationship of the external call will change greatly due to different call requirements of the external system, that is, the external call data changes greatly, making the impact of the external call data on the load parameters more dynamic, so using external call data to construct training samples can achieve data simplification and reduce the computational complexity in the model training process, and the internal call data with a relatively fixed impact on the load parameters is not used, which is conducive to ensuring the accuracy of prediction while achieving data simplification. And, since the load parameters of any period are most related to the external call data of the period, it is beneficial to ensure the accuracy of prediction by predicting the load parameters corresponding to the period based on the external call data of a certain period. After obtaining the target service prediction model, when receiving a service prediction request, the prediction load parameters corresponding to the microservice system in the prediction service period can be output through the target service prediction model according to the external call prediction data in the service prediction request to achieve prediction. The external call prediction data can be used to identify the business calls of the external system to the microservice system in the prediction service period. It can be seen that the prediction data of the internal call is not used in the model application stage, which reduces the computational complexity of the model application process. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technical members in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0043] Figure 1 A schematic diagram of an application scenario of a method for determining a service prediction model provided in an embodiment of the present application;

[0044] Figure 2 A flowchart of a method for determining a service prediction model provided in an embodiment of the present application;

[0045] Figure 3 A schematic diagram of the model structure of an initial service prediction model provided in an embodiment of the present application;

[0046] Figure 4 A schematic diagram of a data simplification method provided in an embodiment of the present application;

[0047] Figure 5 A schematic diagram of an external call matrix provided in an embodiment of the present application;

[0048] Figure 6 A schematic diagram of the processing process of an initial service prediction model provided in an embodiment of the present application;

[0049] Figure 7 A structural diagram of a service prediction model determination device provided in an embodiment of the present application;

[0050] Figure 8 A structural diagram of a terminal provided in an embodiment of the present application;

[0051] Fig. 9 A structural diagram of a server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0052] The embodiments of the present application are described below in conjunction with the accompanying drawings.

[0053] In practical applications, in order to flexibly respond to business calls, the load parameters of the microservice system can usually be predicted to evaluate the capacity of the microservice system and facilitate flexible adjustments to avoid the instability of the microservice system during business calls. The load parameter can be used to reflect the service resource usage of the microservice system. For example, the load parameter can be the CPU usage of the microservice system.

[0054] In the related art, the model training can be carried out through the call relationship of the microservices in the microservice system and the load parameters of the microservices, and then the load parameters can be predicted using the obtained service prediction model. Specifically, the model training can be carried out using the complete set of call relationships between microservices in the microservice system using a graph neural network to obtain the corresponding service prediction model. However, with the growth of business, the complexity of the microservice system increases, and the number and call relationships of microservices will become more and more complex, which will lead to a sharp increase in computational complexity. On this basis, in order to enable the trained service prediction model to take into account these complex call relationships and other features, heterogeneous network modules are usually introduced, which will further increase the computational complexity. In this way, when adopting the method provided in the related art, the computational complexity of the model training process and the model application process is relatively high, and the cost is also too high.

[0055] In addition to this service prediction method based on graph neural network, the related technology also provides a service prediction method based on the historical time series data of the microservice system to predict future time series data. Specifically, for example, a spatiotemporal graph neural network combined with a graph attention network and a recurrent neural network can be used. The data features that need to be input may include the call relationship set between microservices included in the microservice system, the number of microservices, the number of microservice workload categories, the current microservice workload and other time series data, and the output prediction data is the predicted time series data of each microservice under the microservice workload category. Among them, the time series data refers to the data of the microservice system at each time point in a certain period of time. The time series data can reflect the changes of the call relationship, the number of microservices, the number of workload categories, the workload, etc. over time in this period of time. The output prediction time series data can reflect the changes over time in a future period of time. The microservice workload category is used to indicate the category of the load parameter, for example, it can indicate that the load parameter is CPU usage, memory occupancy, etc.

[0056] However, for rapidly developing businesses, historical time series data has little reference value for the future. The service prediction method based on historical time series data in related technologies has the problem of poor prediction accuracy. For example, the caller of a business will launch a new business at a certain time in the future. In this case, the number of business calls from the caller to the microservice system will increase rapidly in a short period of time. It is impossible to accurately predict future time series data in such cases based on historical time series data. Therefore, when such a situation occurs, problems such as instability of the microservice system may still occur.

[0057] To this end, the embodiment of the present application provides a method for determining a service prediction model and a related device. On the one hand, internal call data and external call data are distinguished, and external call data are used to construct training samples for model training. Among them, the internal call data can be used to identify the business calls within the microservice system during the historical service period, and the external call data can be used to identify the business calls of the external system to the microservice system during the historical service period. Since the internal business logic and call relationship are relatively stable, that is, the impact of the internal call data on the load parameters is relatively fixed, and the business logic and call relationship of the external call will change greatly due to different call requirements of the external system, that is, the external call data changes greatly, making the impact of the external call data on the load parameters more dynamic, so using external call data to construct training samples can achieve data simplification and reduce the computational complexity in the model training process. The prediction data of the internal call is not used in the model application stage, which reduces the computational complexity in the model application process. Compared with the service prediction method in the related art, it can reduce the computational complexity and reduce costs.

[0058] On the other hand, the present application does not use the internal call data that has a relatively fixed impact on the load parameters, which simplifies the data while also helping to ensure prediction accuracy. Also, since the load parameters of any time period are most relevant to the external call data of that time period, in the present application, the input is the external call data of a certain time period, and the output is the load parameters corresponding to that time period, that is, the load parameters corresponding to the same time period are predicted based on the external call data of a certain time period. Compared with the service prediction method based on historical time series data in the related art, it has higher prediction accuracy. For the aforementioned situation where the launch of new services leads to an increase in the number of requests, more accurate predictions can also be achieved.

[0059] The service prediction model determination method provided in the embodiment of the present application can be implemented by a computer device, which can be a terminal or a server, wherein the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services. Terminals include but are not limited to smart phones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, etc. The terminal and the server can be directly or indirectly connected via wired or wireless communication, and this application is not limited here. The embodiment of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, audio and video, assisted driving, etc. The embodiment of the present application can be specifically applied to service prediction scenarios of various microservice systems, for example, prediction scenarios of CPU usage of microservice systems, etc.

[0060] It should be noted that in the specific implementation of the present application, the process of determining the service prediction model may involve relevant data such as user information. When the above embodiments of the present application are applied to specific products or technologies, the user's separate consent or separate permission is required, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0061] The service prediction model determination method provided in the embodiment of the present application may involve artificial intelligence technology. Artificial intelligence (AI) is the theory, method, technology and application system of using digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain the best results. Among them, artificial intelligence technology is a comprehensive discipline, involving a wide range of fields, including both hardware-level technology and software-level technology. Basic artificial intelligence technology generally includes technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technology, operation / interaction systems, mechatronics, etc. Artificial intelligence software technology mainly includes computer vision technology, speech processing technology, natural language processing technology, and machine learning / deep learning, automatic driving, smart transportation and other major directions. For example, in the embodiment of the present application, machine learning can be used to train the initial service prediction model to obtain the target service prediction model, so as to facilitate the use of the target service prediction model to predict the load parameters of the predicted service period and improve efficiency.

[0062] Figure 1 The application scenario of the service prediction model determination method provided by the embodiment of the present application is shown. Figure 1 In the illustrated scenario, the server 100 is used as an example of the aforementioned computer device for illustration:

[0063] First, the server 100 can obtain the historical call data corresponding to the microservice system in the historical service period, and the server 100 can divide the historical call data into internal call data and external call data. Among them, the internal call data can be used to identify the business calls within the microservice system in the historical service period, which can be seen in Figure 1 The solid arrow example inside the microservice system shown in the figure, the external call data can be used to identify the business calls made by the external system to the microservice system during the historical service period, which can be seen in Figure 1The solid arrow example between the external system and the microservice system is shown in FIG. The external system and the microservice system are independent of each other. The external system may refer to a system other than the microservice system. For example, the external system may include an external caller. The external caller may be, for example, a business party to which the application belongs. The microservice system may provide business services to implement business calls within the microservice system and business calls to the microservice system from the external system.

[0064] Next, the server 100 can use the external call data to construct training samples for model training. Specifically, the initial service prediction model can be input based on the training samples constructed by the external call data, and the sample load parameters corresponding to the microservice system in the historical service period can be output through the initial service prediction model. The sample load parameters can refer to the load parameter prediction results corresponding to the microservice system in the historical service period. During the model training process, the server 100 can adjust the initial service prediction model based on the difference between the sample load parameters and the sample labels of the training samples to obtain the target service prediction model. Among them, the sample labels can be used to identify the historical load parameters corresponding to the microservice system in the historical service period, and the historical load parameters can refer to the actual results of the load parameters corresponding to the microservice system in the historical service period. Therefore, the aforementioned difference is the difference between the load parameter prediction results and the load parameter actual results. Based on this, the initial service prediction model is adjusted to achieve the purpose of model training. The target service prediction model obtained can refer to the initial service prediction model after the model training end conditions are met.

[0065] Since the internal business logic and calling relationship are relatively stable, that is, the internal calling data is relatively stable, and the impact on the load parameters is relatively fixed, and the business logic and calling relationship of external calls will change greatly due to different calling requirements of the external system, that is, the external calling data changes greatly, making the impact of external calling data on load parameters more dynamic, so using external calling data to construct training samples can achieve data simplification and reduce the computational complexity in the model training process, and the internal calling data with a relatively fixed impact on the load parameters is not used, which reduces the computational complexity and is also conducive to ensuring the accuracy of prediction.

[0066] After obtaining the target service prediction model, the target service prediction model can be used to perform service prediction. Specifically, when receiving a service prediction request, the server 100 outputs the predicted load parameters corresponding to the microservice system in the predicted service period through the target service prediction model according to the external call prediction data in the service prediction request to achieve prediction. Figure 1 The model application process indicated by the dashed box in the figure. Among them, the external call prediction data can be used to identify the business calls made by the external system to the microservice system during the predicted service period. Figure 1An example of a dotted arrow between an external system and a microservice system is shown in FIG. It can be seen that the model application phase is also based on external call prediction data, and does not use internal call prediction data, which reduces the computational complexity during the model application process.

[0067] Also, during the model training process, the input external call data and the output historical load parameters correspond to the historical service period. During the model application process, the input external call prediction data and the output prediction load parameters correspond to the predicted service period. It can be seen that this is a way to predict the load parameters of the current period based on the external call data of the current period. Since the load parameters of any period are most relevant to the external call data of that period, this method is conducive to ensuring the accuracy of the prediction. Compared with the service prediction method in the related art that predicts future time series data based on historical time series data, this application does not rely on historical time series data, does not pay attention to the changes in load parameters over time, and for the predicted service period that needs to be predicted, it only needs to pay attention to the external call prediction data corresponding to the predicted service period, so as to achieve more accurate prediction.

[0068] Figure 2 A flowchart of a method for determining a service prediction model provided in an embodiment of the present application is provided, and a server is used as an example of the aforementioned computer device for illustration. The method includes S201-S205:

[0069] S201: Obtain historical call data corresponding to the microservice system in the historical service period.

[0070] The microservice system can be used to provide business services, and the historical call data can refer to the call data generated by the microservice system during the historical service period, and specifically can be the data generated corresponding to the business services provided by the microservice system during the historical service period. In order to achieve service prediction for the microservice system, the server can obtain the historical call data corresponding to the microservice system during the historical service period, so as to carry out subsequent steps.

[0071] S202: Divide the historical call data into internal call data and external call data.

[0072] After obtaining the historical call data, the server can divide the historical call data into internal call data and external call data. Among them, the internal call data can be used to identify the business calls within the microservice system during the historical service period, and the external call data can be used to identify the business calls of the external system to the microservice system during the historical service period. The external system is independent of the microservice system. The external system can refer to a system other than the microservice system. For example, the external system may include an external caller. The external caller may be, for example, a business party to which the application belongs. The microservice system can provide business services to realize the business calls within the microservice system and the business calls of the external system to the microservice system. Accordingly, the internal call data may be the data generated in the process of the microservice system responding to the internal business calls, and the external call data may be the data generated in the process of the microservice system responding to the external business calls.

[0073] It should be noted that the present application does not impose any limitation on how to divide the historical call data into internal call data and external call data. For ease of understanding, the present application provides the following methods as examples:

[0074] In practical applications, whether it is a business call within the microservice system or a business call initiated by an external system to the microservice system, there is usually a corresponding call relationship, and the call relationship can reflect the situation that the microservice system calls related services in order to respond to the business call. Therefore, in a possible implementation method, the external call data and the internal call data can be determined based on the call relationship. In specific implementation, the server can filter the external call data from the historical call data based on the external call relationship corresponding to the microservice system in the historical service period, wherein the external call relationship can be used to identify the call relationship corresponding to the business call initiated by the external system to the microservice system in the historical service period, that is, it can reflect the situation that the service is called in response to the business call initiated by the external system. Therefore, the external call data can be filtered based on the external call relationship. And, the call data other than the external call data in the historical call data can be determined as internal call data. Based on this, the required external call data can be filtered out based on the external call relationship, and at the same time, there is no need to pay attention to the specific internal call data, which is conducive to simplifying the processing flow and saving costs.

[0075] It is understandable that, similar to filtering external call data, if internal call data is needed for analysis in some scenarios, internal call data can also be filtered from historical call data based on internal call relationships. Internal call relationships can be used to identify the call relationships corresponding to business calls within the microservice system during the historical service period, and can reflect the situation of related services called in order to respond to internal business calls. Based on this, when internal call data is needed, it can also be filtered based on internal call relationships, which can help ensure the accuracy of internal call data.

[0076] It should also be noted that this application does not impose any limitation on how to determine the external call relationship. For ease of understanding, this application embodiment provides the following method as an example:

[0077] In practical applications, a microservice system can be a whole composed of several microservices, each of which can be independently operated and deployed, so that the microservice system can be more flexible, for example, flexible expansion and contraction. Generally, microservices can be divided into two types of microservices, that is, a microservice system can include boundary microservices and non-boundary microservices. Accordingly, an external system can be used to initiate a business call to the microservice system by calling a boundary microservice, and a boundary microservice can be used to call a non-boundary microservice to respond to the business call initiated by the external system. In other words, a boundary microservice can refer to a microservice visible to an external system, and the external system can interact with the boundary microservice, while a non-boundary microservice is a microservice that is invisible to the external system. Generally, the number of boundary microservices is relatively small. When responding to a business call initiated by an external system, the boundary microservice may not be enough to complete the entire service response. In this case, the boundary microservice will call the non-boundary microservice to provide a service, that is, although the non-boundary microservice is invisible to the external system, it may also participate in the service response to the business call of the external system.

[0078] Correspondingly, when determining the external call relationship, the server can determine the external call relationship based on the call relationship of the boundary microservice being called by the external system during the historical service period. Based on this, the external call relationship can be determined by using the call situation of the boundary microservice. The boundary microservice is part of the microservice system, and the number of boundary microservices in actual applications is relatively small, which is conducive to improving efficiency.

[0079] S203: Input the training samples constructed based on the external call data into the initial service prediction model, and output the sample load parameters corresponding to the microservice system in the historical service period through the initial service prediction model.

[0080] S204: Based on the difference between the sample load parameters and the sample labels of the training samples, the initial service prediction model is adjusted to obtain a target service prediction model.

[0081] In actual applications, since the internal business logic and call relationship are relatively stable, that is, the internal call data is relatively stable, and the impact on load parameters is relatively fixed, while the business logic and call relationship of external calls will change greatly due to different call requirements of the external system, that is, the external call data changes greatly, and the impact on load parameters is more dynamic. Therefore, after determining the external call data, you can use the external call data to build training samples, which can achieve data simplification and reduce the computational complexity in the model training process.

[0082] In specific implementation, the server can input the training samples constructed based on the external call data into the initial service prediction model, and output the sample load parameters corresponding to the microservice system in the historical service period through the initial service prediction model. The sample load parameters can refer to the load parameter prediction results corresponding to the microservice system in the historical service period. During the model training process, the server can adjust the initial service prediction model based on the difference between the sample load parameters and the sample labels of the training samples to obtain the target service prediction model. Among them, the sample labels can be used to identify the historical load parameters corresponding to the microservice system in the historical service period, and the historical load parameters can refer to the actual results of the load parameters corresponding to the microservice system in the historical service period. Therefore, the aforementioned difference is the difference between the load parameter prediction results and the load parameter actual results. Based on this, the initial service prediction model is adjusted to achieve the purpose of model training. The target service prediction model obtained can refer to the initial service prediction model after the model training end conditions are met.

[0083] Based on this, by distinguishing between internal call data and external call data, and using external call data for model training, data simplification is achieved, the computational complexity in the model training process is reduced, and internal call data with a relatively fixed impact on load parameters is not used, which reduces the computational complexity while also helping to ensure prediction accuracy.

[0084] The present application does not limit how to construct training samples based on external call data. In one possible implementation, the external call data can be directly used as training samples, which is simpler and more convenient. Correspondingly, the historical load parameters of the historical service period can be used as sample labels.

[0085] It should be noted that this application does not impose any limitation on the setting of the initial service prediction model. For ease of understanding, the embodiments of this application provide the following methods as examples:

[0086] In practical applications, in terms of model structure, the initial service prediction model can include convolutional layers, dropout layers, and fully connected layers. Figure 3 As shown, specifically:

[0087] The convolution layer can be used to map the input external call data to obtain the corresponding call features. For example, the convolution layer can use a one-dimensional convolution kernel. Then, the call features output by the convolution layer can be used as the input of the Dropout layer. The Dropout layer can inactivate the network neurons in the model with a set probability (for example, setting the probability p = 0.35), which is helpful to prevent overfitting. The output of the Dropout layer can be used as the input of the fully connected layer. Before the final fully connected layer, the Sigmoid function can be used as the activation function to map the value output by the initial service prediction model to between [0, 1], that is, the range of the output sample load parameter is [0, 1]. Taking the load parameter as the CPU usage rate as an example, the output value can intuitively reflect the CPU usage. It should be noted that this application does not impose any restrictions on the number of convolution layers. For example, multiple convolution layers can be set to achieve feature mapping of different scales and reduce the dimension of the call features input to the Dropout layer. And, in practical applications, in the process of mapping in the convolutional layer, a nonlinear activation function (such as TanH, Relu, etc.) can be used to introduce nonlinear features to the model, so that when the model learns the relationship between the external call matrix and the sample load, it can better learn the nonlinear factors between the two, which is conducive to improving the prediction accuracy. Compared with the linear prediction model determined in the relevant technology (such as the autoregressive moving average model, etc.), this application introduces nonlinear features in the model training process, and the target service prediction model obtained can have better prediction accuracy.

[0088] S205: When a service prediction request is received, the predicted load parameters corresponding to the microservice system in the predicted service period are output through the target service prediction model according to the external call prediction data in the service prediction request.

[0089] After obtaining the target service prediction model, the target service prediction model can be used to perform service prediction to determine the predicted load parameters of the microservice system. In practical applications, when a service prediction request is received, it indicates that a service prediction is required. At this time, the server can output the predicted load parameters corresponding to the microservice system in the predicted service period through the target service prediction model based on the external call prediction data in the service prediction request to complete the service prediction. Among them, the external call prediction data can be used to identify the business call of the external system to the microservice system in the predicted service period, and the predicted service period can refer to a certain period in the future that will occur, that is, the external call prediction data can reflect the business call that the external system is expected to initiate to the microservice system in a certain period in the future. The predicted load parameter can refer to the load parameter prediction result corresponding to the microservice system in the predicted service period, which can reflect the load situation of the microservice system when the microservice system responds to the business call expected to be initiated by the external system in a certain period in the future.

[0090] In practical applications, after obtaining the predicted load parameters, the predicted load parameters can be used to evaluate whether the microservice system will have insufficient capacity, instability, etc. during the predicted service period, so as to guide whether it is necessary to expand or shrink the capacity, etc. For example, if the predicted load parameters indicate that the microservice system may have insufficient capacity and instability during the predicted service period, the capacity can be expanded to avoid possible instability.

[0091] It can be understood that after obtaining the target service prediction model, the step of outputting the predicted load parameters based on the external call prediction data and the target service prediction model in the aforementioned S205 only needs to be executed when it is needed. In other words, the aforementioned S205 is not a step that must be executed after the aforementioned S204. The execution of S205 depends on the specific service prediction requirements.

[0092] It should be noted that this application does not impose any limitation on the method for determining the external call prediction data. For ease of understanding, this application embodiment provides the following method as an example:

[0093] In practical applications, the external system and the microservice system are independent of each other. The external system can initiate a business call to the microservice system, and the microservice system can respond to the business call initiated by the external system. Therefore, the external system can also be considered as the upstream of the microservice system. Usually, when service prediction is required, the external system can determine the external call prediction data based on the business call expected to be initiated during the predicted service period, and send the external call prediction data to the server so that the server completes the service prediction based on the external call prediction data. That is, in a possible implementation, the external call prediction data can be determined by the external system based on the pre-business call, and the pre-business call can be the business call that the external system is expected to initiate to the microservice system during the predicted service period. Usually, the server can be deployed on the microservice system side, so it can also be considered that the external call prediction data is determined by the upstream external system, and the service prediction is performed by the downstream microservice system. After completing the service prediction, the microservice system can be flexibly configured according to the predicted load parameters, for example, to determine whether it is necessary to expand or shrink the capacity during the predicted service period.

[0094] For example, the external system needs to launch a new service during the predicted service period. In this case, the predicted service period can be a special time node that requires capacity expansion. Accordingly, after determining the predicted load parameters, it can be determined whether capacity expansion is required based on the specific situation of the predicted load parameters to ensure that during the predicted service period, service responses can be provided to the service calls initiated by the external system in a stable manner.

[0095] It can be seen from the above technical solution that the historical call data corresponding to the microservice system in the historical service period is divided into internal call data and external call data, and the external call data is used to construct training samples for model training. Among them, the internal call data can be used to identify the business calls within the microservice system in the historical service period, and the external call data can be used to identify the business calls of the external system to the microservice system in the historical service period. Since the internal business logic and call relationship are relatively stable, that is, the internal call data is relatively stable, and the impact on the load parameters is relatively fixed, and the business logic and call relationship of the external call will change greatly due to different call requirements of the external system, that is, the external call data changes greatly, making the impact of the external call data on the load parameters more dynamic, so using external call data to construct training samples can achieve data simplification and reduce the computational complexity in the model training process, and the internal call data with a relatively fixed impact on the load parameters is not used, which is conducive to ensuring the accuracy of prediction while achieving data simplification. And, since the load parameters of any period are most related to the external call data of the period, it is beneficial to ensure the accuracy of prediction by predicting the load parameters corresponding to the period based on the external call data of a certain period. After obtaining the target service prediction model, when receiving a service prediction request, the prediction load parameters corresponding to the microservice system in the prediction service period can be output through the target service prediction model according to the external call prediction data in the service prediction request to achieve prediction. The external call prediction data can be used to identify the business calls of the external system to the microservice system in the prediction service period. It can be seen that the prediction data of the internal call is not used in the model application stage, which reduces the computational complexity of the model application process.

[0096] Through the above embodiments, the service prediction model determination process and use process provided by this application are described. In this application, external call data is used. It should be noted that this application does not make any restrictions on how to determine the external call data. For better understanding, the embodiments of this application provide the following methods as examples:

[0097] In practical applications, the call data generated by a business call can be in the form of the number of calls, that is, the aforementioned historical call data can be the number of historical calls. Using the number of calls can more intuitively and concisely reflect the situation of the business call, which is conducive to reducing the complexity of calculation. Usually, in the same service period, the more calls, the higher the load of the microservice system in the service period, and correspondingly, the larger the load parameter, the less available capacity of the microservice system in the service period. Therefore, using the number of calls as call data can not only be more intuitive and concise, but also accurately reflect the relationship between business calls and load parameters, and ensure accuracy.

[0098] Correspondingly, the aforementioned external call data and internal call data can both be in the form of call counts. In order to better understand the external call data used in the present application for service prediction, taking the historical call data as the historical call count as an example, the following example is provided for determining the external call data:

[0099] In practical applications, a microservice system may include microservices, which may specifically be a service response to a business service initiated by an external system by calling a microservice. Accordingly, the external call data may be generated in the process of calling a microservice to respond to a business service initiated by an external system. Accordingly, the external call data may be related to the t microservices included in the microservice system, that is, indicating that t microservices are called to initiate a business call. Typically, an external system may include s external callers, that is, a microservice system may provide business services to different external callers. Wherein, t and s may both be positive integers. In practical applications, a microservice may include a service interface, which may be a business call in the form of interacting with the service interface. Therefore, in the aforementioned example where the external call data is the number of calls, the external call data may be determined by counting the number of calls to the service interface, which is simple and fast.

[0100] It is understandable that in the historical service period, the load parameters corresponding to the business calls initiated by s external callers to the microservice system are theoretically no different from the load parameters corresponding to the equal number of business calls initiated by one external caller to the microservice system. Therefore, the s external callers can be considered as a whole, that is, the number of calls to the microservice by the s external callers can be summed to determine the external call data. In addition, in actual applications, the number of service interfaces included in a microservice may affect the load parameters when calling the microservice. Therefore, when determining the external call data by counting the number of calls to the service interface, the number of service interfaces included in the microservice can also be comprehensively considered.

[0101] If each of the t microservices includes the same number of service interfaces, in this case, the impact on the load parameters may be the same for different microservices that are called the same number of times. Therefore, in a possible implementation, the service interface can be ignored, and the total number of times each microservice is called by s external callers can be counted in units of microservices to determine the external call data. In specific implementation, the server can count the total number of interface calls of the microservices called by s external callers during the historical service period, and can construct a t*1 external call number matrix as the external call data according to the total number of interface calls corresponding to the t microservices. Among them, the jth matrix element in the external call number matrix can be used to represent the total number of interface calls corresponding to the jth microservice. For the jth microservice, the total number of interface calls can represent how many times the jth microservice has been called by s external callers in total, without distinguishing between service interfaces, thereby simplifying the external call data and reducing the computational complexity.

[0102] If the jth microservice among t microservices can include Ij service interfaces, the number of service interfaces included may be the same or different for different microservices. In practical applications, if the number of service interfaces of two microservices is different, when equal business calls are initiated to the two microservices respectively, the load parameters corresponding to the two microservices may be different. Therefore, in another possible implementation, the service interface can also be distinguished, and the total number of times each service interface in the microservice is called by s external callers is counted in units of the service interface in the microservice to determine the external call data. In specific implementation, the server can count the number of interface calls of s external callers calling Ij service interfaces respectively in the historical service period, and can construct a 1*Ij interface call number matrix corresponding to the jth microservice based on the number of interface calls of Ij service interfaces, wherein the kth matrix element in the interface call number matrix can be used to represent the total number of calls of the kth service interface among Ij service interfaces by s external callers in the historical service period. Based on this, for each service interface in a microservice, the total number of calls to this service interface by s external callers can be counted. In this way, for a microservice, the interface call count matrix can reflect the total number of calls to each service interface in the microservice, and achieve the purpose of distinguishing the number of service interface call counts. Finally, the server can determine the external call data according to the interface call count matrix corresponding to t microservices. Based on this, by distinguishing the number of service interface call counts, the distribution of call counts on the service interface can be reflected in the determined external call data, which is conducive to the initial service prediction model learning the distribution of call counts on the service interface, the relationship between the number of service interfaces and load parameters, and is conducive to improving the prediction accuracy.

[0103] In order to better understand the method of determining external call data by counting the number of calls in this application, the embodiment of this application takes the call data as the number of calls and the unit of the historical service period as minutes as an example, and provides the following example:

[0104] In practical applications, the process of determining external call data can be called the data preprocessing process of historical call data, which can be divided into two sub-stages: historical data extraction sub-stage and historical data preprocessing sub-stage. Specifically:

[0105] In the historical data extraction sub-phase, the number of service interfaces of each microservice in the microservice system can be obtained, and for each microservice, the number of calls of each service interface per minute can be obtained, that is, the call number matrix of the microservice can be obtained. Among them, m can represent the historical service period as the mth minute, q can represent the number of all callers, that is, the q callers can include the aforementioned s external callers and callers within the microservice system (for example, they can be microservices in a microservice system), and Ij can represent the number of service interfaces included in the jth microservice among the t microservices. For ease of understanding, the call count matrix corresponding to the jth microservice can be found in Figure 4 As shown, the call count matrix includes both business calls from external callers and internal business calls. In the call count matrix, the matrix element in the i-th row and k-th column can represent the number of calls made by the i-th caller to the k-th service interface, specifically, the number of calls made by the i-th caller to the k-th service interface among Ij service interfaces within the m-th minute. For example, the matrix element in the 2nd row and 3rd column can represent the number of calls made by the 2nd caller to the 3rd service interface among Ij service interfaces within the m-th minute.

[0106] In order to retain external call data, in the historical data preprocessing sub-stage, all call times from within the microservice system can be removed, that is, the call times of the callers within the microservice system among the q callers are removed, so as to retain the call times of s external callers. At the same time, the call times of these s external callers can be summed up. In this way, the minute-level call times matrix of a single microservice can be simplified to a 1*Ij matrix, that is, the interface call times matrix of the jth microservice is obtained. For details, please refer to Figure 4 In the interface call count matrix, the matrix element in the 1st row and the kth column (i.e., the kth matrix element mentioned above) can be used to represent the total number of calls made by s external callers to the kth service interface, specifically, the total number of calls made by s external callers to the kth service interface among the Ij service interfaces within the mth minute. In practical applications, the interface call count matrix of the jth microservice can be recorded as

[0107] It is understandable that in Figure 4 In this example, the service interface is differentiated. If the above method of not distinguishing the service interface is adopted, the sum can be calculated in the service interface dimension, that is, Figure 4 The 1*Ij interface call count matrix of the example is simplified to a 1*1 matrix ( Figure 4 (not shown in the figure), the only matrix element in the simplified matrix can represent the total number of interface calls made by s external callers to the jth microservice in the mth minute, thereby achieving further simplification and reducing computational complexity.

[0108] It is understandable that in actual applications, in the historical data extraction sub-stage, what may be obtained is the call count matrix corresponding to all microservices included in the microservice system. In this case, the call count matrix corresponding to the t microservices associated with the external call data can be first screened, and then the aforementioned historical data preprocessing sub-stage is executed to simplify the data. Alternatively, the aforementioned historical data preprocessing sub-stage can be directly executed, and after completing the data simplification, the interface call count matrix corresponding to the t microservices can be screened. In one example, the t microservices can be boundary microservices in the microservice system, so screening the t microservices is to screen the boundary microservices, based on which the external call data is obtained.

[0109] Usually, t microservices can be some microservices in a microservice system. In order to realize the overall prediction of the microservice system based on t microservices (such as predicting the load parameters corresponding to each microservice in the microservice system), a holistic external call data can be constructed based on the external call situation of t microservices, and input into the initial service prediction model at one time to realize the overall prediction. In practical applications, the number of service interfaces included in different microservices may be different. In order to facilitate model learning when realizing the overall prediction, the service interface can also be supplemented. For ease of explanation, for this situation, assuming that the jth microservice among t microservices can include Ij service interfaces, and the maximum number of service interfaces included in a single microservice is Ix, then when determining the external call data, the server can determine the external call submatrix corresponding to the jth microservice according to the external call data corresponding to the Ij service interfaces and the size relationship between Ij and Ix, the number of columns of the external call submatrix is ​​Ix, the Ix column matrix elements can include Ij column matrix elements, the kth column matrix elements in the Ij column matrix elements can be used to represent the external call data corresponding to the kth service interface among the Ij service interfaces, if Ij is less than Ix, then the Ix-Ij column matrix elements in the Ix column matrix elements can be used to represent the padding data corresponding to the jth microservice. Based on this, padding is achieved so that each microservice can construct an external call submatrix with the same number of columns. Accordingly, the external call data can be determined based on the external call submatrices corresponding to the t microservices. This allows the external call data in matrix form to be determined based on the external call sub-matrices of t microservices as the overall input, which facilitates model learning, achieves holistic prediction, and ensures prediction accuracy. In practical applications, padding is to facilitate model learning, so the padding process can also be called the process of aligning model input data.

[0110] It should be noted that this application does not impose any limitation on how to complete the method. For ease of understanding, this application embodiment takes the call data as the number of calls as an example, and provides the following method as an example:

[0111] If Ij is less than Ix, it indicates that padding is required, and when padding is performed, padding can be performed from the end. That is, the aforementioned Ij column matrix elements are the first Ij column matrix elements in the Ix column matrix elements, and the aforementioned Ix-Ij column matrix elements are the Ij+1 column matrix elements to the Ix column matrix elements in the Ix column matrix elements. Based on this, it can be intuitively reflected which ones have been padded.

[0112] When padding, in order to balance the impact of padding on the number of calls to different microservices, in a possible implementation, the same data can be used for padding, that is, the padding data corresponding to different microservices is the same. In this way, the deviation caused by using different data to pad different microservices can be avoided, which is conducive to ensuring accuracy. For example, when padding, 0 can be used for padding. At the same time, in order to avoid the impact of 0 values ​​on the model processing process, Laplace smoothing can be further used to increase all data by 1. In this way, the values ​​of the matrix elements in the Ij+1th column to the Ixth column are all 1, that is, the aforementioned padding data are all 1, and the matrix elements in the first Ij columns are increased by 1 based on the actual number of calls. In this way, padding can be achieved, and for each microservice, an external call submatrix with the same number of columns can be constructed.

[0113] For a better understanding, take the example of filling in all data as 1, and combine Figure 4 Take the interface call count matrix of the example as an example, that is, the number of rows in the interface call count matrix of each microservice is 1. Correspondingly, based on the external call submatrix obtained after completion, a t*Ix external call matrix can be constructed as the external call data, where the matrix elements in the jth row and the kth column in the external call matrix can be used to represent the number of external calls corresponding to the kth service interface among the Ij service interfaces or the completed data corresponding to the jth microservice. For example, the t*Ix external call matrix can be found in Figure 5 As shown in the figure, in the external call matrix, each row can represent an external call sub-matrix corresponding to a microservice, and the 1 in the external call matrix can represent the padding data. Figure 5 The external call matrix of the example is used as a training sample. Next, we can enter the model building phase, that is, after completing the alignment of the model input data, we can input the training sample into the initial service prediction model.

[0114] Typically, t microservices may be some microservices in a microservice system (e.g., t microservices may be boundary microservices in a microservice system). In order to better understand the method of implementing overall prediction based on some microservices in the present application, the present application embodiment takes the microservice system including n microservices as an example for explanation:

[0115] Among them, n microservices can include the aforementioned t microservices. In practical applications, the aforementioned Figure 5The external call matrix of t*Ix in the example is used as a training sample and directly input into the initial service prediction model. In order to achieve holistic prediction, the corresponding sample label can be used to identify the historical load parameters corresponding to the n microservices in the historical service period, and the sample load parameter can be used to identify the load parameter prediction results corresponding to the n microservices in the historical service period. Based on this, it is possible to build a model input based on t microservices to achieve holistic prediction of n microservices, which is conducive to reducing computational complexity. For example, the sample label can be an n*1 label matrix, and the i-th matrix element in the label matrix can be used to represent the historical load parameters of the i-th microservice among the n microservices in the historical service period. The sample load parameter can be an n*1 load matrix, and the i-th matrix element in the load matrix can be used to represent the load parameter prediction result corresponding to the i-th microservice in the historical service period.

[0116] Furthermore, the training samples are constructed based on external call data, but the sample labels are constructed based on real historical load parameters. Since the real historical load parameters are the corresponding load parameters when the external call data and internal call data of the historical service period occur simultaneously, even though the internal call data is removed from the data, the model can still learn the impact of internal business calls on the load parameters during the model training process. In other words, removing the internal call data can reduce the computational complexity and will not affect the prediction effect of the model.

[0117] For better understanding, the present embodiment takes the training sample as the aforementioned t*Ix external call matrix (Ix=63) as an example, combined with the aforementioned Figure 3 The initial service prediction model of the example is illustrated as follows for this application:

[0118] For details, please refer to Figure 6 As shown, it should be noted that Figure 6 In the example, the convolutional layer in the initial service prediction model can be set to have two layers, namely Figure 6The first and second convolutional layers in the example. The external call matrix of t*63 can be input into the initial service prediction model. In the actual processing process, the external call matrix can be considered as a multi-channel matrix, and a row in the external call matrix (i.e., the external call submatrix of a microservice) can occupy one channel exclusively. In specific implementation, the first convolutional layer can be used to map the external call matrix of t*63 to obtain an 80*54 feature matrix, that is, to obtain a feature matrix with a fixed number of rows and columns. The 80*54 feature matrix can be used as the input of the second convolutional layer, and the second convolutional layer is used to further map the 80*54 feature matrix to obtain a 120*48 feature matrix, and also obtain a feature matrix with a fixed number of rows and columns. Based on this, the convolutional layer is used to map the input external call matrix to a feature matrix with a fixed number of rows and columns. In this way, it can be compatible with the situation where the number of rows and columns of the input external call matrix is ​​different due to differences in t and Ix, thereby improving versatility.

[0119] In the process of mapping in the convolutional layer, a nonlinear activation function (such as TanH, Relu, etc.) can be used to introduce nonlinear features to the model, so that when the model learns the relationship between the external call matrix and the sample load, it can better learn the nonlinear factors between the two, which is conducive to improving the prediction accuracy. Compared with the linear prediction model determined in the relevant technology (such as the autoregressive moving average model, etc.), this application introduces nonlinear features in the model training process, and the target service prediction model obtained can have better prediction accuracy.

[0120] The 120*48 feature matrix can be used as the input of the Dropout layer. In the Dropout layer, nonlinear activation functions (such as TanH, Relu, etc.) can also be used, and the network neurons in the model can be inactivated with a set probability (for example, setting the probability p=0.35), which is helpful to prevent overfitting. After the Dropout layer is processed, the 700*1 initial prediction result can be output and used as the input of the fully connected layer, and the Sigmoid function can be used as the activation function to map the initial prediction result value to [0, 1], and output the final n*1 sample load parameter, that is, the load parameter prediction result corresponding to each microservice in the historical service period is obtained.

[0121] In practical applications, the initial service prediction model can be adjusted based on the difference between the output n*1 sample load parameters and the n*1 sample labels to obtain the target service prediction model, so as to provide convenient and accurate prediction services when service predictions are required for the predicted service period in the future.

[0122] In order to ensure that the target service prediction model has good prediction accuracy when used in the application stage, in the model training stage, in addition to constructing training samples for model training, test samples can also be constructed. The target service prediction model obtained by model training based on the training samples can be tested using test samples. If the prediction accuracy on the test samples is high, the model training can be terminated. Otherwise, iterative optimization can be performed to perform the next round of model training until a target service prediction model with the expected prediction accuracy is obtained. In practical applications, before the next round of model training, the parameters of each layer in the model can be adjusted (such as the number of adjustments), and then the next round of model training can be performed in order to select the model with the best prediction effect.

[0123] For better understanding, in the embodiment of the present application, taking the CPU usage rate as the load parameter as an example, for a microservice system with 21 microservices (i.e., n=21) related to the payment speaker, the historical call data of the past 7 days was extracted, wherein the training samples were constructed using the historical call data of the first 6 days, and the test samples were constructed using the historical call data of the 7th day. For example, a total of 1440 test samples were constructed (each test sample was at the minute level). Using 1440 test samples, the aforementioned target service prediction model can be tested, and the test results can be seen in Table 1:

[0124] Table 1. Test results

[0125]

[0126]

[0127] It should be noted that in Table 1, e is used to represent scientific notation. As can be seen from Table 1, for the test samples that were not seen in the model training process, the average prediction error of the CPU usage of the 21 microservices on the 7th day was below 0.01, that is, the average prediction error of the 1440 minute-level CPU usage corresponding to each microservice was below 1%. The largest error occurred in the 16th microservice system, reaching 0.082, that is, the predicted CPU usage of a certain minute differed from the actual CPU usage by 8.2%. However, under the premise of a small overall error, this individual outlier is still within the tolerance range. It can be seen that, overall, the target service prediction model has good prediction accuracy and can provide relatively accurate and reliable prediction services in practical applications.

[0128] It should be noted that, based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods.

[0129] based on Figure 2Corresponding to the service prediction model determination method provided in the embodiment, the embodiment of the present application also provides a service prediction model determination device 700, wherein the service prediction model determination device 700 includes an acquisition unit 701, a division unit 702, an output unit 703, and an adjustment unit 704:

[0130] The acquisition unit 701 is used to acquire the historical call data corresponding to the microservice system in the historical service period;

[0131] The division unit 702 is used to divide the historical call data into internal call data and external call data, wherein the internal call data is used to identify the service calls within the microservice system during the historical service period, and the external call data is used to identify the service calls made by the external system to the microservice system during the historical service period;

[0132] The output unit 703 is used to input the training samples constructed based on the external call data into the initial service prediction model, and output the sample load parameters corresponding to the microservice system in the historical service period through the initial service prediction model;

[0133] The adjusting unit 704 is used to adjust the initial service prediction model based on the difference between the sample load parameter and the sample label of the training sample to obtain a target service prediction model, wherein the sample label is used to identify the historical load parameter corresponding to the microservice system in the historical service period;

[0134] The output unit 703 is also used to output the predicted load parameters corresponding to the microservice system in the predicted service period through the target service prediction model when a service prediction request is received, based on the external call prediction data in the service prediction request, and the external call prediction data is used to identify the business call of the external system to the microservice system in the predicted service period.

[0135] In a possible implementation manner, the dividing unit is further configured to:

[0136] Based on the external call relationship corresponding to the microservice system in the historical service period, the external call data is filtered from the historical call data, and the call data other than the external call data in the historical call data is determined as the internal call data, wherein the external call relationship is used to identify the call relationship corresponding to the business call initiated by the external system to the microservice system in the historical service period.

[0137] In a possible implementation, the microservice system includes boundary microservices and non-boundary microservices, the external system is used to initiate a service call to the microservice system by calling the boundary microservice, the boundary microservice is used to call the non-boundary microservice to perform a service response to the service call initiated by the external system, and the acquisition unit is further used to:

[0138] The external call relationship is determined according to the call relationship of the boundary class microservice being called by the external system during the historical service period.

[0139] In a possible implementation, the historical call data is the number of historical calls.

[0140] In a possible implementation, the external system includes s external callers, the external call data is related to t microservices included in the microservice system, and each of the t microservices includes the same number of service interfaces, and the acquisition unit is further used to:

[0141] Count the total number of times the s external callers call the interface of the microservice during the historical service period;

[0142] According to the total number of interface calls corresponding to the t microservices, a t*1 external call number matrix is ​​constructed as the external call data, and the j-th matrix element in the external call number matrix is ​​used to represent the total number of interface calls corresponding to the j-th microservice.

[0143] In a possible implementation, the external system includes s external callers, the external call data is related to t microservices included in the microservice system, and the j-th microservice among the t microservices includes 1j service interfaces, and the acquisition unit is further used to:

[0144] Counting the number of times the s external callers respectively call the 1j service interfaces during the historical service period;

[0145] Based on the interface call times of the Ij service interfaces, a 1*Ij interface call times matrix corresponding to the j-th microservice is constructed, wherein the k-th matrix element in the interface call times matrix is ​​used to represent the total number of times the s external callers call the k-th service interface among the Ij service interfaces in the historical service period;

[0146] The external call data is determined according to the interface call number matrices corresponding to the t microservices.

[0147] In a possible implementation, the external call data is related to t microservices included in the microservice system, and the j-th microservice among the t microservices includes Ij service interfaces, and the maximum number of service interfaces included in a single microservice is Ix, and the acquisition unit is further used to:

[0148] According to the external call data corresponding to the Ij service interfaces and the size relationship between Ij and Ix, the external call sub-matrix corresponding to the j-th microservice is determined, the number of columns of the external call sub-matrix is ​​Ix, the Ix column matrix elements include Ij column matrix elements, the k-th column matrix elements in the Ij column matrix elements are used to represent the external call data corresponding to the k-th service interface in the Ij service interfaces, if Ij is less than Ix, the Ix-Ij column matrix elements in the Ix column matrix elements are used to represent the complementary data corresponding to the j-th microservice;

[0149] The external call data is determined based on the external call sub-matrices corresponding to the t microservices respectively.

[0150] In a possible implementation, the completion data corresponding to different microservices are the same.

[0151] In one possible implementation, the microservice system includes n microservices, the n microservices include t microservices, the sample labels are used to identify the historical load parameters corresponding to the n microservices in the historical service period, and the sample load parameters are used to identify the load parameter prediction results corresponding to the n microservices in the historical service period.

[0152] In a possible implementation, the external call prediction data is determined by the external system based on a pre-service call, where the pre-service call is a service call that the external system is expected to initiate to the microservice system during the predicted service period.

[0153] It can be seen from the above technical solution that the historical call data corresponding to the microservice system in the historical service period is divided into internal call data and external call data, and the external call data is used to construct training samples for model training. Among them, the internal call data can be used to identify the business calls within the microservice system in the historical service period, and the external call data can be used to identify the business calls of the external system to the microservice system in the historical service period. Since the internal business logic and call relationship are relatively stable, that is, the internal call data is relatively stable, and the impact on the load parameters is relatively fixed, and the business logic and call relationship of the external call will change greatly due to different call requirements of the external system, that is, the external call data changes greatly, making the impact of the external call data on the load parameters more dynamic, so using external call data to construct training samples can achieve data simplification and reduce the computational complexity in the model training process, and the internal call data with a relatively fixed impact on the load parameters is not used, which is conducive to ensuring the accuracy of prediction while achieving data simplification. And, since the load parameters of any period are most related to the external call data of the period, it is beneficial to ensure the accuracy of prediction by predicting the load parameters corresponding to the period based on the external call data of a certain period. After obtaining the target service prediction model, when receiving a service prediction request, the prediction load parameters corresponding to the microservice system in the prediction service period can be output through the target service prediction model according to the external call prediction data in the service prediction request to achieve prediction. The external call prediction data can be used to identify the business calls of the external system to the microservice system in the prediction service period. It can be seen that the prediction data of the internal call is not used in the model application stage, which reduces the computational complexity of the model application process.

[0154] The embodiment of the present application further provides a computer device, which may be a terminal. For example, the terminal is a smart phone:

[0155] Figure 8 The block diagram shows a partial structure of a smart phone provided in an embodiment of the present application. Figure 8 The smartphone includes: a radio frequency (RF) circuit 810, a memory 820, an input unit 830, a display unit 840, a sensor 850, an audio circuit 860, a wireless fidelity (WiFi) module 870, a processor 880, and a power supply 890. The input unit 830 may include a touch panel 831 and other input devices 832, the display unit 840 may include a display panel 841, and the audio circuit 860 may include a speaker 861 and a microphone 862. Those skilled in the art will appreciate that Figure 8The structure of the smartphone shown in the figure does not constitute a limitation of the smartphone, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0156] The memory 820 can be used to store software programs and modules. The processor 880 executes various functional applications and data processing of the smartphone by running the software programs and modules stored in the memory 820. The memory 820 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area may store data created according to the use of the smartphone (such as audio data, a phone book, etc.), etc. In addition, the memory 820 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0157] The processor 880 is the control center of the smartphone, which uses various interfaces and lines to connect various parts of the entire smartphone, and executes various functions of the smartphone and processes data by running or executing software programs and / or modules stored in the memory 820, and calling data stored in the memory 820. Optionally, the processor 880 may include one or more processing units; preferably, the processor 880 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 880.

[0158] In this embodiment, the steps performed by the processor 880 in the smartphone may be based on Figure 8 The structure shown is implemented.

[0159] The computer device provided in the embodiment of the present application may also be a server. Fig. 9 As shown, Fig. 9The structural diagram of the server 900 provided in the embodiment of the present application, the server 900 may have relatively large differences due to different configurations or performances, and may include one or more processors, such as a central processing unit (CPU) 922, and a memory 932, one or more storage media 930 (such as one or more mass storage devices) storing application programs 942 or data 944. Among them, the memory 932 and the storage medium 930 can be short-term storage or permanent storage. The program stored in the storage medium 930 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the server. Furthermore, the central processing unit 922 can be configured to communicate with the storage medium 930 and execute a series of instruction operations in the storage medium 930 on the server 900.

[0160] The server 900 may also include one or more power supplies 926, one or more wired or wireless network interfaces 950, one or more input and output interfaces 958, and / or one or more operating systems 941, such as Windows Server 2000. TM , Mac OS X TM , Unix TM ,Linux TM , FreeBSD TM etc.

[0161] In this embodiment, the central processor 922 in the server 900 may perform the following steps:

[0162] Obtain the historical call data of the microservice system corresponding to the historical service period;

[0163] Divide the historical call data into internal call data and external call data, wherein the internal call data is used to identify the service calls within the microservice system during the historical service period, and the external call data is used to identify the service calls made by the external system to the microservice system during the historical service period;

[0164] Inputting the training samples constructed based on the external call data into the initial service prediction model, and outputting the sample load parameters corresponding to the microservice system in the historical service period through the initial service prediction model;

[0165] Based on the difference between the sample load parameter and the sample label of the training sample, the initial service prediction model is adjusted to obtain a target service prediction model, wherein the sample label is used to identify the historical load parameter of the microservice system corresponding to the historical service period;

[0166] When a service prediction request is received, the predicted load parameters corresponding to the microservice system in the predicted service period are output through the target service prediction model based on the external call prediction data in the service prediction request, and the external call prediction data is used to identify the business call of the external system to the microservice system in the predicted service period.

[0167] According to one aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium is used to store a computer program. When the computer program is executed by a computer device, the computer device executes the service prediction model determination method described in the aforementioned embodiments.

[0168] According to one aspect of the present application, a computer program product is provided, the computer program product comprising a computer program, the computer program being stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, so that the computer device executes the method provided in various optional implementations of the above-mentioned embodiments.

[0169] The descriptions of the processes or structures corresponding to the above-mentioned figures have different emphases. For parts that are not described in detail in a certain process or structure, please refer to the relevant descriptions of other processes or structures.

[0170] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein, for example. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0171] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0172] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0173] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0174] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the relevant technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

[0175] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, ordinary technical members in the art should understand that they can still modify the technical solutions recorded in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for determining a service prediction model, It is characterized in that The method comprises: Obtain the historical call data of the microservice system corresponding to the historical service period; Divide the historical call data into internal call data and external call data, wherein the internal call data is used to identify the service calls within the microservice system during the historical service period, and the external call data is used to identify the service calls made by the external system to the microservice system during the historical service period; Inputting the training samples constructed based on the external call data into the initial service prediction model, and outputting the sample load parameters corresponding to the microservice system in the historical service period through the initial service prediction model; Based on the difference between the sample load parameter and the sample label of the training sample, the initial service prediction model is adjusted to obtain a target service prediction model, wherein the sample label is used to identify the historical load parameter of the microservice system corresponding to the historical service period; When a service prediction request is received, the predicted load parameters corresponding to the microservice system in the predicted service period are output through the target service prediction model based on the external call prediction data in the service prediction request, and the external call prediction data is used to identify the business call of the external system to the microservice system in the predicted service period.

2. The method according to claim 1, It is characterized in that The dividing the historical call data into internal call data and external call data includes: Based on the external call relationship corresponding to the microservice system in the historical service period, the external call data is filtered from the historical call data, and the call data other than the external call data in the historical call data is determined as the internal call data, wherein the external call relationship is used to identify the call relationship corresponding to the business call initiated by the external system to the microservice system in the historical service period.

3. The method according to claim 2, It is characterized in that The microservice system includes boundary microservices and non-boundary microservices, the external system is used to initiate a service call to the microservice system by calling the boundary microservice, and the boundary microservice is used to call the non-boundary microservice to perform a service response to the service call initiated by the external system, and the method further includes: The external call relationship is determined according to the call relationship of the boundary class microservice being called by the external system during the historical service period.

4. The method according to claim 1, It is characterized in that The historical call data is the number of historical calls.

5. The method according to claim 4, It is characterized in that The external system includes s external callers, the external call data is related to t microservices included in the microservice system, and each of the t microservices includes the same number of service interfaces, and the external call data is determined in the following manner: Count the total number of times the s external callers call the interface of the microservice during the historical service period; According to the total number of interface calls corresponding to the t microservices, a t*1 external call number matrix is ​​constructed as the external call data, and the j-th matrix element in the external call number matrix is ​​used to represent the total number of interface calls corresponding to the j-th microservice.

6. The method according to claim 4, It is characterized in that The external system includes s external callers, the external call data is related to t microservices included in the microservice system, and the j-th microservice among the t microservices includes 1j service interfaces, and the external call data is determined in the following manner: Counting the number of times the s external callers respectively call the 1j service interfaces during the historical service period; Based on the interface call times of the Ij service interfaces, a 1*Ij interface call times matrix corresponding to the j-th microservice is constructed, wherein the k-th matrix element in the interface call times matrix is ​​used to represent the total number of times the s external callers call the k-th service interface among the Ij service interfaces in the historical service period; The external call data is determined according to the interface call count matrices corresponding to the t microservices.

7. The method according to claim 1, It is characterized in that The external call data is related to the t microservices included in the microservice system, and the j-th microservice among the t microservices includes Ij service interfaces, and the maximum number of service interfaces included in a single microservice is Ix. The external call data is determined in the following manner: According to the external call data corresponding to the Ij service interfaces and the size relationship between Ij and Ix, the external call submatrix corresponding to the j-th microservice is determined, the number of columns of the external call submatrix is ​​Ix, the Ix column matrix elements include Ij column matrix elements, the k-th column matrix elements in the Ij column matrix elements are used to represent the external call data corresponding to the k-th service interface in the Ij service interfaces, if Ij is less than Ix, the Ix-Ij column matrix elements in the Ix column matrix elements are used to represent the complementary data corresponding to the j-th microservice; The external call data is determined based on the external call sub-matrices corresponding to the t microservices respectively.

8. The method according to claim 7, It is characterized in that The complementary data corresponding to different microservices are the same.

9. The method according to claim 7, It is characterized in that The microservice system includes n microservices, the n microservices include t microservices, the sample labels are used to identify historical load parameters corresponding to the n microservices in the historical service period, and the sample load parameters are used to identify load parameter prediction results corresponding to the n microservices in the historical service period.

10. The method according to any one of claims 1 to 9, It is characterized in that The external call prediction data is determined by the external system based on a pre-service call, where the pre-service call is a service call that the external system is expected to initiate to the microservice system during the predicted service period.

11. A device for determining a service prediction model, It is characterized in that The device comprises an acquisition unit, a division unit, an output unit and an adjustment unit: The acquisition unit is used to acquire historical call data corresponding to the microservice system in the historical service period; The division unit is used to divide the historical call data into internal call data and external call data, wherein the internal call data is used to identify the service calls within the microservice system during the historical service period, and the external call data is used to identify the service calls made by the external system to the microservice system during the historical service period; The output unit is used to input the training samples constructed based on the external call data into the initial service prediction model, and output the sample load parameters corresponding to the microservice system in the historical service period through the initial service prediction model; The adjustment unit is used to adjust the initial service prediction model based on the difference between the sample load parameter and the sample label of the training sample to obtain a target service prediction model, wherein the sample label is used to identify the historical load parameter corresponding to the microservice system in the historical service period; The output unit is also used to output the predicted load parameters corresponding to the microservice system in the predicted service period through the target service prediction model when a service prediction request is received, based on the external call prediction data in the service prediction request, and the external call prediction data is used to identify the business call of the external system to the microservice system in the predicted service period.

12. A computer device, It is characterized in that The computer device comprises a processor and a memory: The memory is used to store a computer program and transmit the computer program to the processor; The processor is configured to execute the method according to any one of claims 1 to 10 according to the instructions in the computer program.

13. A computer-readable storage medium, It is characterized in that The computer-readable storage medium is used to store a computer program, and when the computer program is executed by a computer device, the computer device executes the method according to any one of claims 1 to 10.

14. A computer program product comprising a computer program, It is characterized in that When the method is executed on a computer device, the computer device is enabled to execute the method according to any one of claims 1 to 10.

Images